From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 02:44:19 2008 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 ADCAE106564A for ; Sun, 20 Jul 2008 02:44:19 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57010.mail.re3.yahoo.com (web57010.mail.re3.yahoo.com [66.196.97.114]) by mx1.freebsd.org (Postfix) with SMTP id 57A398FC12 for ; Sun, 20 Jul 2008 02:44:19 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 93554 invoked by uid 60001); 20 Jul 2008 02:44:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=4K0VnFBZK62gCw+gPTqbZqCQ9hB4+2pPav7rJYeKON7o+fD4C3znug925/wcdQvH/LAvigtlO3Hg9ZrxgAelOhvE7TPG7AeHrIW8cSIbvc408KUBbK9265Brgs7m/Uy7IW4EP88SuAeV2wcDO00aBH+IlWVNNaDUPoSPZK1pXbE=; Received: from [220.255.7.244] by web57010.mail.re3.yahoo.com via HTTP; Sat, 19 Jul 2008 19:44:18 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Sat, 19 Jul 2008 19:44:18 -0700 (PDT) From: Unga To: Dan Nelson In-Reply-To: <20080719213056.GE19044@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <545719.90429.qm@web57010.mail.re3.yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: Pseudoterminals increase: compilation error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 02:44:19 -0000 --- On Sun, 7/20/08, Dan Nelson wrote: > Expect's error message doesn't say anything except > "something isn't > working but I won't tell you what". Run > > truss -o truss.log -f expect -c "spawn ls" > > and determine which syscall is failing, with what error > number, just > before expect prints its "no more ptys" message. > That will tell you > whether it's a permissions issue, or something else. > If there are no > obvious errors, post a part of the log. > > Also, what version of expect are you running? Versions > between > 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile that > limited the > number of ptys expect could see. See > http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 . > Here are more detail. In fact, I noted it through strace after my previous email. ls -l /dev/ | grep pty crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1 truss -o truss.log -f expect -c "spawn ls" 1178: open("/dev/ptyp0",O_RDWR,027757763030) ERR#5 'Input/output error' 1178: open("/dev/ptyp1",O_RDWR,027757763030) ERR#5 'Input/output error' 1178: open("/dev/ptyp2",O_RDWR,027757763030) = 5 (0x5) 1178: fstat(5,{mode=crw-rw-rw- ,inode=178,size=0,blksize=4096}) = 0 (0x0) : : 1178: chown("/dev/ttyp2",1002,4) ERR#1 'Operation not permitted' 1178: close(5) = 0 (0x0) 1178: close(-1) ERR#9 'Bad file descriptor' 1178: close(-1) ERR#9 'Bad file descriptor' 1178: open("/",O_RDONLY,027757764430) = 5 (0x5) 1178: close(5) = 0 (0x0) 1178: write(2,"The system has no more ptys. As"...,106) = 106 (0x6a) 1178: write(2,"\r\n",2) = 1179 (0x49b) = 2 (0x2) ls -l /dev/ | grep pty crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1 crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2 I'm using Expect-5.43.0 compiled from sources. So, it looks like some sort of a misconfiguration. Still investigating. Regards Unga From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 02:50:40 2008 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 B4C18106566B for ; Sun, 20 Jul 2008 02:50:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 424CB8FC0C for ; Sun, 20 Jul 2008 02:50:39 +0000 (UTC) (envelope-from brett@lariat.net) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id UAA17164 for stable@freebsd.org; Sat, 19 Jul 2008 20:30:57 -0600 (MDT) Date: Sat, 19 Jul 2008 20:30:57 -0600 (MDT) From: Brett Glass Message-Id: <200807200230.UAA17164@lariat.net> To: stable@freebsd.org Cc: Subject: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 02:50:40 -0000 Everyone: Will FreeBSD 7.1 be released in time to use it as an upgrade to close the BIND cache poisoning hole? We'd like to upgrade affected servers to the latest FreeBSD at the same time that we upgrade BIND if possible. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 03:02:35 2008 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 DD08C106564A for ; Sun, 20 Jul 2008 03:02:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 85F588FC15 for ; Sun, 20 Jul 2008 03:02:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 37B2D28448 for ; Sun, 20 Jul 2008 11:02:34 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C0990EB90F8; Sun, 20 Jul 2008 11:02:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id eFR1bd3EAbju; Sun, 20 Jul 2008 11:02:28 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id CB277EB093E; Sun, 20 Jul 2008 11:02:27 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hRS3BkLW9+n/w0BTVC8bIar0Czk73jFXtM3Nlnc7PiXnT+0LIFUppunFr2hxMEIn+ BjTYiSSkmoHFi9+/wYFNQ== Message-ID: <4882AAC1.6010501@delphij.net> Date: Sat, 19 Jul 2008 20:02:25 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Brett Glass References: <200807200230.UAA17164@lariat.net> In-Reply-To: <200807200230.UAA17164@lariat.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 03:02:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brett Glass wrote: | Everyone: | | Will FreeBSD 7.1 be released in time to use it as an upgrade to | close the BIND cache poisoning hole? We'd like to upgrade affected | servers to the latest FreeBSD at the same time that we upgrade | BIND if possible. Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already patched and not vulnerable to the problem. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiCqsEACgkQi+vbBBjt66CnfQCfRazbYaZYS/u9oqV2FV6MdP7U 7OsAni83DoLYN6fkUVCZig0YZbSFTLuW =OMOy -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 03:21:15 2008 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 252D1106566B for ; Sun, 20 Jul 2008 03:21:15 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id ABC578FC13 for ; Sun, 20 Jul 2008 03:21:14 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id VAA17553; Sat, 19 Jul 2008 21:21:00 -0600 (MDT) Message-Id: <200807200321.VAA17553@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 19 Jul 2008 21:20:55 -0600 To: d@delphij.net From: Brett Glass In-Reply-To: <4882AAC1.6010501@delphij.net> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 03:21:15 -0000 I'd like to install a fully tested 7.1-RELEASE, rather than a snapshot of 7-STABLE (in which there have, apparently, been some problems due to driver updates and work on the TCP stack). Alas, I haven't seen any schedule or "to do" list for the release process yet -- just a note saying that 7.1-RELEASE is scheduled for August. I'm sure that a lot of folks are in the same boat as I: they'd like to start with a complete release that doesn't need patching and recompiling. --Brett Glass At 09:02 PM 7/19/2008, Xin LI wrote: >Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already >patched and not vulnerable to the problem. > >Cheers, >- -- >Xin LI http://www.delphij.net/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 03:36:57 2008 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 5E1D9106566C for ; Sun, 20 Jul 2008 03:36:57 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 079D98FC1A for ; Sun, 20 Jul 2008 03:36:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id VAA17727; Sat, 19 Jul 2008 21:36:43 -0600 (MDT) Message-Id: <200807200336.VAA17727@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 19 Jul 2008 21:36:38 -0600 To: Subhro From: Brett Glass In-Reply-To: References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stable@freebsd.org, d@delphij.net Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 03:36:57 -0000 At 09:28 PM 7/19/2008, Subhro wrote: >You need to understand the release engineering process of FreeeBSD. I've been watching it (and testing release candidates) since 2.x, so I think I may possibly have some understanding of it by now. ;-) >The release edition is essential created from the stabe edition. 7.1R >would not be something new which is *not* present on 7-STABLE today. Mostly true. But the new release would undergo extensive testing, and changes which were "not ready for prime time" would be rolled back or made solid. I've had enough trouble with some recent snapshots of -STABLE that I'd rather install a release that's been thoroughly tested... preferably with the latest ports. That's why I'm asking about the likely actual release date of 7.1. --Brett From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 03:40:03 2008 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 8CBF2106567B for ; Sun, 20 Jul 2008 03:40:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 341A98FC1C for ; Sun, 20 Jul 2008 03:40:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 3BFD72844E for ; Sun, 20 Jul 2008 11:40:02 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A6922EB91FD; Sun, 20 Jul 2008 11:40:01 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id LvHYM-bEbMZq; Sun, 20 Jul 2008 11:39:56 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 97439EB91B0; Sun, 20 Jul 2008 11:39:55 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=AURxuelcfCFwpRKMN/WKcr8DLNswO6EMeY9Bg5aqC0zr8QVB5QZ6ChxyUM4U3iST4 FqBQCkW0wEowwq9/1318w== Message-ID: <4882B389.7050806@delphij.net> Date: Sat, 19 Jul 2008 20:39:53 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Brett Glass References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> In-Reply-To: <200807200321.VAA17553@lariat.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, d@delphij.net Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 03:40:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brett Glass wrote: | I'd like to install a fully tested 7.1-RELEASE, rather than | a snapshot of 7-STABLE (in which there have, apparently, been | some problems due to driver updates and work on the TCP stack). If you presently installed FreeBSD 7.0-RELEASE, you can use the new binary update approach -- freebsd-update to patch it, which contains only security/stability fixes. Another way is to upgrade to RELENG_7_0, which will give you 7.0-RELEASE-p3 at this moment, it's the same as binary upgrade approach but useful if you did some customization in compiling. | Alas, I haven't seen any schedule or "to do" list for the release | process yet -- just a note saying that 7.1-RELEASE is scheduled | for August. | | I'm sure that a lot of folks are in the same boat as I: they'd | like to start with a complete release that doesn't need patching | and recompiling. | | --Brett Glass | | At 09:02 PM 7/19/2008, Xin LI wrote: | |> Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already |> patched and not vulnerable to the problem. |> |> Cheers, |> - -- |> Xin LI http://www.delphij.net/ | | _______________________________________________ | 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" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiCs4kACgkQi+vbBBjt66CJ+gCgrJzqiUGVgELB6wcEl/lDJCKa N6sAnRYNl25Lxdd/YNuT/H9vSIN+DRAf =sjpM -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 03:44:13 2008 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 B86221065675 for ; Sun, 20 Jul 2008 03:44:13 +0000 (UTC) (envelope-from subhro.kar@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.226]) by mx1.freebsd.org (Postfix) with ESMTP id 701C08FC14 for ; Sun, 20 Jul 2008 03:44:13 +0000 (UTC) (envelope-from subhro.kar@gmail.com) Received: by qb-out-0506.google.com with SMTP id a16so2659440qbd.35 for ; Sat, 19 Jul 2008 20:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pVG8lkHOn5YIs0gVQUvEnOui9ziAa7OjMp6hou0QCaI=; b=cketvd1yJowFXzrF6aaSRxLEk3O+ll0bBGMyVW/8X8vmiCm9LeSGwZ9tu+dI6bnwKG 46Uy0sj5c+QfX1xFqlzwOmWvp6jAiNsb70+kACHrvGM4XH2R96KTqMTv89RizsBr9iBO vXY09gPhoIt7e/C3f69rAKcebx85nc+bBo4KE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MRg8ZKHqUjc3N5t2SfPy3s83/edLZ2t+V50W7xurISp9erix5W8FaO0s1FOFrbfKtY oUyYeZK63uaHZrZyU/CF/xMY1VSptOTcUiPX40MhfjmiXGSIMGC7UY2zp45YRDVOSG3G d0rD3D5VdKEPdmDv9Dse22NGVeiYUDZ+rUIzU= Received: by 10.115.48.12 with SMTP id a12mr1596967wak.38.1216524489511; Sat, 19 Jul 2008 20:28:09 -0700 (PDT) Received: by 10.114.15.4 with HTTP; Sat, 19 Jul 2008 20:28:09 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 08:58:09 +0530 From: Subhro To: "Brett Glass" In-Reply-To: <200807200321.VAA17553@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> Cc: stable@freebsd.org, d@delphij.net Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 03:44:13 -0000 Brett, You need to understand the release engineering process of FreeeBSD. The release edition is essential created from the stabe edition. 7.1R would not be something new which is *not* present on 7-STABLE today. In addition, while a particular branch is alive (not declared as end of life) all security updates are backported. The fix which you are looking for is also present on 7.0-R so you may well install that. Thanks Subhro On Sun, Jul 20, 2008 at 8:50 AM, Brett Glass wrote: > I'd like to install a fully tested 7.1-RELEASE, rather than > a snapshot of 7-STABLE (in which there have, apparently, been > some problems due to driver updates and work on the TCP stack). > > Alas, I haven't seen any schedule or "to do" list for the release > process yet -- just a note saying that 7.1-RELEASE is scheduled > for August. > > I'm sure that a lot of folks are in the same boat as I: they'd > like to start with a complete release that doesn't need patching > and recompiling. > > --Brett Glass > > At 09:02 PM 7/19/2008, Xin LI wrote: > >>Yes. FreeBSD 7-STABLE and RELENG_7_0 errata branches are already >>patched and not vulnerable to the problem. >> >>Cheers, >>- -- >>Xin LI http://www.delphij.net/ > > _______________________________________________ > 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" > -- Subhro Kar Software Engineer Dynamic Digital Technologies Pvt. Ltd. EPY-3, Sector: V Salt Lake City 700091 India From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 04:40:35 2008 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 2508C1065672 for ; Sun, 20 Jul 2008 04:40:35 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id D96558FC0A for ; Sun, 20 Jul 2008 04:40:34 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 16A642218A25; Sun, 20 Jul 2008 14:22:49 +1000 (EST) X-Viruscan-Id: <4882BD9800004F6ABC234C@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id B0BC321B42E9; Sun, 20 Jul 2008 14:22:48 +1000 (EST) Received: from k7.mavetju (ppp121-44-34-200.lns10.syd7.internode.on.net [121.44.34.200]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 35BD0221881D; Sun, 20 Jul 2008 14:22:48 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 36BE2567; Sun, 20 Jul 2008 14:22:09 +1000 (EST) Date: Sun, 20 Jul 2008 14:22:09 +1000 From: Edwin Groothuis To: Brett Glass Message-ID: <20080720042209.GA3928@k7.mavetju> References: <200807200230.UAA17164@lariat.net> <4882AAC1.6010501@delphij.net> <200807200321.VAA17553@lariat.net> <200807200336.VAA17727@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807200336.VAA17727@lariat.net> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 04:40:35 -0000 On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote: > At 09:28 PM 7/19/2008, Subhro wrote: > > >You need to understand the release engineering process of FreeeBSD. > > I've been watching it (and testing release candidates) since 2.x, so > I think I may possibly have some understanding of it by now. ;-) > > >The release edition is essential created from the stabe edition. 7.1R > >would not be something new which is *not* present on 7-STABLE today. > > Mostly true. But the new release would undergo extensive testing, and > changes which were "not ready for prime time" would be rolled back or > made solid. I've had enough trouble with some recent snapshots of > -STABLE that I'd rather install a release that's been thoroughly > tested... preferably with the latest ports. That's why I'm asking > about the likely actual release date of 7.1. The best thing a looking glass can come up with is: http://www.freebsd.org/releng/#schedule But that unless an announcement that as much worth as the lifetime of the electrons hitting the back of your eyes. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 05:19:50 2008 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 90E041065678 for ; Sun, 20 Jul 2008 05:19:50 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57008.mail.re3.yahoo.com (web57008.mail.re3.yahoo.com [66.196.97.112]) by mx1.freebsd.org (Postfix) with SMTP id 55C188FC0A for ; Sun, 20 Jul 2008 05:19:50 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 40295 invoked by uid 60001); 20 Jul 2008 05:19:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=MWNYgPUycLWXANHFC5aB2TB00lLh/iL9v51ZvF0bBmiDfVt1BQexGZ0sCZe4ketXsfCfCuTgicbLe2NpTntVC6WzZxFeX9I9Htp1vGt1k+0oI0//Lv0Irjb4jMBgq2FSxONGh/z9X0wAFZxfKRoPkBqrq5MWPjRafxdvJswWj00=; Received: from [220.255.7.205] by web57008.mail.re3.yahoo.com via HTTP; Sat, 19 Jul 2008 22:19:49 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Sat, 19 Jul 2008 22:19:49 -0700 (PDT) From: Unga To: freebsd-stable@freebsd.org In-Reply-To: <545719.90429.qm@web57010.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <451954.40252.qm@web57008.mail.re3.yahoo.com> Cc: gavin@FreeBSD.org, dnelson@allantgroup.com Subject: Re: Pseudoterminals increase: compilation error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 05:19:50 -0000 --- On Sun, 7/20/08, Unga wrote: > From: Unga > Subject: Re: Pseudoterminals increase: compilation error > To: "Dan Nelson" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 10:44 AM > --- On Sun, 7/20/08, Dan Nelson > wrote: > > > Expect's error message doesn't say anything > except > > "something isn't > > working but I won't tell you what". Run > > > > truss -o truss.log -f expect -c "spawn ls" > > > > and determine which syscall is failing, with what > error > > number, just > > before expect prints its "no more ptys" > message. > > That will tell you > > whether it's a permissions issue, or something > else. > > If there are no > > obvious errors, post a part of the log. > > > > Also, what version of expect are you running? > Versions > > between > > 5.38.0_1 and 5.43.0_2 had a bug in the port Makefile > that > > limited the > > number of ptys expect could see. See > > http://www.freebsd.org/cgi/query-pr.cgi?pr=108311 . > > > > Here are more detail. In fact, I noted it through strace > after my previous email. > > ls -l /dev/ | grep pty > crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 > crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:22 ptyp1 > > truss -o truss.log -f expect -c "spawn ls" > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > : > : > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > 1178: close(5) = 0 (0x0) > 1178: close(-1) ERR#9 > 'Bad file descriptor' > 1178: close(-1) ERR#9 > 'Bad file descriptor' > 1178: open("/",O_RDONLY,027757764430) > = 5 (0x5) > 1178: close(5) = 0 (0x0) > 1178: write(2,"The system has no more ptys. > As"...,106) = 106 (0x6a) > 1178: write(2,"\r\n",2) > = 1179 (0x49b) > = 2 (0x2) > > ls -l /dev/ | grep pty > crw-rw-rw- 1 root wheel 0, 169 Jul 20 10:11 ptyp0 > crw-rw-rw- 1 root wheel 0, 171 Jul 20 10:23 ptyp1 > crw-rw-rw- 1 root wheel 0, 178 Jul 20 10:11 ptyp2 > > I'm using Expect-5.43.0 compiled from sources. > > So, it looks like some sort of a misconfiguration. Still > investigating. > Here is a more narrow down. This problem is happening inside a chroot jail but only as a normal user: Here is what it create for following command: expect -c "spawn ls" On FreeBSD ========== crw--w---- 1 test tty 0, 181 Jul 20 10:11 ttyp3 On chroot ========= crw-rw-rw- 1 root wheel 0, 181 Jul 20 10:11 ttyp3 For some reason devfs creates ttys differently. "devfs rule showsets" shows same for both /dev and /path/dev. Its just 1, 2, 3, 4. I tried to add a new ruleset as follows (inside chroot jail): devfs ruleset 10 devfs rule add path tty* type tty mode 660 group tty devfs rule applyset Now devfs creates ttys as follows: crw-rw---- 1 root tty 0, 179 Jul 20 13:08 ttyp2 So, now the question is how to get the devfs to create ttys owned by the requested user? or can it be something else? As for Gavin's suggestion to upgrade to Expect-5.43.0_2, actually, there is no such version on http://expect.nist.gov/, latest is still Expect-5.43.0. Regards Unga From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 10:37:15 2008 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 8FB441065711 for ; Sun, 20 Jul 2008 10:37:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 20CFF8FC13 for ; Sun, 20 Jul 2008 10:37:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m6KAbCf8008714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 20:37:13 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m6KAbCnT082814; Sun, 20 Jul 2008 20:37:12 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m6KAbBfs082813; Sun, 20 Jul 2008 20:37:12 +1000 (EST) (envelope-from peter) Date: Sun, 20 Jul 2008 20:37:11 +1000 From: Peter Jeremy To: Unga Message-ID: <20080720103711.GG24076@server.vk2pj.dyndns.org> References: <20080719213056.GE19044@dan.emsphone.com> <545719.90429.qm@web57010.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <545719.90429.qm@web57010.mail.re3.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Pseudoterminals increase: compilation error 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, 20 Jul 2008 10:37:15 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jul-19 19:44:18 -0700, Unga wrote: >truss -o truss.log -f expect -c "spawn ls" > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) ERR#5 'Input/output error' > 1178: open("/dev/ptyp1",O_RDWR,027757763030) ERR#5 'Input/output error' > 1178: open("/dev/ptyp2",O_RDWR,027757763030) =3D 5 (0x5) > 1178: fstat(5,{mode=3Dcrw-rw-rw- ,inode=3D178,size=3D0,blksize=3D4096}) = =3D 0 (0x0) > : > : > 1178: chown("/dev/ttyp2",1002,4) ERR#1 'Operation not perm= itted' This is definitely wrong. expect should not be calling chown(2), it should be calling pt_chown. >I'm using Expect-5.43.0 compiled from sources. > >So, it looks like some sort of a misconfiguration. Still investigating. Have you built the FreeBSD port or used your own build configuration? If the latter, I suggest you build the port - it works for me. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiDFVcACgkQ/opHv/APuIcGfACffJ0DUf9T2hH2hbRKGPpFpseZ 8dUAn06Wzi1eBLqZHLlBpjm108tveh0S =ViLT -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 13:41:52 2008 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 EF056106567F for ; Sun, 20 Jul 2008 13:41:52 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57011.mail.re3.yahoo.com (web57011.mail.re3.yahoo.com [66.196.97.115]) by mx1.freebsd.org (Postfix) with SMTP id 87EB68FC13 for ; Sun, 20 Jul 2008 13:41:52 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 88676 invoked by uid 60001); 20 Jul 2008 13:41:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=vj56egLmT7GN9zg5unMoKKzIVuS/B80+rRmz5N9+SvTnf3ypubWhTyANcL05KG7bnuWcqvnTxHKDXISelb4Qyx+9Ae/fWmjpsPyej4DDX+pj/+pcm75hiB21xur6M6Yp0OO36p4M4b+LE3cr28iXyf+lfWoZwSSQH29b6bu03Vo=; Received: from [165.21.155.75] by web57011.mail.re3.yahoo.com via HTTP; Sun, 20 Jul 2008 06:41:51 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Sun, 20 Jul 2008 06:41:51 -0700 (PDT) From: Unga To: Peter Jeremy In-Reply-To: <20080720103711.GG24076@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <490974.88404.qm@web57011.mail.re3.yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: Pseudoterminals increase: compilation error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 13:41:53 -0000 --- On Sun, 7/20/08, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 6:37 PM > On 2008-Jul-19 19:44:18 -0700, Unga > wrote: > >truss -o truss.log -f expect -c "spawn ls" > > > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > > : > > : > > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > > This is definitely wrong. expect should not be calling > chown(2), > it should be calling pt_chown. > Hmm...that's a good point. I'll check that. > >I'm using Expect-5.43.0 compiled from sources. > > > >So, it looks like some sort of a misconfiguration. > Still investigating. > > Have you built the FreeBSD port or used your own build > configuration? > If the latter, I suggest you build the port - it works for > me. > Yes, I build my own build configuration. Anyway, I'll check what are the patches applied by the FreeBSD port. Unga From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 16:44:32 2008 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 AC17B106567B for ; Sun, 20 Jul 2008 16:44:32 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 9758A8FC0A for ; Sun, 20 Jul 2008 16:44:32 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id AXM15332; Sun, 20 Jul 2008 09:44:32 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 01C024500E; Sun, 20 Jul 2008 09:44:32 -0700 (PDT) To: Edwin Groothuis In-Reply-To: Your message of "Sun, 20 Jul 2008 14:22:09 +1000." <20080720042209.GA3928@k7.mavetju> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1216572271_14758P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 20 Jul 2008 09:44:31 -0700 From: "Kevin Oberman" Message-Id: <20080720164432.01C024500E@ptavv.es.net> Cc: Brett Glass , stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 16:44:32 -0000 --==_Exmh_1216572271_14758P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 20 Jul 2008 14:22:09 +1000 > From: Edwin Groothuis > Sender: owner-freebsd-stable@freebsd.org > > On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote: > > At 09:28 PM 7/19/2008, Subhro wrote: > > > > >You need to understand the release engineering process of FreeeBSD. > > > > I've been watching it (and testing release candidates) since 2.x, so > > I think I may possibly have some understanding of it by now. ;-) > > > > >The release edition is essential created from the stabe edition. 7.1R > > >would not be something new which is *not* present on 7-STABLE today. > > > > Mostly true. But the new release would undergo extensive testing, and > > changes which were "not ready for prime time" would be rolled back or > > made solid. I've had enough trouble with some recent snapshots of > > -STABLE that I'd rather install a release that's been thoroughly > > tested... preferably with the latest ports. That's why I'm asking > > about the likely actual release date of 7.1. > > The best thing a looking glass can come up with is: > > http://www.freebsd.org/releng/#schedule > > But that unless an announcement that as much worth as the lifetime > of the electrons hitting the back of your eyes. I think we might have a communications issue. If I am wrong, sorry for the waste of bandwidth, First, 7.1 will not be out before Black Hat where the details of the vulnerability will be discussed publicly, so scratch that. Second, RELENG_7_0 has the patch plus two other security patches. IT IS NOT STABLE! It is 7.0 with exactly three important security patches and nothing else. While I find stable to be more stable and generally far better tested than release versions, I understand th preference many have for release versions. You have three options: 1. Upgrade to STABLE 2. Apply the patch to your existing system 3. Upgrade to RELENG_7_0 Of these, 2 is generally the easiest. 3 is probably the closest you can get to what you want, but pulls in two other security patches (which you probably should have installed, anyway) and 1 is probably the best approach in terms of system stability, but it does make a great many changes and it is probably not the best choice for a production environment where careful testing would be needed before deployment. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1216572271_14758P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIg2tvkn3rs5h7N1ERAsWwAJ99C4FOk/EfYrwBLcRbIuvgMk8xAgCfd6r0 YJ4kM3YQM0YTnzfbXh/M9DQ= =kUp3 -----END PGP SIGNATURE----- --==_Exmh_1216572271_14758P-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 18:16:08 2008 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 8EE44106566B for ; Sun, 20 Jul 2008 18:16:08 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 127F28FC08 for ; Sun, 20 Jul 2008 18:16:07 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 8E03ED005F; Sun, 20 Jul 2008 08:15:56 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id BF94B153882; Sun, 20 Jul 2008 08:15:55 -1000 (HST) Date: Sun, 20 Jul 2008 08:15:55 -1000 From: Clifton Royston To: Brett Glass Message-ID: <20080720181554.GA5405@lava.net> References: <200807200230.UAA17164@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807200230.UAA17164@lariat.net> User-Agent: Mutt/1.4.2.2i Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 18:16:08 -0000 On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote: > Everyone: > > Will FreeBSD 7.1 be released in time to use it as an upgrade to > close the BIND cache poisoning hole? We'd like to upgrade affected > servers to the latest FreeBSD at the same time that we upgrade > BIND if possible. Given that 7.1 and 6.4 are still listed as "August" in the RE page, and things often slip a bit as the date approaches, I'd say you'd be well-advised not to wait. Assuming you're running 7.0 or 6.3, upgrade to the latest _RELENG patch which is much less work than a full version upgrade. My opinion only. I'm not a developer, and I'm not running any recursive resolvers on BIND these days; my limited set of machines are running djbdns instead, so I have more flexibility. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 18:24:59 2008 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 EF1CE106567B for ; Sun, 20 Jul 2008 18:24:59 +0000 (UTC) (envelope-from subhro.kar@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 803AB8FC08 for ; Sun, 20 Jul 2008 18:24:59 +0000 (UTC) (envelope-from subhro.kar@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so548296wah.3 for ; Sun, 20 Jul 2008 11:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8vbRT2lC+tiiU0RV6/7hKpX+GST+hSyeaETRQc/1LIA=; b=xhgJMikzmOGwVWR1XDyRMJvId4jE74rvZ+CsEotDBNgbhzYy8sO43+MoS98oi5BzP3 9PyWp2BM+d/ymKcuPqZFUQpn9I1xNcCwjuS4I99tA/Urw1UwNVS9N1VVA8cX7PdcAIJM RFO8H8POX3Xuex3HbZ/MlLFodYNp2eWaR2/JA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DXXssEt1eln/tQri4lRdf3O4k0f8sVMIbxIv84WOT4Dz2XaosxnxIPIEFDCo9Z3CXk rP0gjwEUORLhdF5mmFOnJVK6LEw9RK7/yPkRDmcv99w4s/rMjpMHEHgIxBCa6HPyOUdz PNxN6+l/Zc42T7bFNw/XRn1zXdNFtcYlIaOPA= Received: by 10.114.26.18 with SMTP id 18mr2039669waz.130.1216578299132; Sun, 20 Jul 2008 11:24:59 -0700 (PDT) Received: by 10.114.15.4 with HTTP; Sun, 20 Jul 2008 11:24:59 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 23:54:59 +0530 From: Subhro To: "Clifton Royston" In-Reply-To: <20080720181554.GA5405@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807200230.UAA17164@lariat.net> <20080720181554.GA5405@lava.net> Cc: Brett Glass , stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 18:25:00 -0000 Cilton, Off topic, but could you please tell me (us) the advantages(and disadvantages) of djbdns over bind? Thanks Subhro On Sun, Jul 20, 2008 at 11:45 PM, Clifton Royston wrote: > On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote: >> Everyone: >> >> Will FreeBSD 7.1 be released in time to use it as an upgrade to >> close the BIND cache poisoning hole? We'd like to upgrade affected >> servers to the latest FreeBSD at the same time that we upgrade >> BIND if possible. > > Given that 7.1 and 6.4 are still listed as "August" in the RE page, > and things often slip a bit as the date approaches, I'd say you'd be > well-advised not to wait. Assuming you're running 7.0 or 6.3, upgrade > to the latest _RELENG patch which is much less work than a full version > upgrade. > > My opinion only. I'm not a developer, and I'm not running any > recursive resolvers on BIND these days; my limited set of machines are > running djbdns instead, so I have more flexibility. > > -- Clifton > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > 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" > -- Subhro Kar Software Engineer Dynamic Digital Technologies Pvt. Ltd. EPY-3, Sector: V Salt Lake City 700091 India From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 18:31:10 2008 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 EE550106566C for ; Sun, 20 Jul 2008 18:31:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (in-addr.broker.freenet6.net [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id AA3848FC15 for ; Sun, 20 Jul 2008 18:31:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1KKdgY-0002ac-5K; Sun, 20 Jul 2008 14:31:06 -0400 Date: Sun, 20 Jul 2008 14:31:06 -0400 From: Gary Palmer To: Kevin Oberman Message-ID: <20080720183106.GA26333@in-addr.com> References: <20080720042209.GA3928@k7.mavetju> <20080720164432.01C024500E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080720164432.01C024500E@ptavv.es.net> Cc: Brett Glass , Edwin Groothuis , stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 20 Jul 2008 18:31:11 -0000 On Sun, Jul 20, 2008 at 09:44:31AM -0700, Kevin Oberman wrote: [ snip ] > Second, RELENG_7_0 has the patch plus two other security patches. IT IS > NOT STABLE! It is 7.0 with exactly three important security patches and > nothing else. [ snip ] I believe the second sentence could be better written as IT IS NOT -STABLE! which is an important difference ;) Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 22:29:57 2008 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 135571065678; Sun, 20 Jul 2008 22:29:57 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.freebsd.org (Postfix) with ESMTP id D42FD8FC12; Sun, 20 Jul 2008 22:29:56 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB0098E572; Mon, 21 Jul 2008 00:29:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Mon, 21 Jul 2008 00:29:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> In-Reply-To: <20080719221813.GC4733@garage.freebsd.pl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Panic on ZFS startup after crash Thread-Index: Acjp7ZPdbzk0KW4IRjOWKCDZGC91IwAycrdg References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> From: "Daniel Eriksson" To: Cc: Pawel Jakub Dawidek Subject: RE: Panic on ZFS startup after crash 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, 20 Jul 2008 22:29:57 -0000 Pawel Jakub Dawidek wrote: > Can you try this patch? >=20 > http://people.freebsd.org/~pjd/patches/space_map.c.patch Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a backtrace in a day or two if it would help. Any other suggestions Pawel? ___ Daniel Eriksson (http://www.toomuchdata.com/) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 05:11:25 2008 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 A0860106566B for ; Mon, 21 Jul 2008 05:11:25 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57004.mail.re3.yahoo.com (web57004.mail.re3.yahoo.com [66.196.97.108]) by mx1.freebsd.org (Postfix) with SMTP id 2CCAE8FC08 for ; Mon, 21 Jul 2008 05:11:24 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 95317 invoked by uid 60001); 21 Jul 2008 05:11:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=DtCLE29KD1JCHBCczi/Kb0muci6UEFgJ7IHUMk1699baaOWSkDUYD8XoXVewFc5NINWHlJRoLPBq1owz6joGDGHvBplm3q53P+00kuN9TzH5jgTS6W4WJ7UbBWCIs+cpgXHXAt2iEKcI9xW0p2jYhH1F4zzr15mpubROw1Vn+m4=; Received: from [220.255.7.209] by web57004.mail.re3.yahoo.com via HTTP; Sun, 20 Jul 2008 22:11:23 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Sun, 20 Jul 2008 22:11:23 -0700 (PDT) From: Unga To: Peter Jeremy In-Reply-To: <20080720103711.GG24076@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <223782.94918.qm@web57004.mail.re3.yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: Pseudoterminals increase: compilation error [SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 05:11:25 -0000 --- On Sun, 7/20/08, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Pseudoterminals increase: compilation error > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Sunday, July 20, 2008, 6:37 PM > On 2008-Jul-19 19:44:18 -0700, Unga > wrote: > >truss -o truss.log -f expect -c "spawn ls" > > > > 1178: open("/dev/ptyp0",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp1",O_RDWR,027757763030) > ERR#5 'Input/output error' > > 1178: open("/dev/ptyp2",O_RDWR,027757763030) > = 5 (0x5) > > 1178: fstat(5,{mode=crw-rw-rw- > ,inode=178,size=0,blksize=4096}) = 0 (0x0) > > : > > : > > 1178: chown("/dev/ttyp2",1002,4) > ERR#1 'Operation not permitted' > > This is definitely wrong. expect should not be calling > chown(2), > it should be calling pt_chown. > Yep, it was pt_chown was missing. Fixed the issue. Now ttyp* are created with correct ownerships. A big thank specially to Peter Jeremy and all others who helped me to solve this. Best regards Unga From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 09:02:40 2008 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 1AFFC1065672 for ; Mon, 21 Jul 2008 09:02:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 643F98FC08 for ; Mon, 21 Jul 2008 09:02:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7014545B36; Mon, 21 Jul 2008 11:02:36 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 97C43456B1; Mon, 21 Jul 2008 11:02:31 +0200 (CEST) Date: Mon, 21 Jul 2008 11:02:36 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20080721090235.GA2953@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Panic on ZFS startup after crash 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, 21 Jul 2008 09:02:40 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote: > Pawel Jakub Dawidek wrote: >=20 > > Can you try this patch? > >=20 > > http://people.freebsd.org/~pjd/patches/space_map.c.patch >=20 > Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a > backtrace in a day or two if it would help. The backtrace won't help here. I'm afraid your pool's metadata is somehow corrupted that ZFS can't handle that. I saw warnings in your first e-mail about ZFS not beeing able to replay ZIL. Can you try disabling ZIL? Something like: # zpool export # kldunload zfs # kenv vfs.zfs.zil_disable=3D1 # kldload zfs # zpool import Although I'm not sure if disabling ZIL will prevent replaying previously prepared ZIL. If that won't help, I'm afraid the last suggestion I can provide is to try the lastest ZFS version (I can prepare a patch for you in a few days). The panic you're seeing is in dmu_write() function. You could also try to import a pool read-only, but I just tried doing so with 'zpool import -o ro ' command and it mount file systems read-write. Not sure why it doesn't work, but I'll try to fix it today. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhFCrForvXbEpPzQRAl42AKCjAd8ynPjxVhzr3KjCcemh9ptAtgCeLPrI 6e/bYiAlTonBaUkzlYEDD0s= =NRaL -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 09:51:01 2008 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 8DF0C1065678 for ; Mon, 21 Jul 2008 09:51:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id D78188FC1F for ; Mon, 21 Jul 2008 09:51:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 85D8245C8C; Mon, 21 Jul 2008 11:50:59 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A458F4569A; Mon, 21 Jul 2008 11:50:55 +0200 (CEST) Date: Mon, 21 Jul 2008 11:51:01 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20080721095100.GB2953@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <20080721090235.GA2953@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Panic on ZFS startup after crash 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, 21 Jul 2008 09:51:01 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 11:02:36AM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote: > > Pawel Jakub Dawidek wrote: > >=20 > > > Can you try this patch? > > >=20 > > > http://people.freebsd.org/~pjd/patches/space_map.c.patch > >=20 > > Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a > > backtrace in a day or two if it would help. >=20 > The backtrace won't help here. I'm afraid your pool's metadata is > somehow corrupted that ZFS can't handle that. I saw warnings in your > first e-mail about ZFS not beeing able to replay ZIL. Can you try > disabling ZIL? Something like: >=20 > # zpool export > # kldunload zfs > # kenv vfs.zfs.zil_disable=3D1 > # kldload zfs > # zpool import >=20 > Although I'm not sure if disabling ZIL will prevent replaying previously > prepared ZIL. If that won't help, I'm afraid the last suggestion I can > provide is to try the lastest ZFS version (I can prepare a patch for you > in a few days). >=20 > The panic you're seeing is in dmu_write() function. You could also try > to import a pool read-only, but I just tried doing so with > 'zpool import -o ro ' command and it mount file systems > read-write. Not sure why it doesn't work, but I'll try to fix it today. I fixed 'zpool import -o ro' problem in HEAD, but you can also patch your 7.0 sources with this patch: http://people.freebsd.org/~pjd/patches/opensolaris_vfs.c.2.patch With this patch applied and ZIL disabled, try to: # zpool import -o ro --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhFwDForvXbEpPzQRAlJ1AJ4mHkmzd0SVy6Fa5OluljB3Jl9h8gCeI0+g JTNWWvI5f0BKXLsJf3fD5/c= =NvAx -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 10:07:54 2008 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 6CD631065679; Mon, 21 Jul 2008 10:07:54 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh01.opentransfer.com (smh01.opentransfer.com [71.18.216.112]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6EE8FC1C; Mon, 21 Jul 2008 10:07:53 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: by smh01.opentransfer.com (Postfix, from userid 8) id CFA11102053F; Mon, 21 Jul 2008 06:07:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on smh01.opentransfer.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=MIME_QP_LONG_LINE,RDNS_NONE autolearn=disabled version=3.2.4 Received: from webmail5.opentransfer.com (unknown [69.49.230.6]) by smh01.opentransfer.com (Postfix) with ESMTP id 96D6C1023995; Mon, 21 Jul 2008 06:07:40 -0400 (EDT) Received: from webmail5.opentransfer.com (webmail5.opentransfer.com [127.0.0.1]) by webmail5.opentransfer.com (8.13.8/8.13.8) with ESMTP id m6LA7qAk027322; Mon, 21 Jul 2008 05:07:52 -0500 Received: (from nobody@localhost) by webmail5.opentransfer.com (8.13.8/8.13.8/Submit) id m6LA7qA9027321; Mon, 21 Jul 2008 13:07:52 +0300 X-Authentication-Warning: webmail5.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from cabin.theweb.org.ua (cabin.theweb.org.ua [91.195.184.50]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Mon, 21 Jul 2008 13:07:52 +0300 Message-ID: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> Date: Mon, 21 Jul 2008 13:07:52 +0300 From: "Oleg V. Nauman" To: "Oleg V. Nauman" References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719080212.GA89036@eos.sc1.parodius.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> In-Reply-To: <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 91.195.184.50 Cc: Jeremy Chadwick , stable@FreeBSD.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 21 Jul 2008 10:07:54 -0000 Quoting "Oleg V. Nauman" : > Quoting Jeremy Chadwick : > >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >>> It seems to be something was changed with ACPI support on 7.0-STABLE so >>> my next system upgrade ended with ACPI HPET not working anymore on my >>> ASUS A9Rp laptop. >>> >>> Here is the part of /var/log/dmesg.today dated July 13: >>> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >>> [..] >>> acpi0: on motherboard >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 77f00000 (3) failed >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> acpi_ec0: port 0x62,0x66 on acpi0 >>> acpi_hpet0: iomem =20 >>> 0xfed00000-0xfed003ff on acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>> >>> Here is the fresh dmesg output info: >>> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >>> [..] >>> acpi0: on motherboard >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 77f00000 (3) failed >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> [..] >>> acpi_hpet0: iomem =20 >>> 0xfed00000-0xfed003ff on acpi0 >>> device_attach: acpi_hpet0 attach returned 12 >>> >>> And the part of actual sysctl kern.timecounter output: >>> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000= ) >>> kern.timecounter.hardware: ACPI-safe >> >> Seems okay here: >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul =20 >> 12 10:53:08 PDT 2008 =20 >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> acpi_hpet0: iomem =20 >> 0xfed00000-0xfed003ff on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> Timecounters tick every 1.000 msec >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) =20 >> i8254(0) dummy(-1000000) >> kern.timecounter.hardware: ACPI-fast >> >> You sure you haven't upgraded your BIOS or something and forgot to >> re-enable HPET? > > No it was not upgraded.. Have no option to enable/disable HPET through > BIOS settings though I was unclear a bit or so. There are no ACPI related settings in my =20 laptop's BIOS. Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c =20 (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi= 0 Timecounter "HPET" frequency 14318180 Hz quality 900 kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) =20 dummy(-1000000) kern.timecounter.hardware: HPET Hopefully it helps to understand what is went wrong there. Oleg > > > _______________________________________________ > 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 Mon Jul 21 10:46:48 2008 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 D637E106564A; Mon, 21 Jul 2008 10:46:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B36728FC1D; Mon, 21 Jul 2008 10:46:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A76361CC09E; Mon, 21 Jul 2008 03:46:48 -0700 (PDT) Date: Mon, 21 Jul 2008 03:46:48 -0700 From: Jeremy Chadwick To: jhb@freebsd.org Message-ID: <20080721104648.GA29700@eos.sc1.parodius.com> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719080212.GA89036@eos.sc1.parodius.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 21 Jul 2008 10:46:48 -0000 On Mon, Jul 21, 2008 at 01:07:52PM +0300, Oleg V. Nauman wrote: > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: HPET > > Hopefully it helps to understand what is went wrong there. John, do you have any ideas WRT this regression? HPET on this user's system has the most granularity. -- | Jeremy Chadwick jdc at 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 Jul 21 11:08:39 2008 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 44599106569E; Mon, 21 Jul 2008 11:08:39 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id E817E8FC0C; Mon, 21 Jul 2008 11:08:38 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtFs-0007eu-QN; Mon, 21 Jul 2008 12:08:36 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtFs-000J7B-Ow; Mon, 21 Jul 2008 12:08:36 +0100 To: sven@dmv.com In-Reply-To: <1216304215.14562.19.camel@lanshark.dmv.com> Message-Id: From: Pete French Date: Mon, 21 Jul 2008 12:08:36 +0100 Cc: koitsu@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Multi-machine mirroring choices 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, 21 Jul 2008 11:08:39 -0000 > The *big* issue I have right now is dealing with the slave machine going > down. Once the master no longer has a connection to the ggated devices, > all processes trying to use the device hang in D status. I have tried > pkill'ing ggatec to no avail and ggatec destroy returns a message of > gctl being busy. Trying to ggatec destroy -f panics the machine. Oddly enough, this was the issue I had with iscsi which made me move to using ggated instead. On our machines I use '-t 10' as an argument to ggatec, and this makes it timeout once the connection has been down for a certain amount of time. I am using gmirror on top, not ZFS, and this handled the drive vanishing from the mirror quite happily. I haven't tried it with ZFS, which may not like having the device suddenly dissapear. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 12:27:25 2008 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 70CF51065670 for ; Mon, 21 Jul 2008 12:27:25 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 246148FC1A for ; Mon, 21 Jul 2008 12:27:24 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAOsdhEhMCqa7/2dsb2JhbACLZ6FsAw X-IronPort-AV: E=Sophos;i="4.31,223,1215403200"; d="scan'208";a="24583688" Received: from not.enough.unixsluts.com (HELO kevin) ([76.10.166.187]) by ironport2-out.teksavvy.com with ESMTP; 21 Jul 2008 08:27:09 -0400 From: "Kevin K" To: "'Torfinn Ingolfsen'" , References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> Date: Mon, 21 Jul 2008 08:26:57 -0400 Message-ID: <005301c8eb2d$113598c0$33a0ca40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjoJzuF8FoUpx1mRjaC7x0bNrjnEgDBZ8mA Content-Language: en-us Cc: Subject: RE: HP Pavilion dv2000 laptop wont boot off install cd 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, 21 Jul 2008 12:27:25 -0000 > On Thu, 17 Jul 2008 08:31:37 -0400 > Kevin K wrote: > > > For 7.0-RELEASE, it > > seemed to hang at "Trying to mount root from ufs:/dev/md0". > > How long did you wait? If you didn't wait 10 or 15 minutes, please do. > Various tests / probes take a long time to time out on some hardware. > > HTH > -- > Regards, > Torfinn Ingolfsen I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding the spacebar @ /boot/loader.conf). It stopped at Trying to mount root from ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from that point -- the keyboard was also unresponsive. Does anyone know if this is a known issue? From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 13:49:27 2008 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 3148F106566B; Mon, 21 Jul 2008 13:49:27 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.freebsd.org (Postfix) with ESMTP id D02D98FC19; Mon, 21 Jul 2008 13:49:26 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB009AC52A; Mon, 21 Jul 2008 15:49:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Mon, 21 Jul 2008 15:49:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> In-Reply-To: <20080721090235.GA2953@garage.freebsd.pl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Panic on ZFS startup after crash Thread-Index: AcjrEMumyrEYBtvwSkq8gGV+vg0W2AAJjvLQ References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> From: "Daniel Eriksson" To: Cc: Pawel Jakub Dawidek Subject: RE: Panic on ZFS startup after crash 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, 21 Jul 2008 13:49:27 -0000 Pawel Jakub Dawidek wrote: > I'm afraid your pool's metadata is > somehow corrupted that ZFS can't handle that. Yes, that's my conclusion also. It looks like the intent log is messed up enough to trigger an assert while ZFS tries to parse/replay it. > I saw warnings in your > first e-mail about ZFS not beeing able to replay ZIL. Can you try > disabling ZIL? Something like: I've already tried this, and it made no difference. When the box crashed ZIL was enabled, and for some reason garbage got written into the ZIL. Now whenever ZFS tries to import the pool it sees a non-empty ZIL and tries to parse/replay it. Is there an easy way to trick ZFS into thinking the ZIL is empty? > Although I'm not sure if disabling ZIL will prevent replaying=20 > previously prepared ZIL. It won't unfortunately. > If that won't help, I'm afraid the last suggestion I can > provide is to try the lastest ZFS version (I can prepare a=20 > patch for you in a few days). I could probably prepare a temporary install of 8-CURRENT on a spare drive and boot from that if it's easier for you to make a patch against CURRENT instead of RELENG_7_0. > You could also try=20 > to import a pool read-only, but I just tried doing so with > 'zpool import -o ro ' command and it mount file systems > read-write. Not sure why it doesn't work, but I'll try to fix=20 > it today. I'll try that! ___ Daniel Eriksson (http://www.toomuchdata.com/) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 13:52:00 2008 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 294391065674 for ; Mon, 21 Jul 2008 13:52:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1908FC12 for ; Mon, 21 Jul 2008 13:51:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0945545C99; Mon, 21 Jul 2008 15:51:55 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5E9DB45685; Mon, 21 Jul 2008 15:51:51 +0200 (CEST) Date: Mon, 21 Jul 2008 15:51:56 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20080721135156.GA6310@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Panic on ZFS startup after crash 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, 21 Jul 2008 13:52:00 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote: > Pawel Jakub Dawidek wrote: >=20 > > I'm afraid your pool's metadata is > > somehow corrupted that ZFS can't handle that. >=20 > Yes, that's my conclusion also. It looks like the intent log is messed > up enough to trigger an assert while ZFS tries to parse/replay it. >=20 > > I saw warnings in your > > first e-mail about ZFS not beeing able to replay ZIL. Can you try > > disabling ZIL? Something like: >=20 > I've already tried this, and it made no difference. When the box crashed > ZIL was enabled, and for some reason garbage got written into the ZIL. > Now whenever ZFS tries to import the pool it sees a non-empty ZIL and > tries to parse/replay it. >=20 > Is there an easy way to trick ZFS into thinking the ZIL is empty? I'll check that. > > If that won't help, I'm afraid the last suggestion I can > > provide is to try the lastest ZFS version (I can prepare a=20 > > patch for you in a few days). >=20 > I could probably prepare a temporary install of 8-CURRENT on a spare > drive and boot from that if it's easier for you to make a patch against > CURRENT instead of RELENG_7_0. The ZFS code in 7.0 is the same as in HEAD, so no worries. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhJR8ForvXbEpPzQRAjDxAJ9i6i7v78rxBReNEifa2wbpwRCgWQCfb3TT pBJJkgMaMdLs1DiHjxkhha0= =V7MM -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 14:28:01 2008 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 E73B01065677 for ; Mon, 21 Jul 2008 14:28:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7341F8FC0C for ; Mon, 21 Jul 2008 14:28:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CDF3545B36; Mon, 21 Jul 2008 16:27:59 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EDC6345683; Mon, 21 Jul 2008 16:27:54 +0200 (CEST) Date: Mon, 21 Jul 2008 16:28:00 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20080721142800.GB6310@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20080721135156.GA6310@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Panic on ZFS startup after crash 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, 21 Jul 2008 14:28:02 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 03:51:56PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote: > > Pawel Jakub Dawidek wrote: > >=20 > > > I'm afraid your pool's metadata is > > > somehow corrupted that ZFS can't handle that. > >=20 > > Yes, that's my conclusion also. It looks like the intent log is messed > > up enough to trigger an assert while ZFS tries to parse/replay it. > >=20 > > > I saw warnings in your > > > first e-mail about ZFS not beeing able to replay ZIL. Can you try > > > disabling ZIL? Something like: > >=20 > > I've already tried this, and it made no difference. When the box crashed > > ZIL was enabled, and for some reason garbage got written into the ZIL. > > Now whenever ZFS tries to import the pool it sees a non-empty ZIL and > > tries to parse/replay it. > >=20 > > Is there an easy way to trick ZFS into thinking the ZIL is empty? >=20 > I'll check that. Ok. We may try not to replay the ZIL, but leave it there and see what will happen. We can also try to destroy the ZIL without replaying it. What we do from now on can mess up your pool even further, so you may want to backup entire disks if you want. To skip replaying the ZIL you need to edit /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c file, find zil_replay() function and make the head of it looks like this: void zil_replay(objset_t *os, void *arg, uint64_t *txgp, zil_replay_func_t *replay_func[TX_MAX_TYPE]) { zilog_t *zilog =3D dmu_objset_zil(os); const zil_header_t *zh =3D zilog->zl_header; zil_replay_arg_t zr; /* XXX: Try to skip the ZIL replay. */ return; if (zil_empty(zilog)) { zil_destroy(zilog, B_TRUE); return; } [...] If that won't work, we can try to destroy the ZIL without replaying it: void zil_replay(objset_t *os, void *arg, uint64_t *txgp, zil_replay_func_t *replay_func[TX_MAX_TYPE]) { zilog_t *zilog =3D dmu_objset_zil(os); const zil_header_t *zh =3D zilog->zl_header; zil_replay_arg_t zr; /* XXX: Destroy the ZIL without replaying it. */ zil_destroy(zilog, B_FALSE); return; if (zil_empty(zilog)) { zil_destroy(zilog, B_TRUE); return; } [...] --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhJzvForvXbEpPzQRArjZAKCnJagjVv6KQPxySdMmtTefeL8/0gCgwXcv Nkz76RFnstg5jhQjieJQ+2E= =iDjn -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 15:23:58 2008 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 EA6EE1065674; Mon, 21 Jul 2008 15:23:58 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.freebsd.org (Postfix) with ESMTP id 76F6E8FC12; Mon, 21 Jul 2008 15:23:58 +0000 (UTC) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) by smtp-gw-cl-c.dmv.com (8.12.10/8.12.10) with ESMTP id m6LFNtu6031378; Mon, 21 Jul 2008 11:23:55 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [192.168.0.101] (c-71-200-111-79.hsd1.md.comcast.net [71.200.111.79]) (authenticated bits=0) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id m6LFNmee000605; Mon, 21 Jul 2008 11:23:49 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <4884AA04.7000404@dmv.com> Date: Mon, 21 Jul 2008 11:23:48 -0400 From: Sven W User-Agent: Thunderbird 2.0.0.14 (X11/20080508) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 Cc: koitsu@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Multi-machine mirroring choices 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, 21 Jul 2008 15:23:59 -0000 Pete French presumably uttered the following on 07/21/08 07:08: >> The *big* issue I have right now is dealing with the slave machine going >> down. Once the master no longer has a connection to the ggated devices, >> all processes trying to use the device hang in D status. I have tried >> pkill'ing ggatec to no avail and ggatec destroy returns a message of >> gctl being busy. Trying to ggatec destroy -f panics the machine. > > Oddly enough, this was the issue I had with iscsi which made me move > to using ggated instead. On our machines I use '-t 10' as an argument to > ggatec, and this makes it timeout once the connection has been down for > a certain amount of time. I am using gmirror on top, not ZFS, and this > handled the drive vanishing from the mirror quite happily. I haven't > tried it with ZFS, which may not like having the device suddenly dissapear. > > -pete. What I have found is that the master machine will lock up if the slave disappears during a large file transfer. I tested this by setting up zpool mirror on the master using a ggatec device from the slave. Then I: pkill'ed ggated on the slave machine. dd if=/dev/zero of=/data1/testfile2 bs=16k count=8192 [128MB] on the master The dd command finished and the /var/log/messages showed I/O errors to the slave drive as expected. Messages also showed ggatec trying to reconnect every 10 seconds (ggatec was started with the -t 10 parameter). Finally zfs marked the drive unavailable which then allowed me to ggatec destroy -u 0 without getting the "ioctl(/dev/ggctl): Device busy" error message. (By the way, using ggatec destroy does not kill the "ggatec create" that created the process to begin with, I had to pkill ggatec to get that stop - bug?) The above behavior would be acceptable for multi-machine mirroring as it would be scriptable. The problem comes with Large writes. I tried to repeat the above with dd if=/dev/zero of=/data1/testfile2 bs=16k count=32768 [512MB] which then locks zfs, and ultimately the system itself. It seems once the write size/buffer is full, zfs is unable to fail/unavail the slave drive and the entire system becomes unresponsive (cannot even ssh into it). The bottom line is that without some type of "timeout" or "time to fail" (bad I/O to fail?) zpool + ggate[cd] seems to be an unworkable solution. This is actually a shame as the recover process swapping from master to slave and back again was so much cleaner and faster than using gmirror. Sven From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 15:51:14 2008 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 4617A106566C for ; Mon, 21 Jul 2008 15:51:14 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 334D08FC22 for ; Mon, 21 Jul 2008 15:51:12 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so303724uge.37 for ; Mon, 21 Jul 2008 08:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=27z0gLuCyA41jcWv+ga32HM2JGfw4ee58339JZIY22Q=; b=N/3Fv58OxpXyTrldC3+mTe/5FiU1498DoZGQ0NaY7A2tAntgUxl9aBA4RcAcvUP/XF /xd3ZgW3Mrv7FmEdMo8nYmhMgif58D5Xp18bAnRXTd9eaigxlhnsxS8xEkmE0eHGIDWy WO4Ytn4Q8zlqFSOQNBuvr7xC3WI8m1JosbtkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=l8f3Pg7+pQvRnY404TnqbU6QB2QKS159sDu2pLyxqW0QBAFxI0bO4xq6caex9b9dLy elycL5ZDGrDmeM0AvOj2HRNeedmNEBvioLrnoPKcus0LLBf3Olexa/KVEzmdwaMshKP7 d9rFXjGgFLGvnub4ymM0lTY6D6GW5XMIN0eoY= Received: by 10.66.232.9 with SMTP id e9mr1725505ugh.17.1216655471813; Mon, 21 Jul 2008 08:51:11 -0700 (PDT) Received: by 10.67.31.16 with HTTP; Mon, 21 Jul 2008 08:51:11 -0700 (PDT) Message-ID: Date: Mon, 21 Jul 2008 12:51:11 -0300 From: "Carlos A. M. dos Santos" To: "Kevin K" In-Reply-To: <005301c8eb2d$113598c0$33a0ca40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807161353.m6GDrDFB058142@lurza.secnetix.de> <009301c8e797$1385e880$3a91b980$@com> <00b301c8e806$eeb3d5b0$cc1b8110$@com> <00b401c8e809$0ed63c50$2c82b4f0$@com> <20080717170601.b7f1f9ad.torfinn.ingolfsen@broadpark.no> <005301c8eb2d$113598c0$33a0ca40$@com> Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: HP Pavilion dv2000 laptop wont boot off install cd 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, 21 Jul 2008 15:51:14 -0000 On Mon, Jul 21, 2008 at 9:26 AM, Kevin K wrote: >> On Thu, 17 Jul 2008 08:31:37 -0400 >> Kevin K wrote: >> >> > For 7.0-RELEASE, it >> > seemed to hang at "Trying to mount root from ufs:/dev/md0". >> >> How long did you wait? If you didn't wait 10 or 15 minutes, please do. >> Various tests / probes take a long time to time out on some hardware. >> >> HTH >> -- >> Regards, >> Torfinn Ingolfsen > > > I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding > the spacebar @ /boot/loader.conf). I have seen this on some HP notebooks. It seems that the CD drive does not to stabilize on time before booting, leading to some disk read errors. The trick is to press F9 (or F12, depending on the notebook model) to force the BIOS to show the boot device menu. Then, *after the CD drive stop spinning*, choose the boot from CD/DVD option. > It stopped at Trying to mount root from > ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from that > point -- the keyboard was also unresponsive. > > Does anyone know if this is a known issue? Try to disable kbdmux before booting. Jump to the loader prompt and type: set hint.kbdmux.0.disabled=1 boot -v -- If you think things can't get worse it's probably only because you lack sufficient imagination. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 19:14:27 2008 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 D72E51065692 for ; Mon, 21 Jul 2008 19:14:27 +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 5AB618FC1C for ; Mon, 21 Jul 2008 19:14:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1632 invoked by uid 399); 21 Jul 2008 19:14:24 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Jul 2008 19:14:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4884E00E.1090009@FreeBSD.org> Date: Mon, 21 Jul 2008 12:14:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Brett Glass References: <200807200230.UAA17164@lariat.net> In-Reply-To: <200807200230.UAA17164@lariat.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 19:14:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Brett Glass wrote: | Everyone: | | Will FreeBSD 7.1 be released in time to use it as an upgrade to | close the BIND cache poisoning hole? Brett, et al, I'll make this simple for you. If you have a server that is running BIND, update BIND now. If you need to use the ports, that's fine, just do it now. Make sure that you are not specifying a port via any query-source* options in named.conf, and that any firewall between your named process and the outside world does keep-state on outgoing UDP packets. If you have a system with BIND installed (as it is by default) but you are NOT running named, you don't need to worry about updating now, but you should do it "soonish" just in case someone gets a wild hair and starts up named on that box. As for the meta-question, FreeBSD is currently operating on a time-based release schedule, not a feature-based one. And to your actual question, the answer is no. hope this helps, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkiE4A0ACgkQyIakK9Wy8PtSWACeN+lmId1jdMF9zGt3v905XEgy bT8AoJtmWCWRjyXSktaeJ6IHiwJas7Fk =vtRp -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 19:51:23 2008 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 9BCB6106566B for ; Mon, 21 Jul 2008 19:51:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 24A278FC1B for ; Mon, 21 Jul 2008 19:51:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-048-174.pools.arcor-ip.net [88.66.48.174]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1KL1Db298w-0000SD; Mon, 21 Jul 2008 21:38:47 +0200 Received: (qmail 57899 invoked from network); 21 Jul 2008 19:38:46 -0000 Received: from myhost.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 21 Jul 2008 19:38:46 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Mon, 21 Jul 2008 21:38:46 +0200 User-Agent: KMail/1.9.9 References: <200807200230.UAA17164@lariat.net> <4884E00E.1090009@FreeBSD.org> In-Reply-To: <4884E00E.1090009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807212138.46703.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19nMQ//1BBy//i21n0fJbdbRz/v/sT6ewU4rNW xdlVlwbT66sqYyUP3COVgCmOiuGaufUY9Q82Gd0zkN55wZ/5CH zWmLJrdkNdxLoONNK45YQ== Cc: Brett Glass , stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 19:51:23 -0000 On Monday 21 July 2008 21:14:22 Doug Barton wrote: > Brett Glass wrote: > | Everyone: > | > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > | close the BIND cache poisoning hole? > > Brett, et al, > > I'll make this simple for you. If you have a server that is running > BIND, update BIND now. If you need to use the ports, that's fine, just > do it now. Make sure that you are not specifying a port via any > query-source* options in named.conf, and that any firewall between > your named process and the outside world does keep-state on outgoing > UDP packets. ... and that any NAT device employs at least a somewhat random port allocation mechanism - pf provides this. > If you have a system with BIND installed (as it is by default) but you > are NOT running named, you don't need to worry about updating now, but > you should do it "soonish" just in case someone gets a wild hair and > starts up named on that box. > > As for the meta-question, FreeBSD is currently operating on a > time-based release schedule, not a feature-based one. And to your > actual question, the answer is no. > > > hope this helps, > > Doug -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 19:51:23 2008 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 F0DE01065671 for ; Mon, 21 Jul 2008 19:51:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 793338FC1C for ; Mon, 21 Jul 2008 19:51:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-048-174.pools.arcor-ip.net [88.66.48.174]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1KL1Db2bEp-0001wF; Mon, 21 Jul 2008 21:38:47 +0200 Received: (qmail 57899 invoked from network); 21 Jul 2008 19:38:46 -0000 Received: from myhost.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 21 Jul 2008 19:38:46 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Mon, 21 Jul 2008 21:38:46 +0200 User-Agent: KMail/1.9.9 References: <200807200230.UAA17164@lariat.net> <4884E00E.1090009@FreeBSD.org> In-Reply-To: <4884E00E.1090009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807212138.46703.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1974LsGGH3WWmZ7WfrOYxMARyZr4KDq3mMG0QT xW/LRAAAb0zLEcwbkvPBLj3pZnMRSku89iYys6FG4KhqVghyUx uRT3/c6GbdmQgleOYQD7w== Cc: Brett Glass , stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 19:51:24 -0000 On Monday 21 July 2008 21:14:22 Doug Barton wrote: > Brett Glass wrote: > | Everyone: > | > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > | close the BIND cache poisoning hole? > > Brett, et al, > > I'll make this simple for you. If you have a server that is running > BIND, update BIND now. If you need to use the ports, that's fine, just > do it now. Make sure that you are not specifying a port via any > query-source* options in named.conf, and that any firewall between > your named process and the outside world does keep-state on outgoing > UDP packets. ... and that any NAT device employs at least a somewhat random port allocation mechanism - pf provides this. > If you have a system with BIND installed (as it is by default) but you > are NOT running named, you don't need to worry about updating now, but > you should do it "soonish" just in case someone gets a wild hair and > starts up named on that box. > > As for the meta-question, FreeBSD is currently operating on a > time-based release schedule, not a feature-based one. And to your > actual question, the answer is no. > > > hope this helps, > > Doug -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 20:34:53 2008 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 DA0B41065670; Mon, 21 Jul 2008 20:34:53 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFAC8FC13; Mon, 21 Jul 2008 20:34:53 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal3.es.net [198.128.3.207]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id BBT30420; Mon, 21 Jul 2008 13:24:20 -0700 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id BBT70518; Mon, 21 Jul 2008 13:24:18 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7CF9B4500E; Mon, 21 Jul 2008 13:24:18 -0700 (PDT) To: Max Laier In-Reply-To: Your message of "Mon, 21 Jul 2008 21:38:46 +0200." <200807212138.46703.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1216671858_23030P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 21 Jul 2008 13:24:18 -0700 From: "Kevin Oberman" Message-Id: <20080721202418.7CF9B4500E@ptavv.es.net> Cc: Brett Glass , stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 20:34:54 -0000 --==_Exmh_1216671858_23030P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: Max Laier > Date: Mon, 21 Jul 2008 21:38:46 +0200 > Sender: owner-freebsd-stable@freebsd.org > > On Monday 21 July 2008 21:14:22 Doug Barton wrote: > > Brett Glass wrote: > > | Everyone: > > | > > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > > | close the BIND cache poisoning hole? > > > > Brett, et al, > > > > I'll make this simple for you. If you have a server that is running > > BIND, update BIND now. If you need to use the ports, that's fine, just > > do it now. Make sure that you are not specifying a port via any > > query-source* options in named.conf, and that any firewall between > > your named process and the outside world does keep-state on outgoing > > UDP packets. > > ... and that any NAT device employs at least a somewhat random port > allocation mechanism - pf provides this. And, if you are not sure how good a job it does (and I am not), you should use the OARC test to check how well it works: dig +short porttest.dns-oarc.net TXT If the result is not "GOOD", it's not good enough. You can test a remote server by adding "@remote-server" to the dig command. The server may be specified by name or IP address. Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1216671858_23030P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIhPBykn3rs5h7N1ERAhFPAJ4/QBlNj4volDF2fns3Ca0DdCqWHACfVJlm 7vHwUlwTS1sTRnG4kLfy9Fo= =M8Eg -----END PGP SIGNATURE----- --==_Exmh_1216671858_23030P-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 20:34:53 2008 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 DA0B41065670; Mon, 21 Jul 2008 20:34:53 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFAC8FC13; Mon, 21 Jul 2008 20:34:53 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal3.es.net [198.128.3.207]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id BBT30420; Mon, 21 Jul 2008 13:24:20 -0700 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id BBT70518; Mon, 21 Jul 2008 13:24:18 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7CF9B4500E; Mon, 21 Jul 2008 13:24:18 -0700 (PDT) To: Max Laier In-Reply-To: Your message of "Mon, 21 Jul 2008 21:38:46 +0200." <200807212138.46703.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1216671858_23030P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 21 Jul 2008 13:24:18 -0700 From: "Kevin Oberman" Message-Id: <20080721202418.7CF9B4500E@ptavv.es.net> Cc: Brett Glass , stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 20:34:54 -0000 --==_Exmh_1216671858_23030P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: Max Laier > Date: Mon, 21 Jul 2008 21:38:46 +0200 > Sender: owner-freebsd-stable@freebsd.org > > On Monday 21 July 2008 21:14:22 Doug Barton wrote: > > Brett Glass wrote: > > | Everyone: > > | > > | Will FreeBSD 7.1 be released in time to use it as an upgrade to > > | close the BIND cache poisoning hole? > > > > Brett, et al, > > > > I'll make this simple for you. If you have a server that is running > > BIND, update BIND now. If you need to use the ports, that's fine, just > > do it now. Make sure that you are not specifying a port via any > > query-source* options in named.conf, and that any firewall between > > your named process and the outside world does keep-state on outgoing > > UDP packets. > > ... and that any NAT device employs at least a somewhat random port > allocation mechanism - pf provides this. And, if you are not sure how good a job it does (and I am not), you should use the OARC test to check how well it works: dig +short porttest.dns-oarc.net TXT If the result is not "GOOD", it's not good enough. You can test a remote server by adding "@remote-server" to the dig command. The server may be specified by name or IP address. Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1216671858_23030P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIhPBykn3rs5h7N1ERAhFPAJ4/QBlNj4volDF2fns3Ca0DdCqWHACfVJlm 7vHwUlwTS1sTRnG4kLfy9Fo= =M8Eg -----END PGP SIGNATURE----- --==_Exmh_1216671858_23030P-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 20:56:25 2008 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 E331C10657C9; Mon, 21 Jul 2008 20:56:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 74B578FC12; Mon, 21 Jul 2008 20:56:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6LKtZIA084378; Mon, 21 Jul 2008 16:56:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Jeremy Chadwick Date: Mon, 21 Jul 2008 11:48:46 -0400 User-Agent: KMail/1.9.7 References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <20080721104648.GA29700@eos.sc1.parodius.com> In-Reply-To: <20080721104648.GA29700@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807211148.46704.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 21 Jul 2008 16:56:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7770/Mon Jul 21 15:30:47 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 21 Jul 2008 20:56:26 -0000 On Monday 21 July 2008 06:46:48 am Jeremy Chadwick wrote: > On Mon, Jul 21, 2008 at 01:07:52PM +0300, Oleg V. Nauman wrote: > > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > > dummy(-1000000) > > kern.timecounter.hardware: HPET > > > > Hopefully it helps to understand what is went wrong there. > > John, do you have any ideas WRT this regression? HPET on this user's > system has the most granularity. ENOCONTEXT. I will try to find the thread in my stable@ inbox, but right now I can't tell anything from just this e-mail. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 21:17:38 2008 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 AC53E1065673 for ; Mon, 21 Jul 2008 21:17:38 +0000 (UTC) (envelope-from hostmaster@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 856798FC19 for ; Mon, 21 Jul 2008 21:17:38 +0000 (UTC) (envelope-from hostmaster@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m6LLHZBa004129; Mon, 21 Jul 2008 14:17:35 -0700 (PDT) (envelope-from hostmaster@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.361] Message-Id: From: Jo Rhett To: Peter Wemm In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 21 Jul 2008 14:17:29 -0700 References: <20080711164939.GA10238@lava.net> X-Mailer: Apple Mail (2.928.1) Cc: FreeBSD Stable Subject: chipset causing locks. 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, 21 Jul 2008 21:17:38 -0000 Thanks for the note. No, just a coincidence. The chipset is a VIA ProSavageDDR KM266. But thanks for bringing that up ;-) FWIW, as others have speculated enabling more logging from GEOM produced nothing. It does appear to be a hardware failure of some sort. On Jul 18, 2008, at 11:29 PM, Peter Wemm wrote: > On Wed, Jul 16, 2008 at 2:42 PM, Jo Rhett > wrote: >>> On Fri, Jul 11, 2008 at 12:59:33AM -0700, Jo Rhett wrote: >>>> >>>> Every time it is rebuilding ad0. Every single boot in the last >>>> two >>>> weeks. >> >> On Jul 11, 2008, at 9:49 AM, Clifton Royston wrote: >>> >>> That just means that it halted without a proper shutdown. If it >>> crashes, the mirror isn't stopped properly, so it's marked dirty, >>> so it >>> must rebuild it. It is the precise analogy of finding all the file >>> systems dirty on boot and fscking them, following a crash. >> >> >> Thanks for the clarification. Dang, I hoped I was on to something. > > This is really off on a tangent, but I thought I'd mention it on the > off-chance that it fit your problem. > > Recently there have been grumblings about heat problems with certain > nvidia chipsets on consumer boards. Apparently, there is some process > issue, if you believe trade rags like theinquirer.net etc. Apparently > there is some issue with heat damage over time. Consumer motherboards > with passive cooled (no fan) heat pipes etc seem to be particularly > vulnerable. I use the word "apparently" because it is far from a > verified fact. > > However, I've got two motherboards, one running freebsd, one running > windows, with nvidia chipsets. Both used to be fine with onboard IDE > activity. Both now use raid controllers so the IDE interfaces have > been idle for a good year or so. > > Something came up and I had to use the IDE interfaces for a lot of > data transfer. Suddenly, both machines are flakey. The windows > machine blue screens under load. My freebsd box just "turns off" > (motherboard appears to power off, but the power supply is on still). > The same happens when I use a linux boot disk, so I know its not > FreeBSD's fault. > > The common factor seems to be that the motherboards are now about a > year and a half old. They both have the same nvidia south bridge that > theinquirer.net was trashing. Both used to work fine, now have > problems with IDE. and now I recalled the article and started > wondering... > > Do you, by any wildly remote chance, have an nvidia based motherboard? > > I believe the fault I'm seeing is the system asserting a fatal error > by doing a HT ECC flood to halt everything. > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > "All of this is for nothing if we don't go to the stars" - JMS/B5 > "If Java had true garbage collection, most programs would delete > themselves upon execution." -- Robert Sewell -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 21:18:19 2008 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 CA979106567F for ; Mon, 21 Jul 2008 21:18:19 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC9D8FC1A for ; Mon, 21 Jul 2008 21:18:19 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so543320ywe.13 for ; Mon, 21 Jul 2008 14:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:message-id :in-reply-to:references:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance:sender; bh=xtLhS/AJiKMLf92u39vBnK3oXkY1Xn6FAfw/icRnBgA=; b=atZJoctNw+ohuYoM18q5gnuHpO28L9V5lyh31YCEdqicyZDiMWl+V7IkgMy1Odk0Se fxuQa8UXfn4gA2TzwTCnOqcXG+xB2mOFT1RrgvWBMeMaGR9SLoWAfYv8jRFcOf8kGONO 37vaEdrhFVcybT6ihCKc5LK2RC716Uqm2UrDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance:sender; b=PCKm/1nEx5Int5fYdOkllj0eJxqntOg+GXkYBtHII8IH19f14HNnFAZEAl7SlbJhWT Cdzjikn+biJrU8HlSTIx0JtsswwjXPCbc+hJp87f2JyQI90UicsA/X+qA2hiJRFdo6Gi G9Azz6xk+tjBCovUDWJzWQQJc5x61CmU6+WHQ= Received: by 10.151.39.21 with SMTP id r21mr4360063ybj.238.1216675098411; Mon, 21 Jul 2008 14:18:18 -0700 (PDT) Received: from cygnus.homeunix.com ( [189.71.38.112]) by mx.google.com with ESMTPS id 8sm4645766ywg.6.2008.07.21.14.18.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jul 2008 14:18:17 -0700 (PDT) Received: by cygnus.homeunix.com (Postfix, from userid 80) id 59764EB; Mon, 21 Jul 2008 18:18:10 -0300 (BRT) Received: from 200.252.157.118 (proxying for 10.12.1.211, 10.12.1.3) (SquirrelMail authenticated user matheus@eternamente.info) by cygnus.homeunix.com with HTTP; Mon, 21 Jul 2008 18:18:10 -0300 (BRT) Message-ID: <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> In-Reply-To: <20080721135156.GA6310@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> Date: Mon, 21 Jul 2008 18:18:10 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: Nenhum_de_Nos Subject: Re: Panic on ZFS startup after crash 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, 21 Jul 2008 21:18:19 -0000 > The ZFS code in 7.0 is the same as in HEAD, so no worries. I'm trying zfs myself in a small enviroment at home, but for that I do follow 7-STABLE. there's no need to do that, as based in the above statement ? thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 22:18:00 2008 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 327AB10656D4; Mon, 21 Jul 2008 22:18:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD05E8FC20; Mon, 21 Jul 2008 22:17:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6LMHrxu085122; Mon, 21 Jul 2008 18:17:53 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 21 Jul 2008 18:00:12 -0400 User-Agent: KMail/1.9.7 References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> In-Reply-To: <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807211800.12415.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 21 Jul 2008 18:17:53 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7771/Mon Jul 21 17:09:37 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jeremy Chadwick Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 21 Jul 2008 22:18:00 -0000 On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > Quoting "Oleg V. Nauman" : > > > Quoting Jeremy Chadwick : > > > >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > >>> It seems to be something was changed with ACPI support on 7.0-STABLE so > >>> my next system upgrade ended with ACPI HPET not working anymore on my > >>> ASUS A9Rp laptop. > >>> > >>> Here is the part of /var/log/dmesg.today dated July 13: > >>> > >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >>> [..] > >>> acpi0: on motherboard > >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >>> acpi0: [ITHREAD] > >>> acpi0: Power Button (fixed) > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, 77f00000 (3) failed > >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >>> acpi_ec0: port 0x62,0x66 on acpi0 > >>> acpi_hpet0: iomem > >>> 0xfed00000-0xfed003ff on acpi0 > >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >>> > >>> Here is the fresh dmesg output info: > >>> > >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >>> [..] > >>> acpi0: on motherboard > >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >>> acpi0: [ITHREAD] > >>> acpi0: Power Button (fixed) > >>> acpi0: reservation of 0, a0000 (3) failed > >>> acpi0: reservation of 100000, 77f00000 (3) failed > >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >>> [..] > >>> acpi_hpet0: iomem > >>> 0xfed00000-0xfed003ff on acpi0 > >>> device_attach: acpi_hpet0 attach returned 12 > >>> > >>> And the part of actual sysctl kern.timecounter output: > >>> > >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) > >>> kern.timecounter.hardware: ACPI-safe > >> > >> Seems okay here: > >> > >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul > >> 12 10:53:08 PDT 2008 > >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > >> > >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > >> acpi_hpet0: iomem > >> 0xfed00000-0xfed003ff on acpi0 > >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> Timecounters tick every 1.000 msec > >> > >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > >> i8254(0) dummy(-1000000) > >> kern.timecounter.hardware: ACPI-fast > >> > >> You sure you haven't upgraded your BIOS or something and forgot to > >> re-enable HPET? > > > > No it was not upgraded.. Have no option to enable/disable HPET through > > BIOS settings though > > I was unclear a bit or so. There are no ACPI related settings in my > laptop's BIOS. > > Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: HPET > > Hopefully it helps to understand what is went wrong there. Ok, so the attempt to allocate the resource is failing for some reason. Can you get output from 'devinfo -r' and 'devinfo -u'? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 22:20:05 2008 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 931E31065676; Mon, 21 Jul 2008 22:20:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 02C9A8FC2A; Mon, 21 Jul 2008 22:20:04 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA01486; Mon, 21 Jul 2008 16:19:38 -0600 (MDT) Message-Id: <200807212219.QAA01486@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jul 2008 16:18:16 -0600 To: "Kevin Oberman" , Max Laier From: Brett Glass In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 22:20:05 -0000 At 02:24 PM 7/21/2008, Kevin Oberman wrote: >Don't forget that ANY server that caches data, including an end system >running a caching only server is vulnerable. Actually, there is an exception to this. A "forward only" cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. It's really idiosyncratic, but seems to work well -- and if you're just doing a caching resolver you don't have to touch it once you get it configured. Of course, all solutions that randomize ports are really just "security by obscurity," because by shuffling ports you're hiding the way to poison your cache... a little. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 22:31:55 2008 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 5669B1065672 for ; Mon, 21 Jul 2008 22:31:55 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 046F38FC17 for ; Mon, 21 Jul 2008 22:31:54 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 51296 invoked by uid 0); 21 Jul 2008 22:31:53 -0000 Received: from unknown (HELO ?192.168.0.220?) (spork@216.220.116.154) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2008 22:31:53 -0000 Date: Mon, 21 Jul 2008 18:31:53 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Kevin Oberman In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: References: <20080721202418.7CF9B4500E@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org, Brett Glass Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 22:31:55 -0000 On Mon, 21 Jul 2008, Kevin Oberman wrote: >> From: Max Laier >> Date: Mon, 21 Jul 2008 21:38:46 +0200 >> Sender: owner-freebsd-stable@freebsd.org >> >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: >>> Brett Glass wrote: >>> | Everyone: >>> | >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to >>> | close the BIND cache poisoning hole? >>> >>> Brett, et al, >>> >>> I'll make this simple for you. If you have a server that is running >>> BIND, update BIND now. If you need to use the ports, that's fine, just >>> do it now. Make sure that you are not specifying a port via any >>> query-source* options in named.conf, and that any firewall between >>> your named process and the outside world does keep-state on outgoing >>> UDP packets. >> >> ... and that any NAT device employs at least a somewhat random port >> allocation mechanism - pf provides this. > > And, if you are not sure how good a job it does (and I am not), you > should use the OARC test to check how well it works: > dig +short porttest.dns-oarc.net TXT > > If the result is not "GOOD", it's not good enough. I was playing around with this a bit. It seems like a patched server will give a standard deviation of more than 18,000. If I make some queries behind a one-to-many NAT using pf, it falls to somewhere around 6,000 (with a patched BIND - unpatched is pitiful). PF is not *adding* any randomness to unpatched servers. Since it has a (non-configurable?) range of ports it will grab when doing outbound NAT, the results are not as good as with no NAT intervention, but passable I suppose. Of course in a 1:1 NAT setup it is transparent. Charles > You can test a remote server by adding "@remote-server" to the dig > command. The server may be specified by name or IP address. > > Don't forget that ANY server that caches data, including an end system > running a caching only server is vulnerable. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 22:52:40 2008 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 D2ED3106567A for ; Mon, 21 Jul 2008 22:52:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7E38FC16 for ; Mon, 21 Jul 2008 22:52:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA01486; Mon, 21 Jul 2008 16:19:38 -0600 (MDT) Message-Id: <200807212219.QAA01486@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jul 2008 16:18:16 -0600 To: "Kevin Oberman" , Max Laier From: Brett Glass In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> References: <20080721202418.7CF9B4500E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 22:52:40 -0000 At 02:24 PM 7/21/2008, Kevin Oberman wrote: >Don't forget that ANY server that caches data, including an end system >running a caching only server is vulnerable. Actually, there is an exception to this. A "forward only" cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. It's really idiosyncratic, but seems to work well -- and if you're just doing a caching resolver you don't have to touch it once you get it configured. Of course, all solutions that randomize ports are really just "security by obscurity," because by shuffling ports you're hiding the way to poison your cache... a little. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 22:59:55 2008 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 13828106567D for ; Mon, 21 Jul 2008 22:59:55 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id B636D8FC1E for ; Mon, 21 Jul 2008 22:59:54 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 51296 invoked by uid 0); 21 Jul 2008 22:31:53 -0000 Received: from unknown (HELO ?192.168.0.220?) (spork@216.220.116.154) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2008 22:31:53 -0000 Date: Mon, 21 Jul 2008 18:31:53 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Kevin Oberman In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> Message-ID: References: <20080721202418.7CF9B4500E@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , stable@freebsd.org, Doug Barton , freebsd-stable@freebsd.org, Brett Glass Subject: Re: FreeBSD 7.1 and BIND exploit 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, 21 Jul 2008 22:59:55 -0000 On Mon, 21 Jul 2008, Kevin Oberman wrote: >> From: Max Laier >> Date: Mon, 21 Jul 2008 21:38:46 +0200 >> Sender: owner-freebsd-stable@freebsd.org >> >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: >>> Brett Glass wrote: >>> | Everyone: >>> | >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to >>> | close the BIND cache poisoning hole? >>> >>> Brett, et al, >>> >>> I'll make this simple for you. If you have a server that is running >>> BIND, update BIND now. If you need to use the ports, that's fine, just >>> do it now. Make sure that you are not specifying a port via any >>> query-source* options in named.conf, and that any firewall between >>> your named process and the outside world does keep-state on outgoing >>> UDP packets. >> >> ... and that any NAT device employs at least a somewhat random port >> allocation mechanism - pf provides this. > > And, if you are not sure how good a job it does (and I am not), you > should use the OARC test to check how well it works: > dig +short porttest.dns-oarc.net TXT > > If the result is not "GOOD", it's not good enough. I was playing around with this a bit. It seems like a patched server will give a standard deviation of more than 18,000. If I make some queries behind a one-to-many NAT using pf, it falls to somewhere around 6,000 (with a patched BIND - unpatched is pitiful). PF is not *adding* any randomness to unpatched servers. Since it has a (non-configurable?) range of ports it will grab when doing outbound NAT, the results are not as good as with no NAT intervention, but passable I suppose. Of course in a 1:1 NAT setup it is transparent. Charles > You can test a remote server by adding "@remote-server" to the dig > command. The server may be specified by name or IP address. > > Don't forget that ANY server that caches data, including an end system > running a caching only server is vulnerable. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 05:07:15 2008 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 C17C31065677 for ; Tue, 22 Jul 2008 05:07:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0308FC16 for ; Tue, 22 Jul 2008 05:07:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-048-174.pools.arcor-ip.net [88.66.48.174]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1KLA5h2ySD-0000sF; Tue, 22 Jul 2008 07:07:14 +0200 Received: (qmail 66181 invoked from network); 22 Jul 2008 05:07:12 -0000 Received: from myhost.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 22 Jul 2008 05:07:12 -0000 From: Max Laier Organization: FreeBSD To: Charles Sprickman Date: Tue, 22 Jul 2008 07:07:11 +0200 User-Agent: KMail/1.9.9 References: <20080721202418.7CF9B4500E@ptavv.es.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807220707.11870.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19shxzaLZm6mqMtv4XCegBLzQYipsV8QoSAdn9 b8iraH4fXFIXKm1D+MF3fCm8YIkjQT+G61Rdgi9XBB0qJ5jdoa /Otqd2xv4znNSNx7ZH+AQ== Cc: Brett Glass , Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 05:07:15 -0000 On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote: > On Mon, 21 Jul 2008, Kevin Oberman wrote: > >> From: Max Laier > >> Date: Mon, 21 Jul 2008 21:38:46 +0200 > >> Sender: owner-freebsd-stable@freebsd.org > >> > >> On Monday 21 July 2008 21:14:22 Doug Barton wrote: > >>> Brett Glass wrote: > >>> | Everyone: > >>> | > >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to > >>> | close the BIND cache poisoning hole? > >>> > >>> Brett, et al, > >>> > >>> I'll make this simple for you. If you have a server that is running > >>> BIND, update BIND now. If you need to use the ports, that's fine, > >>> just do it now. Make sure that you are not specifying a port via > >>> any query-source* options in named.conf, and that any firewall > >>> between your named process and the outside world does keep-state on > >>> outgoing UDP packets. > >> > >> ... and that any NAT device employs at least a somewhat random port > >> allocation mechanism - pf provides this. > > > > And, if you are not sure how good a job it does (and I am not), you > > should use the OARC test to check how well it works: > > dig +short porttest.dns-oarc.net TXT > > > > If the result is not "GOOD", it's not good enough. > > I was playing around with this a bit. It seems like a patched server > will give a standard deviation of more than 18,000. If I make some > queries behind a one-to-many NAT using pf, it falls to somewhere around > 6,000 (with a patched BIND - unpatched is pitiful). While the standard deviation gives some *indication* about the randomness of the selection it is no real measurement for its quality. > PF is not *adding* any randomness to unpatched servers. Since it has a > (non-configurable?) range of ports it will grab when doing outbound > NAT, the results are not as good as with no NAT intervention, but > passable I suppose. You can configure the range on a per-NAT-rule basis, e.g.: nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if) port 1024:65535 but you have to take care so that you don't collide with the ephemeral port range of the host itself. Obviously you can't do much about an unpatched bind as with UDP there is no notion of "connection" so pf (or any NAT device for that matter) has to keep the NAT binding open for "some time" and a quick sequence of queries to the same server will be sent out through the same port. So putting a NAT firewall in front of a DNS resolver is *NOT* a workaround! > Of course in a 1:1 NAT setup it is transparent. > > Charles > > > You can test a remote server by adding "@remote-server" to the dig > > command. The server may be specified by name or IP address. > > > > Don't forget that ANY server that caches data, including an end > > system running a caching only server is vulnerable. > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 09:07:04 2008 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 B390B106566B for ; Tue, 22 Jul 2008 09:07:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 71D118FC0C for ; Tue, 22 Jul 2008 09:07:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 760B245C98; Tue, 22 Jul 2008 11:07:03 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 90D9545685; Tue, 22 Jul 2008 11:06:58 +0200 (CEST) Date: Tue, 22 Jul 2008 11:07:03 +0200 From: Pawel Jakub Dawidek To: Nenhum_de_Nos Message-ID: <20080722090703.GD3241@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5gxpn/Q6ypwruk0T" Content-Disposition: inline In-Reply-To: <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Panic on ZFS startup after crash 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, 22 Jul 2008 09:07:04 -0000 --5gxpn/Q6ypwruk0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: > > The ZFS code in 7.0 is the same as in HEAD, so no worries. >=20 > I'm trying zfs myself in a small enviroment at home, but for that I do > follow 7-STABLE. there's no need to do that, as based in the above > statement ? There might be some small differences, but the patches I provide here will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --5gxpn/Q6ypwruk0T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhaM3ForvXbEpPzQRAiRxAJ9h5sju19qzsPKwM9LfnwU+pT3eaQCfWyMb ci0XlCci6K2tPm0jo+Ld3+0= =+FO6 -----END PGP SIGNATURE----- --5gxpn/Q6ypwruk0T-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 09:23:22 2008 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 C159A1065675; Tue, 22 Jul 2008 09:23:22 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh01.opentransfer.com (smh01.opentransfer.com [71.18.216.112]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9FC8FC08; Tue, 22 Jul 2008 09:23:22 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: by smh01.opentransfer.com (Postfix, from userid 8) id CC16C10246B2; Tue, 22 Jul 2008 04:37:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on smh01.opentransfer.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=MIME_QP_LONG_LINE,RDNS_NONE autolearn=disabled version=3.2.4 Received: from webmail5.opentransfer.com (unknown [69.49.230.6]) by smh01.opentransfer.com (Postfix) with ESMTP id 854CB10246B1; Tue, 22 Jul 2008 04:37:40 -0400 (EDT) Received: from webmail5.opentransfer.com (webmail5.opentransfer.com [127.0.0.1]) by webmail5.opentransfer.com (8.13.8/8.13.8) with ESMTP id m6M8bql5001221; Tue, 22 Jul 2008 03:37:53 -0500 Received: (from nobody@localhost) by webmail5.opentransfer.com (8.13.8/8.13.8/Submit) id m6M8bp2F001220; Tue, 22 Jul 2008 11:37:51 +0300 X-Authentication-Warning: webmail5.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from cabin.theweb.org.ua (cabin.theweb.org.ua [91.195.184.50]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Tue, 22 Jul 2008 11:37:51 +0300 Message-ID: <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> Date: Tue, 22 Jul 2008 11:37:51 +0300 From: "Oleg V. Nauman" To: John Baldwin References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> In-Reply-To: <200807211800.12415.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 91.195.184.50 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 22 Jul 2008 09:23:22 -0000 Quoting John Baldwin : > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: >> Quoting "Oleg V. Nauman" : >> >> > Quoting Jeremy Chadwick : >> > >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE = so >> >>> my next system upgrade ended with ACPI HPET not working anymore on my >> >>> ASUS A9Rp laptop. >> >>> >> >>> Here is the part of /var/log/dmesg.today dated July 13: >> >>> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >>> [..] >> >>> acpi0: on motherboard >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >>> acpi0: [ITHREAD] >> >>> acpi0: Power Button (fixed) >> >>> acpi0: reservation of 0, a0000 (3) failed >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> >>> acpi_ec0: port 0x62,0x66 on acpi0 >> >>> acpi_hpet0: iomem >> >>> 0xfed00000-0xfed003ff on acpi0 >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >>> >> >>> Here is the fresh dmesg output info: >> >>> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >>> [..] >> >>> acpi0: on motherboard >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >>> acpi0: [ITHREAD] >> >>> acpi0: Power Button (fixed) >> >>> acpi0: reservation of 0, a0000 (3) failed >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> >>> [..] >> >>> acpi_hpet0: iomem >> >>> 0xfed00000-0xfed003ff on acpi0 >> >>> device_attach: acpi_hpet0 attach returned 12 >> >>> >> >>> And the part of actual sysctl kern.timecounter output: >> >>> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) > dummy(-1000000) >> >>> kern.timecounter.hardware: ACPI-safe >> >> >> >> Seems okay here: >> >> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul >> >> 12 10:53:08 PDT 2008 >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 >> >> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> >> acpi_hpet0: iomem >> >> 0xfed00000-0xfed003ff on acpi0 >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> Timecounters tick every 1.000 msec >> >> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) >> >> i8254(0) dummy(-1000000) >> >> kern.timecounter.hardware: ACPI-fast >> >> >> >> You sure you haven't upgraded your BIOS or something and forgot to >> >> re-enable HPET? >> > >> > No it was not upgraded.. Have no option to enable/disable HPET through >> > BIOS settings though >> >> I was unclear a bit or so. There are no ACPI related settings in my >> laptop's BIOS. >> >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: HPET >> >> Hopefully it helps to understand what is went wrong there. > > Ok, so the attempt to allocate the resource is failing for some reason. C= an > you get output from 'devinfo -r' and 'devinfo -u'? Of course.. The kernel with 1.243.2.2 revision of /usr/src/sys/dev/acpica/acpi.c =20 (so HPET working for me): devinfo -r output: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x77fcffff npx0 acpi0 Interrupt request lines: 21 I/O ports: 0x10-0x1f 0x22-0x3f 0x63 0x65 0x67-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x250-0x25f 0x40b 0x480-0x4bf 0x4d0-0x4d1 0x4d6 0x500-0x53f 0x800-0x89f 0x900-0x90f 0x910-0x91f 0xc00-0xc01 0xc14 0xc50-0xc51 0xc52 0xc6c 0xc6f 0xcd4-0xcd5 0xcd6-0xcd7 0xcd8-0xcdf 0x4000-0x4004 0x4005-0x40ff I/O memory addresses: 0xc0000-0xcffff 0xe0000-0xfffff 0xe0000000-0xefffffff 0xfec00000-0xfec00fff 0xfee00000-0xfee00fff 0xfff80000-0xffffffff cpu0 ACPI I/O ports: 0x814 0x815 coretemp0 p4tcc0 cpufreq0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 I/O ports: 0x9800-0x98ff I/O memory addresses: 0xc0000000-0xcfffffff 0xfe1f0000-0xfe1fffff ohci0 Interrupt request lines: 19 I/O memory addresses: 0xfebff000-0xfebfffff usb0 uhub0 ums0 ohci1 I/O memory addresses: 0xfebfe000-0xfebfefff usb1 uhub1 ehci0 I/O memory addresses: 0xfebfd000-0xfebfdfff usb2 uhub2 atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xff00-0xff0f ata0 Interrupt request lines: 14 acd0 atapicam0 ata1 Interrupt request lines: 15 ad2 atapicam1 pcm0 Interrupt request lines: 16 I/O memory addresses: 0xfebf8000-0xfebfbfff isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xccfff pmtimer0 pcib2 pci2 rl0 Interrupt request lines: 20 I/O ports: 0xb800-0xb8ff I/O memory addresses: 0xfeaffc00-0xfeaffcff miibus0 rlphy0 cbb0 I/O memory addresses: 0xfe200000-0xfe200fff cardbus0 pccard0 atpic0 atdma0 attimer0 attimer1 npxisa0 acpi_sysresource0 acpi_sysresource1 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psmcpnp0 acpi_sysresource2 acpi_ec0 I/O ports: 0x62 0x66 acpi_lid0 acpi_sysresource3 acpi_acad0 battery0 acpi_sysresource4 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 acpi_button0 acpi_button1 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x808-0x80b acpi_hpet0 I/O memory addresses: 0xfed00000-0xfed003ff devinfo -u output: Interrupt request lines: 0 (root0) 1 (atkbd0) 3-8 (root0) 10-13 (root0) 14 (ata0) 15 (ata1) 16 (pcm0) 17-18 (root0) 19 (ohci0) 20 (rl0) 21 (acpi0) 22-23 (root0) DMA request lines: 0-7 (root0) I/O ports: 0x0-0xf (root0) 0x10-0x1f (acpi0) 0x20-0x21 (root0) 0x22-0x3f (acpi0) 0x40-0x5f (root0) 0x60 (atkbdc0) 0x61 (root0) 0x62 (acpi_ec0) 0x63 (acpi0) 0x64 (atkbdc0) 0x65 (acpi0) 0x66 (acpi_ec0) 0x67-0x6f (acpi0) 0x70-0x71 (root0) 0x72-0x7f (acpi0) 0x80 (acpi0) 0x81-0x83 (root0) 0x84-0x86 (acpi0) 0x87 (root0) 0x88 (acpi0) 0x89-0x8b (root0) 0x8c-0x8e (acpi0) 0x8f (root0) 0x90-0x9f (acpi0) 0xa0-0xa1 (root0) 0xa2-0xbf (acpi0) 0xc0-0xdf (root0) 0xe0-0xef (acpi0) 0xf0-0x16f (root0) 0x170-0x177 (atapci0) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci0) 0x1f8-0x24f (root0) 0x250-0x25f (acpi0) 0x260-0x375 (root0) 0x376 (atapci0) 0x377-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci0) 0x3f7-0x40a (root0) 0x40b (acpi0) 0x40c-0x47f (root0) 0x480-0x4bf (acpi0) 0x4c0-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x4d5 (root0) 0x4d6 (acpi0) 0x4d7-0x4ff (root0) 0x500-0x53f (acpi0) 0x540-0x7ff (root0) 0x800-0x89f (acpi0) 0x8a0-0x8ff (root0) 0x900-0x90f (acpi0) 0x910-0x91f (acpi0) 0x920-0xaff (root0) 0xb00-0xb0f (ichsmb0) 0xb10-0xbff (root0) 0xc00-0xc01 (acpi0) 0xc02-0xc13 (root0) 0xc14 (acpi0) 0xc15-0xc4f (root0) 0xc50-0xc51 (acpi0) 0xc52 (acpi0) 0xc53-0xc6b (root0) 0xc6c (acpi0) 0xc6d-0xc6e (root0) 0xc6f (acpi0) 0xc70-0xcd3 (root0) 0xcd4-0xcd5 (acpi0) 0xcd6-0xcd7 (acpi0) 0xcd8-0xcdf (acpi0) 0xce0-0x3fff (root0) 0x4000-0x4004 (acpi0) 0x4005-0x40ff (acpi0) 0x4100-0x97ff (root0) 0x9800-0x98ff (vgapci0) 0x9900-0xb7ff (root0) 0xb800-0xb8ff (rl0) 0xb900-0xfeff (root0) 0xff00-0xff0f (atapci0) 0xff10-0xffff (root0) I/O memory addresses: 0x0-0x9efff (ram0) 0x9f000-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xcffff (acpi0) 0xd0000-0xdffff (root0) 0xe0000-0xfffff (acpi0) 0x100000-0x77fcffff (ram0) 0x77fd0000-0xbfffffff (root0) 0xc0000000-0xcfffffff (vgapci0) 0xd0000000-0xdfffffff (root0) 0xe0000000-0xefffffff (acpi0) 0xf0000000-0xfe1effff (root0) 0xfe1f0000-0xfe1fffff (vgapci0) 0xfe200000-0xfe200fff (cbb0) 0xfe201000-0xfeaff3ff (root0) 0xfeaff400-0xfeaff4ff ---- 0xfeaff500-0xfeaff7ff (root0) 0xfeaff800-0xfeaff8ff ---- 0xfeaff900-0xfeaffbff (root0) 0xfeaffc00-0xfeaffcff (rl0) 0xfeaffd00-0xfebf7fff (root0) 0xfebf8000-0xfebfbfff (pcm0) 0xfebfc000-0xfebfcfff (root0) 0xfebfd000-0xfebfdfff (ehci0) 0xfebfe000-0xfebfefff (ohci1) 0xfebff000-0xfebfffff (ohci0) 0xfec00000-0xfec00fff (acpi0) 0xfec01000-0xfecfffff (root0) 0xfed00000-0xfed003ff (acpi_hpet0) 0xfed00400-0xfedfffff (root0) 0xfee00000-0xfee00fff (acpi0) 0xfee01000-0xfff7ffff (root0) 0xfff80000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x63 (root0) 0x65 (root0) 0x67-0x6f (root0) 0x72-0x80 (root0) 0x84-0x86 (root0) 0x88 (root0) 0x8c-0x8e (root0) 0x90-0x9f (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x250-0x25f (root0) 0x40b (root0) 0x480-0x4bf (root0) 0x4d0-0x4d1 (root0) 0x4d6 (root0) 0x500-0x53f (root0) 0x800-0x807 (root0) 0x808-0x80b (acpi_timer0) 0x80c-0x813 (root0) 0x814 (cpu0) 0x815 (cpu0) 0x816-0x89f (root0) 0x900-0x91f (root0) 0xc00-0xc01 (root0) 0xc14 (root0) 0xc50-0xc52 (root0) 0xc6c (root0) 0xc6f (root0) 0xcd4-0xcdf (root0) 0x4000-0x40ff (root0) ACPI I/O memory addresses: 0xc0000-0xccfff (orm0) 0xcd000-0xcffff (root0) 0xe0000-0xfffff (root0) 0xe0000000-0xefffffff (root0) 0xfec00000-0xfec00fff (root0) 0xfee00000-0xfee00fff (root0) 0xfff80000-0xffffffff (root0) For the kernel with 1.243.2.3 revision of =20 /usr/src/sys/dev/acpica/acpi.c ( so HPET is not working for me): Will not provide with full listings but just a diff comparing two =20 states (this good one with HPET working and bad w/o it): rainhaven# diff devinfo.r.good devinfo.r.bad 177,179d176 < acpi_hpet0 < I/O memory addresses: < 0xfed00000-0xfed003ff rainhaven# diff devinfo.u.good devinfo.u.bad 128c128 < 0xfed00000-0xfed003ff (acpi_hpet0) --- > 0xfed00000-0xfed003ff (ichsmb0) So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c =20 allocates the region required to ichsmb0 instead HPET (it not helps to =20 ichsmb0 because it never was working on my laptop but it is another =20 story I think). Thank you for looking into. > > -- > John Baldwin > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 15:12:40 2008 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 AB5891065672 for ; Tue, 22 Jul 2008 15:12:40 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.freebsd.org (Postfix) with ESMTP id 919ED8FC2C for ; Tue, 22 Jul 2008 15:12:40 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 21540 invoked from network); 22 Jul 2008 14:46:00 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 14:46:00 -0000 Message-ID: <4885F2A6.5020204@aldan.algebra.com> Date: Tue, 22 Jul 2008 10:45:58 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: questions@FreeBSD.org, stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: "sleeping without queue" ? 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, 22 Jul 2008 15:12:40 -0000 Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 15:29:43 2008 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 40A9B1065674; Tue, 22 Jul 2008 15:29:43 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 40DA48FC20; Tue, 22 Jul 2008 15:29:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4885FCE5.1060507@FreeBSD.org> Date: Tue, 22 Jul 2008 17:29:41 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mikhail Teterin References: <4885F2A6.5020204@aldan.algebra.com> In-Reply-To: <4885F2A6.5020204@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, questions@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 15:29:43 -0000 Mikhail Teterin wrote: > Hello! > > My attempt to build openoffice.org-3 seems to be hanging. Pressing > Ctrl-T produces: > > load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k > > (tcsh is used by OOo's build-script). What is this "sleeping without > queue" state, and why is process in it for so long? > > This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is > currently in use and the box seems to be perfectly fine otherwise. > Uptime is 55 days, two different X-sessions are functional... The kernel > is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. > > Thanks! What is the process backtrace? Kris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 15:52:45 2008 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 6E509106566C for ; Tue, 22 Jul 2008 15:52:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE9888FC14 for ; Tue, 22 Jul 2008 15:52:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m6MFqg75009489; Tue, 22 Jul 2008 17:52:43 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m6MFqgpm009488; Tue, 22 Jul 2008 17:52:42 +0200 (CEST) (envelope-from olli) Date: Tue, 22 Jul 2008 17:52:42 +0200 (CEST) Message-Id: <200807221552.m6MFqgpm009488@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200807212219.QAA01486@lariat.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (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-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 22 Jul 2008 17:52:43 +0200 (CEST) Cc: Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 15:52:45 -0000 Brett Glass wrote: > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > Don't forget that ANY server that caches data, including an end system > > running a caching only server is vulnerable. > > Actually, there is an exception to this. A "forward only" > cache/resolver is only as vulnerable as its forwarder(s). This is a > workaround for the vulnerability for folks who have systems that they > cannot easily upgrade: point at a trusted forwarder that's patched. > > We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? > Of course, all solutions that randomize ports are really just > "security by obscurity," because by shuffling ports you're hiding the > way to poison your cache... a little. True, but there is currently no better solution, AFAIK. The problem is inherent in the way DNS queries work. 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 "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:05:47 2008 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 9337F106564A for ; Tue, 22 Jul 2008 16:05:47 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 335F68FC12 for ; Tue, 22 Jul 2008 16:05:47 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id B6FB533C52; Tue, 22 Jul 2008 18:05:43 +0200 (CEST) Date: Tue, 22 Jul 2008 18:05:43 +0200 From: cpghost To: freebsd-stable@FreeBSD.ORG Message-ID: <20080722160542.GA14592@epia-2.farid-hajji.net> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807221552.m6MFqgpm009488@lurza.secnetix.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 16:05:47 -0000 On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > I'm curious, is djbdns exploitable, too? Does it randomize > the source ports of UDP queries? Apparently, djbdns had randomization of the source ports a long time ago... > > Of course, all solutions that randomize ports are really just > > "security by obscurity," because by shuffling ports you're hiding the > > way to poison your cache... a little. > > True, but there is currently no better solution, AFAIK. > The problem is inherent in the way DNS queries work. Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. > Best regards > Oliver cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:13:28 2008 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 CFCF9106566C for ; Tue, 22 Jul 2008 16:13:28 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.freebsd.org (Postfix) with ESMTP id B0D018FC16 for ; Tue, 22 Jul 2008 16:13:28 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 31867 invoked from network); 22 Jul 2008 16:13:27 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 16:13:27 -0000 Message-ID: <48860725.9050808@aldan.algebra.com> Date: Tue, 22 Jul 2008 12:13:25 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Kris Kennaway References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> In-Reply-To: <4885FCE5.1060507@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@FreeBSD.org, questions@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 16:13:28 -0000 Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): > Mikhail Teterin wrote: >> Hello! >> >> My attempt to build openoffice.org-3 seems to be hanging. Pressing >> Ctrl-T produces: >> >> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >> 0% 0k >> >> (tcsh is used by OOo's build-script). What is this "sleeping without >> queue" state, and why is process in it for so long? >> >> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >> is currently in use and the box seems to be perfectly fine otherwise. >> Uptime is 55 days, two different X-sessions are functional... The >> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >> >> Thanks! > > What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+ 0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...79759: No such file or directory. Interestingly, the file mentioned in the command-line -- the s_addincol.dpcc -- does not exist anywhere under /meow/ports/editors/openoffice.org-3/work -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:17:17 2008 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 C0AE1106568A for ; Tue, 22 Jul 2008 16:17:17 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from queueout02-winn.ispmail.ntl.com (queueout02-winn.ispmail.ntl.com [81.103.221.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFED8FC24 for ; Tue, 22 Jul 2008 16:17:16 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080722160559.XXNQ16629.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 22 Jul 2008 17:05:59 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080722160606.KSBR16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com> for ; Tue, 22 Jul 2008 17:06:06 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6MFxKSl076368 for ; Tue, 22 Jul 2008 16:59:21 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Tue, 22 Jul 2008 16:59:20 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221659.20396.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Subject: unable to use gmirror on supermicro 5015b-mt 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, 22 Jul 2008 16:17:17 -0000 These are new boxes. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm core 2 Q6600 CPU 8Gb 667 RAM Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. Build cycle okay. Running (no load) for a week or so. However, when I try to configure gmirror they hang on boot. After some fiddling it appears issuing #kldload geom_mirror hangs the boxes very hard. Ping response stops (after 3), no CAD response, CDROM draw doesn't open! This may well be a foolish thing to do but another (different) amd64 box doesn't hang. I don't believe this to be amd64 specific, I suspect that there's something strange about this hardware. There are very many BIOS options and I feel like I've tried them all without getting anywhere. I'm "on holiday" this week and I've borrowed a box to test. Any suggestions would be welcome. I'll (re)try anything but I need help to stay focused. Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other thread (which may bear fruit more quickly). I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. dmesg after sig [AHCI disabled, SATA legacy mode] Thanks -- ian j hart %dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 UTC 2008 root@palmer.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 real memory = 2145845248 (2046 MB) avail memory = 2059509760 (1964 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 01:41:13) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8601000-0xd86013ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib3: irq 16 at device 28.0 on pci0 pci5: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:64:22:fa pcib5: irq 17 at device 28.5 on pci0 pci15: on pcib5 em1: port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 17 at device 0.0 on pci15 em1: Ethernet address: 00:30:48:64:22:fb uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] usb6: on uhci5 usb6: USB revision 1.0 uhub6: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd8601400-0xd86017ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pci17: on pcib6 pci17: at device 3.0 (no driver attached) atapci0: port 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f irq 23 at device 4.0 on pci17 ata2: on atapci0 ata3: on atapci0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c10-0x1c1f,0x1c00-0x1c0f at device 31.2 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 31.3 (no driver attached) atapci2: port 0x1c68-0x1c6f,0x1c5c-0x1c5f,0x1c60-0x1c67,0x1c58-0x1c5b,0x1c30-0x1c3f,0x1c20-0x1c2f irq 18 at device 31.5 on pci0 ata4: on atapci2 ata5: on atapci2 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model VersaPad, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detected. ad0: 305245MB at ata0-master SATA300 acd0: DVDROM at ata2-slave UDMA33 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/ad0s1a From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:17:40 2008 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 9686F1065695 for ; Tue, 22 Jul 2008 16:17:40 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 455638FC38 for ; Tue, 22 Jul 2008 16:17:40 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so316137yxb.13 for ; Tue, 22 Jul 2008 09:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:message-id :in-reply-to:references:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance:sender; bh=5XUBpfCmY/fWbLLR6TfeBH7yaoAsPlqPyCjwmgFyGZA=; b=bxEqxaCbHDo9O7LPBHU1b+fyZaXqQlKJLSzAG6Ci5AX6uGLpDZzQyGOabTC74friXL t453F/LRoIsfzqyonp+5sCSv/Do7m3gOqAUSYS/u20jZWUW06NYMFRTkaadehJQyq7kL VYjepOCgodnwHSZyVFGRg+KETea0/rlnosL5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance:sender; b=xM5DK5mHBzIwZDEEFbjqXvwa4EsP/nmEBJVoh3GgJZHm8rVwOsIztAlpNnHzu6PDjC n4a8HHi4J8hnUfF8B31PDqCNSYmNAw1/53ZboL0ZQxcFQVfhTfNbsveXCDMWiEpeE0dl cXQI89UgmYzPvrpF90sUj3jXBbWqJG069nP4k= Received: by 10.151.155.10 with SMTP id h10mr5692756ybo.96.1216743459376; Tue, 22 Jul 2008 09:17:39 -0700 (PDT) Received: from cygnus.homeunix.com ( [189.71.23.16]) by mx.google.com with ESMTPS id 7sm2075923ywo.7.2008.07.22.09.17.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jul 2008 09:17:38 -0700 (PDT) Received: by cygnus.homeunix.com (Postfix, from userid 80) id 85416EB; Tue, 22 Jul 2008 13:17:31 -0300 (BRT) Received: from 200.252.157.118 (proxying for 10.12.1.211, 10.12.1.3) (SquirrelMail authenticated user matheus@eternamente.info) by cygnus.homeunix.com with HTTP; Tue, 22 Jul 2008 13:17:31 -0300 (BRT) Message-ID: In-Reply-To: <20080722090703.GD3241@garage.freebsd.pl> References: <4F9C9299A10AE74E89EA580D14AA10A61A197A@royal64.emp.zapto.org> <20080719221813.GC4733@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197E@royal64.emp.zapto.org> <20080721090235.GA2953@garage.freebsd.pl> <4F9C9299A10AE74E89EA580D14AA10A61A197F@royal64.emp.zapto.org> <20080721135156.GA6310@garage.freebsd.pl> <1cb3959e4dbda185cbba0150f4884413.squirrel@cygnus.homeunix.com> <20080722090703.GD3241@garage.freebsd.pl> Date: Tue, 22 Jul 2008 13:17:31 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: Nenhum_de_Nos Subject: Re: Panic on ZFS startup after crash 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, 22 Jul 2008 16:17:40 -0000 On Tue, July 22, 2008 06:07, Pawel Jakub Dawidek wrote: > On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: >> > The ZFS code in 7.0 is the same as in HEAD, so no worries. >> >> I'm trying zfs myself in a small enviroment at home, but for that I do >> follow 7-STABLE. there's no need to do that, as based in the above >> statement ? > > There might be some small differences, but the patches I provide here > will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! ok, but my main wonder was about to be using the most new but stable zfs code :) do I keep running stable ? thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:19:58 2008 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 880FE1065675; Tue, 22 Jul 2008 16:19:58 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 64F2E8FC1B; Tue, 22 Jul 2008 16:19:58 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 058461CC0A6; Tue, 22 Jul 2008 09:19:58 -0700 (PDT) Date: Tue, 22 Jul 2008 09:19:58 -0700 From: Jeremy Chadwick To: Mikhail Teterin Message-ID: <20080722161958.GA11139@eos.sc1.parodius.com> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48860725.9050808@aldan.algebra.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Kris Kennaway , questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 16:19:58 -0000 On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: > Kris Kennaway ???????(??): >> Mikhail Teterin wrote: >>> Hello! >>> >>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>> Ctrl-T produces: >>> >>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>> 0% 0k >>> >>> (tcsh is used by OOo's build-script). What is this "sleeping without >>> queue" state, and why is process in it for so long? >>> >>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>> is currently in use and the box seems to be perfectly fine otherwise. >>> Uptime is 55 days, two different X-sessions are functional... The >>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>> >>> Thanks! >> >> What is the process backtrace? > Hard to say... The process ID 79759. According to ps(1), that PID exists: > 79759 p6 DE+ 0:00,00 /bin/tcsh -fc > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend > @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc > According to gdb, it does not: > gdb 79759 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"...79759: No such file > or directory. Syntax appears wrong; "gdb [program] 79759" would be what you want. -- | Jeremy Chadwick jdc at 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 Tue Jul 22 16:20:28 2008 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 1B255106564A for ; Tue, 22 Jul 2008 16:20:28 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF0C8FC17 for ; Tue, 22 Jul 2008 16:20:27 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 957B8D00BD; Tue, 22 Jul 2008 06:20:26 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id BE41A153882; Tue, 22 Jul 2008 06:20:25 -1000 (HST) Date: Tue, 22 Jul 2008 06:20:25 -1000 From: Clifton Royston To: Oliver Fromme Message-ID: <20080722162024.GA1279@lava.net> Mail-Followup-To: Oliver Fromme , freebsd-stable@FreeBSD.ORG References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807221552.m6MFqgpm009488@lurza.secnetix.de> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 16:20:28 -0000 On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > Brett Glass wrote: > > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > > > Don't forget that ANY server that caches data, including an end system > > > running a caching only server is vulnerable. > > > > Actually, there is an exception to this. A "forward only" > > cache/resolver is only as vulnerable as its forwarder(s). This is a > > workaround for the vulnerability for folks who have systems that they > > cannot easily upgrade: point at a trusted forwarder that's patched. > > > > We're also looking at using dnscache from the djbdns package. > > I'm curious, is djbdns exploitable, too? Does it randomize > the source ports of UDP queries? AFAIK Dan Bernstein first spelled out the fundamental problems with DNS response forgery in 2001. He implemented dnscache to randomize source ports and IDs from the beginning, via a cryptographic quality RNG. See for instance this page, much of it written in 2003: He rubs a lot of people the wrong way, but I think he has usually proved to be right on security issues. I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:22:43 2008 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 917D51065674 for ; Tue, 22 Jul 2008 16:22:43 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.freebsd.org (Postfix) with ESMTP id 705FB8FC1A for ; Tue, 22 Jul 2008 16:22:43 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 30972 invoked from network); 22 Jul 2008 16:22:43 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 16:22:42 -0000 Message-ID: <4886094F.4020101@aldan.algebra.com> Date: Tue, 22 Jul 2008 12:22:39 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Jeremy Chadwick References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> In-Reply-To: <20080722161958.GA11139@eos.sc1.parodius.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Kris Kennaway , questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 16:22:43 -0000 Jeremy Chadwick ÎÁÐÉÓÁ×(ÌÁ): > On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: > >> Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): >> >>> Mikhail Teterin wrote: >>> >>>> Hello! >>>> >>>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>>> Ctrl-T produces: >>>> >>>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>>> 0% 0k >>>> >>>> (tcsh is used by OOo's build-script). What is this "sleeping without >>>> queue" state, and why is process in it for so long? >>>> >>>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>>> is currently in use and the box seems to be perfectly fine otherwise. >>>> Uptime is 55 days, two different X-sessions are functional... The >>>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>>> >>> What is the process backtrace? >>> >> Hard to say... The process ID 79759. According to ps(1), that PID exists: >> 79759 p6 DE+ 0:00,00 /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend >> @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc >> According to gdb, it does not: >> [...] > Syntax appears wrong; "gdb [program] 79759" would be what you want. > Yes, indeed. The result is similar, though: % gdb /bin/tcsh 79759 [...] Attaching to program: /bin/tcsh, process 79759 ptrace: No such process. /meow/ports/79759: No such file or directory. Thanks, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:27:58 2008 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 899D61065674 for ; Tue, 22 Jul 2008 16:27:58 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id F19098FC14 for ; Tue, 22 Jul 2008 16:27:57 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080722163258.QLUU28496.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 22 Jul 2008 17:32:58 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080722163436.LEYU16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com> for ; Tue, 22 Jul 2008 17:34:36 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6MGRr6Q076713 for ; Tue, 22 Jul 2008 17:27:53 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Tue, 22 Jul 2008 17:27:52 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221727.52718.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Subject: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 22 Jul 2008 16:27:58 -0000 Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Thanks -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:37:17 2008 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 8A90C1065681 for ; Tue, 22 Jul 2008 16:37:17 +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 1DE5A8FC1D for ; Tue, 22 Jul 2008 16:37:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 12372 invoked by uid 399); 22 Jul 2008 16:37:16 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2008 16:37:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48860CBA.6010903@FreeBSD.org> Date: Tue, 22 Jul 2008 09:37:14 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> In-Reply-To: <20080722162024.GA1279@lava.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 16:37:17 -0000 Clifton Royston wrote: > I also think that modular design of security-sensitive tools is the > way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:37:24 2008 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 870BC1065683 for ; Tue, 22 Jul 2008 16:37:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACD68FC16 for ; Tue, 22 Jul 2008 16:37:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 61B8B1CC0A7; Tue, 22 Jul 2008 09:37:24 -0700 (PDT) Date: Tue, 22 Jul 2008 09:37:24 -0700 From: Jeremy Chadwick To: ian j hart Message-ID: <20080722163724.GA11757@eos.sc1.parodius.com> References: <200807221727.52718.ianjhart@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807221727.52718.ianjhart@ntlworld.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 22 Jul 2008 16:37:24 -0000 On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > Same hardware as my other thread. > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > [using 2Gb RAM and SATA in legacy mode] > > I'd like to focus only on making the CDROM boot complete. > > Summary: hangs just after the CPUs are launched. > > 6.2-RELEASE works okay, no AHCI support > 6.3-RELEASE works okay > 7.0-RELEASE hangs > 7.0-STABLE-200806-SNAPSHOT hangs > 8.0-CURRENT-200806-SNAPSHOT hangs > > I thought I could do a binary search using the current snapshot boot-only CDs > but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date --> Set to GMT, not local time!!! * Serial ATA --> SATA Controller Mode --> Enhanced --> SATA AHCI --> Enabled * Advanced * Boot Features --> Quiet Mode --> Disabled --> Enable Multimedia Timer --> Enabled * PCI Configuration --> Onboard G-LAN1 OPROM --> Disabled --> Large Disk Access Mode --> Other * Advanced Processor Options --> Intel(R) Virtualization Technology --> Enabled --> C1 Enhanced Mode --> Enabled -- | Jeremy Chadwick jdc at 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 Tue Jul 22 16:39:22 2008 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 7C775106567E for ; Tue, 22 Jul 2008 16:39:22 +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 D84848FC2A for ; Tue, 22 Jul 2008 16:39:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15927 invoked by uid 399); 22 Jul 2008 16:39:21 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2008 16:39:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48860D38.6060209@FreeBSD.org> Date: Tue, 22 Jul 2008 09:39:20 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: cpghost References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> In-Reply-To: <20080722160542.GA14592@epia-2.farid-hajji.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 16:39:22 -0000 cpghost wrote: > Yes indeed. If I understand all this correctly, it's because the > transaction ID that has to be sent back is only 2 bytes long, 2 bits, 16 bytes. > and if the query port doesn't change as well with every query, that > can be cracked in milliseconds: sending 65536 DNS queries to a > constant port is just way too easy! The namespace is way too small, > and there's no way to fix this by switching to, say, 4 bytes or > even more for the transaction ID without breaking existing > resolvers; actually without breaking the protocol itself. That's more or less accurate, yes. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:45:01 2008 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 7427E1065677; Tue, 22 Jul 2008 16:45:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 42C1B8FC1D; Tue, 22 Jul 2008 16:44:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48860E8C.6050400@FreeBSD.org> Date: Tue, 22 Jul 2008 18:45:00 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jeremy Chadwick References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> In-Reply-To: <20080722161958.GA11139@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mikhail Teterin , stable@FreeBSD.org, questions@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 16:45:01 -0000 Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: >> Kris Kennaway ???????(??): >>> Mikhail Teterin wrote: >>>> Hello! >>>> >>>> My attempt to build openoffice.org-3 seems to be hanging. Pressing >>>> Ctrl-T produces: >>>> >>>> load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s >>>> 0% 0k >>>> >>>> (tcsh is used by OOo's build-script). What is this "sleeping without >>>> queue" state, and why is process in it for so long? >>>> >>>> This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap >>>> is currently in use and the box seems to be perfectly fine otherwise. >>>> Uptime is 55 days, two different X-sessions are functional... The >>>> kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. >>>> >>>> Thanks! >>> What is the process backtrace? >> Hard to say... The process ID 79759. According to ps(1), that PID exists: >> 79759 p6 DE+ 0:00,00 /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend >> @/tmp/mk2WUYYi > ../../../unxfbsdx.pro/misc/s_addincol.dpcc >> According to gdb, it does not: >> gdb 79759 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"...79759: No such file >> or directory. > > Syntax appears wrong; "gdb [program] 79759" would be what you want. > Well, I mean kernel backtrace. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:46:50 2008 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 105571065676 for ; Tue, 22 Jul 2008 16:46:50 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.freebsd.org (Postfix) with ESMTP id E924D8FC18 for ; Tue, 22 Jul 2008 16:46:49 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 27897 invoked from network); 22 Jul 2008 16:46:49 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 16:46:49 -0000 Message-ID: <48860EF6.2040007@aldan.algebra.com> Date: Tue, 22 Jul 2008 12:46:46 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Kris Kennaway References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> In-Reply-To: <48860E8C.6050400@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Jeremy Chadwick , questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 16:46:50 -0000 Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): > Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:01:57 2008 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 45E8A1065670; Tue, 22 Jul 2008 17:01:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28AFF8FC12; Tue, 22 Jul 2008 17:01:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48861284.1050706@FreeBSD.org> Date: Tue, 22 Jul 2008 19:01:56 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mikhail Teterin References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> In-Reply-To: <48860EF6.2040007@aldan.algebra.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Jeremy Chadwick , questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 17:01:57 -0000 Mikhail Teterin wrote: > Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): >> Well, I mean kernel backtrace. > Can I obtain that remotely and without restarting/panicking the box? > Thanks, > > -mi > > kgdb on /dev/mem or procstat Kris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:03:51 2008 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 AC742106567E; Tue, 22 Jul 2008 17:03:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 28A3A8FC30; Tue, 22 Jul 2008 17:03:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 5BDBED011C; Tue, 22 Jul 2008 07:03:50 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id D6ECB153882; Tue, 22 Jul 2008 07:03:49 -1000 (HST) Date: Tue, 22 Jul 2008 07:03:49 -1000 From: Clifton Royston To: Doug Barton Message-ID: <20080722170348.GB1279@lava.net> Mail-Followup-To: Doug Barton , freebsd-stable@freebsd.org References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48860CBA.6010903@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 17:03:51 -0000 On Tue, Jul 22, 2008 at 09:37:14AM -0700, Doug Barton wrote: > Clifton Royston wrote: > > I also think that modular design of security-sensitive tools is the > >way to go, with his DNS tools as with Postfix. > > Dan didn't write postfix, he wrote qmail. I know, but I think qmail sucks. Wietse didn't write a DNS server or I'd probably be using that. :-) > If you're interested in a resolver-only solution (and that is not a > bad way to go) then you should evaluate dns/unbound. It is a > lightweight resolver-only server that has a good security model and > already implements query port randomization. It also has the advantage > of being maintained, and compliant to 21st Century DNS standards > including DNSSEC (which, btw, is the real solution to the response > forgery problem, it just can't be deployed universally before 8/5). Sounds interesting; is it a caching resolver? I'm not totally convinced DNSSEC would solve everything (though it would solve the current vulnerability) but I'm not sure I follow the arguments pro and con. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:07:28 2008 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 B49D3106569B; Tue, 22 Jul 2008 17:07:28 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id EC3118FC0A; Tue, 22 Jul 2008 17:07:27 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 2D8F3D0125; Tue, 22 Jul 2008 07:07:27 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 0ED65153882; Tue, 22 Jul 2008 07:07:27 -1000 (HST) Date: Tue, 22 Jul 2008 07:07:26 -1000 From: Clifton Royston To: Doug Barton Message-ID: <20080722170726.GC1279@lava.net> Mail-Followup-To: Doug Barton , freebsd-stable@FreeBSD.ORG References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> <48860D38.6060209@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48860D38.6060209@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 17:07:28 -0000 On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: > cpghost wrote: > >Yes indeed. If I understand all this correctly, it's because the > >transaction ID that has to be sent back is only 2 bytes long, > > 2 bits, 16 bytes. ^^^^ ^^^^^ Think you mean those the other way! > >and if the query port doesn't change as well with every query, that > >can be cracked in milliseconds: sending 65536 DNS queries to a > >constant port is just way too easy! The namespace is way too small, > >and there's no way to fix this by switching to, say, 4 bytes or > >even more for the transaction ID without breaking existing > >resolvers; actually without breaking the protocol itself. > > That's more or less accurate, yes. > > Doug I just saw mention in Infoworld - adequate details of the exploit were guessed by another developer and then confirmed. They're now circulating, so I think we can expect engineered attacks soon. All: Upgrade your servers today, do not wait. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:09:30 2008 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 A22721065690 for ; Tue, 22 Jul 2008 17:09:30 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id 821058FC2B for ; Tue, 22 Jul 2008 17:09:30 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 17825 invoked from network); 22 Jul 2008 17:09:30 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 17:09:29 -0000 Message-ID: <48861448.7020708@aldan.algebra.com> Date: Tue, 22 Jul 2008 13:09:28 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Kris Kennaway References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> In-Reply-To: <48861284.1050706@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Jeremy Chadwick , questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 17:09:30 -0000 Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): > Mikhail Teterin wrote: >> Kris Kennaway ÎÁÐÉÓÁ×(ÌÁ): >>> Well, I mean kernel backtrace. >> Can I obtain that remotely and without restarting/panicking the box? >> Thanks, > kgdb on /dev/mem or procstat root@aldan:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x0000000000000000 in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: root@aldan:~ (108) locate procstat root@aldan:~ (109) procstat procstat: îÅצÄÏÍÁ ËÏÍÁÎÄÁ. root@aldan:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:13:30 2008 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 E83D71065675 for ; Tue, 22 Jul 2008 17:13:30 +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 5BCDE8FC20 for ; Tue, 22 Jul 2008 17:13:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13674 invoked by uid 399); 22 Jul 2008 17:13:29 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2008 17:13:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48861537.6060406@FreeBSD.org> Date: Tue, 22 Jul 2008 10:13:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Doug Barton , freebsd-stable@FreeBSD.ORG References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722160542.GA14592@epia-2.farid-hajji.net> <48860D38.6060209@FreeBSD.org> <20080722170726.GC1279@lava.net> In-Reply-To: <20080722170726.GC1279@lava.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 17:13:31 -0000 Clifton Royston wrote: > On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: >> cpghost wrote: >>> Yes indeed. If I understand all this correctly, it's because the >>> transaction ID that has to be sent back is only 2 bytes long, >> 2 bits, 16 bytes. > ^^^^ ^^^^^ Think you mean those the other way! Oops, ELACKOFCAFFEINE >>> and if the query port doesn't change as well with every query, that >>> can be cracked in milliseconds: sending 65536 DNS queries to a >>> constant port is just way too easy! The namespace is way too small, >>> and there's no way to fix this by switching to, say, 4 bytes or >>> even more for the transaction ID without breaking existing >>> resolvers; actually without breaking the protocol itself. >> That's more or less accurate, yes. >> >> Doug > > I just saw mention in Infoworld - adequate details of the exploit > were guessed by another developer and then confirmed. They're now > circulating, so I think we can expect engineered attacks soon. > > All: > Upgrade your servers today, do not wait. Agreed on both counts. -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:16:57 2008 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 2CA7A106564A; Tue, 22 Jul 2008 17:16:57 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD198FC1B; Tue, 22 Jul 2008 17:16:56 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.2/8.14.2) with ESMTP id m6MHGnJL047138; Tue, 22 Jul 2008 18:16:51 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.6.0 smtp.infracaninophile.co.uk m6MHGnJL047138 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1216747011; bh=rRhF8ZkMD9JL+b 6pQ8hDfkF+aMjeV/wwvn4KDRhvHdo=; h=Message-ID:Date:From:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type:Cc:Content-Type: Date:From:In-Reply-To:Message-ID:Mime-Version:References:To; z=Mes sage-ID:=20<488615F5.80405@infracaninophile.co.uk>|Date:=20Tue,=202 2=20Jul=202008=2018:16:37=20+0100|From:=20Matthew=20Seaman=20|Organization:=20Infracaninophile|User-A gent:=20Thunderbird=202.0.0.14=20(X11/20080607)|MIME-Version:=201.0 |To:=20Doug=20Barton=20|CC:=20freebsd-stable@fre ebsd.org|Subject:=20Re:=20FreeBSD=207.1=20and=20BIND=20exploit|Refe rences:=20<200807212219.QAA01486@lariat.net>=09<200807221552.m6MFqg pm009488@lurza.secnetix.de>=09<20080722162024.GA1279@lava.net>=20<4 8860CBA.6010903@FreeBSD.org>|In-Reply-To:=20<48860CBA.6010903@FreeB SD.org>|X-Enigmail-Version:=200.95.6|Content-Type:=20multipart/sign ed=3B=20micalg=3Dpgp-sha256=3B=0D=0A=20protocol=3D"application/pgp- signature"=3B=0D=0A=20boundary=3D"------------enig32912119FCAFC30F8 F21FE78"; b=vWeGBd3DmDMvr7J5QSueiWNT8O05aUcDvzsl2MQ3dSK9zJIKnashagU bGaaPGT29708keYhilsTJLf/3dMP5cW1pzz2HUIYgfcQyMYzFQu0dsvi/NTLNoSF7uV j3/G4F3aGcNscvVQyj94E+3K4PTBC2RWri79AmCuQl1tbulCI= Message-ID: <488615F5.80405@infracaninophile.co.uk> Date: Tue, 22 Jul 2008 18:16:37 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.14 (X11/20080607) MIME-Version: 1.0 To: Doug Barton References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> In-Reply-To: <48860CBA.6010903@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig32912119FCAFC30F8F21FE78" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Tue, 22 Jul 2008 18:16:51 +0100 (BST) X-Virus-Scanned: ClamAV 0.93.3/7779/Tue Jul 22 10:22:01 2008 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 17:16:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig32912119FCAFC30F8F21FE78 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > Clifton Royston wrote: >> I also think that modular design of security-sensitive tools is the >> way to go, with his DNS tools as with Postfix. >=20 > Dan didn't write postfix, he wrote qmail. >=20 > If you're interested in a resolver-only solution (and that is not a bad= =20 > way to go) then you should evaluate dns/unbound. It is a lightweight=20 > resolver-only server that has a good security model and already=20 > implements query port randomization. It also has the advantage of being= =20 > maintained, and compliant to 21st Century DNS standards including DNSSE= C Are there any plans to enable DNSSEC capability in the resolver built int= o FreeBSD? > (which, btw, is the real solution to the response forgery problem, it=20 > just can't be deployed universally before 8/5). That big announcement Dan Kaminsky was going to make at the Blackhat Conference in August? Unfortunately the cat has already been let out of the bag: http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally= -leaked.html There's no implementation of DNS that can be any /more/ proof against thi= s than BIND+latest patches because the problem is intrinsic to the design o= f=20 the DNS protocol. You'ld better be patched up or using alternative DNS=20 implementations equally secure already. Even so that just increases the = search space from about 16bits to about 30bits, which should make it not = really feasible given current network and server capabilities. =20 Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig32912119FCAFC30F8F21FE78 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiGFgEACgkQ8Mjk52CukIz1HQCcCFdf9JQLDJ859kpJswu4k/Qz Cu0An3seGbFxOB3bbGAyOZHkKrLiWAmt =yS2R -----END PGP SIGNATURE----- --------------enig32912119FCAFC30F8F21FE78-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:27:44 2008 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 7CE4F1065679 for ; Tue, 22 Jul 2008 17:27:44 +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 19E078FC1C for ; Tue, 22 Jul 2008 17:27:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 12775 invoked by uid 399); 22 Jul 2008 17:27:43 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2008 17:27:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4886188E.6090805@FreeBSD.org> Date: Tue, 22 Jul 2008 10:27:42 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Matthew Seaman References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> In-Reply-To: <488615F5.80405@infracaninophile.co.uk> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 17:27:44 -0000 Matthew Seaman wrote: > Are there any plans to enable DNSSEC capability in the resolver built > into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of "trust anchors" (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:28:13 2008 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 BDF401065675 for ; Tue, 22 Jul 2008 17:28:13 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA5B8FC16 for ; Tue, 22 Jul 2008 17:28:13 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,232,1215406800"; d="scan'208";a="4138822" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 22 Jul 2008 11:59:11 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 885FF23DDF for ; Tue, 22 Jul 2008 11:59:12 -0500 (CDT) Date: Tue, 22 Jul 2008 11:59:11 -0500 From: Paul Schmehl To: freebsd-stable@freebsd.org Message-ID: <24AEB3BFE15219E4ADA1F2E9@utd65257.utdallas.edu> In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:28:13 -0000 --On Tuesday, July 22, 2008 09:37:14 -0700 Doug Barton wrote: > Clifton Royston wrote: >> I also think that modular design of security-sensitive tools is the >> way to go, with his DNS tools as with Postfix. > > Dan didn't write postfix, he wrote qmail. I think his point was that djbdns is modular just like Postfix is modular - not that Dan wrote both. I'm pretty sure everyone on the planet knows that Weitse wrote/maintains Postfix. If djbdns was as easy to setup as Postfix is, I'd use it too. > > If you're interested in a resolver-only solution (and that is not a bad way > to go) then you should evaluate dns/unbound. It is a lightweight > resolver-only server that has a good security model and already implements > query port randomization. It also has the advantage of being maintained, and > compliant to 21st Century DNS standards including DNSSEC (which, btw, is the > real solution to the response forgery problem, it just can't be deployed > universally before 8/5). > What happens on 8/5? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:47:44 2008 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 EA1961065689 for ; Tue, 22 Jul 2008 17:47:44 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id BBBB98FC1E for ; Tue, 22 Jul 2008 17:47:40 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080722175242.SERB28496.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Tue, 22 Jul 2008 18:52:42 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080722175842.BXAR8797.aamtaout03-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com>; Tue, 22 Jul 2008 18:58:42 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6MHlZ4M077627; Tue, 22 Jul 2008 18:47:35 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: Jeremy Chadwick Date: Tue, 22 Jul 2008 18:47:34 +0100 User-Agent: KMail/1.9.7 References: <200807221727.52718.ianjhart@ntlworld.com> <20080722163724.GA11757@eos.sc1.parodius.com> In-Reply-To: <20080722163724.GA11757@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200807221847.34935.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Cc: freebsd-stable@freebsd.org Subject: Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 22 Jul 2008 17:47:45 -0000 On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > Same hardware as my other thread. > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > [using 2Gb RAM and SATA in legacy mode] > > > > I'd like to focus only on making the CDROM boot complete. > > > > Summary: hangs just after the CPUs are launched. > > > > 6.2-RELEASE works okay, no AHCI support > > 6.3-RELEASE works okay > > 7.0-RELEASE hangs > > 7.0-STABLE-200806-SNAPSHOT hangs > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > I thought I could do a binary search using the current snapshot boot-only > > CDs but they only go back to March. Are there any older ones available? > > Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is "best"? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint > > Also, AHCI should work just fine on those systems -- I know because I > have fairly extensive experience with Supermicro hardware, although what > you're using is newer than what I presently have. I don't know why > you're setting Compatible/Legacy mode on your controller (you mention > doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. > > Below is what we use on our systems; factory defaults, then make the > following changes. (The G-LAN1 OPROM option you can do whatever you > want with -- it's specific to our environment). > > * Main > * Date > --> Set to GMT, not local time!!! > * Serial ATA > --> SATA Controller Mode --> Enhanced > --> SATA AHCI --> Enabled > > * Advanced > * Boot Features > --> Quiet Mode --> Disabled > --> Enable Multimedia Timer --> Enabled > * PCI Configuration > --> Onboard G-LAN1 OPROM --> Disabled > --> Large Disk Access Mode --> Other > * Advanced Processor Options > --> Intel(R) Virtualization Technology --> Enabled > --> C1 Enhanced Mode --> Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Thanks for your help. -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 17:52:16 2008 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 3CA2C1065689 for ; Tue, 22 Jul 2008 17:52:16 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 110BE8FC1F for ; Tue, 22 Jul 2008 17:52:15 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,232,1215406800"; d="scan'208";a="4141258" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 22 Jul 2008 12:52:15 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 3947B23DE2; Tue, 22 Jul 2008 12:52:16 -0500 (CDT) Date: Tue, 22 Jul 2008 12:52:15 -0500 From: Paul Schmehl To: Doug Barton , Matthew Seaman Message-ID: <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> In-Reply-To: <4886188E.6090805@FreeBSD.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:52:16 -0000 --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton wrote: > Matthew Seaman wrote: > >> Are there any plans to enable DNSSEC capability in the resolver built >> into FreeBSD? > > The server is already capable of it. I'm seriously considering enabling the > define to make the CLI tools (dig/host/nslookup) capable as well (there is > already an OPTION for this in ports). > > The problem is that _using_ DNSSEC requires configuration changes in > named.conf, and more importantly, configuration of "trust anchors" (even for > the command line stuff) since the root is not signed. It's not hard to do > that with the DLV system that ISC has in place, and I would be willing to > create a conf file that shows how to do that for users to include if they > choose to. I am not comfortable enabling it by default (not yet anyway), it's > too big of a POLA issue. > I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named.ca gets updated automagically every month.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 18:34:15 2008 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 A22701065680 for ; Tue, 22 Jul 2008 18:34:15 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id E25B98FC20 for ; Tue, 22 Jul 2008 18:34:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 47736 invoked from network); 22 Jul 2008 18:07:33 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Jul 2008 18:07:33 -0000 Date: Tue, 22 Jul 2008 20:07:09 +0200 (CEST) Message-Id: <20080722.200709.74704291.sthaug@nethelp.no> To: dougb@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <48860CBA.6010903@FreeBSD.org> References: <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 18:34:15 -0000 > If you're interested in a resolver-only solution (and that is not a > bad way to go) then you should evaluate dns/unbound. It is a > lightweight resolver-only server that has a good security model and > already implements query port randomization. It also has the advantage > of being maintained, and compliant to 21st Century DNS standards > including DNSSEC (which, btw, is the real solution to the response > forgery problem, it just can't be deployed universally before 8/5). I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, uniprocessor, 32 bit mode, 2 GB memory). Don't know what I'm doing wrong so far - but I've been unable to scale Unbound to more than a couple of hundred q/s. Any more than that and I get serious (several hundred ms) delays on lots of queries, including stuff which is known to be in the cache. I'll be doing some more Unbound tests the next few days. For now, both CNS and PowerDNS handle our load (around 2.5K q/s) fine. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 18:37:45 2008 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 A36AB106567D; Tue, 22 Jul 2008 18:37:45 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5288FC15; Tue, 22 Jul 2008 18:37:44 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.2/8.14.2) with ESMTP id m6MIbcpL050539; Tue, 22 Jul 2008 19:37:39 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.6.0 smtp.infracaninophile.co.uk m6MIbcpL050539 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1216751859; bh=9ejlIqZIt78k0i /WcbiP21+hiiayPw8xGz8ag60FZhA=; h=Message-ID:Date:From:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type:Cc:Content-Type: Date:From:In-Reply-To:Message-ID:Mime-Version:References:To; z=Mes sage-ID:=20<488628EC.5030801@infracaninophile.co.uk>|Date:=20Tue,=2 022=20Jul=202008=2019:37:32=20+0100|From:=20Matthew=20Seaman=20|Organization:=20Infracaninophile|User -Agent:=20Thunderbird=202.0.0.14=20(X11/20080607)|MIME-Version:=201 .0|To:=20Doug=20Barton=20|CC:=20freebsd-stable@F reeBSD.org|Subject:=20Re:=20FreeBSD=207.1=20and=20BIND=20exploit|Re ferences:=20<200807212219.QAA01486@lariat.net>=09<200807221552.m6MF qgpm009488@lurza.secnetix.de>=09<20080722162024.GA1279@lava.net>=20 <48860CBA.6010903@FreeBSD.org>=20<488615F5.80405@infracaninophile.c o.uk>=20<4886188E.6090805@FreeBSD.org>|In-Reply-To:=20<4886188E.609 0805@FreeBSD.org>|X-Enigmail-Version:=200.95.6|Content-Type:=20mult ipart/signed=3B=20micalg=3Dpgp-sha256=3B=0D=0A=20protocol=3D"applic ation/pgp-signature"=3B=0D=0A=20boundary=3D"------------enig5488BAD 5E4511AF4D0C2864A"; b=Ysg05nFA+NNZieFZApzihsU3UpShFjjcOg/lGoZj6t/Ia 0T7O7Q/T/h3nm0+JyrPXHX9cUBXktanPC6nYZJBZ/Nv93tUtCq7IzL1gFrwqbPDCepg Ljcx9C+UhHEnxJnQ910k3WJgU6t/ivQLbbghYJBFp6hPlGrAUN8qqNEpWGQ= Message-ID: <488628EC.5030801@infracaninophile.co.uk> Date: Tue, 22 Jul 2008 19:37:32 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.14 (X11/20080607) MIME-Version: 1.0 To: Doug Barton References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> In-Reply-To: <4886188E.6090805@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5488BAD5E4511AF4D0C2864A" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Tue, 22 Jul 2008 19:37:39 +0100 (BST) X-Virus-Scanned: ClamAV 0.93.3/7781/Tue Jul 22 18:35:50 2008 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 18:37:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5488BAD5E4511AF4D0C2864A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > Matthew Seaman wrote: >=20 >> Are there any plans to enable DNSSEC capability in the resolver built = >> into FreeBSD? >=20 > The server is already capable of it. I'm seriously considering enabling= =20 > the define to make the CLI tools (dig/host/nslookup) capable as well=20 > (there is already an OPTION for this in ports). Forgive me for being obtuse. What I meant was the capability to enable c= hecking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Which I suppose simply means that if you're in the habit of, for example,= =20 taking your laptop into the coffee shop and getting on line there then yo= u=20 need to run your own instance of named on your laptop rather than blindly= =20 trusting whatever servers the coffee shop provides via their DHCP. > The problem is that _using_ DNSSEC requires configuration changes in=20 > named.conf, and more importantly, configuration of "trust anchors" (eve= n=20 > for the command line stuff) since the root is not signed. It's not hard= =20 > to do that with the DLV system that ISC has in place, and I would be=20 > willing to create a conf file that shows how to do that for users to=20 > include if they choose to. I am not comfortable enabling it by default = > (not yet anyway), it's too big of a POLA issue. I sense a business opportunity in providing DLV there. I'm wondering why= the likes of Verisign (including Thawte and Geotrust), Comodo group and=20 GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps th= ey=20 are. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig5488BAD5E4511AF4D0C2864A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiGKPIACgkQ8Mjk52CukIxbWACfTVCDPVViUJ0NTd5GLMMVU8bD xXkAniwbkPNqgVZYLi4a/5aQHYFxBHSo =T6Z8 -----END PGP SIGNATURE----- --------------enig5488BAD5E4511AF4D0C2864A-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 19:26:36 2008 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 173981065676 for ; Tue, 22 Jul 2008 19:26:36 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id CDF958FC21 for ; Tue, 22 Jul 2008 19:26:35 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 29769 invoked from network); 22 Jul 2008 19:26:34 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 19:26:33 -0000 Message-ID: <48863465.8080204@aldan.algebra.com> Date: Tue, 22 Jul 2008 15:26:29 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Kostik Belousov References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080722192155.GC17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Kris Kennaway , questions@freebsd.org, stable@freebsd.org, Jeremy Chadwick Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 19:26:36 -0000 Kostik Belousov ÎÁÐÉÓÁ×(ÌÁ): > Did you switched to the process before doing backtrace (using the proc > command)? Ok, thanks. Did not know about this one. Here: ... (kgdb) proc 79759 (kgdb) bt #0 sched_switch (td=0xffffff01286dc000, newtd=0xffffff00010ce000, flags=2) at /var/src/sys/kern/sched_4bsd.c:928 #1 0x0000000000000000 in ?? () #2 0xffffffff802f1108 in mi_switch (flags=678281216, newtd=0x2) at /var/src/sys/kern/kern_synch.c:442 #3 0xffffffff80318513 in sleepq_check_timeout () at /var/src/sys/kern/subr_sleepqueue.c:519 #4 0xffffffff80318c85 in sleepq_timedwait (wchan=0xffffffff80688408) at /var/src/sys/kern/subr_sleepqueue.c:597 #5 0xffffffff802f16a2 in _sleep (ident=0xffffffff80688408, lock=0x0, priority=0, wmesg=0xffffffff804f3059 "vmo_de", timo=1) at /var/src/sys/kern/kern_synch.c:224 #6 0xffffffff8043036b in vm_object_deallocate (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 #7 0xffffffff8042920e in vm_map_delete (map=0xffffff0015ba4b60, start=18446742979242478224, end=140737488355328) at /var/src/sys/vm/vm_map.c:2315 #8 0xffffffff804293df in vm_map_remove (map=0xffffff0015ba4b60, start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 #9 0xffffffff8042b813 in vmspace_exit (td=0xffffff01286dc000) at /var/src/sys/vm/vm_map.c:324 #10 0xffffffff802c8cff in exit1 (td=0xffffff01286dc000, rv=0) at /var/src/sys/kern/kern_exit.c:294 #11 0xffffffff802ca08e in sys_exit (td=Variable "td" is not available. ) at /var/src/sys/kern/kern_exit.c:98 #12 0xffffffff8045a700 in syscall (frame=0xffffffffb0d89c70) at /var/src/sys/amd64/amd64/trap.c:852 #13 0xffffffff8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #14 0x000000080095f34c in ?? () Previous frame inner to this frame (corrupt stack?) > What is the exact version of the system ? Note that procstat > appeared in the late RELENG_7. FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 > > Also, show the output of ps axl . UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 19:41:22 2008 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 14579106569D; Tue, 22 Jul 2008 19:41:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A51D08FC22; Tue, 22 Jul 2008 19:41:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6MJfFsm048898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 22:41:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6MJfEUO075632; Tue, 22 Jul 2008 22:41:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6MJfECJ075631; Tue, 22 Jul 2008 22:41:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Jul 2008 22:41:14 +0300 From: Kostik Belousov To: Mikhail Teterin Message-ID: <20080722194114.GE17123@deviant.kiev.zoral.com.ua> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> <48863465.8080204@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oltTW8qmWaTZVW5l" Content-Disposition: inline In-Reply-To: <48863465.8080204@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URI_NOVOWEL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , stable@freebsd.org, Jeremy Chadwick Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 19:41:22 -0000 --oltTW8qmWaTZVW5l Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: > Kostik Belousov =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >Did you switched to the process before doing backtrace (using the proc= =20 > > > >command)? > Ok, thanks. Did not know about this one. Here: > ... > (kgdb) proc 79759 > (kgdb) bt > #0 sched_switch (td=3D0xffffff01286dc000, newtd=3D0xffffff00010ce000,=20 > flags=3D2) at /var/src/sys/kern/sched_4bsd.c:928 > #1 0x0000000000000000 in ?? () > #2 0xffffffff802f1108 in mi_switch (flags=3D678281216, newtd=3D0x2) at= =20 > /var/src/sys/kern/kern_synch.c:442 > #3 0xffffffff80318513 in sleepq_check_timeout () at=20 > /var/src/sys/kern/subr_sleepqueue.c:519 > #4 0xffffffff80318c85 in sleepq_timedwait (wchan=3D0xffffffff80688408) a= t=20 > /var/src/sys/kern/subr_sleepqueue.c:597 > #5 0xffffffff802f16a2 in _sleep (ident=3D0xffffffff80688408, lock=3D0x0,= =20 > priority=3D0, wmesg=3D0xffffffff804f3059 "vmo_de", timo=3D1) at=20 > /var/src/sys/kern/kern_synch.c:224 > #6 0xffffffff8043036b in vm_object_deallocate=20 > (object=3D0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 =46rom this frame, please, print the object (like p *object) and likewise, print the object that is at the head of the object->shadow_head list. Another question is what scheduler do you use ? > #7 0xffffffff8042920e in vm_map_delete (map=3D0xffffff0015ba4b60,=20 > start=3D18446742979242478224, end=3D140737488355328) at=20 > /var/src/sys/vm/vm_map.c:2315 > #8 0xffffffff804293df in vm_map_remove (map=3D0xffffff0015ba4b60,=20 > start=3D0, end=3D140737488355328) at /var/src/sys/vm/vm_map.c:2423 > #9 0xffffffff8042b813 in vmspace_exit (td=3D0xffffff01286dc000) at=20 > /var/src/sys/vm/vm_map.c:324 > #10 0xffffffff802c8cff in exit1 (td=3D0xffffff01286dc000, rv=3D0) at=20 > /var/src/sys/kern/kern_exit.c:294 > #11 0xffffffff802ca08e in sys_exit (td=3DVariable "td" is not available. > ) at /var/src/sys/kern/kern_exit.c:98 > #12 0xffffffff8045a700 in syscall (frame=3D0xffffffffb0d89c70) at=20 > /var/src/sys/amd64/amd64/trap.c:852 > #13 0xffffffff8043f38b in Xfast_syscall () at=20 > /var/src/sys/amd64/amd64/exception.S:290 > #14 0x000000080095f34c in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > >What is the exact version of the system ? Note that procstat > >appeared in the late RELENG_7. > FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 > > > >Also, show the output of ps axl . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00=20 > /bin/tcsh -fc=20 > /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.p= ro/bin/ma It makes sense to show the whole ps axl output. >=20 > Yours, >=20 > -mi --oltTW8qmWaTZVW5l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiGN9oACgkQC3+MBN1Mb4gixACgzafvZTjueYYkuhWU6a5kJAae Ag4An1h8Q6MF39xIBFkAtSpLV0G0jFzZ =QzKi -----END PGP SIGNATURE----- --oltTW8qmWaTZVW5l-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 19:54:43 2008 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 0095D106566C; Tue, 22 Jul 2008 19:54:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 554EE8FC14; Tue, 22 Jul 2008 19:54:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6MJLtmE047673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 22:21:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6MJLtd7075208; Tue, 22 Jul 2008 22:21:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6MJLtDW075207; Tue, 22 Jul 2008 22:21:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Jul 2008 22:21:55 +0300 From: Kostik Belousov To: Mikhail Teterin Message-ID: <20080722192155.GC17123@deviant.kiev.zoral.com.ua> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ccySeEbMfjxkcnOC" Content-Disposition: inline In-Reply-To: <48861448.7020708@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , questions@freebsd.org, stable@freebsd.org, Jeremy Chadwick Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 19:54:43 -0000 --ccySeEbMfjxkcnOC Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: > Kris Kennaway =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >Mikhail Teterin wrote: > >>Kris Kennaway =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >>>Well, I mean kernel backtrace. > >>Can I obtain that remotely and without restarting/panicking the box?=20 > >>Thanks, > >kgdb on /dev/mem or procstat > root@aldan:~ (107) kgdb /boot/kernel/kernel /dev/mem > [...] > (kgdb) bt > #0 0x0000000000000000 in ?? () > Error accessing memory address 0x0: Bad address. >=20 > Even less luck with procstat: >=20 > root@aldan:~ (108) locate procstat > root@aldan:~ (109) procstat > procstat: =EE=C5=D7?=C4=CF=CD=C1 =CB=CF=CD=C1=CE=C4=C1. > root@aldan:~ (110) man procstat > No manual entry for procstat >=20 > I'm sorry, but you'll need to be more specific. What should I type? Thank= s, Did you switched to the process before doing backtrace (using the proc command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl . --ccySeEbMfjxkcnOC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiGM1EACgkQC3+MBN1Mb4i1GQCeKdXwhZ8vMvn3vn32c/qpPS0t yXwAniVeqfbnnS+VtS0kEL1SNURtFy8D =RCc9 -----END PGP SIGNATURE----- --ccySeEbMfjxkcnOC-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:00:00 2008 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 9E28510656E1 for ; Tue, 22 Jul 2008 20:00:00 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7991E8FC2C for ; Tue, 22 Jul 2008 20:00:00 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 31447 invoked from network); 22 Jul 2008 19:59:59 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Jul 2008 19:59:59 -0000 Message-ID: <48863C3D.7090401@aldan.algebra.com> Date: Tue, 22 Jul 2008 15:59:57 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Kostik Belousov References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> <48863465.8080204@aldan.algebra.com> <20080722194114.GE17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080722194114.GE17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Kris Kennaway , stable@freebsd.org, Jeremy Chadwick Subject: Re: "sleeping without queue" ? 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, 22 Jul 2008 20:00:00 -0000 Kostik Belousov ÎÁÐÉÓÁ×(ÌÁ): > On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: >> Kostik Belousov ÎÁÐÉÓÁ×(ÌÁ): >>> Did you switched to the process before doing backtrace (using the proc >>> >>> command)? >> Ok, thanks. Did not know about this one. Here: >> ... >> (kgdb) proc 79759 >> (kgdb) bt >> #0 sched_switch (td=0xffffff01286dc000, newtd=0xffffff00010ce000, >> flags=2) at /var/src/sys/kern/sched_4bsd.c:928 >> #1 0x0000000000000000 in ?? () >> #2 0xffffffff802f1108 in mi_switch (flags=678281216, newtd=0x2) at >> /var/src/sys/kern/kern_synch.c:442 >> #3 0xffffffff80318513 in sleepq_check_timeout () at >> /var/src/sys/kern/subr_sleepqueue.c:519 >> #4 0xffffffff80318c85 in sleepq_timedwait (wchan=0xffffffff80688408) at >> /var/src/sys/kern/subr_sleepqueue.c:597 >> #5 0xffffffff802f16a2 in _sleep (ident=0xffffffff80688408, lock=0x0, >> priority=0, wmesg=0xffffffff804f3059 "vmo_de", timo=1) at >> /var/src/sys/kern/kern_synch.c:224 >> #6 0xffffffff8043036b in vm_object_deallocate >> (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > From this frame, please, print the object (like p *object) and > likewise, print the object that is at the head of the object->shadow_head > list. kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". There is no member named pathname. Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Reading symbols from /opt/modules/rtc.ko...done. Loaded symbols for /opt/modules/rtc.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from /boot/kernel/msdosfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/msdosfs.ko #0 0x0000000000000000 in ?? () (kgdb) frame 6 Error accessing memory address 0x0: Bad address. (kgdb) pid 79759 Undefined command: "pid". Try "help". (kgdb) proc 79759 (kgdb) frame 6 #6 0xffffffff8043036b in vm_object_deallocate (object=0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 509 pause("vmo_de", 1); (kgdb) p *object $1 = {mtx = {lock_object = {lo_name = 0xffffffff804f21c4 "vm object", lo_type = 0xffffffff804f3018 "standard object", lo_flags = 21168128, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, object_list = {tqe_next = 0xffffff0005018a90, tqe_prev = 0xffffff00539a6850}, shadow_head = {lh_first = 0xffffff005d3afa90}, shadow_list = {le_next = 0x0, le_prev = 0xffffff005d2cd048}, memq = { tqh_first = 0xffffff007eb9fa58, tqh_last = 0xffffff007f864820}, root = 0xffffff007ee14d38, size = 427, generation = 66, ref_count = 2, shadow_count = 1, type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0, resident_page_count = 44, backing_object = 0x0, backing_object_offset = 0, pager_object_list = { tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86, tqh_last = 0x0}}, swp = {swp_bcount = 576646}}} (kgdb) p (object->shadow_head) $2 = {lh_first = 0xffffff005d3afa90} (kgdb) p *object->shadow_head.lh_first $3 = {mtx = {lock_object = {lo_name = 0xffffffff804f21c4 "vm object", lo_type = 0xffffffff804f3018 "standard object", lo_flags = 21168128, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, object_list = {tqe_next = 0xffffff0066c32340, tqe_prev = 0xffffff012f673ac0}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xffffff0053024ad0}, memq = { tqh_first = 0xffffff007779f9a0, tqh_last = 0xffffff0077c04140}, root = 0xffffff0077c04130, size = 387, generation = 3, ref_count = 1, shadow_count = 0, type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0, resident_page_count = 2, backing_object = 0xffffff0053024a90, backing_object_offset = 163840, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = {vnp_size = 365278}, devp = {devp_pglist = { tqh_first = 0x592de, tqh_last = 0x0}}, swp = {swp_bcount = 365278}}} > > Another question is what scheduler do you use ? options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption >>> Also, show the output of ps axl . >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00 >> /bin/tcsh -fc >> /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma > > It makes sense to show the whole ps axl output. See http://aldan.algebra.com/~mi/tmp/ps-axl.txt -- I edited it for privacy a little bit, but process-states are intact. The java-processes in the linuxf have remained unkillable for weeks now -- I even forgot about them. But those are linuxulator problems, whereas the tcsh is native... Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:05:20 2008 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 799FC1065688 for ; Tue, 22 Jul 2008 20:05:20 +0000 (UTC) (envelope-from royce@alaska.net) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.173.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3880A8FC0A for ; Tue, 22 Jul 2008 20:05:20 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [10.0.102.101] (209-112-156-43-adslb0fh.acsalaska.net [209.112.156.43]) by iris.acsalaska.net (8.14.1/8.14.1) with ESMTP id m6MJjUOk025326; Tue, 22 Jul 2008 11:45:30 -0800 (AKDT) (envelope-from royce@alaska.net) Message-ID: <488638DA.7010005@alaska.net> Date: Tue, 22 Jul 2008 11:45:30 -0800 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.tycho.org/royce/royce@alaska.net.asc X-Face: ">19[ShfDD9'g", GrH$'v:=qBVZdg.kXSBR6*ZC$am:D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.4; spamdefang 1.122 Cc: Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 22 Jul 2008 20:05:20 -0000 We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. Other than switching to a debugging kernel, a little sysctl tuning, and patching with freebsd-update, they are stock. The debugging kernel was built from source that is also being patched with freebsd-update. These systems are running postfix and Courier imapd for an ISP with a userbase on the order of 10^4 users. They use gmirror, but the mailstore is over NFS. That NFS server is under pretty high load. All of the servers with this app and load pattern are panic'ing. I have little experience with kernel debugging, but the box in question is out of our farm and available for testing, and I am motivated to cooperate. :-) The full debugging kernel options I used are: include SMP options KDB options KDB_TRACE options DDB options BREAK_TO_DEBUGGER options WITNESS options WITNESS_SKIPSPIN db> trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 page_alloc(c1453780,1000,eba6a8bf,102,c06b8a84,...) at page_alloc+0x1a slab_zalloc(c1453780,102,c14537e0,c1453780,c1460d5c,...) at slab_zalloc+0xa1 uma_zone_slab(c1453780,2) at uma_zone_slab+0xf0 uma_zalloc_bucket(c1453780,2) at uma_zalloc_bucket+0x11c uma_zalloc_arg(c1453780,0,2) at uma_zalloc_arg+0x24c cache_enter(cd02c220,c9e62880,eba6a9fc) at cache_enter+0xa6 nfs_readdirplusrpc(cd02c220,eba6aa60,cc0ab880) at nfs_readdirplusrpc+0x6a6 nfs_doio(cd02c220,dce59668,cc0ab880,cc08b180,dce59668,...) at nfs_doio+0x20f nfs_bioread(cd02c220,eba6acb0,0,cc0ab880) at nfs_bioread+0xa64 nfs_readdir(eba6ac90) at nfs_readdir+0xe6 VOP_READDIR_APV(c09ebbc0,eba6ac90) at VOP_READDIR_APV+0x38 getdirentries(cc08b180,eba6ad04) at getdirentries+0x146 syscall(3b,3b,3b,9085f00,9085f00,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0xb825a79b, esp = 0xbfbfa1fc, ebp = 0xbfbfa228 --- Royce -- Royce D. Williams - http://royce.ws/ I don't like that man. I must get to know him better. - A. Lincoln From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:07:22 2008 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 C1321106566C; Tue, 22 Jul 2008 20:07:22 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id 775748FC21; Tue, 22 Jul 2008 20:07:22 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id CBD40421; Tue, 22 Jul 2008 13:07:21 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0540245048; Tue, 22 Jul 2008 13:07:20 -0700 (PDT) To: Paul Schmehl In-Reply-To: Your message of "Tue, 22 Jul 2008 12:52:15 CDT." <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1216757240_66746P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 22 Jul 2008 13:07:20 -0700 From: "Kevin Oberman" Message-Id: <20080722200720.0540245048@ptavv.es.net> Cc: freebsd-stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 20:07:23 -0000 --==_Exmh_1216757240_66746P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 22 Jul 2008 12:52:15 -0500 > From: Paul Schmehl > Sender: owner-freebsd-stable@freebsd.org > > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > > > Matthew Seaman wrote: > > > >> Are there any plans to enable DNSSEC capability in the resolver built > >> into FreeBSD? > > > > The server is already capable of it. I'm seriously considering enabling the > > define to make the CLI tools (dig/host/nslookup) capable as well (there is > > already an OPTION for this in ports). > > > > The problem is that _using_ DNSSEC requires configuration changes in > > named.conf, and more importantly, configuration of "trust anchors" (even for > > the command line stuff) since the root is not signed. It's not hard to do > > that with the DLV system that ISC has in place, and I would be willing to > > create a conf file that shows how to do that for users to include if they > > choose to. I am not comfortable enabling it by default (not yet anyway), it's > > too big of a POLA issue. > > > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. No one is likely to argue with that statement! > Once you implement DNSSEC you *must* generate keys every 30 days. So, > I think, if you're going to enable it by default, there needs to be a > script in periodic that will do all the magic to change keys every 30 > days. Maybe put vars in /etc/rc.conf to override the default key > lengths and other portions of the commands that could change per > installation. No, you don't HAVE to generate keys every 30 days, but you should if you want real security. Still, for a while, until the infrastructure is complete enough to make DNSSEC really of value to the end user, just getting signed domains with keys published in an easily accessed place is at least getting things started and getting the infrastructure moving. Rolling keys is a rather tricky operation where mistakes, once DNSSEC makes it to the end user, would be disastrous, so it would require a couple of scripts, one to set a new key and another to remove the old one. You need both key present for a period of time. > If I were to implement it, I'd write a shell script to turn the keys > over and cron it because doing it manually every 30 days ain't gonna > happen. Too many ways to forget to do it. (I did the same for the > root servers so that named.ca gets updated automagically every month.) And that is FAR less important than the signatures. (named.ca could be updated once a year and be just fine.) > But until root is signed, it's not worth it for those of us who don't > have dedicated staff doing dns only. Work continues on getting the root signed, but it .com and .net that present the really big problems. The root delay is mostly political, not technical. .com and .net are both. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1216757240_66746P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIhj34kn3rs5h7N1ERAoybAJ9OlCt7mZV8Abk9qM4QsoxhKE0inACfS8ff xr9ZcdpPQxvY71V0Zs1KsSo= =yJOR -----END PGP SIGNATURE----- --==_Exmh_1216757240_66746P-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:12:22 2008 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 576461065675 for ; Tue, 22 Jul 2008 20:12:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B83C98FC15; Tue, 22 Jul 2008 20:12:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48863F23.9020504@FreeBSD.org> Date: Tue, 22 Jul 2008 22:12:19 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Royce Williams References: <488638DA.7010005@alaska.net> In-Reply-To: <488638DA.7010005@alaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 22 Jul 2008 20:12:22 -0000 Royce Williams wrote: > db> trace > Tracing pid 71182 tid 100325 td 0xcc08b180 > kdb_enter(c095f294) at kdb_enter+0x2b > panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 > kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 You forgot to include the panic, but this is probably the "kmem_map too small" panic. It says that your kernel ran out of memory, and the solution is to fix that situation by giving more memory to the kernel. Increase the vm.kmem_size tunable until your system stops running out of memory on your workload. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:30:54 2008 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 43DC71065674; Tue, 22 Jul 2008 20:30:54 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6328FC1F; Tue, 22 Jul 2008 20:30:53 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,233,1215406800"; d="scan'208";a="4150040" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 22 Jul 2008 15:30:53 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 5FB5623DE2; Tue, 22 Jul 2008 15:30:54 -0500 (CDT) Date: Tue, 22 Jul 2008 15:30:53 -0500 From: Paul Schmehl To: Kevin Oberman , Paul Schmehl Message-ID: <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> In-Reply-To: <20080722200720.0540245048@ptavv.es.net> References: <20080722200720.0540245048@ptavv.es.net> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 20:30:54 -0000 --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman wrote: > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, >> I think, if you're going to enable it by default, there needs to be a >> script in periodic that will do all the magic to change keys every 30 >> days. Maybe put vars in /etc/rc.conf to override the default key >> lengths and other portions of the commands that could change per >> installation. > > No, you don't HAVE to generate keys every 30 days, but you should if you > want real security. For me that means must. :-) Someone needs to write a really good tutorial on dnssec. The bits and pieces are scattered about the web, but explanations of now to publish your keys, to whom they need to be published and what is involved in the ongoing maintenance are lacking. Especially a clear explanation of what is required to run both keyed and "legacy" dns at the same time. > Still, for a while, until the infrastructure is > complete enough to make DNSSEC really of value to the end user, just > getting signed domains with keys published in an easily accessed place > is at least getting things started and getting the infrastructure > moving. > Where do you publish the keys? > Rolling keys is a rather tricky operation where mistakes, once DNSSEC > makes it to the end user, would be disastrous, so it would require a > couple of scripts, one to set a new key and another to remove the old > one. You need both key present for a period of time. > I'd not read that. Can you explain? I thought you simply overwrote the existing keys with the new ones (in the zone file.) In fact I was thinking that an $INCLUDE would make a great deal more sense. I didn't realize you had to retain the old keys for a while. That complicates matters significantly. BTW, I think without those scripts (or at least examples) you'll find adoption will be a great deal slower. Many people that need to run dns are far from experts and often intimidated by its complexity - especially the complexity of dnssec. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 21:00:43 2008 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 1CC41106567D; Tue, 22 Jul 2008 21:00:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A42B78FC25; Tue, 22 Jul 2008 21:00:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6ML0CwX038643; Tue, 22 Jul 2008 17:00:36 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Oleg V. Nauman" Date: Tue, 22 Jul 2008 15:14:54 -0400 User-Agent: KMail/1.9.7 References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> In-Reply-To: <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221514.55055.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 22 Jul 2008 17:00:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7784/Tue Jul 22 15:40:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 22 Jul 2008 21:00:43 -0000 On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: > Quoting John Baldwin : > > > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > >> Quoting "Oleg V. Nauman" : > >> > >> > Quoting Jeremy Chadwick : > >> > > >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE so > >> >>> my next system upgrade ended with ACPI HPET not working anymore on my > >> >>> ASUS A9Rp laptop. > >> >>> > >> >>> Here is the part of /var/log/dmesg.today dated July 13: > >> >>> > >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >>> [..] > >> >>> acpi0: on motherboard > >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >>> acpi0: [ITHREAD] > >> >>> acpi0: Power Button (fixed) > >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >>> acpi_ec0: port 0x62,0x66 on acpi0 > >> >>> acpi_hpet0: iomem > >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >>> > >> >>> Here is the fresh dmesg output info: > >> >>> > >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >>> [..] > >> >>> acpi0: on motherboard > >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >>> acpi0: [ITHREAD] > >> >>> acpi0: Power Button (fixed) > >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >>> [..] > >> >>> acpi_hpet0: iomem > >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >>> device_attach: acpi_hpet0 attach returned 12 > >> >>> > >> >>> And the part of actual sysctl kern.timecounter output: > >> >>> > >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) > > dummy(-1000000) > >> >>> kern.timecounter.hardware: ACPI-safe > >> >> > >> >> Seems okay here: > >> >> > >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul > >> >> 12 10:53:08 PDT 2008 > >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > >> >> > >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > >> >> acpi_hpet0: iomem > >> >> 0xfed00000-0xfed003ff on acpi0 > >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >> Timecounters tick every 1.000 msec > >> >> > >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > >> >> i8254(0) dummy(-1000000) > >> >> kern.timecounter.hardware: ACPI-fast > >> >> > >> >> You sure you haven't upgraded your BIOS or something and forgot to > >> >> re-enable HPET? > >> > > >> > No it was not upgraded.. Have no option to enable/disable HPET through > >> > BIOS settings though > >> > >> I was unclear a bit or so. There are no ACPI related settings in my > >> laptop's BIOS. > >> > >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > >> > >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > > acpi0 > >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> > >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > >> dummy(-1000000) > >> kern.timecounter.hardware: HPET > >> > >> Hopefully it helps to understand what is went wrong there. > > > > Ok, so the attempt to allocate the resource is failing for some reason. Can > > you get output from 'devinfo -r' and 'devinfo -u'? > > ... > > Will not provide with full listings but just a diff comparing two > states (this good one with HPET working and bad w/o it): > > rainhaven# diff devinfo.r.good devinfo.r.bad > 177,179d176 > < acpi_hpet0 > < I/O memory addresses: > < 0xfed00000-0xfed003ff > > rainhaven# diff devinfo.u.good devinfo.u.bad > 128c128 > < 0xfed00000-0xfed003ff (acpi_hpet0) > --- > > 0xfed00000-0xfed003ff (ichsmb0) > > So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > allocates the region required to ichsmb0 instead HPET (it not helps to > ichsmb0 because it never was working on my laptop but it is another > story I think). > > Thank you for looking into. Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this change, it restores the probe orders to be more of what they used to be and just gives CPUs a really high probe order so that they should be after other devices. Index: acpi.c =================================================================== RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.248 diff -u -r1.248 acpi.c --- acpi.c 7 Apr 2008 18:35:11 -0000 1.248 +++ acpi.c 22 Jul 2008 19:12:56 -0000 @@ -1531,8 +1531,7 @@ * 1. I/O port and memory system resource holders * 2. Embedded controllers (to handle early accesses) * 3. PCI Link Devices - * ACPI_DEV_BASE_ORDER. Host-PCI bridges - * ACPI_DEV_BASE_ORDER + 10. CPUs + * 100000. CPUs */ AcpiGetType(handle, &type); if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) @@ -1541,10 +1540,8 @@ *order = 2; else if (acpi_MatchHid(handle, "PNP0C0F")) *order = 3; - else if (acpi_MatchHid(handle, "PNP0A03")) - *order = ACPI_DEV_BASE_ORDER; else if (type == ACPI_TYPE_PROCESSOR) - *order = ACPI_DEV_BASE_ORDER + 10; + *order = 100000; } /* @@ -1594,10 +1591,8 @@ * placeholder so that the probe/attach passes will run * breadth-first. Orders less than ACPI_DEV_BASE_ORDER * are reserved for special objects (i.e., system - * resources). Orders between ACPI_DEV_BASE_ORDER and 100 - * are used for Host-PCI bridges (and effectively all - * their children) and CPUs. Larger values are used for - * all other devices. + * resources). CPU devices have a very high order to + * ensure they are probed after other devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str)); order = level * 10 + 100; -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 21:04:03 2008 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 667C61065678 for ; Tue, 22 Jul 2008 21:04:03 +0000 (UTC) (envelope-from royce@alaska.net) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.173.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7D18FC12 for ; Tue, 22 Jul 2008 21:04:02 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [10.0.102.101] (209-112-156-43-adslb0fh.acsalaska.net [209.112.156.43]) by malik.acsalaska.net (8.14.1/8.14.1) with ESMTP id m6ML41Qr072415; Tue, 22 Jul 2008 13:04:01 -0800 (AKDT) (envelope-from royce@alaska.net) Message-ID: <48864B41.50300@alaska.net> Date: Tue, 22 Jul 2008 13:04:01 -0800 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kris Kennaway References: <488638DA.7010005@alaska.net> <48863F23.9020504@FreeBSD.org> In-Reply-To: <48863F23.9020504@FreeBSD.org> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.tycho.org/royce/royce@alaska.net.asc X-Face: ">19[ShfDD9'g", GrH$'v:=qBVZdg.kXSBR6*ZC$am:D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 22 Jul 2008 21:04:03 -0000 Kris Kennaway wrote, on 7/22/2008 12:12 PM: > Royce Williams wrote: > >> db> trace >> Tracing pid 71182 tid 100325 td 0xcc08b180 >> kdb_enter(c095f294) at kdb_enter+0x2b >> panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 >> kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 > > You forgot to include the panic Is there is a way to get the panic after dropping into the debugger? This serial console setup has no scrollback, so I couldn't see the preceding text. > but this is probably the "kmem_map too small" panic. Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: "Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory." > It says that your kernel ran out of memory, and the > solution is to fix that situation by giving more memory to the kernel. > Increase the vm.kmem_size tunable until your system stops running out of > memory on your workload. Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, please clarify: is the Right Thing to do to use vm.kmem_size, or vm.kmem_size_max? I tried vm.kmem_size_max, which yields: # sysctl -a | grep kmem vm.kmem_size: 419430400 vm.kmem_size_max: 419430400 vm.kmem_size_scale: 3 Should I contribute some additional language to the FAQ, saying that the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Royce -- Royce D. Williams - http://royce.ws/ Reproof should not exhaust its power upon petty failings. - S. Johnson From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 21:19:51 2008 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 53EB6106567B; Tue, 22 Jul 2008 21:19:51 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id CBA158FC12; Tue, 22 Jul 2008 21:19:50 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:3c8a:29d7:6d22:ea49] (unknown [IPv6:2001:7b8:3a7:0:3c8a:29d7:6d22:ea49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EBDAA3F; Tue, 22 Jul 2008 23:19:48 +0200 (CEST) Message-ID: <48864EF4.3090708@andric.com> Date: Tue, 22 Jul 2008 23:19:48 +0200 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.17pre (Windows/20080719) MIME-Version: 1.0 To: John Baldwin References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <20080719111838.il32fec2880wok4g@webmail.opentransfer.com> <20080721130752.pstwcwkz88wso8cs@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> In-Reply-To: <200807211800.12415.jhb@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 22 Jul 2008 21:19:51 -0000 On 2008-07-22 00:00, John Baldwin wrote: > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) >> dummy(-1000000) >> kern.timecounter.hardware: HPET >> >> Hopefully it helps to understand what is went wrong there. > > Ok, so the attempt to allocate the resource is failing for some reason. Can > you get output from 'devinfo -r' and 'devinfo -u'? FWIW, I've tried acpi.c revs 1.243.2.1 through 1.243.2.3, and all give the same result: acpi_hpet0: iomem 0xfe800000-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 E.g. it looks like bus_alloc_resource_any() in acpi_hpet_attach() fails, but no idea why? Anyway, devinfo -r and -u give: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x1eedffff npx0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x400-0x47f 0x4d0-0x4d1 0x500-0x50f 0x800-0x805 I/O memory addresses: 0xf0000-0xfffff 0x1eee0000-0x1eefffff 0xfe800000-0xfe8000ff 0xfea00000-0xfea000ff 0xfec00000-0xfecfffff 0xfee00000-0xfeefffff 0xfff80000-0xfffeffff 0xffff0000-0xffffffff cpu0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 acpi_button0 acpi_sysresource0 pcib0 pci0 hostb0 I/O memory addresses: 0xe8000000-0xefffffff hostb1 hostb2 hostb3 hostb4 hostb5 pcib1 pci1 vgapci0 I/O memory addresses: 0xf4000000-0xf7ffffff 0xfb000000-0xfbffffff re0 Interrupt request lines: 18 I/O ports: 0xf000-0xf0ff I/O memory addresses: 0xfdfff000-0xfdfff0ff miibus0 rgephy0 re1 Interrupt request lines: 19 I/O ports: 0xf200-0xf2ff I/O memory addresses: 0xfdffe000-0xfdffe0ff miibus1 rgephy1 atapci0 Interrupt request lines: 20 I/O ports: 0xf400-0xf4ff 0xfb00-0xfb0f 0xfc00-0xfc03 0xfd00-0xfd07 0xfe00-0xfe03 0xff00-0xff07 ata2 ad4 subdisk4 ata3 ad6 subdisk6 atapci1 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfa00-0xfa0f ata0 Interrupt request lines: 14 ata1 Interrupt request lines: 15 uhci0 Interrupt request lines: 21 I/O ports: 0xf900-0xf91f usb0 uhub0 uhci1 I/O ports: 0xf800-0xf81f usb1 uhub1 uhci2 I/O ports: 0xf700-0xf71f usb2 uhub2 uhci3 I/O ports: 0xf600-0xf61f usb3 uhub3 ehci0 I/O memory addresses: 0xfdffd000-0xfdffd0ff usb4 uhub4 isab0 isa0 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xcf7ff pmtimer0 acpi_sysresource1 acpi_sysresource2 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 pci_link8 pci_link9 pci_link10 pci_link11 acpi_sysresource3 atpic0 atdma0 attimer0 attimer1 npxisa0 uart0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff uart1 Interrupt request lines: 3 I/O ports: 0x2f8-0x2ff ppc0 Interrupt request lines: 7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x408-0x40b Interrupt request lines: 0 (root0) 1 (atkbd0) 3 (uart1) 4 (uart0) 5-6 (root0) 7 (ppc0) 8 (root0) 9 (acpi0) 10-13 (root0) 14 (ata0) 15 (ata1) 16-17 (root0) 18 (re0) 19 (re1) 20 (atapci0) 21 (uhci0) 22-23 (root0) DMA request lines: 0-7 (root0) I/O ports: 0x0-0xf (root0) 0x10-0x1f (acpi0) 0x20-0x21 (root0) 0x22-0x3f (acpi0) 0x40-0x43 (root0) 0x44-0x5f (acpi0) 0x60 (atkbdc0) 0x61 (root0) 0x62-0x63 (acpi0) 0x64 (atkbdc0) 0x65-0x6f (acpi0) 0x70-0x73 (root0) 0x74-0x7f (acpi0) 0x80-0x90 (root0) 0x91-0x93 (acpi0) 0x94-0xa1 (root0) 0xa2-0xbf (acpi0) 0xc0-0xdf (root0) 0xe0-0xef (acpi0) 0xf0-0x16f (root0) 0x170-0x177 (atapci1) 0x178-0x1ef (root0) 0x1f0-0x1f7 (atapci1) 0x1f8-0x28f (root0) 0x290-0x297 (acpi0) 0x298-0x2f7 (root0) 0x2f8-0x2ff (uart1) 0x300-0x375 (root0) 0x376 (atapci1) 0x377 (root0) 0x378-0x37f (ppc0) 0x380-0x3bf (root0) 0x3c0-0x3df (vga0) 0x3e0-0x3f5 (root0) 0x3f6 (atapci1) 0x3f7 (fdc0) 0x3f8-0x3ff (uart0) 0x400-0x47f (acpi0) 0x480-0x4cf (root0) 0x4d0-0x4d1 (acpi0) 0x4d2-0x4ff (root0) 0x500-0x50f (acpi0) 0x510-0x7ff (root0) 0x800-0x805 (acpi0) 0x806-0xedff (root0) 0xee00-0xeeff ---- 0xef00-0xefff (root0) 0xf000-0xf0ff (re0) 0xf100-0xf1ff (root0) 0xf200-0xf2ff (re1) 0xf300-0xf3ff (root0) 0xf400-0xf4ff (atapci0) 0xf500-0xf5ff (root0) 0xf600-0xf61f (uhci3) 0xf620-0xf6ff (root0) 0xf700-0xf71f (uhci2) 0xf720-0xf7ff (root0) 0xf800-0xf81f (uhci1) 0xf820-0xf8ff (root0) 0xf900-0xf91f (uhci0) 0xf920-0xf9ff (root0) 0xfa00-0xfa0f (atapci1) 0xfa10-0xfaff (root0) 0xfb00-0xfb0f (atapci0) 0xfb10-0xfbff (root0) 0xfc00-0xfc03 (atapci0) 0xfc04-0xfcff (root0) 0xfd00-0xfd07 (atapci0) 0xfd08-0xfdff (root0) 0xfe00-0xfe03 (atapci0) 0xfe04-0xfeff (root0) 0xff00-0xff07 (atapci0) 0xff08-0xffff (root0) I/O memory addresses: 0x0-0x9efff (ram0) 0x9f000-0x9ffff (root0) 0xa0000-0xbffff (vga0) 0xc0000-0xcf7ff (orm0) 0xcf800-0xeffff (root0) 0xf0000-0xfffff (acpi0) 0x100000-0x1eedffff (ram0) 0x1eee0000-0x1eefffff (acpi0) 0x1ef00000-0xe7ffffff (root0) 0xe8000000-0xefffffff (hostb0) 0xf0000000-0xf3ffffff (root0) 0xf4000000-0xf7ffffff (vgapci0) 0xf8000000-0xfaffffff (root0) 0xfb000000-0xfbffffff (vgapci0) 0xfc000000-0xfdffcfff (root0) 0xfdffd000-0xfdffd0ff (ehci0) 0xfdffd100-0xfdffdfff (root0) 0xfdffe000-0xfdffe0ff (re1) 0xfdffe100-0xfdffefff (root0) 0xfdfff000-0xfdfff0ff (re0) 0xfdfff100-0xfe7fffff (root0) 0xfe800000-0xfe8000ff (acpi0) 0xfe800100-0xfe9fffff (root0) 0xfea00000-0xfea000ff (acpi0) 0xfea00100-0xfebfffff (root0) 0xfec00000-0xfecfffff (acpi0) 0xfed00000-0xfedfffff (root0) 0xfee00000-0xfeefffff (acpi0) 0xfef00000-0xfff7ffff (root0) 0xfff80000-0xfffeffff (acpi0) 0xffff0000-0xffffffff (acpi0) ACPI I/O ports: 0x10-0x1f (root0) 0x22-0x3f (root0) 0x44-0x5f (root0) 0x62-0x63 (root0) 0x65-0x6f (root0) 0x74-0x7f (root0) 0x91-0x93 (root0) 0xa2-0xbf (root0) 0xe0-0xef (root0) 0x290-0x297 (root0) 0x400-0x407 (root0) 0x408-0x40b (acpi_timer0) 0x40c-0x413 (root0) 0x414 (cpu0) 0x415 (cpu0) 0x416-0x47f (root0) 0x4d0-0x4d1 (root0) 0x500-0x50f (root0) 0x800-0x805 (root0) ACPI I/O memory addresses: 0xf0000-0xfffff (root0) 0x1eee0000-0x1eefffff (root0) 0xfe800000-0xfe8000ff (root0) 0xfea00000-0xfea000ff (root0) 0xfec00000-0xfecfffff (root0) 0xfee00000-0xfeefffff (root0) 0xfff80000-0xfffeffff (root0) 0xffff0000-0xffffffff (root0) From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 21:49:27 2008 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 AE7AA106564A; Tue, 22 Jul 2008 21:49:27 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4FAE98FC17; Tue, 22 Jul 2008 21:49:26 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id CCT34126; Tue, 22 Jul 2008 14:49:26 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 390584500E; Tue, 22 Jul 2008 14:49:25 -0700 (PDT) To: Paul Schmehl In-Reply-To: Your message of "Tue, 22 Jul 2008 15:30:53 CDT." <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1216763365_66746P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 22 Jul 2008 14:49:25 -0700 From: "Kevin Oberman" Message-Id: <20080722214925.390584500E@ptavv.es.net> Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 22 Jul 2008 21:49:27 -0000 --==_Exmh_1216763365_66746P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 22 Jul 2008 15:30:53 -0500 > From: Paul Schmehl > > --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman wrote: > > > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, > >> I think, if you're going to enable it by default, there needs to be a > >> script in periodic that will do all the magic to change keys every 30 > >> days. Maybe put vars in /etc/rc.conf to override the default key > >> lengths and other portions of the commands that could change per > >> installation. > > > > No, you don't HAVE to generate keys every 30 days, but you should if you > > want real security. > > For me that means must. :-) > > Someone needs to write a really good tutorial on dnssec. The bits and > pieces are scattered about the web, but explanations of now to publish > your keys, to whom they need to be published and what is involved in > the ongoing maintenance are lacking. Especially a clear explanation > of what is required to run both keyed and "legacy" dns at the same > time. I can't imagine why anyone would want to run both. Resolvers which don't know how to check signatures simple don't do so and everything still works. A pretty good, though somewhat outdated tutorial can be found in NIST SP800-81. It's pretty readable and tells you how to generate keys and sign a zone properly. http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf > > Still, for a while, until the infrastructure is > > complete enough to make DNSSEC really of value to the end user, just > > getting signed domains with keys published in an easily accessed place > > is at least getting things started and getting the infrastructure > > moving. > > > > Where do you publish the keys? I have not done so at this time. We have a DNS system that does not quite support DNSSEC, although that should be resolved shortly. NIST simply puts theirs on a web page. This is not a good long-term answer, but is adequate for growing the infrastructure and letting people play with it. DNSSEC really needs to be ready now, but it's simply not, so we need to get some sort of start and more experience in using it. I have a test server that is signed and that I am playing with and I hope that I will be able to sign our production zones in the next few months. Our plan is to buy a network appliance to do the key generation, signing and key rolls. > > Rolling keys is a rather tricky operation where mistakes, once DNSSEC > > makes it to the end user, would be disastrous, so it would require a > > couple of scripts, one to set a new key and another to remove the old > > one. You need both key present for a period of time. > > > > I'd not read that. Can you explain? I thought you simply overwrote > the existing keys with the new ones (in the zone file.) In fact I was > thinking that an $INCLUDE would make a great deal more sense. I > didn't realize you had to retain the old keys for a while. That > complicates matters significantly. Since data in cached, you can't simply replace the key and not have failures when the cached old keys are used to try to verify newly received data. You need to have the old key remain valid for the length of your longest TTL. Note: I am not a DNSSEC expert at all. I have been "playing" with it for over a year, but have been unable to actually use it in production because of our DNS management software which does not support DNSSEC. Hopefully everything I said is correct, but it would be best to verify things before basing much on it. > BTW, I think without those scripts (or at least examples) you'll find > adoption will be a great deal slower. Many people that need to run > dns are far from experts and often intimidated by its complexity - > especially the complexity of dnssec. I completely agree that you are right. DNSSEC is not trivial to manage and, while managing it does not require any detailed knowledge of how it works, it does take careful planning and some education for those who will be working with it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1216763365_66746P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIhlXlkn3rs5h7N1ERAhgUAJsGxQYgMRjy683zs/5RlgQje4miMACfZbqj CQmYPIyIyJZRg7MXrS7T1JY= =DNUE -----END PGP SIGNATURE----- --==_Exmh_1216763365_66746P-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 21:56:49 2008 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 22C311065677 for ; Tue, 22 Jul 2008 21:56:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 507448FC13; Tue, 22 Jul 2008 21:56:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <488657A0.9000501@FreeBSD.org> Date: Tue, 22 Jul 2008 23:56:48 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Royce Williams References: <488638DA.7010005@alaska.net> <48863F23.9020504@FreeBSD.org> <48864B41.50300@alaska.net> In-Reply-To: <48864B41.50300@alaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 22 Jul 2008 21:56:49 -0000 Royce Williams wrote: > Kris Kennaway wrote, on 7/22/2008 12:12 PM: >> Royce Williams wrote: >> >>> db> trace >>> Tracing pid 71182 tid 100325 td 0xcc08b180 >>> kdb_enter(c095f294) at kdb_enter+0x2b >>> panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 >>> kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 >> You forgot to include the panic > > Is there is a way to get the panic after dropping into the debugger? > This serial console setup has no scrollback, so I couldn't see the > preceding text. You can either "show msgbuf", or "x/x panicstr" and then "x/s 0x...." where that is the hex value from the previous step. The latter only diplays the format string and not the arguments, but on i386 you can read them off from the panic() line in the stack trace. Actually on i386 the panicstr is the first argument (0xc09768ad here). >> but this is probably the "kmem_map too small" panic. > > Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: > > "Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel > configuration file, increasing the maximum size to 400 MB (options > VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for > machines with up to 6 GB of memory." > > >> It says that your kernel ran out of memory, and the >> solution is to fix that situation by giving more memory to the kernel. >> Increase the vm.kmem_size tunable until your system stops running out of >> memory on your workload. > > Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, > please clarify: is the Right Thing to do to use vm.kmem_size, or > vm.kmem_size_max? kmem_size_max is used for automatically tuning based on RAM size. To increase the actual value explicitly you just need to tune vm.kmem_size. > I tried vm.kmem_size_max, which yields: > > # sysctl -a | grep kmem > vm.kmem_size: 419430400 > vm.kmem_size_max: 419430400 > vm.kmem_size_scale: 3 > > > Should I contribute some additional language to the FAQ, saying that > the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Yes, that would be fantastic! I would also note that the loader tunable is usually more convenient since it doesn't require a kernel recompile, and probably reword the claim about 400MB: the memory needed depends very much on the workload you are giving your kernel, so the best advice is to increase the value until you determine empirically how much you need (i.e. the memory exhaustion stops). You can also use "400M" notation for loader tunables which is often more convenient. Thanks, Kris Kris From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 00:18:41 2008 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 3FD45106566C for ; Wed, 23 Jul 2008 00:18:41 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id CBE478FC1E for ; Wed, 23 Jul 2008 00:18:35 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7A22A1CC0A7; Tue, 22 Jul 2008 17:18:35 -0700 (PDT) Date: Tue, 22 Jul 2008 17:18:35 -0700 From: Jeremy Chadwick To: ian j hart Message-ID: <20080723001835.GA33136@eos.sc1.parodius.com> References: <200807221727.52718.ianjhart@ntlworld.com> <20080722163724.GA11757@eos.sc1.parodius.com> <200807221847.34935.ianjhart@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807221847.34935.ianjhart@ntlworld.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 23 Jul 2008 00:18:41 -0000 On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: > On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > > Same hardware as my other thread. > > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > > > [using 2Gb RAM and SATA in legacy mode] > > > > > > I'd like to focus only on making the CDROM boot complete. > > > > > > Summary: hangs just after the CPUs are launched. > > > > > > 6.2-RELEASE works okay, no AHCI support > > > 6.3-RELEASE works okay > > > 7.0-RELEASE hangs > > > 7.0-STABLE-200806-SNAPSHOT hangs > > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > > > I thought I could do a binary search using the current snapshot boot-only > > > CDs but they only go back to March. Are there any older ones available? > > > > Have you tried disabling ACPI to see if it makes any sort of difference? > > Yes, but I'm happy to re-try. > > Which method is "best"? Or is it 1 + 2 or 3? > > 1) BIOS > 2) Beastie menu option > 3) loader prompt set hint Item #2 is the easiest. You should really be able to leave the BIOS settings at their defaults (Factory Defaults) and have this system work on FreeBSD. Items #2 and #3 are the same. The loader menu option for disabling ACPI simply sets the hint. > > Also, AHCI should work just fine on those systems -- I know because I > > have fairly extensive experience with Supermicro hardware, although what > > you're using is newer than what I presently have. I don't know why > > you're setting Compatible/Legacy mode on your controller (you mention > > doing this in your other thread as well). > > Because I don't know what's wrong yet and AHCI support is newer than SATA > support and this is a newish board? [At least 6.2 doesn't seem to support it > and it has an AHCI legacy option!] > > I'd be happy to swap this over. Slight problem; the drives get renumbered, so > I'd rather not swap back and forth. You *absolutely* should have AHCI enabled. There's a lot of reasons why, too. I highly recommend avoiding the "SATA Compatible" mode. AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because we have many Supermicro boards running those versions which do have AHCI enabled. Please use it, and stick with it. Here's added proof that AHCI works fine on 6.3: $ dmesg -a | grep -i ahci atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe0000400-0xe00007ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected $ uname -r -s FreeBSD 6.3-PRERELEASE The adX device renumbering is expected. There are workarounds for this, but I recommend you simply enable AHCI. Do not keep toggling it on/off. > > Below is what we use on our systems; factory defaults, then make the > > following changes. (The G-LAN1 OPROM option you can do whatever you > > want with -- it's specific to our environment). > > > > * Main > > * Date > > --> Set to GMT, not local time!!! > > * Serial ATA > > --> SATA Controller Mode --> Enhanced > > --> SATA AHCI --> Enabled > > > > * Advanced > > * Boot Features > > --> Quiet Mode --> Disabled > > --> Enable Multimedia Timer --> Enabled > > * PCI Configuration > > --> Onboard G-LAN1 OPROM --> Disabled > > --> Large Disk Access Mode --> Other > > * Advanced Processor Options > > --> Intel(R) Virtualization Technology --> Enabled > > --> C1 Enhanced Mode --> Enabled > > I've got as close as I can to this. > > This board also has an AHCI legacy option [disabled] which hides ports 5 and > 6. I also disabled quickboot and POST errors. I assume multimedia timer is > the same as HPET. Doesn't seem to be any disk translation option. I took the > fans off 'flat out'. Okay, I've had a chance to review the board manual that comes with the X7SBi. You should set the following: Serial ATA: Enabled Native Mode Operation: Serial ATA SATA AHCI: Enabled SATA AHCI Legacy: Disabled The name "SATA AHCI Legacy" a horrible name for what it does. The ICH9 itself has support for 6 SATA ports, but (if I remember correctly, based on reading some Intel design documents) there are extra registers you have to tweak to get those ports to work, and the OS has to be fully aware of how to do that. The BIOS option simply disables SATA ports 5 and 6 altogether; the underlying OS never sees them. I'd recommend keeping that setting Disabled (the default) unless you have disks on those ports (I don't see how, since it's a 4-disk system!). I don't think this option is what's causing you problems, though. "Multimedia Timer" is indeed HPET. Looks like they changed the name to be more reflective of what it actually is. The "Large Disk Access" mode does appear to be missing from that BIOS, probably for a good reason. I can enable/disable it on our boards with no repercussions (the options are "DOS" and "Other", which is why I choose "Other"). I'm not entirely sure what it does. As for your problem... If the CDROM is the problem (which would be odd, since the disc does boot and load the kernel successfully), can you try going into the BIOS and setting IDE Channel 0 Master (which I think is the CDROM -- I could be wrong here) and set "Transfer Mode" to PIO1 and "Ultra DMA Mode" to Disabled? I have a feeling the problem isn't related to the CDROM, but I'm not entirely sure how to debug it. There are other users using the X7SBi with success: http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread/d0a2d20f8965361a http://www.webhostingtalk.com/showthread.php?t=666686 Also, can you make sure your BIOS revision is 1.1a, just to rule out any BIOS-related issues? -- | Jeremy Chadwick jdc at 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 Jul 23 00:46:48 2008 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 5D5A11065670; Wed, 23 Jul 2008 00:46:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 168DC8FC0A; Wed, 23 Jul 2008 00:46:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6N0khvt008606; Wed, 23 Jul 2008 10:46:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807230046.m6N0khvt008606@drugs.dv.isc.org> To: Paul Schmehl From: Mark Andrews In-reply-to: Your message of "Tue, 22 Jul 2008 12:52:15 EST." <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> Date: Wed, 23 Jul 2008 10:46:43 +1000 Sender: marka@isc.org Cc: freebsd-stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 00:46:48 -0000 > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > > > Matthew Seaman wrote: > > > >> Are there any plans to enable DNSSEC capability in the resolver built > >> into FreeBSD? > > > > The server is already capable of it. I'm seriously considering enabling the > > define to make the CLI tools (dig/host/nslookup) capable as well (there is > > already an OPTION for this in ports). > > > > The problem is that _using_ DNSSEC requires configuration changes in > > named.conf, and more importantly, configuration of "trust anchors" (even fo > r > > the command line stuff) since the root is not signed. It's not hard to do > > that with the DLV system that ISC has in place, and I would be willing to > > create a conf file that shows how to do that for users to include if they > > choose to. I am not comfortable enabling it by default (not yet anyway), it > 's > > too big of a POLA issue. > > > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin > k, > if you're going to enable it by default, there needs to be a script in period > ic > that will do all the magic to change keys every 30 days. Maybe put vars in > /etc/rc.conf to override the default key lengths and other portions of the > commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. KSKs annually. This is what the TLD's are doing and that is a very conservative exposure period. In practice it could be multiple years between key rollovers. The reason it is done this frequently is so humans don't forget what they need to do. ZSKs are generally weaker than KSKs but again they don't need to be done monthly. > If I were to implement it, I'd write a shell script to turn the keys over and > cron it because doing it manually every 30 days ain't gonna happen. Too many > ways to forget to do it. (I did the same for the root servers so that named. > ca > gets updated automagically every month.) > > But until root is signed, it's not worth it for those of us who don't have > dedicated staff doing dns only. There are solutions to the root not being signed. If all the TLD were signed the trust anchor work load would not be too great to managed by hand. For those that want a single trust anchor solution there is DLV. Sign your zone. Add it to a DLV. Ask you parent to sign their zone. If you don't sign you parent has no insentive to sign. This can be driven bottom up. That is one of the reasons why DLV was invented to provide incentive for the parent zones to sign. Mark > -- > Paul Schmehl > As if it wasn't already obvious, > my opinions are my own and not > those of my employer. > > _______________________________________________ > 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: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 00:54:35 2008 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 BB5CD1065674; Wed, 23 Jul 2008 00:54:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 436D38FC19; Wed, 23 Jul 2008 00:54:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6N0sYKi008687; Wed, 23 Jul 2008 10:54:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807230054.m6N0sYKi008687@drugs.dv.isc.org> To: Matthew Seaman From: Mark Andrews In-reply-to: Your message of "Tue, 22 Jul 2008 19:37:32 +0100." <488628EC.5030801@infracaninophile.co.uk> Date: Wed, 23 Jul 2008 10:54:34 +1000 Sender: marka@isc.org Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 00:54:35 -0000 > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig5488BAD5E4511AF4D0C2864A > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Doug Barton wrote: > > Matthew Seaman wrote: > >=20 > >> Are there any plans to enable DNSSEC capability in the resolver built = > > >> into FreeBSD? > >=20 > > The server is already capable of it. I'm seriously considering enabling= > =20 > > the define to make the CLI tools (dig/host/nslookup) capable as well=20 > > (there is already an OPTION for this in ports). > > Forgive me for being obtuse. What I meant was the capability to enable c= > hecking signatures on DNS RRs as a routine effect of getnameinfo() etc. > by modifying resolver(3) routines or similar locally, without needing a > DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling > the answer is no, but I haven't been able to find anything definitive. > > Which I suppose simply means that if you're in the habit of, for example,= > =20 > taking your laptop into the coffee shop and getting on line there then yo= > u=20 > need to run your own instance of named on your laptop rather than blindly= > =20 > trusting whatever servers the coffee shop provides via their DHCP. Use a local (on machine) validating caching nameserver. > > The problem is that _using_ DNSSEC requires configuration changes in=20 > > named.conf, and more importantly, configuration of "trust anchors" (eve= > n=20 > > for the command line stuff) since the root is not signed. It's not hard= > =20 > > to do that with the DLV system that ISC has in place, and I would be=20 > > willing to create a conf file that shows how to do that for users to=20 > > include if they choose to. I am not comfortable enabling it by default = > > > (not yet anyway), it's too big of a POLA issue. > > I sense a business opportunity in providing DLV there. I'm wondering why= > > the likes of Verisign (including Thawte and Geotrust), Comodo group and=20 > GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps th= > ey=20 > are. You only need one DLV. ISC is offering the service for free. Donations welcome as it does cost to run the service. > Cheers, > > Matthew > > --=20 > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > > --------------enig5488BAD5E4511AF4D0C2864A > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEAREIAAYFAkiGKPIACgkQ8Mjk52CukIxbWACfTVCDPVViUJ0NTd5GLMMVU8bD > xXkAniwbkPNqgVZYLi4a/5aQHYFxBHSo > =T6Z8 > -----END PGP SIGNATURE----- > > --------------enig5488BAD5E4511AF4D0C2864A-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 01:58:09 2008 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 EFE751065701 for ; Wed, 23 Jul 2008 01:58:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCE48FC15 for ; Wed, 23 Jul 2008 01:58:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6N1w6BR015766; Wed, 23 Jul 2008 11:58:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807230158.m6N1w6BR015766@drugs.dv.isc.org> To: Oliver Fromme , freebsd-stable@FreeBSD.ORG From: Mark Andrews Mail-Followup-To: Oliver Fromme , freebsd-stable@FreeBSD.ORG In-reply-to: Your message of "Tue, 22 Jul 2008 06:20:25 -1000." <20080722162024.GA1279@lava.net> Date: Wed, 23 Jul 2008 11:58:06 +1000 Sender: marka@isc.org Cc: Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 01:58:10 -0000 > On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: > > Brett Glass wrote: > > > At 02:24 PM 7/21/2008, Kevin Oberman wrote: > > > > > > > Don't forget that ANY server that caches data, including an end system > > > > running a caching only server is vulnerable. > > > > > > Actually, there is an exception to this. A "forward only" > > > cache/resolver is only as vulnerable as its forwarder(s). This is a > > > workaround for the vulnerability for folks who have systems that they > > > cannot easily upgrade: point at a trusted forwarder that's patched. > > > > > > We're also looking at using dnscache from the djbdns package. > > > > I'm curious, is djbdns exploitable, too? Does it randomize > > the source ports of UDP queries? > > AFAIK Dan Bernstein first spelled out the fundamental problems with > DNS response forgery in 2001. He implemented dnscache to randomize > source ports and IDs from the beginning, via a cryptographic quality > RNG. See for instance this page, much of it written in 2003: > > And the IETF was working on a solution well before that. One that addressed not only off path attacks but also addressed on path attacks. One that worked with kernels that only supported limited numbers of file desriptors. One that worked regardless on the number of concurrent outstanding queries. That solution is called DNSSEC. We looked at what Dan did and said it didn't go far enough and that it has implementation issues at high query rates that can't be solved just by throwing more cpu at the problem. The problems are inherent to how UDP works. > He rubs a lot of people the wrong way, but I think he has usually > proved to be right on security issues. Dan is often right. However a different, more encompassing, solution was choosen. > I also think that modular design of security-sensitive tools is the > way to go, with his DNS tools as with Postfix. > -- Clifton > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > 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: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 01:58:55 2008 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 95A7F1065684; Wed, 23 Jul 2008 01:58:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 57C058FC15; Wed, 23 Jul 2008 01:58:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 316581CC09C; Tue, 22 Jul 2008 18:58:55 -0700 (PDT) Date: Tue, 22 Jul 2008 18:58:55 -0700 From: Jeremy Chadwick To: Paul Schmehl Message-ID: <20080723015855.GA36829@eos.sc1.parodius.com> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 01:58:55 -0000 On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote: > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > wrote: > >> Matthew Seaman wrote: >> >>> Are there any plans to enable DNSSEC capability in the resolver built >>> into FreeBSD? >> >> The server is already capable of it. I'm seriously considering enabling the >> define to make the CLI tools (dig/host/nslookup) capable as well (there is >> already an OPTION for this in ports). >> >> The problem is that _using_ DNSSEC requires configuration changes in >> named.conf, and more importantly, configuration of "trust anchors" (even for >> the command line stuff) since the root is not signed. It's not hard to do >> that with the DLV system that ISC has in place, and I would be willing to >> create a conf file that shows how to do that for users to include if they >> choose to. I am not comfortable enabling it by default (not yet anyway), it's >> too big of a POLA issue. >> > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. I completely agree on both points. To give you some idea of how much of an annoyance DNSSEC is, a friend of mine who used to work at Nominum stated that one of their software engineers, when signing, on had a clause appended to his employee agreement stating he would not be required to work on DNSSEC code, due to the absurd complexity of it all. For what it's worth, I went looking into DNSSEC last week, and after a few hours of skimming then reading, I concluded it's over-engineered and adds too much hassle for it to be considered a worthwhile "upgrade". In no way am I putting down the need for security, but the added complexity is what's going to turn people off to this, and because of such, very likely ignore it. You can call me ignorant/lazy -- I welcome such -- but I guarantee others feel the same way. DNS, for most people, is expected to be a "simple thing". They like it to be simple, and it's generally not rocket science. People have come to expect that, and while I think most are willing to accept change (take TSIG for example), it has to be easy to set up, simple to maintain, troubleshooting outlined step-by-step with easy-to-follow output, and in the case of a hard failure, the documentation easy to understand. This is not the case with DNSSEC; I feel like I'm setting up a bloody IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its phases, KSK and its phases, etc... There's the "how to make it work in 6 minutes" PDF by the ISC, which appears to have been made/used for/as presentation material -- meaning you're missing the verbal explanations that go along with each item. There's also inconsistencies in configuration syntax within the PDF, making you wonder how much time someone put into it. There also appears to be an assumption made throughout all of the documentation that I've read: that your recursive and non-recursive DNS servers are separate. I'm still trying to understand why that assumption is made; sure, the majority of the "enterprise-class" world has segregated DNS servers (public authoritative vs. internal recursive resolvers), but the runner-up would be administrators who simply run BIND on their servers and use two simple configuration lines: acl "trusted" { my.net.block/cidr; 127.0.0.1; }; options { allow-recursion { trusted; } }; If DNSSEC really requires that your recursive and non-recursive servers be separate, then it will fail. And I still cannot get over the fact that this "HOWTO" is 47 pages long: http://www.nlnetlabs.nl/dnssec_howto/ Let's not forget this packet flow diagram, which is quite legible and easy to understand: http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png > Once you implement DNSSEC you *must* generate keys every 30 days. So, I > think, if you're going to enable it by default, there needs to be a > script in periodic that will do all the magic to change keys every 30 > days. Maybe put vars in /etc/rc.conf to override the default key lengths > and other portions of the commands that could change per installation. I believe you're talking about re-signing the zones. The duration is adjustable, but 30 days appears to be what the documentation and howto site defaults to/recommends using: http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4 > But until root is signed, it's not worth it for those of us who don't > have dedicated staff doing dns only. Bingo. -- | Jeremy Chadwick jdc at 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 Jul 23 02:30:50 2008 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 D13E21065680; Wed, 23 Jul 2008 02:30:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C5CB98FC0A; Wed, 23 Jul 2008 02:30:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 75CF51A4D80; Tue, 22 Jul 2008 19:11:46 -0700 (PDT) Date: Tue, 22 Jul 2008 19:11:46 -0700 From: Alfred Perlstein To: Jeremy Chadwick Message-ID: <20080723021146.GO76659@elvis.mu.org> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> <20080723015855.GA36829@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080723015855.GA36829@eos.sc1.parodius.com> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , freebsd-stable@freebsd.org, Paul Schmehl Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 02:30:50 -0000 Jeremy, I can't agree with you more, for some reason crypto people seem to believe that in order to drive a car you should have to know how to rebuild a carb. Makes no sense. The funny part is that your comparison with setting up IPsec is the same thing that I compare these things to. Back in 2003 I tried to set up a "shared key" IPSEC dhcp at home, basically I'd just make a key and sneaker-net it to the hosts that wanted to connect, after about 6 hours I just gave up and used "wep". *sigh* -Alfred * Jeremy Chadwick [080722 18:59] wrote: > On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote: > > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton > > wrote: > > > >> Matthew Seaman wrote: > >> > >>> Are there any plans to enable DNSSEC capability in the resolver built > >>> into FreeBSD? > >> > >> The server is already capable of it. I'm seriously considering enabling the > >> define to make the CLI tools (dig/host/nslookup) capable as well (there is > >> already an OPTION for this in ports). > >> > >> The problem is that _using_ DNSSEC requires configuration changes in > >> named.conf, and more importantly, configuration of "trust anchors" (even for > >> the command line stuff) since the root is not signed. It's not hard to do > >> that with the DLV system that ISC has in place, and I would be willing to > >> create a conf file that shows how to do that for users to include if they > >> choose to. I am not comfortable enabling it by default (not yet anyway), it's > >> too big of a POLA issue. > >> > > > > I just played around with it recently. It's not that easy to understand > > initially *and* the trust anchors thing is a royal PITA. > > I completely agree on both points. To give you some idea of how much of > an annoyance DNSSEC is, a friend of mine who used to work at Nominum > stated that one of their software engineers, when signing, on had a > clause appended to his employee agreement stating he would not be > required to work on DNSSEC code, due to the absurd complexity of it all. > > For what it's worth, I went looking into DNSSEC last week, and after a > few hours of skimming then reading, I concluded it's over-engineered and > adds too much hassle for it to be considered a worthwhile "upgrade". In > no way am I putting down the need for security, but the added complexity > is what's going to turn people off to this, and because of such, very > likely ignore it. You can call me ignorant/lazy -- I welcome such -- > but I guarantee others feel the same way. > > DNS, for most people, is expected to be a "simple thing". They like it > to be simple, and it's generally not rocket science. People have come > to expect that, and while I think most are willing to accept change > (take TSIG for example), it has to be easy to set up, simple to > maintain, troubleshooting outlined step-by-step with easy-to-follow > output, and in the case of a hard failure, the documentation easy to > understand. > > This is not the case with DNSSEC; I feel like I'm setting up a bloody > IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES > with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust > anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its > phases, KSK and its phases, etc... > > There's the "how to make it work in 6 minutes" PDF by the ISC, which > appears to have been made/used for/as presentation material -- meaning > you're missing the verbal explanations that go along with each item. > There's also inconsistencies in configuration syntax within the PDF, > making you wonder how much time someone put into it. > > There also appears to be an assumption made throughout all of the > documentation that I've read: that your recursive and non-recursive DNS > servers are separate. I'm still trying to understand why that > assumption is made; sure, the majority of the "enterprise-class" world > has segregated DNS servers (public authoritative vs. internal recursive > resolvers), but the runner-up would be administrators who simply run > BIND on their servers and use two simple configuration lines: > > acl "trusted" { my.net.block/cidr; 127.0.0.1; }; > options { > allow-recursion { trusted; } > }; > > If DNSSEC really requires that your recursive and non-recursive servers > be separate, then it will fail. > > And I still cannot get over the fact that this "HOWTO" is 47 pages long: > http://www.nlnetlabs.nl/dnssec_howto/ > > Let's not forget this packet flow diagram, which is quite legible and > easy to understand: > http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png > > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I > > think, if you're going to enable it by default, there needs to be a > > script in periodic that will do all the magic to change keys every 30 > > days. Maybe put vars in /etc/rc.conf to override the default key lengths > > and other portions of the commands that could change per installation. > > I believe you're talking about re-signing the zones. The duration is > adjustable, but 30 days appears to be what the documentation and howto > site defaults to/recommends using: > > http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html > http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4 > > > But until root is signed, it's not worth it for those of us who don't > > have dedicated staff doing dns only. > > Bingo. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > 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" -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 02:47:06 2008 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 524BC1065686; Wed, 23 Jul 2008 02:47:06 +0000 (UTC) (envelope-from prvs=pschmehl_lists=0832cde34@tx.rr.com) Received: from ip-relay-001.utdallas.edu (ip-relay-001.utdallas.edu [129.110.20.111]) by mx1.freebsd.org (Postfix) with ESMTP id 09FAF8FC2F; Wed, 23 Jul 2008 02:47:05 +0000 (UTC) (envelope-from prvs=pschmehl_lists=0832cde34@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,235,1215406800"; d="scan'208";a="4892722" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-001.utdallas.edu with ESMTP; 22 Jul 2008 21:18:13 -0500 Received: from [192.168.2.102] (cpe-24-175-90-48.tx.res.rr.com [24.175.90.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id AD46123DDF; Tue, 22 Jul 2008 21:18:13 -0500 (CDT) Date: Tue, 22 Jul 2008 21:18:11 -0500 From: Paul Schmehl To: Mark Andrews Message-ID: <616A73D0F163394E96936E69@Macintosh.local> In-Reply-To: <200807230046.m6N0khvt008606@drugs.dv.isc.org> References: <200807230046.m6N0khvt008606@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Munged-Reply-To: To reply - figure it out MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========79D675BB9A887D4CB823==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 02:47:06 -0000 --==========79D675BB9A887D4CB823========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On July 23, 2008 10:46:43 AM +1000 Mark Andrews =20 wrote: >> >> I just played around with it recently. It's not that easy to >> understand initially *and* the trust anchors thing is a royal PITA. >> >> Once you implement DNSSEC you *must* generate keys every 30 days. So, >> I thin k, >> if you're going to enable it by default, there needs to be a script in >> period ic >> that will do all the magic to change keys every 30 days. Maybe put >> vars in /etc/rc.conf to override the default key lengths and other >> portions of the commands that could change per installation. > > WRONG. > > You need to re-sign the zone an expire period before the > signatures expire. You need to generate new keys periodically > but no where near every 30 days. > OK. I misspoke. I got the 30 days from Andrew Clegg's presentation and=20 confused keys with signatures. But still, you have to resign *every* zone = every 30 days. "Signatures have lifespans =E2=80=9CBorn-on=E2=80=9D date =E2=80=93 1 hour prior to running dnssecsignzone Expiration date =E2=80=93 30 days after running dnssecsignzone Expired signatures lead to zones that will not validate!" I followed Clegg's presentation to try out dnssec. Then there's this: "Any time you modify a zone =E2=80=93 or at least every 30 days (minus TTL) you must re-run dnssecsignzone If you don't 1) Zone data will be stale 2) Zone data will be GONE" So, for me, that's three zones I have to mess with every 30 days. Then=20 Clegg says the the ZSK keys should be changed every quarter and the KSK=20 keys every year. So I have to resign monthly, regen ZSK keys quarterly=20 and regen KSK keys annually, and I have to do this without breaking any of = my zones so that they stop resolving for periods long enough to clear out=20 caches. How is the average person supposed to understand this, much less do it=20 correctly? Don't misunderstand me, Mark, I'm all for security. But this=20 ain't easy, and the online information only confuses the issue. Clegg also says this: "When finished: 2 ZSK files (.key and .private) 2 KSK files (.key and .private) 2 zonefiles (unsigned and .signed)" So, do I have to have two zone files or not? As someone who is trying to=20 understand this new technology, I have to tell you, the online=20 documentation isn't written for non dns-gurus. I'll be happy to sign my zones, but not until I understand how it works,=20 what the ramifications are and what my maintenance responsibilities are. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. --==========79D675BB9A887D4CB823==========-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 05:07:44 2008 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 036A5106566B for ; Wed, 23 Jul 2008 05:07:44 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 82C258FC08 for ; Wed, 23 Jul 2008 05:07:43 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 7D3D6D0099; Tue, 22 Jul 2008 19:07:29 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 75E28153882; Tue, 22 Jul 2008 19:07:28 -1000 (HST) Date: Tue, 22 Jul 2008 19:07:28 -1000 From: Clifton Royston To: Royce Williams Message-ID: <20080723050727.GD1279@lava.net> Mail-Followup-To: Royce Williams , freebsd-stable@FreeBSD.org References: <488638DA.7010005@alaska.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488638DA.7010005@alaska.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 23 Jul 2008 05:07:44 -0000 On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: > We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few > days. This started shortly after upgrade from 6.2-RELEASE to > 6.3-RELEASE with freebsd-update. I was having similar problems on some servers using 6.2-psomething, which also use an NFS server heavily (for shared configuration files), until I started using the same vmem.kmem_size tunable Kris is recommending. That seemed to solve the problem for me. (I just slapped it up to 512M rather than try to binary search for some optimum value.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 05:34:04 2008 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 79C4F1065676 for ; Wed, 23 Jul 2008 05:34:04 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 79ECE8FC0C for ; Wed, 23 Jul 2008 05:34:04 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 41D721CC0A0; Tue, 22 Jul 2008 22:34:04 -0700 (PDT) Date: Tue, 22 Jul 2008 22:34:04 -0700 From: Jeremy Chadwick To: Royce Williams Message-ID: <20080723053404.GA46617@eos.sc1.parodius.com> References: <488638DA.7010005@alaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488638DA.7010005@alaska.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 23 Jul 2008 05:34:04 -0000 On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: > We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few > days. This started shortly after upgrade from 6.2-RELEASE to > 6.3-RELEASE with freebsd-update. We use the same hardware (board and chassis), and have no such problems running both RELENG_6 and RELENG_7. I don't think your issue is specific to the board or chassis. Kris's explanation makes a lot more sense. :-) -- | Jeremy Chadwick jdc at 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 Jul 23 05:40:06 2008 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 CB63B106564A for ; Wed, 23 Jul 2008 05:40:06 +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 81BD88FC1A for ; Wed, 23 Jul 2008 05:40:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 12519 invoked by uid 399); 23 Jul 2008 05:40:05 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Jul 2008 05:40:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4886C433.5060003@FreeBSD.org> Date: Tue, 22 Jul 2008 22:40:03 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080721202418.7CF9B4500E@ptavv.es.net> In-Reply-To: <20080721202418.7CF9B4500E@ptavv.es.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 05:40:06 -0000 Lots of good discussion on this thread, I'm going to cherry-pick some things to respond to. Kevin Oberman wrote: > And, if you are not sure how good a job it does (and I am not), you > should use the OARC test to check how well it works: dig +short > porttest.dns-oarc.net TXT > > If the result is not "GOOD", it's not good enough. > > You can test a remote server by adding "@remote-server" to the dig > command. The server may be specified by name or IP address. This is good, I would not specify a name server to test by hostname though, you're hitting a chicken/egg problem if you do. There is also https://www.dns-oarc.net/oarc/services/dnsentropy if your desktop is behind the resolver you want to test. Paul Schmehl wrote: > I just played around with it recently. It's not that easy to > understand initially *and* the trust anchors thing is a royal PITA. The trust anchors thing is made mega easier if you use the DLV service provided by ISC. If you want to configure specific trust anchors yourself, you really need to know what you're doing first. > Once you implement DNSSEC you *must* generate keys every 30 days. You are talking about signing a zone you are authoritative for. I am talking about enabling DNSSEC for the named that comes with FreeBSD and by default is configured as a resolver only. > So, I think, if you're going to enable it by default, there needs > to be a script in periodic that will do all the magic to change > keys every 30 days. I would certainly never write, and I can't imagine that I would ever approve such a script. There are too many moving parts to setting good DNSSEC key policy for me to be comfortable with a cookie-cutter approach. Jeremy Chadwick wrote: > For what it's worth, I went looking into DNSSEC last week, and > after a few hours of skimming then reading, I concluded it's > over-engineered and adds too much hassle for it to be considered a > worthwhile "upgrade". I could certainly sympathize with an argument that parts of the DNSSEC spec are over-engineered. The problem however is that the DNS, more than any other Internet system that I can think of, has so many corner cases that they almost seem to be the norm sometimes, and more than any other service it has been engineered to accommodate them. Personally I was in favor of the "flag day" approach to DNSSEC deployment 7 years ago, and was told "that's not how we do things in DNS." The corner cases have gotten worse since then, not better. > DNS, for most people, is expected to be a "simple thing". And back in "the good old days" it could be. Those days are over. (Arguably they ended in 1995, but I digress.) > There also appears to be an assumption made throughout all of the > documentation that I've read: that your recursive and non-recursive > DNS servers are separate. I'm still trying to understand why that > assumption is made; Because we've been telling people to do that since, oh, say, the '90's? There are very good reasons to do that, I'm not going to belabor them here. The simplest way to understand the justification is that by their very nature authoritative service operates in the UNtrusted world, and you would like your name resolution to happen in a more or less TRUSTED way. The two goals are antithetical. Matthew Seaman wrote: > Forgive me for being obtuse. What I meant was the capability to > enable checking signatures on DNS RRs as a routine effect of > getnameinfo() etc. by modifying resolver(3) routines or similar > locally, without needing a DNSSEC enabled recursive resolver listed > in resolv.conf? I've a feeling the answer is no, but I haven't > been able to find anything definitive. Ok, how is this: no. :) But seriously folks, the problem here is that you're talking about 3 completely separate spheres of operation, which for 99.9% of Internet users are all operating under the control of different people. I'll take it as a given that the members of this list understand what authoritative name service is, and that in order for DNSSEC to work you have to sign the zone that is on the authoritative name server. Interestingly enough, that is the easy part. The second "sphere" is the resolving name server (often erroneously referred to as a caching server) that goes out into the wide world and gathers answers to queries generated by users on its network. The third "sphere" is the stub resolver located on your little computer. What you're asking is, can we have a stub resolver in FreeBSD that will "do the DNSSEC thing" regardless of what kind of resolving name server it's sitting behind? (Please note that I and others have made the argument for a long time now that there is actually a fourth sphere, the application itself. More people agree with that idea now than did in the past, but the question is still what to do about it.) So, here is the problem (actually, problemS) with that. First, the authoritative server is just spitting out bits, it really has no knowledge of what it's sending (let's leave nasty stuff like NSEC out of the picture). The way things stand now, it's the resolver's job to validate that the signature on the data is good, similar to doing "gpg --verify $blah." If the signature validates, then there are no "issues," you just pass the answer back to the stub and you're done. But (and here is where the corner cases start to come in), what if the signature is valid, but the key is expired? Or, what if the signature doesn't validate at all? How much do I care? If you're talking about me surfing over to my bank's website, I care quite a bit! If you're talking about surfing to my webcomic sites, it would be nice if the signatures were good, but it might also be fun to go to a pseudo-random site that is supposed to be my favorite webcomic. (Or, I might know that the admin of the webcomic site is a doofus, and regularly screws up his zone editing process thereby making the signatures invalid for N period of time, and I can live with that.) In a world where the root and $YourFavoriteTLD are both signed, it is theoretically possible that you could engineer a system where your stub gets passed the data it needs (RRs, signatures, keys, etc.) AND is capable of doing the validation, but that's really, really unlikely to ever happen. (Thus my "no" answer above.) Now, if you'd really like your head to hurt, start thinking about ways that the resolving name server can signal the stub about the relative validity of the data it's passing (signed/unsigned/signed but bad sig/signed w/expired key ...), and then if your head doesn't hurt enough already, start thinking about the fourth sphere above, what is the application going to do with that knowledge? (Forget what the user is going to do with it, they already blow right past the SSL warnings, no reason to believe that this will be any different.) For now, the "solution" is to configure the resolver to know about zones that must be signed in order to pass answers back to the stubs. I don't think anyone thinks that's even the tip of this particular iceberg though. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 06:38:00 2008 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 1F328106564A for ; Wed, 23 Jul 2008 06:38:00 +0000 (UTC) (envelope-from royce@alaska.net) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.173.227]) by mx1.freebsd.org (Postfix) with ESMTP id F0D528FC08 for ; Wed, 23 Jul 2008 06:37:59 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [192.168.254.100] (66-230-109-191-rb1.nwc.dsl.dynamic.acsalaska.net [66.230.109.191]) by malik.acsalaska.net (8.14.1/8.14.1) with ESMTP id m6N6bwrM014450 for ; Tue, 22 Jul 2008 22:37:59 -0800 (AKDT) (envelope-from royce@alaska.net) Message-ID: <4886D1E9.1090905@alaska.net> Date: Tue, 22 Jul 2008 22:38:33 -0800 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <488638DA.7010005@alaska.net> <20080723053404.GA46617@eos.sc1.parodius.com> In-Reply-To: <20080723053404.GA46617@eos.sc1.parodius.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 23 Jul 2008 06:38:00 -0000 Jeremy Chadwick wrote, on 7/22/2008 9:34 PM: > On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: >> We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few >> days. This started shortly after upgrade from 6.2-RELEASE to >> 6.3-RELEASE with freebsd-update. > > We use the same hardware (board and chassis), and have no such problems > running both RELENG_6 and RELENG_7. > > I don't think your issue is specific to the board or chassis. Kris's > explanation makes a lot more sense. :-) Jeremy/Kris/Clifton - Looks like we have consensus. :-) Thanks, all of you, for your helpful insight. I've bumped vm.kmem_size up to 400M on half of the affected boxes, leaving the other half as a control group. I'll report back once I have something to report. Royce -- Royce D. Williams - http://royce.ws/ I learn by going where I have to go. - Theodore Roethke From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 07:25:50 2008 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 911C71065680; Wed, 23 Jul 2008 07:25:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 439C68FC32; Wed, 23 Jul 2008 07:25:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6N7PlZJ035859; Wed, 23 Jul 2008 17:25:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807230725.m6N7PlZJ035859@drugs.dv.isc.org> To: Paul Schmehl From: Mark Andrews In-reply-to: Your message of "Tue, 22 Jul 2008 21:18:11 EST." <616A73D0F163394E96936E69@Macintosh.local> Date: Wed, 23 Jul 2008 17:25:47 +1000 Sender: marka@isc.org Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 07:25:50 -0000 > --==========79D675BB9A887D4CB823========== > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > --On July 23, 2008 10:46:43 AM +1000 Mark Andrews =20 > wrote: > >> > >> I just played around with it recently. It's not that easy to > >> understand initially *and* the trust anchors thing is a royal PITA. > >> > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, > >> I thin k, > >> if you're going to enable it by default, there needs to be a script in > >> period ic > >> that will do all the magic to change keys every 30 days. Maybe put > >> vars in /etc/rc.conf to override the default key lengths and other > >> portions of the commands that could change per installation. > > > > WRONG. > > > > You need to re-sign the zone an expire period before the > > signatures expire. You need to generate new keys periodically > > but no where near every 30 days. > > > > OK. I misspoke. I got the 30 days from Andrew Clegg's presentation and=20 > confused keys with signatures. But still, you have to resign *every* zone = > > every 30 days. > > "Signatures have lifespans > > =E2=80=9CBorn-on=E2=80=9D date =E2=80=93 1 hour prior to running > dnssecsignzone > > Expiration date =E2=80=93 30 days after running > dnssecsignzone > > Expired signatures lead to zones that > will not validate!" > > I followed Clegg's presentation to try out dnssec. > > Then there's this: > > "Any time you modify a zone =E2=80=93 or at > least every 30 days (minus TTL) you > must re-run dnssecsignzone > > If you don't > 1) Zone data will be stale > 2) Zone data will be GONE" > > So, for me, that's three zones I have to mess with every 30 days. Then=20 > Clegg says the the ZSK keys should be changed every quarter and the KSK=20 > keys every year. So I have to resign monthly, regen ZSK keys quarterly=20 > and regen KSK keys annually, and I have to do this without breaking any of = > my zones so that they stop resolving for periods long enough to clear out=20 > caches. > > How is the average person supposed to understand this, much less do it=20 > correctly? Don't misunderstand me, Mark, I'm all for security. But this=20 > ain't easy, and the online information only confuses the issue. Firstly just re-sign weekly (pick a day of the week and keep to it). You have to be away multiple weeks for the zone to expire. BIND 9.6 will be able to automatically re-sign a dynamic zone. To roll a zone signing key. Add the new key at the weekly signing. Remove the old key the next week. This provides a one week overlap and as long as no TTL in the zone is larger than 1 week (enforced by lots of caches). To roll a key signing key. Add the key at a weekly signing. Wait for the DNSKEY RRset TTL to expire. Send the new DS/DLV records for the new keys to the parent/DLV operator. Once the updated parent / DLV operator has updated the DS/DLV RRset wait for the old TTL to expire. Remove the old key signing key at your discression. Normally you would do this at the next weekly signing. This proceedure requires one interaction with the parent/dlv operator during the rollover. Note this is not much different than what is required when changing a nameservers. > Clegg also says this: > > "When finished: > 2 ZSK files (.key and .private) > 2 KSK files (.key and .private) > 2 zonefiles (unsigned and .signed)" > > So, do I have to have two zone files or not? As someone who is trying to=20 > understand this new technology, I have to tell you, the online=20 > documentation isn't written for non dns-gurus. > > I'll be happy to sign my zones, but not until I understand how it works,=20 > what the ramifications are and what my maintenance responsibilities are. > Paul Schmehl > If it isn't already obvious, > my opinions are my own and not > those of my employer. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 07:50:56 2008 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 621351065688 for ; Wed, 23 Jul 2008 07:50:56 +0000 (UTC) (envelope-from erwan@rail.eu.org) Received: from depot.rail.eu.org (bievres.rail.eu.org [82.227.34.188]) by mx1.freebsd.org (Postfix) with ESMTP id 27EC58FC46 for ; Wed, 23 Jul 2008 07:50:55 +0000 (UTC) (envelope-from erwan@rail.eu.org) Received: from depot.rail.eu.org (localhost [127.0.0.1]) by depot.rail.eu.org (Postfix) with ESMTP id 4E98081BC05 for ; Wed, 23 Jul 2008 09:32:49 +0200 (CEST) Received: from ratagaz.local (pot44-1-88-172-64-250.fbx.proxad.net [88.172.64.250]) by depot.rail.eu.org (Postfix) with ESMTPSA id 2470E81BC04 for ; Wed, 23 Jul 2008 09:32:49 +0200 (CEST) Received: by ratagaz.local (Postfix, from userid 501) id B04C0BA35BC; Wed, 23 Jul 2008 09:32:47 +0200 (CEST) Date: Wed, 23 Jul 2008 09:32:47 +0200 From: Erwan David To: freebsd-stable@freebsd.org Message-ID: <20080723073247.GJ308@rail.eu.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <616A73D0F163394E96936E69@Macintosh.local> <200807230725.m6N7PlZJ035859@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807230725.m6N7PlZJ035859@drugs.dv.isc.org> X-Republicain: 5 thermidor an CCXVI =?iso-8859-1?B?KELp?= =?iso-8859-1?Q?lier=29?= User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 07:50:56 -0000 Le Wed 23/07/2008, Mark Andrews disait > > To roll a key signing key. Add the key at a weekly signing. > Wait for the DNSKEY RRset TTL to expire. Send the new > DS/DLV records for the new keys to the parent/DLV operator. > Once the updated parent / DLV operator has updated the > DS/DLV RRset wait for the old TTL to expire. Remove the > old key signing key at your discression. Normally you > would do this at the next weekly signing. This proceedure > requires one interaction with the parent/dlv operator during > the rollover. > > Note this is not much different than what is required when > changing a nameservers. But changing nameserver is an exceptional operation. Nobody wants the burden of an exceptional operation to come back regularly. -- Erwan From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 07:56:52 2008 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 88250106564A for ; Wed, 23 Jul 2008 07:56:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 308B38FC0A for ; Wed, 23 Jul 2008 07:56:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6N7uoNW036882 for ; Wed, 23 Jul 2008 17:56:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807230756.m6N7uoNW036882@drugs.dv.isc.org> To: freebsd-stable@freebsd.org From: Mark Andrews Mail-Followup-To: freebsd-stable@freebsd.org In-reply-to: Your message of "Wed, 23 Jul 2008 09:32:47 +0200." <20080723073247.GJ308@rail.eu.org> Date: Wed, 23 Jul 2008 17:56:50 +1000 Sender: marka@isc.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 07:56:52 -0000 > Le Wed 23/07/2008, Mark Andrews disait > > > > To roll a key signing key. Add the key at a weekly signing. > > Wait for the DNSKEY RRset TTL to expire. Send the new > > DS/DLV records for the new keys to the parent/DLV operator. > > Once the updated parent / DLV operator has updated the > > DS/DLV RRset wait for the old TTL to expire. Remove the > > old key signing key at your discression. Normally you > > would do this at the next weekly signing. This proceedure > > requires one interaction with the parent/dlv operator during > > the rollover. > > > > Note this is not much different than what is required when > > changing a nameservers. > > But changing nameserver is an exceptional operation. Nobody wants the burden > of an exceptional operation to come back regularly. KSK changes should be approximately annual which is short enough not to forget but long enough to not be a burden. > -- > Erwan > _______________________________________________ > 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: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 08:33:08 2008 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 488F81065670; Wed, 23 Jul 2008 08:33:08 +0000 (UTC) (envelope-from pol@leissner.se) Received: from mailgate.leissner.se (mailgate.leissner.se [212.3.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id A769A8FC1B; Wed, 23 Jul 2008 08:33:06 +0000 (UTC) (envelope-from pol@leissner.se) Received: from mailgate.leissner.se (localhost [127.0.0.1]) by mailgate.leissner.se (8.14.3/8.14.3) with ESMTP id m6N87wC5083007; Wed, 23 Jul 2008 10:07:58 +0200 (CEST) (envelope-from pol@leissner.se) Received: (from uucp@localhost) by mailgate.leissner.se (8.14.3/8.14.3/Submit) id m6N87w99083003; Wed, 23 Jul 2008 10:07:58 +0200 (CEST) (envelope-from pol@leissner.se) Received: from pol.leissner.se(192.71.29.17), claiming to be "pol" via SMTP by mailgate.leissner.se, id smtpd0Vm4oQ; Wed Jul 23 10:07:52 2008 Received: by pol (Postfix, from userid 1000) id 87D38A40048; Wed, 23 Jul 2008 10:07:46 +0200 (CEST) Date: Wed, 23 Jul 2008 10:07:46 +0200 From: Peter Olsson To: Paul Schmehl Message-ID: <20080723080746.GK6675@pol.leissner.se> References: <20080722200720.0540245048@ptavv.es.net> <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> X-NCC-RegID: se.leissner X-Organization: Leissner Data AB User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 08:33:08 -0000 About scripts for automating DNSSEC maintenance, check this out: http://www.hznet.de/dns/zkt/ There are also some DNSSEC howtos on that site. We use ZKT for our DNSSEC zones, and everything except KSK rollover is fully automated. Has been working fine for about half a year now. Automatic KSK rollover will be in next release of ZKT, I don't know the details of how that is going to work. -- Peter Olsson pol@leissner.se From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 11:09:31 2008 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 81BD11065674; Wed, 23 Jul 2008 11:09:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh01.opentransfer.com (smh01.opentransfer.com [71.18.216.112]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1A38FC0C; Wed, 23 Jul 2008 11:09:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: by smh01.opentransfer.com (Postfix, from userid 8) id 485AB1024CA5; Wed, 23 Jul 2008 07:09:12 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on smh01.opentransfer.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=MIME_QP_LONG_LINE,RDNS_NONE autolearn=disabled version=3.2.4 Received: from webmail6.opentransfer.com (unknown [69.49.230.6]) by smh01.opentransfer.com (Postfix) with ESMTP id F0D361024CAB; Wed, 23 Jul 2008 07:09:11 -0400 (EDT) Received: from webmail6.opentransfer.com (webmail6.opentransfer.com [127.0.0.1]) by webmail6.opentransfer.com (8.13.8/8.13.8) with ESMTP id m6NB9T41031461; Wed, 23 Jul 2008 06:09:29 -0500 Received: (from nobody@localhost) by webmail6.opentransfer.com (8.13.8/8.13.8/Submit) id m6NB9RUL031460; Wed, 23 Jul 2008 14:09:27 +0300 X-Authentication-Warning: webmail6.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from oleg.ecommerce-dev.com (oleg.ecommerce-dev.com [193.142.124.7]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Wed, 23 Jul 2008 14:09:27 +0300 Message-ID: <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> Date: Wed, 23 Jul 2008 14:09:27 +0300 From: "Oleg V. Nauman" To: John Baldwin References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> In-Reply-To: <200807221514.55055.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 193.142.124.7 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 23 Jul 2008 11:09:31 -0000 Quoting John Baldwin : > On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: >> Quoting John Baldwin : >> >> > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: >> >> Quoting "Oleg V. Nauman" : >> >> >> >> > Quoting Jeremy Chadwick : >> >> > >> >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: >> >> >>> It seems to be something was changed with ACPI support on 7.0-STAB= LE > so >> >> >>> my next system upgrade ended with ACPI HPET not working anymore on= my >> >> >>> ASUS A9Rp laptop. >> >> >>> >> >> >>> Here is the part of /var/log/dmesg.today dated July 13: >> >> >>> >> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 >> >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >> >>> [..] >> >> >>> acpi0: on motherboard >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >> >>> acpi0: [ITHREAD] >> >> >>> acpi0: Power Button (fixed) >> >> >>> acpi0: reservation of 0, a0000 (3) failed >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acp= i0 >> >> >>> acpi_ec0: port 0x62,0x66 on acpi0 >> >> >>> acpi_hpet0: iomem >> >> >>> 0xfed00000-0xfed003ff on acpi0 >> >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> >>> >> >> >>> Here is the fresh dmesg output info: >> >> >>> >> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 >> >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 >> >> >>> [..] >> >> >>> acpi0: on motherboard >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 >> >> >>> acpi0: [ITHREAD] >> >> >>> acpi0: Power Button (fixed) >> >> >>> acpi0: reservation of 0, a0000 (3) failed >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acp= i0 >> >> >>> [..] >> >> >>> acpi_hpet0: iomem >> >> >>> 0xfed00000-0xfed003ff on acpi0 >> >> >>> device_attach: acpi_hpet0 attach returned 12 >> >> >>> >> >> >>> And the part of actual sysctl kern.timecounter output: >> >> >>> >> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) >> > dummy(-1000000) >> >> >>> kern.timecounter.hardware: ACPI-safe >> >> >> >> >> >> Seems okay here: >> >> >> >> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul >> >> >> 12 10:53:08 PDT 2008 >> >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 >> >> >> >> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on ac= pi0 >> >> >> acpi_hpet0: iomem >> >> >> 0xfed00000-0xfed003ff on acpi0 >> >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> >> Timecounters tick every 1.000 msec >> >> >> >> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) >> >> >> i8254(0) dummy(-1000000) >> >> >> kern.timecounter.hardware: ACPI-fast >> >> >> >> >> >> You sure you haven't upgraded your BIOS or something and forgot to >> >> >> re-enable HPET? >> >> > >> >> > No it was not upgraded.. Have no option to enable/disable HPET thro= ugh >> >> > BIOS settings though >> >> >> >> I was unclear a bit or so. There are no ACPI related settings in my >> >> laptop's BIOS. >> >> >> >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: >> >> >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff o= n >> > acpi0 >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> >> >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) >> >> dummy(-1000000) >> >> kern.timecounter.hardware: HPET >> >> >> >> Hopefully it helps to understand what is went wrong there. >> > >> > Ok, so the attempt to allocate the resource is failing for some reason. > Can >> > you get output from 'devinfo -r' and 'devinfo -u'? >> >> ... >> >> Will not provide with full listings but just a diff comparing two >> states (this good one with HPET working and bad w/o it): >> >> rainhaven# diff devinfo.r.good devinfo.r.bad >> 177,179d176 >> < acpi_hpet0 >> < I/O memory addresses: >> < 0xfed00000-0xfed003ff >> >> rainhaven# diff devinfo.u.good devinfo.u.bad >> 128c128 >> < 0xfed00000-0xfed003ff (acpi_hpet0) >> --- >> > 0xfed00000-0xfed003ff (ichsmb0) >> >> So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c >> allocates the region required to ichsmb0 instead HPET (it not helps to >> ichsmb0 because it never was working on my laptop but it is another >> story I think). >> >> Thank you for looking into. > > Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this It never was working for me. Well nothing more than ichsmb0: port 0xb00-0xb0f mem 0xfed00000-0xfed003ff =20 at device 20.0 on pci0 ichsmb0: can't map I/O device_attach: ichsmb0 attach returned 6 > change, it restores the probe orders to be more of what they used to be an= d > just gives CPUs a really high probe order so that they should be after oth= er > devices. It was the patch against the CURRENT as far I understand while my =20 laptop running 7.0-STABLE. Well it was applied manually (not a so big =20 issue finally) against 1.243.2.3 revision of =20 /usr/src/sys/dev/acpica/acpi.c and reporting success for the HPET =20 functionality at least (part of relevant verbose dmesg output): ACPI: HPET @ 0x0x77fd6800/0x0038 (v 1 A M I OEMHPET 0x10000626 MSFT =20 0x00000097) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi= 0 acpi_hpet0: vend: 0x4353 rev: 0x10 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 And part of sysctl variables related: kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) =20 dummy(-1000000) kern.timecounter.hardware: HPET I/O mem conflict with ichsmb still in place though Thank you > > Index: acpi.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.248 > diff -u -r1.248 acpi.c > --- acpi.c=097 Apr 2008 18:35:11 -0000=091.248 > +++ acpi.c=0922 Jul 2008 19:12:56 -0000 > @@ -1531,8 +1531,7 @@ > * 1. I/O port and memory system resource holders > * 2. Embedded controllers (to handle early accesses) > * 3. PCI Link Devices > - * ACPI_DEV_BASE_ORDER. Host-PCI bridges > - * ACPI_DEV_BASE_ORDER + 10. CPUs > + * 100000. CPUs > */ > AcpiGetType(handle, &type); > if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, =20 > "PNP0C02")) > @@ -1541,10 +1540,8 @@ > =09*order =3D 2; > else if (acpi_MatchHid(handle, "PNP0C0F")) > =09*order =3D 3; > - else if (acpi_MatchHid(handle, "PNP0A03")) > -=09*order =3D ACPI_DEV_BASE_ORDER; > else if (type =3D=3D ACPI_TYPE_PROCESSOR) > -=09*order =3D ACPI_DEV_BASE_ORDER + 10; > +=09*order =3D 100000; > } > > /* > @@ -1594,10 +1591,8 @@ > =09 * placeholder so that the probe/attach passes will run > =09 * breadth-first. Orders less than ACPI_DEV_BASE_ORDER > =09 * are reserved for special objects (i.e., system > -=09 * resources). Orders between ACPI_DEV_BASE_ORDER and 100 > -=09 * are used for Host-PCI bridges (and effectively all > -=09 * their children) and CPUs. Larger values are used for > -=09 * all other devices. > +=09 * resources). CPU devices have a very high order to > +=09 * ensure they are probed after other devices. > =09 */ > =09 ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str))= ; > =09 order =3D level * 10 + 100; > > -- > John Baldwin > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 12:04:02 2008 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 7D5E21065689; Wed, 23 Jul 2008 12:04:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id E3AD18FC1A; Wed, 23 Jul 2008 12:04:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6NC3nA9007853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 15:03:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6NC3nDa095462; Wed, 23 Jul 2008 15:03:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6NC3mjE095461; Wed, 23 Jul 2008 15:03:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Jul 2008 15:03:48 +0300 From: Kostik Belousov To: jhb@freebsd.org Message-ID: <20080723120348.GJ17123@deviant.kiev.zoral.com.ua> References: <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> <20080722192155.GC17123@deviant.kiev.zoral.com.ua> <48863465.8080204@aldan.algebra.com> <20080722194114.GE17123@deviant.kiev.zoral.com.ua> <48863C3D.7090401@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xg083K01wEKuIc36" Content-Disposition: inline In-Reply-To: <48863C3D.7090401@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URI_NOVOWEL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mikhail Teterin , Kris Kennaway , stable@freebsd.org Subject: Re: "sleeping without queue" ? 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, 23 Jul 2008 12:04:02 -0000 --xg083K01wEKuIc36 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 03:59:57PM -0400, Mikhail Teterin wrote: > Kostik Belousov =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: > >>Kostik Belousov =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >>>Did you switched to the process before doing backtrace (using the proc= =20 > >>> > >>>command)? > >>Ok, thanks. Did not know about this one. Here: > >>... > >>(kgdb) proc 79759 > >>(kgdb) bt > >>#0 sched_switch (td=3D0xffffff01286dc000, newtd=3D0xffffff00010ce000,= =20 > >>flags=3D2) at /var/src/sys/kern/sched_4bsd.c:928 > >>#1 0x0000000000000000 in ?? () > >>#2 0xffffffff802f1108 in mi_switch (flags=3D678281216, newtd=3D0x2) at= =20 > >>/var/src/sys/kern/kern_synch.c:442 > >>#3 0xffffffff80318513 in sleepq_check_timeout () at=20 > >>/var/src/sys/kern/subr_sleepqueue.c:519 > >>#4 0xffffffff80318c85 in sleepq_timedwait (wchan=3D0xffffffff80688408)= at=20 > >>/var/src/sys/kern/subr_sleepqueue.c:597 > >>#5 0xffffffff802f16a2 in _sleep (ident=3D0xffffffff80688408, lock=3D0x= 0,=20 > >>priority=3D0, wmesg=3D0xffffffff804f3059 "vmo_de", timo=3D1) at=20 > >>/var/src/sys/kern/kern_synch.c:224 > >>#6 0xffffffff8043036b in vm_object_deallocate=20 > >>(object=3D0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > >From this frame, please, print the object (like p *object) and > >likewise, print the object that is at the head of the object->shadow_head > >list. > kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem > [GDB will not be able to debug user-mode threads:=20 > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd". > There is no member named pathname. > Reading symbols from /opt/modules/fuse.ko...done. > Loaded symbols for /opt/modules/fuse.ko > Reading symbols from /opt/modules/rtc.ko...done. > Loaded symbols for /opt/modules/rtc.ko > Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from=20 > /boot/kernel/snd_ich.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_ich.ko > Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from=20 > /boot/kernel/msdosfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/msdosfs.ko > #0 0x0000000000000000 in ?? () > (kgdb) frame 6 > Error accessing memory address 0x0: Bad address. > (kgdb) pid 79759 > Undefined command: "pid". Try "help". > (kgdb) proc 79759 > (kgdb) frame 6 > #6 0xffffffff8043036b in vm_object_deallocate=20 > (object=3D0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > 509 pause("vmo_de", 1); > (kgdb) p *object > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff804f21c4 "vm obje= ct",=20 > lo_type =3D 0xffffffff804f3018 "standard object", lo_flags =3D 21168128,= =20 > lo_witness_data =3D { > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, mtx_lock = =3D 4,=20 > mtx_recurse =3D 0}, object_list =3D {tqe_next =3D 0xffffff0005018a90, > tqe_prev =3D 0xffffff00539a6850}, shadow_head =3D {lh_first =3D=20 > 0xffffff005d3afa90}, shadow_list =3D {le_next =3D 0x0, le_prev =3D=20 > 0xffffff005d2cd048}, memq =3D { > tqh_first =3D 0xffffff007eb9fa58, tqh_last =3D 0xffffff007f864820}, ro= ot=20 > =3D 0xffffff007ee14d38, size =3D 427, generation =3D 66, ref_count =3D 2,= =20 > shadow_count =3D 1, > type =3D 0 '\0', flags =3D 256, pg_color =3D 0, paging_in_progress =3D 0= ,=20 > resident_page_count =3D 44, backing_object =3D 0x0, backing_object_offset= =3D=20 > 0, pager_object_list =3D { > tqe_next =3D 0x0, tqe_prev =3D 0x0}, cache =3D 0x0, handle =3D 0x0, un= _pager=20 > =3D {vnp =3D {vnp_size =3D 576646}, devp =3D {devp_pglist =3D {tqh_first = =3D 0x8cc86, > tqh_last =3D 0x0}}, swp =3D {swp_bcount =3D 576646}}} > (kgdb) p (object->shadow_head) > $2 =3D {lh_first =3D 0xffffff005d3afa90} > (kgdb) p *object->shadow_head.lh_first > $3 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff804f21c4 "vm obje= ct",=20 > lo_type =3D 0xffffffff804f3018 "standard object", lo_flags =3D 21168128,= =20 > lo_witness_data =3D { > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, mtx_lock = =3D 4,=20 > mtx_recurse =3D 0}, object_list =3D {tqe_next =3D 0xffffff0066c32340, > tqe_prev =3D 0xffffff012f673ac0}, shadow_head =3D {lh_first =3D 0x0},= =20 > shadow_list =3D {le_next =3D 0x0, le_prev =3D 0xffffff0053024ad0}, memq = =3D { > tqh_first =3D 0xffffff007779f9a0, tqh_last =3D 0xffffff0077c04140}, ro= ot=20 > =3D 0xffffff0077c04130, size =3D 387, generation =3D 3, ref_count =3D 1,= =20 > shadow_count =3D 0, > type =3D 0 '\0', flags =3D 8452, pg_color =3D 0, paging_in_progress =3D = 0,=20 > resident_page_count =3D 2, backing_object =3D 0xffffff0053024a90,=20 > backing_object_offset =3D 163840, > pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, cache =3D 0x= 0,=20 > handle =3D 0x0, un_pager =3D {vnp =3D {vnp_size =3D 365278}, devp =3D {de= vp_pglist =3D { > tqh_first =3D 0x592de, tqh_last =3D 0x0}}, swp =3D {swp_bcount =3D= 365278}}} >=20 >=20 > > > >Another question is what scheduler do you use ? > options SCHED_4BSD # 4BSD scheduler > options PREEMPTION # Enable kernel thread preemption The state of the both object being destroyed and the object that is shadowed looks right for me. Moreover, the shadowed object is not locked, value of the mtx_lock is 4. It seems as if the thread missed the wakeup owed by pause. John, could it be that the following commit is supposed to fix the issue ? r179974 | jhb | 2008-06-24 22:36:33 +0300 (Tue, 24 Jun 2008) | 3 lines MFC: Change the roundrobin implementation in the 4BSD scheduler to trigger a userland preemption directly from hardclock() via sched_clock() >=20 > >>>Also, show the output of ps axl . > >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMM= AND > >> 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00=20 > >>/bin/tcsh -fc=20 > >>/meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx= .pro/bin/ma > > > >It makes sense to show the whole ps axl output. > See http://aldan.algebra.com/~mi/tmp/ps-axl.txt -- I edited it for=20 > privacy a little bit, but process-states are intact. > The java-processes in the linuxf have remained unkillable for weeks now= =20 > -- I even forgot about them. But those are linuxulator problems, whereas= =20 > the tcsh is native... It seems that pid 63930 is problematic too ? --xg083K01wEKuIc36 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiHHiMACgkQC3+MBN1Mb4hubwCdEaKZyQqJuk28P0Tmfyl44Kpw kM0An0iMAiDKRH9uj8wQtwgbFnl+0RgR =DMrw -----END PGP SIGNATURE----- --xg083K01wEKuIc36-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 12:32:04 2008 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 A190B1065679; Wed, 23 Jul 2008 12:32:04 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6F01C8FC2A; Wed, 23 Jul 2008 12:32:04 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95002CE1F3; Wed, 23 Jul 2008 14:32:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Wed, 23 Jul 2008 14:32:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1981@royal64.emp.zapto.org> In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MCP55 SATA data corruption in FreeBSD 7 Thread-Index: AcjbWSPaqAfW4rtJQwiRClpfJFg2GARZZjQg References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> From: "Daniel Eriksson" To: Cc: sos@FreeBSD.org Subject: RE: MCP55 SATA data corruption in FreeBSD 7 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, 23 Jul 2008 12:32:04 -0000 I wrote: > I am having problems with silent data corruption on (some) drives > connected to an MCP55 SATA controller. The original problem showed up when talking to (brand new) Samsung 1TB drives in SATA-300 mode hooked up to the onboard controller. I have now tested with a 750GB Seagate drive in both SATA-300 and SATA-150 mode. Unfortunately the problem was not Samsung-related or SATA-300 specific. This points to a driver problem with the chipset/controller combination, or possibly some sort of strange interaction with other hardware (interrupts?). I have no idea how to troubleshoot this any further. ___ Daniel Eriksson (http://www.toomuchdata.com/) From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 12:46:19 2008 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 CD290106564A; Wed, 23 Jul 2008 12:46:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id CD4D88FC1F; Wed, 23 Jul 2008 12:46:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7F4C91CC09E; Wed, 23 Jul 2008 05:46:19 -0700 (PDT) Date: Wed, 23 Jul 2008 05:46:19 -0700 From: Jeremy Chadwick To: Daniel Eriksson Message-ID: <20080723124619.GA65224@eos.sc1.parodius.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <4F9C9299A10AE74E89EA580D14AA10A61A1981@royal64.emp.zapto.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1981@royal64.emp.zapto.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, sos@FreeBSD.org Subject: Re: MCP55 SATA data corruption in FreeBSD 7 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, 23 Jul 2008 12:46:19 -0000 On Wed, Jul 23, 2008 at 02:32:01PM +0200, Daniel Eriksson wrote: > > I am having problems with silent data corruption on (some) drives > > connected to an MCP55 SATA controller. > > The original problem showed up when talking to (brand new) Samsung 1TB > drives in SATA-300 mode hooked up to the onboard controller. I have now > tested with a 750GB Seagate drive in both SATA-300 and SATA-150 mode. > Unfortunately the problem was not Samsung-related or SATA-300 specific. > > This points to a driver problem with the chipset/controller combination, > or possibly some sort of strange interaction with other hardware > (interrupts?). I have no idea how to troubleshoot this any further. Or it could just be a bad motherboard. (I'd need to go re-read the thread to remember if you were seeing this on more than one board.) -- | Jeremy Chadwick jdc at 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 Jul 23 13:39:16 2008 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 198491065671 for ; Wed, 23 Jul 2008 13:39:16 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id A849D8FC13 for ; Wed, 23 Jul 2008 13:39:15 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1216820349; bh=UKPuJ6LlXY4nFQqf0sEqJGP8u7za+l/1puw+lLT7/B8=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Pgp-Agent:X-Mailer; b=P/xQjF+SzCAkaqx06Xm7qPUlkhVSSTlfaVyFATOoVF yAvc4qlJPVgYE7ylbaY9D6sbs8Aj3+V9SmRZuODG87tUZNxuy9CySZDQCnVY0hcumD+ wVencb5SR27N/VHyf2s3d7MlJ9Y2X/QUEyUldB7Cz/g/5xeB4I8+oSDtGgRxfM= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id m6NDd1xT040357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jul 2008 13:39:09 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] Message-Id: <3200E316-1DD0-4B44-B7F6-CDFF689F00DB@verweg.com> From: Ruben van Staveren To: Kevin Oberman In-Reply-To: <20080722214925.390584500E@ptavv.es.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-84-142450675" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 23 Jul 2008 15:38:55 +0200 References: <20080722214925.390584500E@ptavv.es.net> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV 0.93/6805/Wed Apr 16 19:57:54 2008 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Wed, 23 Jul 2008 13:39:10 +0000 (UTC) Cc: Doug Barton , freebsd-stable@freebsd.org, Paul Schmehl Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 13:39:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-84-142450675 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 22 Jul 2008, at 23:49, Kevin Oberman wrote: >> Someone needs to write a really good tutorial on dnssec. The bits >> and >> pieces are scattered about the web, but explanations of now to >> publish >> your keys, to whom they need to be published and what is involved in >> the ongoing maintenance are lacking. Especially a clear explanation >> of what is required to run both keyed and "legacy" dns at the same >> time. Another piece of text can be found at http://www.nlnetlabs.nl/dnssec_howto/ > I can't imagine why anyone would want to run both. Resolvers which > don't > know how to check signatures simple don't do so and everything still > works. > > A pretty good, though somewhat outdated tutorial can be found in NIST > SP800-81. It's pretty readable and tells you how to generate keys and > sign a zone properly. > http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf Regards, Ruben --Apple-Mail-84-142450675 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFIhzRvZ88+mcQxRw0RAt4cAJ9N5HB629dM7ib6sMu1doSsxOKJIACdFkQR 93Uuv3IMXxFlsoEadABeON0= =c0lW -----END PGP SIGNATURE----- --Apple-Mail-84-142450675-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 13:41:35 2008 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 929D110656A0; Wed, 23 Jul 2008 13:41:35 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id B18598FC1B; Wed, 23 Jul 2008 13:41:33 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080723134648.EHMA7070.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Wed, 23 Jul 2008 14:46:48 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20080723134505.OGMS29365.aamtaout02-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com>; Wed, 23 Jul 2008 14:45:05 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6NDfIjS090672; Wed, 23 Jul 2008 14:41:19 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: Jeremy Chadwick Date: Wed, 23 Jul 2008 14:41:18 +0100 User-Agent: KMail/1.9.7 References: <200807221727.52718.ianjhart@ntlworld.com> <200807221847.34935.ianjhart@ntlworld.com> <20080723001835.GA33136@eos.sc1.parodius.com> In-Reply-To: <20080723001835.GA33136@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200807231441.18350.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Cc: freebsd-stable@freebsd.org Subject: Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 23 Jul 2008 13:41:35 -0000 On Wednesday 23 July 2008 01:18:35 Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: > > On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > > > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > > > Same hardware as my other thread. > > > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > > > > > [using 2Gb RAM and SATA in legacy mode] > > > > > > > > I'd like to focus only on making the CDROM boot complete. > > > > > > > > Summary: hangs just after the CPUs are launched. > > > > > > > > 6.2-RELEASE works okay, no AHCI support > > > > 6.3-RELEASE works okay > > > > 7.0-RELEASE hangs > > > > 7.0-STABLE-200806-SNAPSHOT hangs > > > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > > > > > I thought I could do a binary search using the current snapshot > > > > boot-only CDs but they only go back to March. Are there any older > > > > ones available? > > > > > > Have you tried disabling ACPI to see if it makes any sort of > > > difference? > > > > Yes, but I'm happy to re-try. > > > > Which method is "best"? Or is it 1 + 2 or 3? > > > > 1) BIOS > > 2) Beastie menu option > > 3) loader prompt set hint > > Item #2 is the easiest. You should really be able to leave the BIOS > settings at their defaults (Factory Defaults) and have this system work > on FreeBSD. You would think so, although I usually try to buy only "obsolete" hardware to give the drivers a chance to mature. That saves money too :) > > Items #2 and #3 are the same. The loader menu option for disabling ACPI > simply sets the hint. Okay, that's clearer now. I was probably confusing this with APIC. Anyway, result is. No change. FWIW without ACPI the boot dies at trying to mount md0. No drives appear to be probed (I'd need to double check that). > > > > Also, AHCI should work just fine on those systems -- I know because I > > > have fairly extensive experience with Supermicro hardware, although > > > what you're using is newer than what I presently have. I don't know > > > why you're setting Compatible/Legacy mode on your controller (you > > > mention doing this in your other thread as well). > > > > Because I don't know what's wrong yet and AHCI support is newer than SATA > > support and this is a newish board? [At least 6.2 doesn't seem to support > > it and it has an AHCI legacy option!] > > > > I'd be happy to swap this over. Slight problem; the drives get > > renumbered, so I'd rather not swap back and forth. > > You *absolutely* should have AHCI enabled. There's a lot of reasons > why, too. I highly recommend avoiding the "SATA Compatible" mode. > > AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because > we have many Supermicro boards running those versions which do have AHCI > enabled. Please use it, and stick with it. Yes, it does work on 6.3. This thread is tangential to the problem I'm trying to fix. I'm experienced enough to know that noone is going to fix the kldload issue on 6.3. If I can get to 7.0-whatever there's at least some chance someone will look at it. My initial thought was to regression test the CDs. So I tried every one that I had lying around. This included 6.1 and 6.2, neither of which appear to have AHCI support, hence the messing about with the BIOS. [I've now tested 6.0 as well. The CDROM has some issue which results in danger will robinson. Presumably fixed in later versions.] Noone has yet suggested a source for 7.0-CURRENT boot CDROMs so I'm a bit stuck at the moment. > > Here's added proof that AHCI works fine on 6.3: > > $ dmesg -a | grep -i ahci > atapci1: port > 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem > 0xe0000400-0xe00007ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version > 01.10 controller with 4 ports detected > $ uname -r -s > FreeBSD 6.3-PRERELEASE > > The adX device renumbering is expected. There are workarounds for this, > but I recommend you simply enable AHCI. Do not keep toggling it on/off. > > > > Below is what we use on our systems; factory defaults, then make the > > > following changes. (The G-LAN1 OPROM option you can do whatever you > > > want with -- it's specific to our environment). > > > > > > * Main > > > * Date > > > --> Set to GMT, not local time!!! > > > * Serial ATA > > > --> SATA Controller Mode --> Enhanced > > > --> SATA AHCI --> Enabled > > > > > > * Advanced > > > * Boot Features > > > --> Quiet Mode --> Disabled > > > --> Enable Multimedia Timer --> Enabled > > > * PCI Configuration > > > --> Onboard G-LAN1 OPROM --> Disabled > > > --> Large Disk Access Mode --> Other > > > * Advanced Processor Options > > > --> Intel(R) Virtualization Technology --> Enabled > > > --> C1 Enhanced Mode --> Enabled > > > > I've got as close as I can to this. > > > > This board also has an AHCI legacy option [disabled] which hides ports 5 > > and 6. I also disabled quickboot and POST errors. I assume multimedia > > timer is the same as HPET. Doesn't seem to be any disk translation > > option. I took the fans off 'flat out'. > > Okay, I've had a chance to review the board manual that comes with the > X7SBi. You should set the following: > > Serial ATA: Enabled > Native Mode Operation: Serial ATA > SATA AHCI: Enabled > SATA AHCI Legacy: Disabled Those were the settings I started with. > > The name "SATA AHCI Legacy" a horrible name for what it does. The ICH9 > itself has support for 6 SATA ports, but (if I remember correctly, based > on reading some Intel design documents) there are extra registers you > have to tweak to get those ports to work, and the OS has to be fully > aware of how to do that. The BIOS option simply disables SATA ports 5 > and 6 altogether; the underlying OS never sees them. I'd recommend > keeping that setting Disabled (the default) unless you have disks on > those ports (I don't see how, since it's a 4-disk system!). > > I don't think this option is what's causing you problems, though. I don't think so either. Or at least, if this (ATA) is the problem it's also broken for legacy settings as well. Of course I didn't know that until after I'd tested it :) > > "Multimedia Timer" is indeed HPET. Looks like they changed the name to > be more reflective of what it actually is. > > The "Large Disk Access" mode does appear to be missing from that BIOS, > probably for a good reason. I can enable/disable it on our boards with > no repercussions (the options are "DOS" and "Other", which is why I > choose "Other"). I'm not entirely sure what it does. > > As for your problem... > > If the CDROM is the problem (which would be odd, since the disc does > boot and load the kernel successfully), can you try going into the BIOS > and setting IDE Channel 0 Master (which I think is the CDROM -- I could > be wrong here) and set "Transfer Mode" to PIO1 and "Ultra DMA Mode" to > Disabled? I'll try this. IIRC a CDROM spinup issue was mentioned in the HP laptop thread with the same issue (boot from CDROM). > > I have a feeling the problem isn't related to the CDROM, but I'm not > entirely sure how to debug it. That's two of us then > > There are other users using the X7SBi with success: > > http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread >/d0a2d20f8965361a Wow! The exact problem I have. I guess I should have Googled the mobo, not just the server model. The box ships with a DVD so old hardware shouldn't be an issue. I'll find another CDROM drive and try it. This also suggests this may be a CDROM (RE) issue not an O/S issue. This would tie in with the HP laptop. I'll try an source or binary upgrade from 6.3. >http://www.webhostingtalk.com/showthread.php?t=666686 This references FreeBSD 5.0/5.1, which I assume is not a typo. > > Also, can you make sure your BIOS revision is 1.1a, just to rule out any > BIOS-related issues? Yes it is, and (for the archive) that's the only one available. I managed to get a verbose boot from the 7.0-RELEASE CDROM, if that's any use to anyone. After the sig again. Thanks again for your time. -- ian j hart Word wrap should be off. Apologies to console users. SMAP type=01 base=0000000000000000 len=000000000009dc00 SMAP type=02 base=000000000009dc00 len=0000000000002400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000007fd70000 SMAP type=03 base=000000007fe70000 len=0000000000011000 SMAP type=04 base=000000007fe81000 len=0000000000003000 SMAP type=02 base=000000007fe84000 len=000000000007c000 SMAP type=02 base=000000007ff00000 len=0000000000100000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000100000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff000000 len=0000000001000000 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80fc8000. Preloaded mfs_root "/boot/mfsroot" at 0xffffffff80fc8210. Calibrating clock(s) ... i8254 clock: 1193177 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394014724 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 2128887808 (2030 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x00000000010c5000 - 0x000000007c22bfff, 2065068032 bytes (504167 pages) avail memory = 2054242304 (1959 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ACPI: RSDP @ 0x0xf69a0/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0x7fe77290/0x00A4 (v 1 PTLTD XSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x7fe80d60/0x00F4 (v 3 INTEL 0x06040000 PTL 0x00000002) ACPI: DSDT @ 0x0x7fe7a435/0x68B7 (v 1 INTEL BEARLAKE 0x06040000 MSFT 0x03000000) ACPI: FACS @ 0x0x7fe83fc0/0x0040 ACPI: _MAR @ 0x0x7fe80e54/0x0030 (v 1 Intel OEMDMAR 0x06040000 LOHR 0x00000001) ACPI: MCFG @ 0x0x7fe80e84/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) ACPI: HPET @ 0x0x7fe80ec0/0x0038 (v 1 PTLTD HPETTBL 0x06040000 LTP 0x00000001) ACPI: APIC @ 0x0x7fe80ef8/0x0090 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x7fe80f88/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SPCR @ 0x0x7fe80fb0/0x0050 (v 1 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) ACPI: SSDT @ 0x0x7fe78ba7/0x025F (v 1 PmRef Cpu0Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe78b01/0x00A6 (v 1 PmRef Cpu7Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe78a5b/0x00A6 (v 1 PmRef Cpu6Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe789b5/0x00A6 (v 1 PmRef Cpu5Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe7890f/0x00A6 (v 1 PmRef Cpu4Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe78869/0x00A6 (v 1 PmRef Cpu3Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe787c3/0x00A6 (v 1 PmRef Cpu2Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe7871d/0x00A6 (v 1 PmRef Cpu1Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0x7fe77334/0x13E9 (v 1 PmRef CpuPm 0x00003000 INTL 0x20050228) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 5, Interrupt 24 at 0xfecc0000 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.IGD0.IGDP -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 ACPI: SSDT @ 0x0x7fe78e06/0x01DD (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050228) cpu0: switching to generic Cx mode est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x7fe78fe3/0x016E (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20050228) est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 ACPI: SSDT @ 0x0x7fe79151/0x016E (v 1 PmRef Cpu2Ist 0x00003000 INTL 0x20050228) est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 ACPI: SSDT @ 0x0x7fe792bf/0x016E (v 1 PmRef Cpu3Ist 0x00003000 INTL 0x20050228) est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29f0, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29f1, revid=0x01 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x294a, revid=0x02 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601400, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2916, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2920, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x1c50, size 3, enabled map[14]: type I/O Port, range 32, base 0x1c44, size 2, enabled map[18]: type I/O Port, range 32, base 0x1c48, size 3, enabled map[1c]: type I/O Port, range 32, base 0x1c40, size 2, enabled map[20]: type I/O Port, range 32, base 0x1c10, size 4, enabled map[24]: type I/O Port, range 32, base 0x1c00, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type Memory, range 64, base 0xd8601800, size 8, memory disabled map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2926, revid=0x02 domain=0, bus=0, slot=31, func=5 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x1c68, size 3, enabled map[14]: type I/O Port, range 32, base 0x1c5c, size 2, enabled map[18]: type I/O Port, range 32, base 0x1c60, size 3, enabled map[1c]: type I/O Port, range 32, base 0x1c58, size 2, enabled map[20]: type I/O Port, range 32, base 0x1c30, size 4, enabled map[24]: type I/O Port, range 32, base 0x1c20, size 4, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2932, revid=0x02 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xd8600000, size 12, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd8100000-0xd81fffff pcib1: no prefetched decode pcib1: could not get PCI interrupt routing table for \_SB_.PCI0.PEG_ - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x032c, revid=0x09 domain=0, bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0326, revid=0x09 domain=0, bus=1, slot=0, func=1 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8100000, size 12, enabled pcib1: requested memory range 0xd8100000-0xd8100fff: good pcib2: at device 0.0 on pci1 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8601000-0xd86013ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib3: irq 16 at device 28.0 on pci0 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci5: on pcib3 pci5: domain=0, physical bus=5 pcib4: irq 16 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 13 pcib4: I/O decode 0x2000-0x2fff pcib4: memory decode 0xd8000000-0xd80fffff pcib4: no prefetched decode pci13: on pcib4 pci13: domain=0, physical bus=13 found-> vendor=0x8086, dev=0x108c, revid=0x03 domain=0, bus=13, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib4: requested memory range 0xd8000000-0xd801ffff: good map[18]: type I/O Port, range 32, base 0x2000, size 5, enabled pcib4: requested I/O range 0x2000-0x201f: in range pcib4: matched entry for 13.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci13 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 52 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: bpf attached em0: Ethernet address: 00:30:48:64:22:fa em0: [FILTER] pcib5: irq 17 at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 15 pcib5: subordinate bus 15 pcib5: I/O decode 0x3000-0x3fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: no prefetched decode pci15: on pcib5 pci15: domain=0, physical bus=15 found-> vendor=0x8086, dev=0x109a, revid=0x00 domain=0, bus=15, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8200000, size 17, enabled pcib5: requested memory range 0xd8200000-0xd821ffff: good map[18]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib5: requested I/O range 0x3000-0x301f: in range pcib5: matched entry for 15.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 em1: port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 17 at device 0.0 on pci15 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8200000 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to vector 53 em1: using IRQ 257 for MSI em1: Using MSI interrupt em1: bpf attached em1: Ethernet address: 00:30:48:64:22:fb em1: [FILTER] uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 55 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd8601400-0xd86017ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601400 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 17 pcib6: subordinate bus 17 pcib6: I/O decode 0x4000-0x4fff pcib6: memory decode 0xd8300000-0xd83fffff pcib6: prefetched decode 0xd0000000-0xd7ffffff pcib6: Subtractively decoded bridge. pci17: on pcib6 pci17: domain=0, physical bus=17 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=17, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 27, enabled pcib6: requested memory range 0xd0000000-0xd7ffffff: good map[14]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib6: requested I/O range 0x4000-0x40ff: in range map[18]: type Memory, range 32, base 0xd8300000, size 16, enabled pcib6: requested memory range 0xd8300000-0xd830ffff: good pcib6: matched entry for 17.3.INTA pcib6: slot 3 INTA hardwired to IRQ 22 found-> vendor=0x1283, dev=0x8213, revid=0x00 domain=0, bus=17, slot=4, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x4420, size 3, enabled pcib6: requested I/O range 0x4420-0x4427: in range map[14]: type I/O Port, range 32, base 0x4414, size 2, enabled pcib6: requested I/O range 0x4414-0x4417: in range map[18]: type I/O Port, range 32, base 0x4418, size 3, enabled pcib6: requested I/O range 0x4418-0x441f: in range map[1c]: type I/O Port, range 32, base 0x4410, size 2, enabled pcib6: requested I/O range 0x4410-0x4413: in range map[20]: type I/O Port, range 32, base 0x4400, size 4, enabled pcib6: requested I/O range 0x4400-0x440f: in range pcib6: matched entry for 17.4.INTA pcib6: slot 4 INTA hardwired to IRQ 23 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8300000-0xd830ffff irq 22 at device 3.0 on pci17 atapci0: port 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f irq 23 at device 4.0 on pci17 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x4420 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x4414 ata2: reset tp1 mask=03 ostat0=60 ostat1=50 ata2: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=20 stat1=00 devices=0x8 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x4418 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x4410 ata3: reset tp1 mask=00 ostat0=ff ostat1=ff ata3: [MPSAFE] ata3: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x1c10-0x1c1f,0x1c00-0x1c0f irq 17 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c10 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0x1c00 ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1c50 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1c44 ata4: reset tp1 mask=03 ostat0=50 ostat1=00 ata4: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x1c48 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x1c40 ata5: reset tp1 mask=03 ostat0=7f ostat1=7f ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat1=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=ff devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0x1c68-0x1c6f,0x1c5c-0x1c5f,0x1c60-0x1c67,0x1c58-0x1c5b,0x1c30-0x1c3f,0x1c20-0x1c2f irq 18 at device 31.5 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c30 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x10 bytes for rid 0x24 type 4 at 0x1c20 ata6: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1c68 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1c5c ata6: reset tp1 mask=03 ostat0=7f ostat1=7f ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat0=0x7f err=0xff lsb=0xff msb=0xff ata6: stat1=0x7f err=0xff lsb=0xff msb=0xff ata6: reset tp2 stat0=ff stat1=ff devices=0x0 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x1c60 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x1c58 ata7: reset tp1 mask=03 ostat0=7f ostat1=7f ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat0=0x7f err=0xff lsb=0xff msb=0xff ata7: stat1=0x7f err=0xff lsb=0xff msb=0xff ata7: reset tp2 stat0=ff stat1=ff devices=0x0 ata7: [MPSAFE] ata7: [ITHREAD] pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 59 sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 60 fdc0: [FILTER] ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 61 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ahc_isa_probe 1: ioport 0x1c00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 132244 -> 100000 procfs registered lapic: Divisor 2, Frequency 133000820 hz Timecounter "TSC" frequency 2394014724 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 ata2-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: DVDROM drive at ata2 as slave acd0: read 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-R 120mm data disc ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 305245MB at ata4-master SATA300 ad8: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Intel check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 2 ioapic0: Assigning ISA IRQ 6 to local APIC 3 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 3 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 2 ioapic0: Assigning PCI IRQ 23 to local APIC 3 msi: Assigning MSI IRQ 256 to local APIC 0 msi: Assigning MSI IRQ 257 to local APIC 1 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 13:49:46 2008 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 A31E2106566C; Wed, 23 Jul 2008 13:49:46 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id 24ED68FC16; Wed, 23 Jul 2008 13:49:45 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1216820984; bh=8WtTONhzkD3gLPxTTNV4AAOtokHNph2hc3kjcF8xcZA=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Pgp-Agent:X-Mailer; b=qIi8sSw7rx45gZMcjRJ6HC7zB2yAqXu2ZvyhNVejnl x1e+A/Qs1KQdj26PQTiOgeCUHWitkDwJO96ZXdmCHyLa+g6h9QUzhHhKiB7pC8JxRZA QAE3oOQeuwM0akt4KwNxq4Q+aC0hqCgN3pOsBtrYrOAySREStYoyzmkEO4ACls= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id m6NDncH7086532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jul 2008 13:49:44 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] Message-Id: <75D115D6-6B38-4A32-AC39-CA5081A5B2A1@verweg.com> From: Ruben van Staveren To: Paul Schmehl In-Reply-To: <616A73D0F163394E96936E69@Macintosh.local> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-85-143088124" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 23 Jul 2008 15:49:32 +0200 References: <200807230046.m6N0khvt008606@drugs.dv.isc.org> <616A73D0F163394E96936E69@Macintosh.local> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV 0.93/6805/Wed Apr 16 19:57:54 2008 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Wed, 23 Jul 2008 13:49:44 +0000 (UTC) Cc: Mark Andrews , freebsd-stable@freebsd.org, Doug Barton Subject: Re: FreeBSD 7.1 and BIND exploit 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, 23 Jul 2008 13:49:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-85-143088124 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 23 Jul 2008, at 4:18, Paul Schmehl wrote: >> >> WRONG. >> >> You need to re-sign the zone an expire period before the >> signatures expire. You need to generate new keys periodically >> but no where near every 30 days. >> > > OK. I misspoke. I got the 30 days from Andrew Clegg's presentation > and confused keys with signatures. But still, you have to resign > *every* zone every 30 days. Don't forget to bump the zone serial too... as your secondaries will not catch up otherwise and start serving expired RRSIG's, leaving your zone dead in the water. - R --Apple-Mail-85-143088124 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFIhzbtZ88+mcQxRw0RAsbPAJ47H0rtZp4MvRPF3GWge2X8ZPOq7QCcDDJC Nc6HHFLKC09rbjtPxh2VBwY= =p1mb -----END PGP SIGNATURE----- --Apple-Mail-85-143088124-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 14:01:09 2008 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 1F3E9106567B for ; Wed, 23 Jul 2008 14:01:09 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 148108FC24 for ; Wed, 23 Jul 2008 14:01:08 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by rv-out-0506.google.com with SMTP id b25so2873686rvf.43 for ; Wed, 23 Jul 2008 07:01:08 -0700 (PDT) Received: by 10.141.36.10 with SMTP id o10mr71306rvj.176.1216820227095; Wed, 23 Jul 2008 06:37:07 -0700 (PDT) Received: by 10.141.97.9 with HTTP; Wed, 23 Jul 2008 06:37:07 -0700 (PDT) Message-ID: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> Date: Wed, 23 Jul 2008 09:37:07 -0400 From: "Edward Ruggeri" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use 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, 23 Jul 2008 14:01:09 -0000 Hi, I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I got kernel panics while using the wireless card under 7-STABLE, so to try to isolate the problem, I've wiped the hard-drive and reinstalled FreeBSD from scratch. Under 7.0-RELEASE, installed yesterday (7/22/08) from FTP source, wireless works well; I can use the Lynx browser, download ports/source, etc. But when I update to 7-STABLE, I can still establish a connection to the wireless network (i.e., receive an IP) and (generally) receive a few webpages, but quickly and inevitably, I get a kernel panic (fatal trap 12: page fault while in kernel mode). I have been using a GENERIC kernel to isolate problems. This suggests (to me, at least) a problem in 7-STABLE that does not exist in 7.0-RELEASE. I do not have the laptop with me here at work. When I get home, I plan to recompile the kernel with debugging options, so I can get and examine a core dump. I'll also switch out the ULE for 4BSD scheduler, and remove SMP support, to see if those might be at fault. I did this about a week ago when I first started having problems under 7-STABLE; changing the scheduler and removing SMP did not seem to fix the problem. A backtrace at that time indicated that, in ath_start, the following assertion failed (line 1478 in ath.c): bf = STAILQ_FIRST(&frags); KASSERT(bf != NULL, ("no buf for txfrag")); I will attempt to verify those results on the new, clean install. Any other recommendations? My understanding is that many people likely have this ath chipset, and even this same ThinkPad wireless card. >From looking over problem reports, it doesn't seem other people have had this problem, though. Is FreeBSD-Stable a good place to ask about this problem, or should I proceed directly to filing a problem report (do not pass go, do not collect $200)? Thanks! Sincerely, -- Ned Ruggeri From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 14:37:29 2008 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 0DED61065682 for ; Wed, 23 Jul 2008 14:37:29 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [204.228.224.242]) by mx1.freebsd.org (Postfix) with ESMTP id 0426E8FC17 for ; Wed, 23 Jul 2008 14:37:28 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net ([204.228.224.242] helo=localhost ident=mailnull) by diana.db.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1KLf50-000Ge2-4x for freebsd-stable@freebsd.org; Wed, 23 Jul 2008 08:12:34 -0600 Received: from diana.db.net ([127.0.0.1] helo=localhost) (envelope-from ) id 1KLf4y-0009v6-RY; Wed, 23 Jul 2008 10:12:32 -0400 Date: Wed, 23 Jul 2008 10:12:32 -0400 From: Diane Bruce To: freebsd-stable@freebsd.org Message-ID: <20080723141232.GA38083@night.db.net> References: <200807230046.m6N0khvt008606@drugs.dv.isc.org> <616A73D0F163394E96936E69@Macintosh.local> <75D115D6-6B38-4A32-AC39-CA5081A5B2A1@verweg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75D115D6-6B38-4A32-AC39-CA5081A5B2A1@verweg.com> User-Agent: Mutt/1.4.2.3i Subject: DNSSEC 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, 23 Jul 2008 14:37:29 -0000 hi, This might be of interest to some. http://arstechnica.com/news.ars/post/20080722-org-first-top-level-domain-to-adopt-dns-security-protocol.html - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:02:21 2008 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 265551065672 for ; Wed, 23 Jul 2008 18:02:21 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFB098FC37 for ; Wed, 23 Jul 2008 18:02:20 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so1819277pyb.10 for ; Wed, 23 Jul 2008 11:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=eoWhr+GD4SAwEaBfh5QDlFOnVAiCOBZM/EPJzWGBL90=; b=gmTVIwsI9DiRB3J4w/bR3sw3QQyTRfGIPC6qBvxjmxXJlvtO7EgeeTA3d8cv883/UG M1mjwux9UnDlef2tCHty2CwQjKV6eQlpy2DThkgTbUS/ZIImSdHZD4HENvMLcNUQF+ND jzqYm24ijonxc9CMzGJHSvUGlYKR1OkcgxVZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IRyYUaj6PB0VrQPpnIXl/4z7Q9KNhP0328j0C109ID7x8UPqeCPeXp71CJg4+nLoKu diUNBpSBMgcE6KySoO46y7b9x3UGLIhCstf4Thjf6XcuQpuGJPgc5y6o4gfkFC4NxA9a z8a5Y8NJ7BugK/4CoFoc9KDaoloL6RxANLeSc= Received: by 10.141.163.12 with SMTP id q12mr327rvo.265.1216834453157; Wed, 23 Jul 2008 10:34:13 -0700 (PDT) Received: by 10.140.126.2 with HTTP; Wed, 23 Jul 2008 10:34:11 -0700 (PDT) Message-ID: Date: Wed, 23 Jul 2008 10:34:11 -0700 From: "Manjunath Ranganathaiah" To: "Daniel Eriksson" In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> Cc: legioner.r@gmail.com, morten@lightworkings.dk, freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: MCP55 SATA data corruption in FreeBSD 7 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, 23 Jul 2008 18:02:21 -0000 On 7/1/08, Daniel Eriksson wrote: > > The server with 570 SLI chipset has a bunch of new SATA-300 drives > hooked up to the MCP55 controller and it is giving me silent data > corruption (easily detectable by running ZFS scrub, every time I run it > new checksum errors show up). Could be in-memory data corruption. How much RAM installed on the system? -Manjunath From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:34:32 2008 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 7D99E1065678; Wed, 23 Jul 2008 18:34:32 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.freebsd.org (Postfix) with ESMTP id 435398FC16; Wed, 23 Jul 2008 18:34:32 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95002DF3EF; Wed, 23 Jul 2008 20:34:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Wed, 23 Jul 2008 20:34:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1982@royal64.emp.zapto.org> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MCP55 SATA data corruption in FreeBSD 7 Thread-Index: Acjs6qgJJ8CYf06xS9m+66o+q/wbQAAB69Ww References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> From: "Daniel Eriksson" To: "Manjunath Ranganathaiah" Cc: legioner.r@gmail.com, morten@lightworkings.dk, freebsd-stable@freebsd.org, sos@freebsd.org Subject: RE: MCP55 SATA data corruption in FreeBSD 7 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, 23 Jul 2008 18:34:32 -0000 Manjunath Ranganathaiah wrote: > Could be in-memory data corruption. How much RAM installed on the > system? I doubt it. If it was a RAM problem then all drives would be affected. ___ Daniel Eriksson (http://www.toomuchdata.com/) From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:46:19 2008 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 DB1B51065677; Wed, 23 Jul 2008 18:46:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49E518FC0A; Wed, 23 Jul 2008 18:46:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6NIk0nA049681; Wed, 23 Jul 2008 14:46:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Oleg V. Nauman" Date: Wed, 23 Jul 2008 11:16:02 -0400 User-Agent: KMail/1.9.7 References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> In-Reply-To: <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231116.02389.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 23 Jul 2008 14:46:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7798/Wed Jul 23 13:42:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: acpi@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working 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, 23 Jul 2008 18:46:20 -0000 On Wednesday 23 July 2008 07:09:27 am Oleg V. Nauman wrote: > Quoting John Baldwin : > > > On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: > >> Quoting John Baldwin : > >> > >> > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > >> >> Quoting "Oleg V. Nauman" : > >> >> > >> >> > Quoting Jeremy Chadwick : > >> >> > > >> >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: > >> >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE > > so > >> >> >>> my next system upgrade ended with ACPI HPET not working anymore on my > >> >> >>> ASUS A9Rp laptop. > >> >> >>> > >> >> >>> Here is the part of /var/log/dmesg.today dated July 13: > >> >> >>> > >> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 > >> >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >> >>> [..] > >> >> >>> acpi0: on motherboard > >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >> >>> acpi0: [ITHREAD] > >> >> >>> acpi0: Power Button (fixed) > >> >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >> >>> acpi_ec0: port 0x62,0x66 on acpi0 > >> >> >>> acpi_hpet0: iomem > >> >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >> >>> > >> >> >>> Here is the fresh dmesg output info: > >> >> >>> > >> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 > >> >> >>> root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >> >>> [..] > >> >> >>> acpi0: on motherboard > >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 > >> >> >>> acpi0: [ITHREAD] > >> >> >>> acpi0: Power Button (fixed) > >> >> >>> acpi0: reservation of 0, a0000 (3) failed > >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed > >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > >> >> >>> [..] > >> >> >>> acpi_hpet0: iomem > >> >> >>> 0xfed00000-0xfed003ff on acpi0 > >> >> >>> device_attach: acpi_hpet0 attach returned 12 > >> >> >>> > >> >> >>> And the part of actual sysctl kern.timecounter output: > >> >> >>> > >> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) > >> > dummy(-1000000) > >> >> >>> kern.timecounter.hardware: ACPI-safe > >> >> >> > >> >> >> Seems okay here: > >> >> >> > >> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul > >> >> >> 12 10:53:08 PDT 2008 > >> >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 > >> >> >> > >> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > >> >> >> acpi_hpet0: iomem > >> >> >> 0xfed00000-0xfed003ff on acpi0 > >> >> >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >> >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >> >> Timecounters tick every 1.000 msec > >> >> >> > >> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) > >> >> >> i8254(0) dummy(-1000000) > >> >> >> kern.timecounter.hardware: ACPI-fast > >> >> >> > >> >> >> You sure you haven't upgraded your BIOS or something and forgot to > >> >> >> re-enable HPET? > >> >> > > >> >> > No it was not upgraded.. Have no option to enable/disable HPET through > >> >> > BIOS settings though > >> >> > >> >> I was unclear a bit or so. There are no ACPI related settings in my > >> >> laptop's BIOS. > >> >> > >> >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > >> >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: > >> >> > >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > >> > acpi0 > >> >> Timecounter "HPET" frequency 14318180 Hz quality 900 > >> >> > >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > >> >> dummy(-1000000) > >> >> kern.timecounter.hardware: HPET > >> >> > >> >> Hopefully it helps to understand what is went wrong there. > >> > > >> > Ok, so the attempt to allocate the resource is failing for some reason. > > Can > >> > you get output from 'devinfo -r' and 'devinfo -u'? > >> > >> ... > >> > >> Will not provide with full listings but just a diff comparing two > >> states (this good one with HPET working and bad w/o it): > >> > >> rainhaven# diff devinfo.r.good devinfo.r.bad > >> 177,179d176 > >> < acpi_hpet0 > >> < I/O memory addresses: > >> < 0xfed00000-0xfed003ff > >> > >> rainhaven# diff devinfo.u.good devinfo.u.bad > >> 128c128 > >> < 0xfed00000-0xfed003ff (acpi_hpet0) > >> --- > >> > 0xfed00000-0xfed003ff (ichsmb0) > >> > >> So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c > >> allocates the region required to ichsmb0 instead HPET (it not helps to > >> ichsmb0 because it never was working on my laptop but it is another > >> story I think). > >> > >> Thank you for looking into. > > > > Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this > > It never was working for me. Well nothing more than > > ichsmb0: port 0xb00-0xb0f mem 0xfed00000-0xfed003ff > at device 20.0 on pci0 > ichsmb0: can't map I/O > device_attach: ichsmb0 attach returned 6 > > > > change, it restores the probe orders to be more of what they used to be and > > just gives CPUs a really high probe order so that they should be after other > > devices. > > It was the patch against the CURRENT as far I understand while my > laptop running 7.0-STABLE. Well it was applied manually (not a so big > issue finally) against 1.243.2.3 revision of > /usr/src/sys/dev/acpica/acpi.c and reporting success for the HPET > functionality at least (part of relevant verbose dmesg output): > > > ACPI: HPET @ 0x0x77fd6800/0x0038 (v 1 A M I OEMHPET 0x10000626 MSFT > 0x00000097) > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > acpi_hpet0: vend: 0x4353 rev: 0x10 num: 3 hz: 14318180 opts: legacy_route > Timecounter "HPET" frequency 14318180 Hz quality 900 > > And part of sysctl variables related: > > kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: HPET > > I/O mem conflict with ichsmb still in place though > > Thank you I've committed the patch. However, I think this actually points out a slightly bigger issue in that the HPET timer is probably piggybacking on the ichsmb0 device's BAR, and they really should both be able to attach somehow. A way to fix that would be to make the HPET device actually borrow the PCI device's resource instead of allocating its own perhaps. I think the HPET ACPI device and the table tell us the PCI deviec the HPET lives in. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:46:36 2008 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 F0DFF1065729; Wed, 23 Jul 2008 18:46:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 56DE48FC13; Wed, 23 Jul 2008 18:46:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6NIk0nC049681; Wed, 23 Jul 2008 14:46:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Wed, 23 Jul 2008 11:23:13 -0400 User-Agent: KMail/1.9.7 References: <48860725.9050808@aldan.algebra.com> <48863C3D.7090401@aldan.algebra.com> <20080723120348.GJ17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080723120348.GJ17123@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807231123.14229.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 23 Jul 2008 14:46:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7798/Wed Jul 23 13:42:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS,URI_NOVOWEL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mikhail Teterin , Kris Kennaway , stable@freebsd.org Subject: Re: "sleeping without queue" ? 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, 23 Jul 2008 18:46:36 -0000 On Wednesday 23 July 2008 08:03:48 am Kostik Belousov wrote: > On Tue, Jul 22, 2008 at 03:59:57PM -0400, Mikhail Teterin wrote: > > Kostik Belousov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(=D0=BB=D0=B0= ): > > >On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: > > >>Kostik Belousov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(=D0=BB=D0= =B0): > > >>>Did you switched to the process before doing backtrace (using the pr= oc=20 > > >>> > > >>>command)? > > >>Ok, thanks. Did not know about this one. Here: > > >>... > > >>(kgdb) proc 79759 > > >>(kgdb) bt > > >>#0 sched_switch (td=3D0xffffff01286dc000, newtd=3D0xffffff00010ce000= ,=20 > > >>flags=3D2) at /var/src/sys/kern/sched_4bsd.c:928 > > >>#1 0x0000000000000000 in ?? () > > >>#2 0xffffffff802f1108 in mi_switch (flags=3D678281216, newtd=3D0x2) = at=20 > > >>/var/src/sys/kern/kern_synch.c:442 > > >>#3 0xffffffff80318513 in sleepq_check_timeout () at=20 > > >>/var/src/sys/kern/subr_sleepqueue.c:519 > > >>#4 0xffffffff80318c85 in sleepq_timedwait (wchan=3D0xffffffff8068840= 8) at=20 > > >>/var/src/sys/kern/subr_sleepqueue.c:597 > > >>#5 0xffffffff802f16a2 in _sleep (ident=3D0xffffffff80688408, lock=3D= 0x0,=20 > > >>priority=3D0, wmesg=3D0xffffffff804f3059 "vmo_de", timo=3D1) at=20 > > >>/var/src/sys/kern/kern_synch.c:224 > > >>#6 0xffffffff8043036b in vm_object_deallocate=20 > > >>(object=3D0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > > >From this frame, please, print the object (like p *object) and > > >likewise, print the object that is at the head of the object->shadow_h= ead > > >list. > > kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem > > [GDB will not be able to debug user-mode threads:=20 > > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u=20 are > > welcome to change it and/or distribute copies of it under certain=20 > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for=20 details. > > This GDB was configured as "amd64-marcel-freebsd". > > There is no member named pathname. > > Reading symbols from /opt/modules/fuse.ko...done. > > Loaded symbols for /opt/modules/fuse.ko > > Reading symbols from /opt/modules/rtc.ko...done. > > Loaded symbols for /opt/modules/rtc.ko > > Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from=20 > > /boot/kernel/snd_ich.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/snd_ich.ko > > Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from=20 > > /boot/kernel/msdosfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/msdosfs.ko > > #0 0x0000000000000000 in ?? () > > (kgdb) frame 6 > > Error accessing memory address 0x0: Bad address. > > (kgdb) pid 79759 > > Undefined command: "pid". Try "help". > > (kgdb) proc 79759 > > (kgdb) frame 6 > > #6 0xffffffff8043036b in vm_object_deallocate=20 > > (object=3D0xffffff0053024a90) at /var/src/sys/vm/vm_object.c:509 > > 509 pause("vmo_de", 1); > > (kgdb) p *object > > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff804f21c4 "vm ob= ject",=20 > > lo_type =3D 0xffffffff804f3018 "standard object", lo_flags =3D 21168128= ,=20 > > lo_witness_data =3D { > > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, mtx_loc= k =3D 4,=20 > > mtx_recurse =3D 0}, object_list =3D {tqe_next =3D 0xffffff0005018a90, > > tqe_prev =3D 0xffffff00539a6850}, shadow_head =3D {lh_first =3D=20 > > 0xffffff005d3afa90}, shadow_list =3D {le_next =3D 0x0, le_prev =3D=20 > > 0xffffff005d2cd048}, memq =3D { > > tqh_first =3D 0xffffff007eb9fa58, tqh_last =3D 0xffffff007f864820}, = root=20 > > =3D 0xffffff007ee14d38, size =3D 427, generation =3D 66, ref_count =3D = 2,=20 > > shadow_count =3D 1, > > type =3D 0 '\0', flags =3D 256, pg_color =3D 0, paging_in_progress =3D= 0,=20 > > resident_page_count =3D 44, backing_object =3D 0x0, backing_object_offs= et =3D=20 > > 0, pager_object_list =3D { > > tqe_next =3D 0x0, tqe_prev =3D 0x0}, cache =3D 0x0, handle =3D 0x0, = un_pager=20 > > =3D {vnp =3D {vnp_size =3D 576646}, devp =3D {devp_pglist =3D {tqh_firs= t =3D 0x8cc86, > > tqh_last =3D 0x0}}, swp =3D {swp_bcount =3D 576646}}} > > (kgdb) p (object->shadow_head) > > $2 =3D {lh_first =3D 0xffffff005d3afa90} > > (kgdb) p *object->shadow_head.lh_first > > $3 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff804f21c4 "vm ob= ject",=20 > > lo_type =3D 0xffffffff804f3018 "standard object", lo_flags =3D 21168128= ,=20 > > lo_witness_data =3D { > > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, mtx_loc= k =3D 4,=20 > > mtx_recurse =3D 0}, object_list =3D {tqe_next =3D 0xffffff0066c32340, > > tqe_prev =3D 0xffffff012f673ac0}, shadow_head =3D {lh_first =3D 0x0}= ,=20 > > shadow_list =3D {le_next =3D 0x0, le_prev =3D 0xffffff0053024ad0}, memq= =3D { > > tqh_first =3D 0xffffff007779f9a0, tqh_last =3D 0xffffff0077c04140}, = root=20 > > =3D 0xffffff0077c04130, size =3D 387, generation =3D 3, ref_count =3D 1= ,=20 > > shadow_count =3D 0, > > type =3D 0 '\0', flags =3D 8452, pg_color =3D 0, paging_in_progress = =3D 0,=20 > > resident_page_count =3D 2, backing_object =3D 0xffffff0053024a90,=20 > > backing_object_offset =3D 163840, > > pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, cache =3D = 0x0,=20 > > handle =3D 0x0, un_pager =3D {vnp =3D {vnp_size =3D 365278}, devp =3D {= devp_pglist =3D=20 { > > tqh_first =3D 0x592de, tqh_last =3D 0x0}}, swp =3D {swp_bcount = =3D=20 365278}}} > >=20 > >=20 > > > > > >Another question is what scheduler do you use ? > > options SCHED_4BSD # 4BSD scheduler > > options PREEMPTION # Enable kernel thread preempti= on > The state of the both object being destroyed and the object that is shado= wed > looks right for me. Moreover, the shadowed object is not locked, value > of the mtx_lock is 4. It seems as if the thread missed the wakeup > owed by pause. >=20 > John, could it be that the following commit is supposed to fix the issue ? >=20 > r179974 | jhb | 2008-06-24 22:36:33 +0300 (Tue, 24 Jun 2008) | 3 lines >=20 > MFC: Change the roundrobin implementation in the 4BSD scheduler to trigge= r a > userland preemption directly from hardclock() via sched_clock() I don't think this would fix the issue. This patch fixed problems where yo= u=20 had a thread pinned to another CPU that held a lock (typically Giant) that = a=20 callout handler run from softclock needed. This prevented the 'roundrobin'= =20 callout from running which would force all the CPUs to do a context switch= =20 (normally this would have forced the pinned thread holding the lock to=20 eventually run). This involves threads on the run queue not getting to run= ,=20 even though they may have a higher priority than what is running now. I think this case is still a lingering bug in the sleep queue code since th= e=20 thread lock stuff went in. There have been several reports of it but I hav= e=20 been unable to figure out how the wakeup is being missed. > > >>>Also, show the output of ps axl . > > >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME=20 COMMAND > > >> 0 79759 79758 0 96 0 0 16 - DE+ p6 0:00,00=20 > > >>/bin/tcsh -fc=20 > >=20 >>/meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.p= ro/bin/ma > > > > > >It makes sense to show the whole ps axl output. > > See http://aldan.algebra.com/~mi/tmp/ps-axl.txt -- I edited it for=20 > > privacy a little bit, but process-states are intact. > > The java-processes in the linuxf have remained unkillable for weeks now= =20 > > -- I even forgot about them. But those are linuxulator problems, wherea= s=20 > > the tcsh is native... > It seems that pid 63930 is problematic too ? >=20 =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 19:57:26 2008 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 DA9301065674; Wed, 23 Jul 2008 19:57:26 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC2E8FC19; Wed, 23 Jul 2008 19:57:25 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080723200355.VABX16629.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Wed, 23 Jul 2008 21:03:55 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080723200403.ELFJ16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com>; Wed, 23 Jul 2008 21:04:03 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6NJvFIE094689; Wed, 23 Jul 2008 20:57:15 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: Jeremy Chadwick Date: Wed, 23 Jul 2008 20:57:15 +0100 User-Agent: KMail/1.9.7 References: <200807221727.52718.ianjhart@ntlworld.com> <200807221847.34935.ianjhart@ntlworld.com> <20080723001835.GA33136@eos.sc1.parodius.com> In-Reply-To: <20080723001835.GA33136@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807232057.15057.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Cc: freebsd-stable@freebsd.org Subject: Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt 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, 23 Jul 2008 19:57:27 -0000 On Wednesday 23 July 2008 01:18:35 Jeremy Chadwick wrote: > On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: > > On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: > > > On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: > > > > Same hardware as my other thread. > > > > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > > > > > > > [using 2Gb RAM and SATA in legacy mode] > > > > > > > > I'd like to focus only on making the CDROM boot complete. > > > > > > > > Summary: hangs just after the CPUs are launched. > > > > > > > > 6.2-RELEASE works okay, no AHCI support > > > > 6.3-RELEASE works okay > > > > 7.0-RELEASE hangs > > > > 7.0-STABLE-200806-SNAPSHOT hangs > > > > 8.0-CURRENT-200806-SNAPSHOT hangs > > > > > > > > I thought I could do a binary search using the current snapshot > > > > boot-only CDs but they only go back to March. Are there any older > > > > ones available? > > > > > > Have you tried disabling ACPI to see if it makes any sort of > > > difference? > > > > Yes, but I'm happy to re-try. > > > > Which method is "best"? Or is it 1 + 2 or 3? > > > > 1) BIOS > > 2) Beastie menu option > > 3) loader prompt set hint > > Item #2 is the easiest. You should really be able to leave the BIOS > settings at their defaults (Factory Defaults) and have this system work > on FreeBSD. > > Items #2 and #3 are the same. The loader menu option for disabling ACPI > simply sets the hint. > > > > Also, AHCI should work just fine on those systems -- I know because I > > > have fairly extensive experience with Supermicro hardware, although > > > what you're using is newer than what I presently have. I don't know > > > why you're setting Compatible/Legacy mode on your controller (you > > > mention doing this in your other thread as well). > > > > Because I don't know what's wrong yet and AHCI support is newer than SATA > > support and this is a newish board? [At least 6.2 doesn't seem to support > > it and it has an AHCI legacy option!] > > > > I'd be happy to swap this over. Slight problem; the drives get > > renumbered, so I'd rather not swap back and forth. > > You *absolutely* should have AHCI enabled. There's a lot of reasons > why, too. I highly recommend avoiding the "SATA Compatible" mode. > > AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because > we have many Supermicro boards running those versions which do have AHCI > enabled. Please use it, and stick with it. > > Here's added proof that AHCI works fine on 6.3: > > $ dmesg -a | grep -i ahci > atapci1: port > 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem > 0xe0000400-0xe00007ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version > 01.10 controller with 4 ports detected > $ uname -r -s > FreeBSD 6.3-PRERELEASE > > The adX device renumbering is expected. There are workarounds for this, > but I recommend you simply enable AHCI. Do not keep toggling it on/off. > > > > Below is what we use on our systems; factory defaults, then make the > > > following changes. (The G-LAN1 OPROM option you can do whatever you > > > want with -- it's specific to our environment). > > > > > > * Main > > > * Date > > > --> Set to GMT, not local time!!! > > > * Serial ATA > > > --> SATA Controller Mode --> Enhanced > > > --> SATA AHCI --> Enabled > > > > > > * Advanced > > > * Boot Features > > > --> Quiet Mode --> Disabled > > > --> Enable Multimedia Timer --> Enabled > > > * PCI Configuration > > > --> Onboard G-LAN1 OPROM --> Disabled > > > --> Large Disk Access Mode --> Other > > > * Advanced Processor Options > > > --> Intel(R) Virtualization Technology --> Enabled > > > --> C1 Enhanced Mode --> Enabled > > > > I've got as close as I can to this. > > > > This board also has an AHCI legacy option [disabled] which hides ports 5 > > and 6. I also disabled quickboot and POST errors. I assume multimedia > > timer is the same as HPET. Doesn't seem to be any disk translation > > option. I took the fans off 'flat out'. > > Okay, I've had a chance to review the board manual that comes with the > X7SBi. You should set the following: > > Serial ATA: Enabled > Native Mode Operation: Serial ATA > SATA AHCI: Enabled > SATA AHCI Legacy: Disabled > > The name "SATA AHCI Legacy" a horrible name for what it does. The ICH9 > itself has support for 6 SATA ports, but (if I remember correctly, based > on reading some Intel design documents) there are extra registers you > have to tweak to get those ports to work, and the OS has to be fully > aware of how to do that. The BIOS option simply disables SATA ports 5 > and 6 altogether; the underlying OS never sees them. I'd recommend > keeping that setting Disabled (the default) unless you have disks on > those ports (I don't see how, since it's a 4-disk system!). > > I don't think this option is what's causing you problems, though. > > "Multimedia Timer" is indeed HPET. Looks like they changed the name to > be more reflective of what it actually is. > > The "Large Disk Access" mode does appear to be missing from that BIOS, > probably for a good reason. I can enable/disable it on our boards with > no repercussions (the options are "DOS" and "Other", which is why I > choose "Other"). I'm not entirely sure what it does. > > As for your problem... > > If the CDROM is the problem (which would be odd, since the disc does > boot and load the kernel successfully), can you try going into the BIOS > and setting IDE Channel 0 Master (which I think is the CDROM -- I could > be wrong here) and set "Transfer Mode" to PIO1 and "Ultra DMA Mode" to > Disabled? > > I have a feeling the problem isn't related to the CDROM, but I'm not > entirely sure how to debug it. I tried each BIOS setting in turn. No joy. I tried a 40 wire cable. No joy I tried an old CDROM (Mitsumi FX4830T circa Feb 2001). No joy Had a feeling that the drive always came up as UDMA33. Tried setting hw.ata.atapi_dma=0 Wahay! The drive throws errors but it boots. Did an install, and that hangs too without this setting in /boot/loader.conf. Frankly I'm kicking myself for not trying this earlier. That's ~16 hours I'll never get back. OTOH this has been the default for a long time now. Thank you Jeremy, I wouldn't have got there without you. > > There are other users using the X7SBi with success: > > http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread >/d0a2d20f8965361a http://www.webhostingtalk.com/showthread.php?t=666686 > > Also, can you make sure your BIOS revision is 1.1a, just to rule out any > BIOS-related issues? -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 20:15:49 2008 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 D6B55106566B for ; Wed, 23 Jul 2008 20:15:49 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id C4E9E8FC1A for ; Wed, 23 Jul 2008 20:15:49 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 10291 invoked from network); 23 Jul 2008 20:15:49 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Jul 2008 20:15:48 -0000 Message-ID: <48879173.60807@aldan.algebra.com> Date: Wed, 23 Jul 2008 16:15:47 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: John Baldwin References: <48860725.9050808@aldan.algebra.com> <48863C3D.7090401@aldan.algebra.com> <20080723120348.GJ17123@deviant.kiev.zoral.com.ua> <200807231123.14229.jhb@freebsd.org> In-Reply-To: <200807231123.14229.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Kostik Belousov , Kris Kennaway , stable@freebsd.org Subject: Re: "sleeping without queue" ? 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, 23 Jul 2008 20:15:49 -0000 John Baldwin напиÑав(ла): > I think this case is still a lingering bug in the sleep queue code since the > thread lock stuff went in. There have been several reports of it but I have > been unable to figure out how the wakeup is being missed. > Is there anything I can still do for the investigation, or can I (try to) kill this thingie and restart my build of OpenOffice? Yours, -mi P.S. NVidia on amd64? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 20:24:01 2008 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 CECF11065684 for ; Wed, 23 Jul 2008 20:24:01 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id 478018FC1E for ; Wed, 23 Jul 2008 20:24:00 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080723203031.VLWO16629.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Wed, 23 Jul 2008 21:30:31 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080723203039.EVYM16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com> for ; Wed, 23 Jul 2008 21:30:39 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6NKNql8094976 for ; Wed, 23 Jul 2008 21:23:52 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Wed, 23 Jul 2008 21:23:52 +0100 User-Agent: KMail/1.9.7 References: <200807221659.20396.ianjhart@ntlworld.com> In-Reply-To: <200807221659.20396.ianjhart@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807232123.52186.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Subject: Re: unable to use gmirror on supermicro 5015b-mt 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, 23 Jul 2008 20:24:01 -0000 On Tuesday 22 July 2008 16:59:20 ian j hart wrote: > These are new boxes. > http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm > > core 2 Q6600 CPU > 8Gb 667 RAM > > Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. > Build cycle okay. Running (no load) for a week or so. > > However, when I try to configure gmirror they hang on boot. > > After some fiddling it appears issuing > #kldload geom_mirror > hangs the boxes very hard. Ping response stops (after 3), no CAD response, > CDROM draw doesn't open! > > This may well be a foolish thing to do but another (different) amd64 box > doesn't hang. I don't believe this to be amd64 specific, I suspect that > there's something strange about this hardware. > > There are very many BIOS options and I feel like I've tried them all > without getting anywhere. > > I'm "on holiday" this week and I've borrowed a box to test. Any suggestions > would be welcome. I'll (re)try anything but I need help to stay focused. > > Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other > thread (which may bear fruit more quickly). > > I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. > > dmesg after sig [AHCI disabled, SATA legacy mode] > > Thanks As I suspected, no takers :) "Fix". In /boot/loader.conf hw.ata.atapi_dma="0" This allows kldload without hang. I'm sure that this fix will allow me to configure a mirror. I'll post back if I'm wrong. -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 22:06:46 2008 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 F218E106564A for ; Wed, 23 Jul 2008 22:06:46 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 7350A8FC13 for ; Wed, 23 Jul 2008 22:06:46 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 7DAB2D00E1; Wed, 23 Jul 2008 12:06:40 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id A8102153882; Wed, 23 Jul 2008 12:06:39 -1000 (HST) Date: Wed, 23 Jul 2008 12:06:39 -1000 From: Clifton Royston To: ian j hart Message-ID: <20080723220638.GF2010@lava.net> Mail-Followup-To: ian j hart , freebsd-stable@freebsd.org References: <200807221659.20396.ianjhart@ntlworld.com> <200807232123.52186.ianjhart@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807232123.52186.ianjhart@ntlworld.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: unable to use gmirror on supermicro 5015b-mt 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, 23 Jul 2008 22:06:47 -0000 On Wed, Jul 23, 2008 at 09:23:52PM +0100, ian j hart wrote: ... > As I suspected, no takers :) > > "Fix". > > In /boot/loader.conf > > hw.ata.atapi_dma="0" > > This allows kldload without hang. I'm sure that this fix will allow me to > configure a mirror. I'll post back if I'm wrong. OK, but *probably* this is an indicator that you need to either replace the cable (think you said you've tried that) or replace the motherboard. If the cable is known-good and the other components are known-good, and it won't run with DMA on supported hardware, something is seriously wrong with this particular board and odds are too high that it will die horribly later. (Not to mention that you'll be hammering your CPU just to get lousy throughput out of it.) As you said in the other post, you've already spent hours of your life you won't get back - do you want to sign up for some more hours further down the road? -- Clifton (suddenly questioning why I'm spending hours on mailing lists today) -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 23:18:25 2008 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 75E751065675 for ; Wed, 23 Jul 2008 23:18:25 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id BB31A8FC20 for ; Wed, 23 Jul 2008 23:18:24 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080723232342.QBZF7070.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Thu, 24 Jul 2008 00:23:42 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080723232505.GUBS16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com> for ; Thu, 24 Jul 2008 00:25:05 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6NNI1gI096851; Thu, 24 Jul 2008 00:18:01 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: Clifton Royston Date: Thu, 24 Jul 2008 00:18:01 +0100 User-Agent: KMail/1.9.7 References: <200807221659.20396.ianjhart@ntlworld.com> <200807232123.52186.ianjhart@ntlworld.com> <20080723220638.GF2010@lava.net> In-Reply-To: <20080723220638.GF2010@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807240018.01208.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Cc: freebsd-stable@freebsd.org Subject: Re: unable to use gmirror on supermicro 5015b-mt 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, 23 Jul 2008 23:18:25 -0000 On Wednesday 23 July 2008 23:06:39 Clifton Royston wrote: > On Wed, Jul 23, 2008 at 09:23:52PM +0100, ian j hart wrote: > ... > > > As I suspected, no takers :) > > > > "Fix". > > > > In /boot/loader.conf > > > > hw.ata.atapi_dma="0" > > > > This allows kldload without hang. I'm sure that this fix will allow me to > > configure a mirror. I'll post back if I'm wrong. > > OK, but *probably* this is an indicator that you need to either > replace the cable (think you said you've tried that) or replace the > motherboard. I tried a 40 wire cable. That's a different test than trying a new (80 wire) cable. > If the cable is known-good and the other components are > known-good, and it won't run with DMA on supported hardware, something > is seriously wrong with this particular board and odds are too high > that it will die horribly later. What are the odds that I bought five systems with exactly the same fault? To avoid tempting fate I should say I only tried "the fix" one one box so far. I'm really not that worried tho'. > (Not to mention that you'll be > hammering your CPU just to get lousy throughput out of it.) Given that the CDROM (DVD if we're being pedantic) will probably get no use at all, ever, I'm not that worried about it's throughput. > > As you said in the other post, you've already spent hours of your > life you won't get back - do you want to sign up for some more hours > further down the road? > > -- Clifton (suddenly questioning why I'm spending hours on mailing lists > today) -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 23:28:23 2008 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 C17DD106566B for ; Wed, 23 Jul 2008 23:28:23 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 6F5F58FC2C for ; Wed, 23 Jul 2008 23:28:23 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 87233 invoked by uid 89); 23 Jul 2008 23:32:36 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 23 Jul 2008 23:32:36 -0000 Message-ID: <4887BEA9.7060900@ibctech.ca> Date: Wed, 23 Jul 2008 19:28:41 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ian j hart , freebsd-stable@freebsd.org References: <200807221659.20396.ianjhart@ntlworld.com> <200807232123.52186.ianjhart@ntlworld.com> <20080723220638.GF2010@lava.net> In-Reply-To: <20080723220638.GF2010@lava.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: unable to use gmirror on supermicro 5015b-mt 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, 23 Jul 2008 23:28:23 -0000 Clifton Royston wrote: > On Wed, Jul 23, 2008 at 09:23:52PM +0100, ian j hart wrote: > ... >> As I suspected, no takers :) >> >> "Fix". >> >> In /boot/loader.conf >> >> hw.ata.atapi_dma="0" >> >> This allows kldload without hang. I'm sure that this fix will allow me to >> configure a mirror. I'll post back if I'm wrong. > > OK, but *probably* this is an indicator that you need to either > replace the cable (think you said you've tried that) or replace the > motherboard. If the cable is known-good and the other components are > known-good, and it won't run with DMA on supported hardware, something > is seriously wrong with this particular board and odds are too high > that it will die horribly later. (Not to mention that you'll be > hammering your CPU just to get lousy throughput out of it.) This was the same issue I experienced with the NVidia board that I mentioned in the 'taskqueue timeout' thread last week. As I mentioned thereafter, I used my workstation board (Intel), and everything worked fine (ZFS). I tried then to set up my Windows workstation on the NVidia board, and thereafter found out that it would ONLY operate in PIO(4), no matter what I did. Needless to say, the board was RMA'd, and I have a new Intel board on its way to handle the ZFS file system. > As you said in the other post, you've already spent hours of your > life you won't get back - do you want to sign up for some more hours > further down the road? IMHO, just replace the board. If you are not able to acquire DMA on the disk subsystem, you've lost already. > -- Clifton (suddenly questioning why I'm spending hours on mailing lists today) ...because your systems are running so smoothly, you have to be typing something to justify your office space? ;) Steve From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 03:01:01 2008 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 441E71065675 for ; Thu, 24 Jul 2008 03:01:01 +0000 (UTC) (envelope-from ohuchi@iij.ad.jp) Received: from otm-mgo00.iij.ad.jp (otm-mgo00.iij.ad.jp [210.138.20.174]) by mx1.freebsd.org (Postfix) with ESMTP id BBCB58FC15 for ; Thu, 24 Jul 2008 03:01:00 +0000 (UTC) (envelope-from ohuchi@iij.ad.jp) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Message-ID: From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; i=ohuchi@iij.ad.jp; s=omgo0; t=1216866528; x=1218076128; bh=BDGVtRXCqoq975xoGVrII KeQyOFfOn9jVgFoBL0UhuE=; b=O/U1cEzfYhAmAKD6Shjvl+VjdCaS4OcoPWD0V/x9xpVBo1kqBBY 0XoTaHgiKAgt92kfewvqM1sT66Nrkr8x8mc+B2RQzpjus2uAWTaKHFStaaAIFFETcCkRO7zQ7MwjR 70kpkKS/3EtzrzYyvaOfUkANmwUDNt7igOPyKy0iMXg=; Received: OTM-MO(otm-mgo00) id m6O2SmT6014758; Thu, 24 Jul 2008 11:28:48 +0900 (JST) Received: OTM-MIX(otm-mix00) id m6O2SliK019851; Thu, 24 Jul 2008 11:28:47 +0900 (JST) Received: from moon (moon.iij.ad.jp [192.168.168.71]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id m6O2SloP008808 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jul 2008 11:28:47 +0900 (JST) Message-ID: <021501c8ed35$0053a330$47a8a8c0@iij.ad.jp> From: "Munenori Ohuchi" To: Date: Thu, 24 Jul 2008 11:28:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: Munenori Ohuchi Subject: Re: MCP55 SATA data corruption in FreeBSD 7 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, 24 Jul 2008 03:01:01 -0000 Hi Daniel, Could you try the following patch? You can apply this patch in freebsd 7.0 just by copying and pasting to your shell. Before you apply this patch, you can check as follows if this works on your environment or not. 1. Set bootverbose mode. cat >> /boot/loader.conf << EOF boot_verbose="YES" EOF 2. Reboot your machine. 3. Check the dmesg log of your HDDs as follows. dmesg | grep ata . . ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ^^^^^^^^^^^^ ad4: 115328MB at ata2-master SATA150 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 953869MB at ata3-master SATA150 If you have a device like 'ad4' which is detected as 'udma=UDMA100', this patch will work. ------------------------patch start---------------------------- cd /usr/src/sys/dev/ata cat> ata-chipset.c.patch <param; /* * if we detect that the device isn't a real SATA device we limit @@ -390,7 +391,7 @@ /* on some drives we need to set the transfer mode */ ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_SETXFER, 0, - ata_limit_mode(dev, mode, ATA_UDMA6)); + ata_limit_mode(dev, mode, ata_umode(atacap))); /* query SATA STATUS for the speed */ if (ch->r_io[ATA_SSTATUS].res && EOF patch -l < ata-chipset.c.patch ------------------------patch end---------------------------- Best regards, -- Munenori Ohuchi Internet Initiative Japan Inc. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 06:26:42 2008 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 7CD451065672 for ; Thu, 24 Jul 2008 06:26:42 +0000 (UTC) (envelope-from rj@shadowbots.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2F68FC1D for ; Thu, 24 Jul 2008 06:26:41 +0000 (UTC) (envelope-from rj@shadowbots.com) Received: by fg-out-1718.google.com with SMTP id l26so1823713fgb.35 for ; Wed, 23 Jul 2008 23:26:40 -0700 (PDT) Received: by 10.103.229.12 with SMTP id g12mr453835mur.6.1216879163347; Wed, 23 Jul 2008 22:59:23 -0700 (PDT) Received: by 10.103.192.5 with HTTP; Wed, 23 Jul 2008 22:59:23 -0700 (PDT) Message-ID: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> Date: Thu, 24 Jul 2008 01:59:23 -0400 From: "Robert Jameson" Sender: rj@shadowbots.com To: freebsd-stable MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1793_24025808.1216879163313" X-Google-Sender-Auth: f1a667244e9d505d X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: network problems 7.0-p3: sendto: Operation not permitted 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, 24 Jul 2008 06:26:42 -0000 ------=_Part_1793_24025808.1216879163313 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Everyone, Recently I upgraded to freebsd 7.0-p3 from 7.0-p2, once i upgraded i began to have problems with my network, nothing has changed configuration wise, let me show you guy's an example. (12:46 AM):(root@cube)/$ ping google.com PING google.com (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=0 ttl=240 time=64.713 ms ^C --- google.com ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 64.713/64.713/64.713/0.000 ms (12:46 AM):(root@cube)/$ ping google.com PING google.com (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=0 ttl=240 time=73.814 ms 64 bytes from 72.14.207.99: icmp_seq=1 ttl=240 time=64.943 ms ^C --- google.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 64.943/69.379/73.814/4.435 ms (12:46 AM):(root@cube)/$ ping google.com PING google.com (72.14.207.99): 56 data bytes ping: sendto: Operation not permitted ^C --- google.com ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss (12:46 AM):(root@cube)/$ As you can see above, I issued the ping command (4) times waiting for output and then doing CTRL+C to interrupt the commands quickly and send them again on the 4th try i did not intterupt it and received the operation not permitted. hitting ctrl+c on this error I can type ping again and it will work correctly. I have the same problem with almost every network command, wget, curl, fetch, lynx, ssh, nslookup, host etc. This appears to be an issue with the network. I have attached my rc.conf and sysctl.conf and pf.conf please let me know if any other information is required. Errors from /var/log/console.log: Jul 18 21:10:02 cube kernel: Jul 18 21:10:02 cube named[908]: socket: too many open file descriptors Jul 19 00:30:13 cube kernel: Jul 19 00:30:13 cube named[9748]: socket: too many open file descriptors Jul 19 00:30:54 cube kernel: Jul 19 00:30:14 cube last message repeated 28 times Initially I figured this problem was bind related and since it has been a planned project for the past few months to switch to djbdns, I took the time to switch to djbdns, so bind is no longer running. I was also receiving this in /var/log/messages: Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to 200 packets/sec Jul 20 22:15:40 cube kernel: Limiting open port RST response from 624 to 200 packets/sec Jul 20 22:15:42 cube kernel: Limiting open port RST response from 213 to 200 packets/sec Jul 20 22:15:50 cube kernel: Limiting open port RST response from 439 to 200 packets/sec Jul 20 22:15:51 cube kernel: Limiting open port RST response from 673 to 200 packets/sec Jul 20 22:15:52 cube kernel: Limiting open port RST response from 730 to 200 packets/sec Jul 20 22:15:53 cube kernel: Limiting open port RST response from 307 to 200 packets/sec Jul 20 22:16:02 cube kernel: Limiting open port RST response from 435 to 200 packets/sec Jul 20 22:16:03 cube kernel: Limiting open port RST response from 730 to 200 packets/sec Jul 20 22:16:04 cube kernel: Limiting open port RST response from 287 to 200 packets/sec Jul 20 22:16:13 cube kernel: Limiting open port RST response from 519 to 200 packets/sec Jul 20 22:16:14 cube kernel: Limiting open port RST response from 740 to 200 packets/sec Jul 20 22:16:15 cube kernel: Limiting open port RST response from 258 to 200 packets/sec Jul 20 22:16:24 cube kernel: Limiting open port RST response from 407 to 200 packets/sec Jul 20 22:16:25 cube kernel: Limiting open port RST response from 660 to 200 packets/sec After spending some time on Google i came up with: /etc/sysctl.conf net.inet.icmp.icmplim=2000 I know it seems abit high, but i kept adjusting until the error went away. (not really fixing the problem?) If your mail client or the mailing list prevents you from seeing the attached You can view them here: http://rj.dawnshosting.com/fbsd_ml/ PS: While running tcpdump I see this tcpdump -i fxp0 Neither one of these ip's exist on my system is my cable company doing something wrong? 01:47:12.135929 arp who-has 64.253.3.161.dyn-cm-pool73.pool.hargray.net tell 64.253.3.1.dyn-cm-pool73.pool.hargray.net 01:47:12.155931 arp who-has 216.16.218.141.dyn-cm-pool46.pool.hargray.nettell 216.16.218.1.dyn-cm-pool46.pool.hargray.net 01:47:12.196000 arp who-has 181.131.216.67.181.static.hargray.net tell 1.131.216.67.1.static.hargray.net tcpdump -i fxp0 | grep ICMP: Is this an attack? 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37084, length 64 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37085, length 64 01:55:43.285913 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37086, length 64 01:55:44.286340 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37087, length 64 01:55:45.287380 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37088, length 64 01:55:46.345843 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37089, length 64 01:55:47.346685 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37090, length 64 01:55:48.347366 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37091, length 64 01:55:49.348370 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37092, length 64 01:55:50.360130 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37093, length 64 01:55:51.596916 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37094, length 64 01:55:52.597659 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37095, length 64 01:55:53.640120 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37096, length 64 01:55:54.735275 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37097, length 64 01:55:55.735568 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37098, length 64 01:55:56.745012 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37099, length 64 01:55:57.835442 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37100, length 64 01:55:58.920583 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37101, length 64 01:56:00.022747 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP echo request, id 22055, seq 37102, length 64 ------=_Part_1793_24025808.1216879163313 Content-Type: application/octet-stream; name=rc.conf Content-Transfer-Encoding: base64 X-Attachment-Id: f_fj0xi4u90 Content-Disposition: attachment; filename=rc.conf PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iaXNvLTg4NTktMSI/Pgo8IURPQ1RZUEUgaHRt bCBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIDEuMCBUcmFuc2l0aW9uYWwvL0VOIgogICAgICAg ICAiaHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwxL0RURC94aHRtbDEtdHJhbnNpdGlvbmFsLmR0 ZCI+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6bGFuZz0i ZW4iIGxhbmc9ImVuIj4KIDxoZWFkPgogIDx0aXRsZT40MDMgLSBGb3JiaWRkZW48L3RpdGxlPgog PC9oZWFkPgogPGJvZHk+CiAgPGgxPjQwMyAtIEZvcmJpZGRlbjwvaDE+CiA8L2JvZHk+CjwvaHRt bD4K ------=_Part_1793_24025808.1216879163313 Content-Type: application/octet-stream; name=sysctl.conf Content-Transfer-Encoding: base64 X-Attachment-Id: f_fj0xic0h1 Content-Disposition: attachment; filename=sysctl.conf PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iaXNvLTg4NTktMSI/Pgo8IURPQ1RZUEUgaHRt bCBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIDEuMCBUcmFuc2l0aW9uYWwvL0VOIgogICAgICAg ICAiaHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwxL0RURC94aHRtbDEtdHJhbnNpdGlvbmFsLmR0 ZCI+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6bGFuZz0i ZW4iIGxhbmc9ImVuIj4KIDxoZWFkPgogIDx0aXRsZT40MDMgLSBGb3JiaWRkZW48L3RpdGxlPgog PC9oZWFkPgogPGJvZHk+CiAgPGgxPjQwMyAtIEZvcmJpZGRlbjwvaDE+CiA8L2JvZHk+CjwvaHRt bD4K ------=_Part_1793_24025808.1216879163313 Content-Type: application/octet-stream; name=pf.conf Content-Transfer-Encoding: base64 X-Attachment-Id: f_fj0xir4a2 Content-Disposition: attachment; filename=pf.conf PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iaXNvLTg4NTktMSI/Pgo8IURPQ1RZUEUgaHRt bCBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIDEuMCBUcmFuc2l0aW9uYWwvL0VOIgogICAgICAg ICAiaHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwxL0RURC94aHRtbDEtdHJhbnNpdGlvbmFsLmR0 ZCI+CjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6bGFuZz0i ZW4iIGxhbmc9ImVuIj4KIDxoZWFkPgogIDx0aXRsZT40MDMgLSBGb3JiaWRkZW48L3RpdGxlPgog PC9oZWFkPgogPGJvZHk+CiAgPGgxPjQwMyAtIEZvcmJpZGRlbjwvaDE+CiA8L2JvZHk+CjwvaHRt bD4K ------=_Part_1793_24025808.1216879163313-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 07:31:56 2008 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 4763A1065675 for ; Thu, 24 Jul 2008 07:31:56 +0000 (UTC) (envelope-from alex@trull.org) Received: from mail.internationalconspiracy.org (mail.internationalconspiracy.org [85.234.142.62]) by mx1.freebsd.org (Postfix) with ESMTP id 8280D8FC17 for ; Thu, 24 Jul 2008 07:31:55 +0000 (UTC) (envelope-from alex@trull.org) Received: from localhost (mail.internationalconspiracy.org [85.234.142.62]) by mail.internationalconspiracy.org (Postfix) with ESMTP id 44B643711; Thu, 24 Jul 2008 08:31:54 +0100 (BST) X-Virus-Scanned: amavisd-new at mail.internationalconspiracy.org Received: from mail.internationalconspiracy.org ([85.234.142.62]) by localhost (mail.internationalconspiracy.org [85.234.142.62]) (amavisd-new, port 10024) with LMTP id hc+aOhCiYSn7; Thu, 24 Jul 2008 08:31:51 +0100 (BST) Received: from [192.168.124.200] (77-96-69-222.cable.ubr09.croy.blueyonder.co.uk [77.96.69.222]) by mail.internationalconspiracy.org (Postfix) with ESMTPSA id 5807036FF; Thu, 24 Jul 2008 08:31:51 +0100 (BST) From: Alex Trull To: Robert Jameson References: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> In-Reply-To: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sIetbD7Lx7ZgMCqrbuYN" Date: Thu, 24 Jul 2008 08:31:50 +0100 Message-Id: <1216884710.6500.0.camel@porksoda> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: freebsd-stable Subject: Re: network problems 7.0-p3: sendto: Operation not permitted 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, 24 Jul 2008 07:31:56 -0000 --=-sIetbD7Lx7ZgMCqrbuYN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert, The config files you attached were a series of 403 forbidden htmls. The icmp pings (1 per second) do not constitute an attack. It looks like you are genuinely running out of free states or file descript= ors. Had you applied any tuning that may have been lost in the upgrade ? How many packets and sessions is this host meant to be handling - and what = sort of traffic ? -- Alex On Thu, Jul 24, 2008 at 01:59:23AM -0400, Robert Jameson wrote: > Hello Everyone, >=20 > Recently I upgraded to freebsd 7.0-p3 from 7.0-p2, once i upgraded i bega= n > to have problems with my network, nothing has changed configuration wise, > let me show you guy's an example. >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=3D0 ttl=3D240 time=3D64.713 ms > ^C > --- google.com ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 64.713/64.713/64.713/0.000 ms >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=3D0 ttl=3D240 time=3D73.814 ms > 64 bytes from 72.14.207.99: icmp_seq=3D1 ttl=3D240 time=3D64.943 ms > ^C > --- google.com ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 64.943/69.379/73.814/4.435 ms >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > ping: sendto: Operation not permitted > ^C > --- google.com ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > (12:46 AM):(root@cube)/$ >=20 >=20 > As you can see above, I issued the ping command (4) times waiting for out= put > and then doing CTRL+C to interrupt the commands quickly and send them aga= in > on the 4th try i did not intterupt it and received the operation not > permitted. hitting ctrl+c on this error I can type ping again and it will > work correctly. >=20 >=20 > I have the same problem with almost every network command, wget, curl, > fetch, lynx, ssh, nslookup, host etc. >=20 >=20 >=20 > This appears to be an issue with the network. >=20 > I have attached my rc.conf and sysctl.conf and pf.conf please let me know= if > any other information is required. >=20 >=20 > Errors from /var/log/console.log: >=20 > Jul 18 21:10:02 cube kernel: Jul 18 21:10:02 cube named[908]: socket: too > many open file descriptors > Jul 19 00:30:13 cube kernel: Jul 19 00:30:13 cube named[9748]: socket: to= o > many open file descriptors > Jul 19 00:30:54 cube kernel: Jul 19 00:30:14 cube last message repeated 2= 8 > times >=20 >=20 >=20 > Initially I figured this problem was bind related and since it has been a > planned project for the past few months to switch to djbdns, I took the t= ime > to switch to djbdns, so bind is no longer running. >=20 > I was also receiving this in /var/log/messages: >=20 > Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to = 200 > packets/sec > Jul 20 22:15:40 cube kernel: Limiting open port RST response from 624 to = 200 > packets/sec > Jul 20 22:15:42 cube kernel: Limiting open port RST response from 213 to = 200 > packets/sec > Jul 20 22:15:50 cube kernel: Limiting open port RST response from 439 to = 200 > packets/sec > Jul 20 22:15:51 cube kernel: Limiting open port RST response from 673 to = 200 > packets/sec > Jul 20 22:15:52 cube kernel: Limiting open port RST response from 730 to = 200 > packets/sec > Jul 20 22:15:53 cube kernel: Limiting open port RST response from 307 to = 200 > packets/sec > Jul 20 22:16:02 cube kernel: Limiting open port RST response from 435 to = 200 > packets/sec > Jul 20 22:16:03 cube kernel: Limiting open port RST response from 730 to = 200 > packets/sec > Jul 20 22:16:04 cube kernel: Limiting open port RST response from 287 to = 200 > packets/sec > Jul 20 22:16:13 cube kernel: Limiting open port RST response from 519 to = 200 > packets/sec > Jul 20 22:16:14 cube kernel: Limiting open port RST response from 740 to = 200 > packets/sec > Jul 20 22:16:15 cube kernel: Limiting open port RST response from 258 to = 200 > packets/sec > Jul 20 22:16:24 cube kernel: Limiting open port RST response from 407 to = 200 > packets/sec > Jul 20 22:16:25 cube kernel: Limiting open port RST response from 660 to = 200 > packets/sec >=20 > After spending some time on Google i came up with: >=20 > /etc/sysctl.conf > net.inet.icmp.icmplim=3D2000 >=20 > I know it seems abit high, but i kept adjusting until the error went away= . > (not really fixing the problem?) >=20 > If your mail client or the mailing list prevents you from seeing the > attached > You can view them here: > http://rj.dawnshosting.com/fbsd_ml/ >=20 >=20 > PS: While running tcpdump I see this >=20 > tcpdump -i fxp0 >=20 > Neither one of these ip's exist on my system is my cable company doing > something wrong? >=20 >=20 > 01:47:12.135929 arp who-has 64.253.3.161.dyn-cm-pool73.pool.hargray.net t= ell > 64.253.3.1.dyn-cm-pool73.pool.hargray.net > 01:47:12.155931 arp who-has 216.16.218.141.dyn-cm-pool46.pool.hargray.net= tell > 216.16.218.1.dyn-cm-pool46.pool.hargray.net > 01:47:12.196000 arp who-has 181.131.216.67.181.static.hargray.net tell > 1.131.216.67.1.static.hargray.net >=20 >=20 > tcpdump -i fxp0 | grep ICMP: >=20 > Is this an attack? >=20 > 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37084, length 64 > 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37085, length 64 > 01:55:43.285913 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37086, length 64 > 01:55:44.286340 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37087, length 64 > 01:55:45.287380 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37088, length 64 > 01:55:46.345843 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37089, length 64 > 01:55:47.346685 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37090, length 64 > 01:55:48.347366 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37091, length 64 > 01:55:49.348370 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37092, length 64 > 01:55:50.360130 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37093, length 64 > 01:55:51.596916 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37094, length 64 > 01:55:52.597659 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37095, length 64 > 01:55:53.640120 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37096, length 64 > 01:55:54.735275 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37097, length 64 > 01:55:55.735568 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37098, length 64 > 01:55:56.745012 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37099, length 64 > 01:55:57.835442 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37100, length 64 > 01:55:58.920583 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37101, length 64 > 01:56:00.022747 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37102, length 64 --=-sIetbD7Lx7ZgMCqrbuYN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIiC/mey4m6/eWxTQRAvnQAJ9H2EeeOYcpNqxt1DLwG69stTDLBACgibvr FIMP7ahxUHjP19f2LjTNc7k= =UPoB -----END PGP SIGNATURE----- --=-sIetbD7Lx7ZgMCqrbuYN-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 07:49:19 2008 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 73B411065675 for ; Thu, 24 Jul 2008 07:49:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3700F8FC13 for ; Thu, 24 Jul 2008 07:49:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 3AE271CC09E; Thu, 24 Jul 2008 00:49:19 -0700 (PDT) Date: Thu, 24 Jul 2008 00:49:19 -0700 From: Jeremy Chadwick To: Robert Jameson Message-ID: <20080724074919.GA36163@eos.sc1.parodius.com> References: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: network problems 7.0-p3: sendto: Operation not permitted 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, 24 Jul 2008 07:49:19 -0000 Let's see if I can figure out the multitude of things you've posted about, since a bunch are unrelated and you appear to be flailing around with your arms in the air. :-) On Thu, Jul 24, 2008 at 01:59:23AM -0400, Robert Jameson wrote: > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > ping: sendto: Operation not permitted This usually indicates firewall rules on the local machine, although I believe there are some other operations where EPERM can be returned. > This appears to be an issue with the network. Can you provide uname -a output? There was a "cable modem compatibility fix" applied to FreeBSD a while ago (a user informed me of such), although I do not know if it applies to you, as I do not know the original symptoms. I believe that fix was also just for TCP. > I have attached my rc.conf and sysctl.conf and pf.conf please let me know if > any other information is required. > Errors from /var/log/console.log: > > Jul 18 21:10:02 cube kernel: Jul 18 21:10:02 cube named[908]: socket: too > many open file descriptors > Jul 19 00:30:13 cube kernel: Jul 19 00:30:13 cube named[9748]: socket: too > many open file descriptors > Jul 19 00:30:54 cube kernel: Jul 19 00:30:14 cube last message repeated 28 > times This indicates a completely different/unrelated problem. > Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to 200 > packets/sec This indicates a high number of ICMP packets being received. Keep in mind this can also be seen due to TCP connections which are being reset and other such things -- ICMP is at a higher layer than TCP. I don't think there's necessarily anything "wrong" with that number (you show up to 740), but it would be worthwhile investigating what's soliciting that amount of ICMP traffic. Are you seeing this 24x7x365? > /etc/sysctl.conf > net.inet.icmp.icmplim=2000 > > I know it seems abit high, but i kept adjusting until the error went away. > (not really fixing the problem?) It's not a big high; FreeBSD's 200 default is too low for any production server, if you ask me. Setting it to 2000 is probably fine. > If your mail client or the mailing list prevents you from seeing the > attached > You can view them here: > http://rj.dawnshosting.com/fbsd_ml/ You should discuss your firewalling rules on freebsd-pf, and not here. I believe you may have some mistakes which are inducing said problem. > PS: While running tcpdump I see this > > tcpdump -i fxp0 > > Neither one of these ip's exist on my system is my cable company doing > something wrong? > > > 01:47:12.135929 arp who-has 64.253.3.161.dyn-cm-pool73.pool.hargray.net tell > 64.253.3.1.dyn-cm-pool73.pool.hargray.net > 01:47:12.155931 arp who-has 216.16.218.141.dyn-cm-pool46.pool.hargray.nettell > 216.16.218.1.dyn-cm-pool46.pool.hargray.net > 01:47:12.196000 arp who-has 181.131.216.67.181.static.hargray.net tell > 1.131.216.67.1.static.hargray.net Nope. This is normal behaviour for a cable modem network; they constantly spam layer 2 ARP for *everyone* on the entire cable network segment. Yes, you read that right. > Is this an attack? > > 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37084, length 64 > 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37085, length 64 At this rate (1 ICMP packet a second), absolutely not. You also don't mention which FQDN/IP is yours; I assume "cube.dawnshosting.com", based on your local hostname in the above. Your machine is sending out an ICMP ping packet to purple.haze.bluntroll.in every 1 second. If you don't know why, you need to investigate why. -- | Jeremy Chadwick jdc at 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 Jul 24 08:47:36 2008 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 ED8721065673; Thu, 24 Jul 2008 08:47:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF1D8FC13; Thu, 24 Jul 2008 08:47:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6O8lQuC074495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 11:47:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6O8lQho019412; Thu, 24 Jul 2008 11:47:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6O8lPlC019411; Thu, 24 Jul 2008 11:47:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jul 2008 11:47:25 +0300 From: Kostik Belousov To: Mikhail Teterin Message-ID: <20080724084725.GF97161@deviant.kiev.zoral.com.ua> References: <48860725.9050808@aldan.algebra.com> <48863C3D.7090401@aldan.algebra.com> <20080723120348.GJ17123@deviant.kiev.zoral.com.ua> <200807231123.14229.jhb@freebsd.org> <48879173.60807@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yRA+Bmk8aPhU85Qt" Content-Disposition: inline In-Reply-To: <48879173.60807@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , stable@freebsd.org, John Baldwin Subject: Re: "sleeping without queue" ? 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, 24 Jul 2008 08:47:37 -0000 --yRA+Bmk8aPhU85Qt Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 23, 2008 at 04:15:47PM -0400, Mikhail Teterin wrote: > John Baldwin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > >I think this case is still a lingering bug in the sleep queue code since= =20 > >the thread lock stuff went in. There have been several reports of it bu= t=20 > >I have been unable to figure out how the wakeup is being missed. > > =20 > Is there anything I can still do for the investigation, or can I (try=20 > to) kill this thingie and restart my build of OpenOffice? Yours, I think I would not gather any additional information from this case for now. You can reboot/restart the system. --yRA+Bmk8aPhU85Qt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiIQZ0ACgkQC3+MBN1Mb4iU7wCgqNHAzm6uAjXeuqwVlgaBG1Uh NvwAoLzW4UKZM+qHbrSxeuaU78A0P5d7 =NS16 -----END PGP SIGNATURE----- --yRA+Bmk8aPhU85Qt-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:06:13 2008 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 E78181065674 for ; Thu, 24 Jul 2008 10:06:13 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id 52F0B8FC0A for ; Thu, 24 Jul 2008 10:06:13 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080724101116.WPOC28496.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Thu, 24 Jul 2008 11:11:16 +0100 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080724101256.KUAO16854.aamtaout01-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com> for ; Thu, 24 Jul 2008 11:12:56 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m6OA610P004079; Thu, 24 Jul 2008 11:06:02 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Thu, 24 Jul 2008 11:06:01 +0100 User-Agent: KMail/1.9.7 References: <005301c8eb2d$113598c0$33a0ca40$@com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807241106.01514.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Cc: "Carlos A. M. dos Santos" , Kevin K , Torfinn Ingolfsen Subject: Re: HP Pavilion dv2000 laptop wont boot off install cd 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, 24 Jul 2008 10:06:14 -0000 On Monday 21 July 2008 16:51:11 Carlos A. M. dos Santos wrote: > On Mon, Jul 21, 2008 at 9:26 AM, Kevin K wrote: > >> On Thu, 17 Jul 2008 08:31:37 -0400 > >> > >> Kevin K wrote: > >> > For 7.0-RELEASE, it > >> > seemed to hang at "Trying to mount root from ufs:/dev/md0". > >> > >> How long did you wait? If you didn't wait 10 or 15 minutes, please do. > >> Various tests / probes take a long time to time out on some hardware. > >> > >> HTH > >> -- > >> Regards, > >> Torfinn Ingolfsen > > > > I tried the 7.0-release-amd64 200807 snapshot and it booted (after > > holding the spacebar @ /boot/loader.conf). > > I have seen this on some HP notebooks. It seems that the CD drive does > not to stabilize on time before booting, leading to some disk read > errors. The trick is to press F9 (or F12, depending on the notebook > model) to force the BIOS to show the boot device menu. Then, *after > the CD drive stop spinning*, choose the boot from CD/DVD option. > > > It stopped at Trying to mount root from > > ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from > > that point -- the keyboard was also unresponsive. > > > > Does anyone know if this is a known issue? > > Try to disable kbdmux before booting. Jump to the loader prompt and type: > > set hint.kbdmux.0.disabled=1 > boot -v > > -- > If you think things can't get worse it's probably only > because you lack sufficient imagination. > _______________________________________________ > 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" Can you try set hw.ata.atapi_dma=0 from the loader prompt. It's a long shot but it just might work. As it's a laptop, you might need to do all the other stuff as well. -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:21:55 2008 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 91AF91065671 for ; Thu, 24 Jul 2008 10:21:55 +0000 (UTC) (envelope-from rj@shadowbots.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id E6EBE8FC22 for ; Thu, 24 Jul 2008 10:21:54 +0000 (UTC) (envelope-from rj@shadowbots.com) Received: by fk-out-0910.google.com with SMTP id k31so2055280fkk.11 for ; Thu, 24 Jul 2008 03:21:54 -0700 (PDT) Received: by 10.180.204.10 with SMTP id b10mr31869bkg.45.1216894914002; Thu, 24 Jul 2008 03:21:54 -0700 (PDT) Received: by 10.103.192.5 with HTTP; Thu, 24 Jul 2008 03:21:53 -0700 (PDT) Message-ID: <9072a4470807240321y59f827fdn287011c0336ae866@mail.gmail.com> Date: Thu, 24 Jul 2008 06:21:53 -0400 From: "Robert Jameson" Sender: rj@shadowbots.com To: freebsd-stable In-Reply-To: <9072a4470807240255v4d3f8e72gf8bfb39999b2dcbd@mail.gmail.com> MIME-Version: 1.0 References: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> <20080724074919.GA36163@eos.sc1.parodius.com> <9072a4470807240255v4d3f8e72gf8bfb39999b2dcbd@mail.gmail.com> X-Google-Sender-Auth: 4bb384486cf627ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: network problems 7.0-p3: sendto: Operation not permitted 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, 24 Jul 2008 10:21:55 -0000 Still don't know whats going on, im currently sitting here with no firewall between me and the internet (very nervous) seeing if it fixes the problems, as of right this moment, still seeing permission denied errors. I have fixed the 403 errors now. http://rj.dawnshosting.com/fbsd_ml/ now contains sysctl.conf rc.conf pf.conf On Thu, Jul 24, 2008 at 3:49 AM, Jeremy Chadwick wrote: > Let's see if I can figure out the multitude of things you've posted > about, since a bunch are unrelated and you appear to be flailing around > with your arms in the air. :-) Sorry about that, bit of a information overload, i really am flailing my arms around! > > > On Thu, Jul 24, 2008 at 01:59:23AM -0400, Robert Jameson wrote: > > (12:46 AM):(root@cube)/$ ping google.com > > PING google.com (72.14.207.99): 56 data bytes > > ping: sendto: Operation not permitted > > This usually indicates firewall rules on the local machine, although I > believe there are some other operations where EPERM can be returned. > Tried running with my firewall disabled/wide problem still occurs > > > > This appears to be an issue with the network. > > Can you provide uname -a output? There was a "cable modem compatibility > fix" applied to FreeBSD a while ago (a user informed me of such), > although I do not know if it applies to you, as I do not know the > original symptoms. I believe that fix was also just for TCP. > FreeBSD cube.dawnshosting.com 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #5: Wed Jul 16 21:55:02 EDT 2008 root@cube.dawnshosting.com:/usr/obj/usr/src/sys/CUBE i386 Was the patch applied upstream? if not and its not too much trouble can you point me in the direction of it. > > > I have attached my rc.conf and sysctl.conf and pf.conf please let me know > if > > any other information is required. > > > Errors from /var/log/console.log: > > > > Jul 18 21:10:02 cube kernel: Jul 18 21:10:02 cube named[908]: socket: too > > many open file descriptors > > Jul 19 00:30:13 cube kernel: Jul 19 00:30:13 cube named[9748]: socket: > too > > many open file descriptors > > Jul 19 00:30:54 cube kernel: Jul 19 00:30:14 cube last message repeated > 28 > > times > > This indicates a completely different/unrelated problem. > Ah, thought they were related, what's causing this :)! > > > > Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to > 200 > > packets/sec > > This indicates a high number of ICMP packets being received. Keep in > mind this can also be seen due to TCP connections which are being reset > and other such things -- ICMP is at a higher layer than TCP. > > I don't think there's necessarily anything "wrong" with that number (you > show up to 740), but it would be worthwhile investigating what's > > soliciting that amount of ICMP traffic. Are you seeing this 24x7x365? Yes its constant. let it me known i also have a 2 network cards in the machne, 1 into my cable modem and nother into a linksys 16port vpn router. the defaultrouter is set to a WAN IP (not 10.192.240.1), not that any of that matters, i dont think? > > > > /etc/sysctl.conf > > net.inet.icmp.icmplim=2000 > > > > I know it seems abit high, but i kept adjusting until the error went > away. > > (not really fixing the problem?) > > It's not a big high; FreeBSD's 200 default is too low for any production > server, if you ask me. Setting it to 2000 is probably fine. I read a bit about it from the handbook, i think it's a non issue. Might be worth mentioning the only real service change to this machine was an ircd daemon w/ about 500 users. > > > > If your mail client or the mailing list prevents you from seeing the > > attached > > You can view them here: > > http://rj.dawnshosting.com/fbsd_ml/ > > You should discuss your firewalling rules on freebsd-pf, and not here. > I believe you may have some mistakes which are inducing said problem. > I will send them an e-mail shortly, thanks. > > > PS: While running tcpdump I see this > > > > tcpdump -i fxp0 > > > > Neither one of these ip's exist on my system is my cable company doing > > something wrong? > > > > > > 01:47:12.135929 arp who-has 64.253.3.161.dyn-cm-pool73.pool.hargray.nettell > > 64.253.3.1.dyn-cm-pool73.pool.hargray.net > > 01:47:12.155931 arp who-has > 216.16.218.141.dyn-cm-pool46.pool.hargray.nettell > > 216.16.218.1.dyn-cm-pool46.pool.hargray.net > > 01:47:12.196000 arp who-has 181.131.216.67.181.static.hargray.net tell > > 1.131.216.67.1.static.hargray.net > > Nope. This is normal behaviour for a cable modem network; they > constantly spam layer 2 ARP for *everyone* on the entire cable network > segment. Yes, you read that right. > ah, ok, nothing to see here, keep moving. > > > Is this an attack? > > > > 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: > ICMP > > echo request, id 22055, seq 37084, length 64 > > 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: > ICMP > > echo request, id 22055, seq 37085, length 64 > > At this rate (1 ICMP packet a second), absolutely not. You also don't > mention which FQDN/IP is yours; I assume "cube.dawnshosting.com", based > on your local hostname in the above. Your machine is sending out an > ICMP ping packet to purple.haze.bluntroll.in every 1 second. If you > don't know why, you need to investigate why. > Correct, cube.dawnshosting.com is the actual FreeBSD machinr. sorry for the newbish question, off the top of your head how can i see who/what is using this process? > > -- > | Jeremy Chadwick jdc at 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 Jul 24 10:22:53 2008 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 317E61065671 for ; Thu, 24 Jul 2008 10:22:53 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: from mercury.meisternet.ch (mercury.meisternet.ch [62.65.147.122]) by mx1.freebsd.org (Postfix) with ESMTP id BC56E8FC24 for ; Thu, 24 Jul 2008 10:22:52 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: by mercury.meisternet.ch (Postfix, from userid 1001) id 34DC7B82B; Thu, 24 Jul 2008 12:07:20 +0200 (CEST) Date: Thu, 24 Jul 2008 12:07:20 +0200 From: Dominik Meister To: freebsd-stable@freebsd.org Message-ID: <20080724100720.GA44545@mercury.meisternet.ch> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> <20080723015855.GA36829@eos.sc1.parodius.com> <20080723021146.GO76659@elvis.mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20080723021146.GO76659@elvis.mu.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: FreeBSD 7.1 and BIND exploit 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, 24 Jul 2008 10:22:53 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alfred Perlstein [Tue, Jul 22, 2008 at 07:11:46PM -0700]: > Back in 2003 I tried to set up a "shared key" IPSEC dhcp > at home, basically I'd just make a key and sneaker-net it > to the hosts that wanted to connect, after about 6 hours > I just gave up and used "wep". Completely off-topic (sorry for that) but you should have used OpenVPN. I'm using it for a VPN-over-Wireless and its dead simple. Dominik --=20 Dominik Meister My public GnuPG key is available at http://www.meisternet.ch/gpg.txt --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiIVFgACgkQVD1CCgD/XK3rkQCfdbvNyBuXSFJ0lkLLMj+UvsD6 C0MAnjkjMrS+YTAjQdl2jjoqpNuccOnb =n1ZG -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:33:20 2008 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 139081065672 for ; Thu, 24 Jul 2008 10:33:20 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by mx1.freebsd.org (Postfix) with ESMTP id A85238FC14 for ; Thu, 24 Jul 2008 10:33:19 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by qb-out-0506.google.com with SMTP id e34so63028qbe.35 for ; Thu, 24 Jul 2008 03:33:18 -0700 (PDT) Received: by 10.64.178.5 with SMTP id a5mr195340qbf.31.1216894612457; Thu, 24 Jul 2008 03:16:52 -0700 (PDT) Received: from kevin ( [76.10.166.187]) by mx.google.com with ESMTPS id 28sm11035271qbw.0.2008.07.24.03.16.51 (version=SSLv3 cipher=RC4-MD5); Thu, 24 Jul 2008 03:16:52 -0700 (PDT) From: "Kevin" To: "'ian j hart'" , References: <005301c8eb2d$113598c0$33a0ca40$@com> <200807241106.01514.ianjhart@ntlworld.com> In-Reply-To: <200807241106.01514.ianjhart@ntlworld.com> Date: Thu, 24 Jul 2008 06:16:42 -0400 Message-ID: <4e6601c8ed76$5f52e0d0$1df8a270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjtdPtoqrAP0/aOTryrHBrT2OucVgAAPoiQ Content-Language: en-us Cc: "'Carlos A. M. dos Santos'" , 'Kevin K' , 'Torfinn Ingolfsen' Subject: RE: HP Pavilion dv2000 laptop wont boot off install cd 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, 24 Jul 2008 10:33:20 -0000 > > Try to disable kbdmux before booting. Jump to the loader prompt and > type: > > > > set hint.kbdmux.0.disabled=1 > > boot -v > > > Can you try > > set hw.ata.atapi_dma=0 > > from the loader prompt. > > It's a long shot but it just might work. > > As it's a laptop, you might need to do all the other stuff as well. I was finally able to get it to boot. Here's what I did : 1. Bringing up the boot choice menu before the loader starts to let the cdrom settle before selecting to boot off cd 2. Entering "set hint.kbdmux.0.disabled=1" in the boot loader prompt What happened, unfortunately, was the USB keyboard I had plugged into the laptop didn't work after the command in #2, obviously. I'm not sure if this will happen every time I boot, or perhaps will work if I plug in the keyboard after waiting to boot, but at the very least I can get into sysinstall now. I will be installing 7-release this weekend and I will post any relevant updates in this thread. Thank you all for your help and assistance in this matter, it is greatly appreciated. ~k From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 10:55:30 2008 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 8FCA1106567F for ; Thu, 24 Jul 2008 10:55:30 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.freebsd.org (Postfix) with ESMTP id 380DC8FC27 for ; Thu, 24 Jul 2008 10:55:30 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95002FD576; Thu, 24 Jul 2008 12:55:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Thu, 24 Jul 2008 12:55:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A1985@royal64.emp.zapto.org> In-Reply-To: <021501c8ed35$0053a330$47a8a8c0@iij.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MCP55 SATA data corruption in FreeBSD 7 Thread-Index: AcjtOgf2Td+BcpruSMynSNt9Kp+QKQAQIN5g References: <021501c8ed35$0053a330$47a8a8c0@iij.ad.jp> From: "Daniel Eriksson" To: Cc: Munenori Ohuchi Subject: RE: MCP55 SATA data corruption in FreeBSD 7 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, 24 Jul 2008 10:55:30 -0000 Munenori Ohuchi wrote: > Could you try the following patch? > ... > If you have a device like 'ad4' which is detected as=20 > 'udma=3DUDMA100', this patch will work. The drive in question looked like this in the verbose boot-log: ata2-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad4: 715404MB at ata2-master SATA300 ad4: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue I tried the patch even though it probably isn't applicable to my problem, and unsurprisingly it didn't help. :-) Thanks for trying to help though! ___ Daniel Eriksson (http://www.toomuchdata.com/) From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 11:12:45 2008 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 1CE30106564A; Thu, 24 Jul 2008 11:12:45 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBD118FC1A; Thu, 24 Jul 2008 11:12:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id F22851CC0B0; Thu, 24 Jul 2008 04:12:44 -0700 (PDT) Date: Thu, 24 Jul 2008 04:12:44 -0700 From: Jeremy Chadwick To: Robert Jameson Message-ID: <20080724111244.GA44703@eos.sc1.parodius.com> References: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> <20080724074919.GA36163@eos.sc1.parodius.com> <9072a4470807240255v4d3f8e72gf8bfb39999b2dcbd@mail.gmail.com> <9072a4470807240321y59f827fdn287011c0336ae866@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9072a4470807240321y59f827fdn287011c0336ae866@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable , cperciva@freebsd.org Subject: Re: network problems 7.0-p3: sendto: Operation not permitted 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, 24 Jul 2008 11:12:45 -0000 On Thu, Jul 24, 2008 at 06:21:53AM -0400, Robert Jameson wrote: > Still don't know whats going on, im currently sitting here with no firewall > between me and the internet (very nervous) seeing if it fixes the problems, > as of right this moment, still seeing permission denied errors. Okay, then the problem isn't with pf, although f/w rules are the only thing I've personally experienced which induces those messages. How did you disable the firewall, by the way? > > Can you provide uname -a output? There was a "cable modem compatibility > > fix" applied to FreeBSD a while ago (a user informed me of such), > > although I do not know if it applies to you, as I do not know the > > original symptoms. I believe that fix was also just for TCP. > > > > FreeBSD cube.dawnshosting.com 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #5: Wed > Jul 16 21:55:02 EDT 2008 > root@cube.dawnshosting.com:/usr/obj/usr/src/sys/CUBE > i386 > > Was the patch applied upstream? if not and its not too much trouble can you > point me in the direction of it. The patch was applied to RELENG_7 on Marth 13th and RELENG_7_0 on June 19th. I don't know which tag you're tracking for src, so I can't tell you if you've got the patch or not: 1.141.2.4 +10 -2 src/sys/netinet/tcp_output.c 1.157.2.2 +5 -2 src/sys/netinet/tcp_var.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h For a discussion of this (read between the lines): http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043595.html > > > Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to > > 200 > > > packets/sec > > > > This indicates a high number of ICMP packets being received. Keep in > > mind this can also be seen due to TCP connections which are being reset > > and other such things -- ICMP is at a higher layer than TCP. > > > > I don't think there's necessarily anything "wrong" with that number (you > > show up to 740), but it would be worthwhile investigating what's > > > > > soliciting that amount of ICMP traffic. Are you seeing this 24x7x365? > > > Yes its constant. let it me known i also have a 2 network cards in the > machne, 1 into my cable modem and nother into a linksys 16port vpn router. > the defaultrouter is set to a WAN IP (not 10.192.240.1), not that any of > that matters, i dont think? No one will know without you describing your network (with IPs and netmasks), and providing netstat -rn output. > > > /etc/sysctl.conf > > > net.inet.icmp.icmplim=2000 > > > > > > I know it seems abit high, but i kept adjusting until the error went > > away. > > > (not really fixing the problem?) > > > > It's not a big high; FreeBSD's 200 default is too low for any production > > server, if you ask me. Setting it to 2000 is probably fine. > > > I read a bit about it from the handbook, i think it's a non issue. > > Might be worth mentioning the only real service change to this machine was > an ircd daemon w/ about 500 users. I see. God help you. Your file descriptor problem with bind may be because of this. IRC servers commonly chew socket resources at a crazy rate, especially if you're under some form of TCP-based attack (which might also explain the ICMP errors, induced by TCP RST). You may want to look at the kern.maxfiles and kern.maxfilesperproc sysctls, and read this. http://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html I don't mean to be rude, but I'd highly recommend avoid running a public IRC server unless you have significant familiarity with your OS, network topology, and have a very robust firewall (read: Cisco or Juniper) *in front* of the machine acting as an IRC server -- and even then, ask yourself if it's worth it. IRC servers are harassment magnets, and you will end up being the target of that harassment. > > > Is this an attack? > > > > > > 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: > > ICMP > > > echo request, id 22055, seq 37084, length 64 > > > 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: > > ICMP > > > echo request, id 22055, seq 37085, length 64 > > > > At this rate (1 ICMP packet a second), absolutely not. You also don't > > mention which FQDN/IP is yours; I assume "cube.dawnshosting.com", based > > on your local hostname in the above. Your machine is sending out an > > ICMP ping packet to purple.haze.bluntroll.in every 1 second. If you > > don't know why, you need to investigate why. > > > > Correct, cube.dawnshosting.com is the actual FreeBSD machinr. > sorry for the newbish question, off the top of your head how can i see > who/what is using this process? FreeBSD comes with sockstat, which should suffice for this. -- | Jeremy Chadwick jdc at 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 Jul 24 12:50:42 2008 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 718BE106568C for ; Thu, 24 Jul 2008 12:50:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4B15C8FC24 for ; Thu, 24 Jul 2008 12:50:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6OCoapB064653; Thu, 24 Jul 2008 08:50:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m6OCoa5n014019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 08:50:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200807241250.m6OCoa5n014019@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Jul 2008 08:50:37 -0400 To: Julian Elischer , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <200807240118.m6O1I8oo061207@repoman.freebsd.org> References: <200807240118.m6O1I8oo061207@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: cvs commit: src/contrib/pf/pfctl parse.y src/lib/libc/sys Symbol.map getsockopt.2 src/sbin/ipfw ipfw.8 ipfw2.c src/sys/conf NOTES options src/sys/contrib/ipfilter/netinet ip_fil_freebsd.c src/sys/contrib/pf/net pf.c pf_ioctl.c src/sys/kern init_sysent.c ... 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, 24 Jul 2008 12:50:42 -0000 This looks like a very cool feature addition to RELENG_7! Are there any performance penalties that you know of with this built in ? ---Mike At 09:13 PM 7/23/2008, Julian Elischer wrote: >julian 2008-07-24 01:13:22 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > contrib/pf/pfctl parse.y > lib/libc/sys Symbol.map getsockopt.2 > sbin/ipfw ipfw.8 ipfw2.c > sys/conf NOTES options > sys/contrib/ipfilter/netinet ip_fil_freebsd.c > sys/contrib/pf/net pf.c pf_ioctl.c > sys/kern init_sysent.c sys_socket.c syscalls.c > syscalls.master systrace_args.c > uipc_socket.c vfs_export.c > sys/net if.c if_atmsubr.c if_fwsubr.c if_gif.c > if_gif.h if_gre.c if_gre.h > if_iso88025subr.c if_stf.c if_var.h > route.c route.h rtsock.c > sys/netatalk at_extern.h at_proto.c > sys/netgraph/netflow netflow.c > sys/netinet if_atm.c if_ether.c in_gif.c in_mcast.c > in_pcb.c in_pcb.h in_rmx.c in_var.h > ip_fastfwd.c ip_fw.h ip_fw2.c ip_icmp.c > ip_input.c ip_mroute.c ip_mroute.h > ip_options.c ip_output.c ip_var.h > raw_ip.c sctp_os_bsd.h tcp_input.c > tcp_subr.c tcp_syncache.c > sys/netinet6 in6.c in6_ifattach.c in6_rmx.c nd6_rtr.c > sys/netipx ipx_proto.c > sys/nfs4client nfs4_vfsops.c > sys/nfsclient bootp_subr.c nfs_vfsops.c > sys/sys domain.h mbuf.h proc.h socket.h > socketvar.h syscall.h syscall.mk > sysproto.h > usr.bin/netstat route.c > Added files: (Branch: RELENG_7) > usr.sbin/setfib Makefile setfib.1 setfib.c > Log: > SVN rev 180774 on 2008-07-24 01:13:22Z by julian > > MFC an ABI compatible implementation of Multiple routing tables. > See the commit message for > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.c > version 1.129 (svn change # 178888) for more info. > > Obtained from: Ironport (Cisco Systems) > > Revision Changes Path > 1.8.2.1 +6 -15 src/contrib/pf/pfctl/parse.y > 1.9.2.3 +1 -0 src/lib/libc/sys/Symbol.map > 1.38.2.1 +7 -0 src/lib/libc/sys/getsockopt.2 > 1.203.2.6 +12 -0 src/sbin/ipfw/ipfw.8 > 1.108.2.8 +21 -2 src/sbin/ipfw/ipfw2.c > 1.1454.2.14 +2 -0 src/sys/conf/NOTES > 1.608.2.6 +1 -0 src/sys/conf/options > 1.6.2.3 +3 -3 src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c > 1.46.2.2 +33 -5 src/sys/contrib/pf/net/pf.c > 1.28.2.3 +3 -3 src/sys/contrib/pf/net/pf_ioctl.c > 1.230.2.2 +1 -1 src/sys/kern/init_sysent.c > 1.73.2.1 +1 -1 src/sys/kern/sys_socket.c > 1.214.2.2 +1 -1 src/sys/kern/syscalls.c > 1.233.2.2 +1 -1 src/sys/kern/syscalls.master > 1.14.2.2 +7 -0 src/sys/kern/systrace_args.c > 1.302.2.4 +20 -0 src/sys/kern/uipc_socket.c > 1.341.2.2 +16 -3 src/sys/kern/vfs_export.c > 1.273.2.3 +6 -3 src/sys/net/if.c > 1.45.2.1 +2 -1 src/sys/net/if_atmsubr.c > 1.24.2.1 +1 -1 src/sys/net/if_fwsubr.c > 1.66.2.2 +3 -0 src/sys/net/if_gif.c > 1.19.2.1 +1 -0 src/sys/net/if_gif.h > 1.46.2.2 +5 -1 src/sys/net/if_gre.c > 1.13.10.1 +1 -0 src/sys/net/if_gre.h > 1.75.2.1 +2 -1 src/sys/net/if_iso88025subr.c > 1.60.2.1 +7 -2 src/sys/net/if_stf.c > 1.115.2.2 +2 -0 src/sys/net/if_var.h > 1.120.2.4 +355 -95 src/sys/net/route.c > 1.65.2.2 +31 -4 src/sys/net/route.h > 1.143.2.2 +9 -5 src/sys/net/rtsock.c > 1.18.2.1 +1 -0 src/sys/netatalk/at_extern.h > 1.13.2.1 +1 -1 src/sys/netatalk/at_proto.c > 1.25.2.2 +3 -2 src/sys/netgraph/netflow/netflow.c > 1.21.2.1 +1 -1 src/sys/netinet/if_atm.c > 1.162.2.1 +185 -116 src/sys/netinet/if_ether.c > 1.38.2.1 +6 -2 src/sys/netinet/in_gif.c > 1.3.2.2 +2 -1 src/sys/netinet/in_mcast.c > 1.196.2.4 +2 -1 src/sys/netinet/in_pcb.c > 1.100.2.2 +1 -1 src/sys/netinet/in_pcb.h > 1.57.2.1 +126 -28 src/sys/netinet/in_rmx.c > 1.61.2.1 +16 -0 src/sys/netinet/in_var.h > 1.41.2.1 +1 -1 src/sys/netinet/ip_fastfwd.c > 1.110.2.4 +4 -0 src/sys/netinet/ip_fw.h > 1.175.2.7 +48 -5 src/sys/netinet/ip_fw2.c > 1.118.2.1 +12 -5 src/sys/netinet/ip_icmp.c > 1.332.2.4 +4 -4 src/sys/netinet/ip_input.c > 1.138.2.1 +2 -2 src/sys/netinet/ip_mroute.c > 1.31.2.1 +1 -1 src/sys/netinet/ip_mroute.h > 1.6.2.2 +3 -2 src/sys/netinet/ip_options.c > 1.276.2.2 +2 -1 src/sys/netinet/ip_output.c > 1.101.2.1 +1 -1 src/sys/netinet/ip_var.h > 1.180.2.2 +1 -1 src/sys/netinet/raw_ip.c > 1.33.2.1 +1 -1 src/sys/netinet/sctp_os_bsd.h > 1.370.2.3 +1 -0 src/sys/netinet/tcp_input.c > 1.300.2.3 +7 -1 src/sys/netinet/tcp_subr.c > 1.130.2.8 +4 -0 src/sys/netinet/tcp_syncache.c > 1.73.2.2 +2 -1 src/sys/netinet6/in6.c > 1.39.2.1 +3 -3 src/sys/netinet6/in6_ifattach.c > 1.18.2.1 +8 -4 src/sys/netinet6/in6_rmx.c > 1.36.2.1 +2 -1 src/sys/netinet6/nd6_rtr.c > 1.22.2.1 +11 -1 src/sys/netipx/ipx_proto.c > 1.27.2.1 +2 -1 src/sys/nfs4client/nfs4_vfsops.c > 1.70.2.1 +3 -2 src/sys/nfsclient/bootp_subr.c > 1.193.2.2 +1 -0 src/sys/nfsclient/nfs_vfsops.c > 1.22.2.1 +6 -0 src/sys/sys/domain.h > 1.217.2.3 +20 -2 src/sys/sys/mbuf.h > 1.491.2.5 +1 -0 src/sys/sys/proc.h > 1.95.2.2 +1 -0 src/sys/sys/socket.h > 1.158.2.3 +1 -0 src/sys/sys/socketvar.h > 1.211.2.2 +1 -0 src/sys/sys/syscall.h > 1.166.2.2 +1 -0 src/sys/sys/syscall.mk > 1.215.2.2 +5 -0 src/sys/sys/sysproto.h > 1.82.2.6 +25 -4 src/usr.bin/netstat/route.c > 1.1.2.1 +6 -0 src/usr.sbin/setfib/Makefile (new) > 1.2.2.1 +97 -0 src/usr.sbin/setfib/setfib.1 (new) > 1.3.2.1 +103 -0 src/usr.sbin/setfib/setfib.c (new) >_______________________________________________ >cvs-all@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/cvs-all >To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 12:55:27 2008 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 EE14B1065677; Thu, 24 Jul 2008 12:55:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C31288FC26; Thu, 24 Jul 2008 12:55:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3383846B94; Thu, 24 Jul 2008 08:37:21 -0400 (EDT) Date: Thu, 24 Jul 2008 13:37:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mikhail Teterin In-Reply-To: <48861448.7020708@aldan.algebra.com> Message-ID: <20080724133555.P63347@fledge.watson.org> References: <4885F2A6.5020204@aldan.algebra.com> <4885FCE5.1060507@FreeBSD.org> <48860725.9050808@aldan.algebra.com> <20080722161958.GA11139@eos.sc1.parodius.com> <48860E8C.6050400@FreeBSD.org> <48860EF6.2040007@aldan.algebra.com> <48861284.1050706@FreeBSD.org> <48861448.7020708@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kris Kennaway , questions@FreeBSD.org, Jeremy Chadwick , stable@FreeBSD.org Subject: Re: "sleeping without queue" ? 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, 24 Jul 2008 12:55:28 -0000 On Tue, 22 Jul 2008, Mikhail Teterin wrote: > Kris Kennaway ???????(??): >> Mikhail Teterin wrote: >>> Kris Kennaway ???????(??): >>>> Well, I mean kernel backtrace. >>> Can I obtain that remotely and without restarting/panicking the box? >>> Thanks, >> kgdb on /dev/mem or procstat > root@aldan:~ (107) kgdb /boot/kernel/kernel /dev/mem > [...] > (kgdb) bt > #0 0x0000000000000000 in ?? () > Error accessing memory address 0x0: Bad address. > > Even less luck with procstat: > > root@aldan:~ (108) locate procstat > root@aldan:~ (109) procstat > procstat: ???????? ???????. > root@aldan:~ (110) man procstat > No manual entry for procstat > > I'm sorry, but you'll need to be more specific. What should I type? Thanks, Assuming you're using 7.0 or an older 7-STABLE: procstat(1) appeared after 7.0 was released, but should be there if you slide forward on 7-STABLE. You can use "procstat -k pid" to see kernel stack traces for kernel threads working on behalf of the process. Depending on the level of detail you require, you can use -kk to also list function offsets inside the kernel, but the results are a bit harder to read. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 16:16:16 2008 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 8ED191065684; Thu, 24 Jul 2008 16:16:16 +0000 (UTC) (envelope-from john@basicnets.co.uk) Received: from server252.basicnets.co.uk (server8.basicnets.co.uk [81.6.221.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3E22D8FC1D; Thu, 24 Jul 2008 16:16:16 +0000 (UTC) (envelope-from john@basicnets.co.uk) Received: from [195.224.14.210] (helo=UKBIM1344) by server252.basicnets.co.uk with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM3Tv-0004yy-MU; Thu, 24 Jul 2008 17:15:56 +0100 From: "John Sullivan" To: "'Kris Kennaway'" , References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net><20080716031640.7DC744500E@ptavv.es.net><62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com><487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> Date: Thu, 24 Jul 2008 17:15:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acjne7VfokRPFkvRRdS4MNKSKMJfmQGK1DXQ Cc: Subject: RE: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 16:16:16 -0000 =20 >> Removing KDB_UNATTENDED from your kernel will allow you=20 >> to interact with the debugger and obtain backtraces etc,=20 >> which is useful when dumps are not being saved. >=20 > Easier said than done, this cause a few panics - no dumps=20 > though ...grrrr!! >=20 > Still the same result ... the system seems to panic twice=20 > then hang.=A0 I will keep trying unless you have some other ideas?? Right, after trying for a number of days the system still just hung = without letting me get either a dump or to interactively debug in the failed state, I reverted back to the Generic kernel, removed half = the memory (2 of the 4 1GB sticks) and the system became stable. I inserted 1 of the 2 removed sticks and all was fine. I = swapped that stick with the remaining stick and all was fine. I put them both back in and I started to see the crashes again - the first = of which, gave me this dump --> server251# kgdb /boot/kernel/kernel /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: = /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0xb0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x8:0xffffffff8068d4bd stack pointer =3D 0x10:0xffffffffb20738e0 frame pointer =3D 0x10:0x0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 72836 (objdump) trap number =3D 12 panic: page fault cpuid =3D 1 Uptime: 28m4s Physical memory: 4082 MB Dumping 518 MB: 503 487 471 455 439 423 407 391 375 359 343 327 311 295 = 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff80477699 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80477a9d in panic (fmt=3D0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff8072ed44 in trap_fatal (frame=3D0xffffff003c39c000,=20 eva=3D18446742974629017808) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8072f115 in trap_pfault (frame=3D0xffffffffb2073830, = usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff8072fa58 in trap (frame=3D0xffffffffb2073830) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff807156be in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff8068d4bd in vm_page_cache_remove (m=3D0xffffff00da9ec3b8) at /usr/src/sys/vm/vm_page.c:896 #9 0xffffffff8068e1b5 in vm_page_alloc (object=3D0xffffff00374ffc30, = pindex=3D14,=20 req=3D64) at /usr/src/sys/vm/vm_page.c:1080 #10 0xffffffff8067fa77 in vm_fault (map=3D0xffffff0005f23d00, = vaddr=3D34365804544,=20 fault_type=3D1 '\001', fault_flags=3D0) at = /usr/src/sys/vm/vm_fault.c:432 #11 0xffffffff8072efaf in trap_pfault (frame=3D0xffffffffb2073c70, = usermode=3D1) at /usr/src/sys/amd64/amd64/trap.c:618 #12 0xffffffff8072fbf8 in trap (frame=3D0xffffffffb2073c70) at /usr/src/sys/amd64/amd64/trap.c:309 #13 0xffffffff807156be in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #14 0x000000080059c54f in ?? () Previous frame inner to this frame (corrupt stack?) So to answer your question are the backtraces always the same, no, they = are not. But I am still confused as to what this means?? I would appreciate any further insight anyone can give. Thanks John From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 16:24:54 2008 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 34B391065678 for ; Thu, 24 Jul 2008 16:24:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 594E98FC17; Thu, 24 Jul 2008 16:24:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4888ACD7.6010803@FreeBSD.org> Date: Thu, 24 Jul 2008 18:24:55 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: John Sullivan References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net><20080716031640.7DC744500E@ptavv.es.net><62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com><487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 16:24:54 -0000 John Sullivan wrote: > >>> Removing KDB_UNATTENDED from your kernel will allow you >>> to interact with the debugger and obtain backtraces etc, >>> which is useful when dumps are not being saved. >> Easier said than done, this cause a few panics - no dumps >> though ...grrrr!! >> >> Still the same result ... the system seems to panic twice >> then hang. I will keep trying unless you have some other ideas?? > > Right, after trying for a number of days the system still just hung without letting me get either a dump or to interactively debug > in the failed state, I reverted back to the Generic kernel, removed half the memory (2 of the 4 1GB sticks) and the system became > stable. I inserted 1 of the 2 removed sticks and all was fine. I swapped that stick with the remaining stick and all was fine. I > put them both back in and I started to see the crashes again - the first of which, gave me this dump --> > > server251# kgdb /boot/kernel/kernel /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0xb0 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8068d4bd > stack pointer = 0x10:0xffffffffb20738e0 > frame pointer = 0x10:0x0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 72836 (objdump) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 28m4s > Physical memory: 4082 MB > Dumping 518 MB: 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 > 23 7 > > #0 doadump () at pcpu.h:194 > 194 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0x0000000000000004 in ?? () > #2 0xffffffff80477699 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff80477a9d in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:563 > #4 0xffffffff8072ed44 in trap_fatal (frame=0xffffff003c39c000, > eva=18446742974629017808) at /usr/src/sys/amd64/amd64/trap.c:724 > #5 0xffffffff8072f115 in trap_pfault (frame=0xffffffffb2073830, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:641 > #6 0xffffffff8072fa58 in trap (frame=0xffffffffb2073830) > at /usr/src/sys/amd64/amd64/trap.c:410 > #7 0xffffffff807156be in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:169 > #8 0xffffffff8068d4bd in vm_page_cache_remove (m=0xffffff00da9ec3b8) > at /usr/src/sys/vm/vm_page.c:896 > #9 0xffffffff8068e1b5 in vm_page_alloc (object=0xffffff00374ffc30, pindex=14, > req=64) at /usr/src/sys/vm/vm_page.c:1080 > #10 0xffffffff8067fa77 in vm_fault (map=0xffffff0005f23d00, vaddr=34365804544, > fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:432 > #11 0xffffffff8072efaf in trap_pfault (frame=0xffffffffb2073c70, usermode=1) > at /usr/src/sys/amd64/amd64/trap.c:618 > #12 0xffffffff8072fbf8 in trap (frame=0xffffffffb2073c70) > at /usr/src/sys/amd64/amd64/trap.c:309 > #13 0xffffffff807156be in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:169 > #14 0x000000080059c54f in ?? () > Previous frame inner to this frame (corrupt stack?) > > So to answer your question are the backtraces always the same, no, they are not. But I am still confused as to what this means?? > > I would appreciate any further insight anyone can give. That's another corrupted backtrace that doesn't point to an actual software problem. Still sounds like bad RAM, or bad hardware. Kris From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 18:36:50 2008 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 2CEE2106567B for ; Thu, 24 Jul 2008 18:36:50 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1919C8FC18 for ; Thu, 24 Jul 2008 18:36:50 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 9F531357EA08; Thu, 24 Jul 2008 11:16:50 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 8C11E464005; Thu, 24 Jul 2008 11:16:50 -0700 (PDT) X-AuditID: 11807135-ab104bb000000854-ef-4888c7120080 Received: from cswiger1.apple.com (cswiger1.apple.com [17.227.140.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id 6175C420008; Thu, 24 Jul 2008 11:16:50 -0700 (PDT) Message-Id: From: Chuck Swiger To: John Sullivan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 24 Jul 2008 11:16:48 -0700 References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> X-Mailer: Apple Mail (2.928.1) X-Brightmail-Tracker: AAAAAA== Cc: FreeBSD Stable List Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 18:36:50 -0000 On Jul 24, 2008, at 9:15 AM, John Sullivan wrote: > Right, after trying for a number of days the system still just hung > without letting me get either a dump or to interactively debug > in the failed state, I reverted back to the Generic kernel, removed > half the memory (2 of the 4 1GB sticks) and the system became > stable. I inserted 1 of the 2 removed sticks and all was fine. I > swapped that stick with the remaining stick and all was fine. I > put them both back in and I started to see the crashes again - the > first of which, gave me this dump --> You might want to double-check the detailed documentation about your motherboard. There are a fair number of consumer-grade motherboards that can't reliably handle 4 double-sided DIMMs at full speed. Some of them require you to downgrade the memory clock from, say, PC3200 (aka 200MHz DDR) down to PC2700 speed (aka 166MHz DDR); others may work, but only if you install the more expensive buffered type of RAM (which also tend to include ECC) rather than generic unbuffered RAM. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 20:09:17 2008 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 29297106566B for ; Thu, 24 Jul 2008 20:09:17 +0000 (UTC) (envelope-from michael.grant@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id F10798FC0A for ; Thu, 24 Jul 2008 20:09:16 +0000 (UTC) (envelope-from michael.grant@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2220382wfg.7 for ; Thu, 24 Jul 2008 13:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=fHI4TLfNvSQKK8ldMuby9qpkHs/rPhFc4FElNehWi2s=; b=mXQkSnspSzN3WUpnf/BQgSveRuFg4Ryr1URFhyZarsmTgeN19oCSAy/0sin+7IhLlf cMjLPbnMCxs6EOek1NcWc1zHCo9OZpSIGxwwxEvOsC7bsBI7RnybGSptz3MQjZ6H2cN1 7vP8vNK5tv8QZ/+qrHNyK+h7Cr6W3xP+/bI2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NNY8UzRZCOl1wjYaTtxXA0nf3r1I0MROit95RCaToe1oP3l37OuTAuJNAMS1ZKGMPh afc8ixb+LBD3fyE/+yhaJeV7nNCPBGFZdaWO6MRIATF6Grfv7Qpe1rmQ9PvjZ1QKKsj4 tY1Q2OQHYgpjFxZkKbqDS3CYBz5PEQzE5ajtA= Received: by 10.142.139.19 with SMTP id m19mr250828wfd.25.1216930156505; Thu, 24 Jul 2008 13:09:16 -0700 (PDT) Received: by 10.142.52.1 with HTTP; Thu, 24 Jul 2008 13:09:16 -0700 (PDT) Message-ID: <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> Date: Thu, 24 Jul 2008 22:09:16 +0200 From: "Michael Grant" Sender: michael.grant@gmail.com To: "FreeBSD Stable List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> X-Google-Sender-Auth: 9115b8a30526a333 Cc: John Sullivan Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 20:09:17 -0000 I have been having what seems like similar panics. I too cannot manage to get a crash dump, neither classic style nor minidump. Nor can I get it to work with DDB, there seems to be a problem with DDB and my Geom mirror. Kris recommended I up kmem_size which I have done (twice now) and since the last time I upped it, the machine has not crashed again (yet?). For the moment, I'm hoping things are stable. In /boot/loader.conf, I currently have the following: vm.kmem_size=1G vm.kmem_size_max=1G vm.kmem_size_scale=2 and in my kernel conf file I have: options KVA_PAGES=512 Here's what top says currently: last pid: 57367; load averages: 0.56, 0.54, 0.61 up 2+10:16:57 15:50:55 407 processes: 6 running, 378 sleeping, 2 zombie, 21 waiting CPU states: 0.1% user, 0.0% nice, 2.3% system, 0.7% interrupt, 97.0% idle Mem: 1309M Active, 1291M Inact, 497M Wired, 155M Cache, 199M Buf, 7408K Free Swap: 9541M Total, 1628K Used, 9540M Free Is this a heavily loaded machine? It's using a lot of memory, but it's mostly idle. I have 2 sticks of double-sided memory (4gig total) in the box. The SuperMicro documentation recommends using single sided sticks for 6 or more sticks. I feel for you John, I've lost many nights sleep in the last couple weeks trying to understand why this production box was crashing. I was really surprised to see this start happening, normally my freebsd boxes have uptimes in terms of years, not hours. Michael Grant From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 20:11:50 2008 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 3BF701065671 for ; Thu, 24 Jul 2008 20:11:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD51A8FC15; Thu, 24 Jul 2008 20:11:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4888E207.4020606@FreeBSD.org> Date: Thu, 24 Jul 2008 22:11:51 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Michael Grant References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> In-Reply-To: <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable List , John Sullivan Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 20:11:50 -0000 Michael Grant wrote: > I have been having what seems like similar panics. I too cannot > manage to get a crash dump, neither classic style nor minidump. Nor > can I get it to work with DDB, there seems to be a problem with DDB > and my Geom mirror. They're not at all similar, please don't confuse the issue :) Kris From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 20:42:08 2008 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 93DC9106566B for ; Thu, 24 Jul 2008 20:42:08 +0000 (UTC) (envelope-from john@basicnets.co.uk) Received: from server252.basicnets.co.uk (server8.basicnets.co.uk [81.6.221.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3D77A8FC14 for ; Thu, 24 Jul 2008 20:42:08 +0000 (UTC) (envelope-from john@basicnets.co.uk) Received: from www by server252.basicnets.co.uk with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM7dE-00079h-0c for freebsd-stable@freebsd.org; Thu, 24 Jul 2008 21:41:48 +0100 Received: from my.firewall (my.firewall [192.168.137.1]) by mail.basicnets.co.uk (Horde MIME library) with HTTP; Thu, 24 Jul 2008 21:41:47 +0100 Message-ID: <20080724214147.d1uz3iuv44g4o4g4@mail.basicnets.co.uk> X-Priority: 3 (Normal) Date: Thu, 24 Jul 2008 21:41:47 +0100 From: john@basicnets.co.uk To: freebsd-stable@freebsd.org References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <20080716031640.7DC744500E@ptavv.es.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> In-Reply-To: <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) / FreeBSD-6.2 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Description: Plaintext Version of Message X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Fresh 7.0 Install: Fatal Trap 12 panic when put under load 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, 24 Jul 2008 20:42:08 -0000 > I feel for you John, I've lost many nights sleep in the last couple > weeks trying to understand why this production box was crashing. I > was really surprised to see this start happening, normally my freebsd > boxes have uptimes in terms of years, not hours. Thanks for the sentiment, at last I have been able to smile about =20 this problem - maybe we should start a support group ... I'll start =20 ... Hi, I'm John and I'm a failing sys admin, I haven't had a panic =20 for 2 hours now and I'm taking it just 1 tick at a time ;-) Just to share with the group, I had an email from Kris off of the list =20 that made a lot of sense. I'm beginning to agree with him that it is =20 probably a hardware issue. I'll go quiet now and spend some money on =20 different hardware. For anyone who finds this thread on Google, I can =20 only echo Michael's comments - the thing that makes these panics so =20 infuriating is that even with dodgy old hardware FreeBSD has always =20 proven to be a very stable OS for me and as you can see, the community =20 is always willing to help. Thanks to all that have spent time on this issue for me. John ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 20:49:54 2008 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 44C66106566C for ; Thu, 24 Jul 2008 20:49:54 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F61C8FC1F for ; Thu, 24 Jul 2008 20:49:53 +0000 (UTC) (envelope-from sven@dmv.com) Received: from [216.240.97.46] (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id m6OKKkN0049867 for ; Thu, 24 Jul 2008 16:20:46 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: stable@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kC4EcY14/3M6hMo0ky2x" Date: Thu, 24 Jul 2008 16:20:46 -0400 Message-Id: <1216930846.6489.21.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Cc: Subject: CARP state changes and devd.conf 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, 24 Jul 2008 20:49:54 -0000 --=-kC4EcY14/3M6hMo0ky2x Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I see mention of CARP as a device-type in the devd.conf documentation but for the life of me cannot manage to get devd to recognize *any* changes in the CARP interface. I have set sysctl net.inet.carp.log=3D2 and I see message in /var/log/messages when the interface goes INIT->BACKUP and BACKUP -> MASTER, but for the life of me cannot get devd to "see" these changes. I have tried something even as simple as: notify 100 { action "logger -p kern.notice '$device-name interface has changed'"; }; and then bringing the CARP interfaces up and down on either boxes to change INIT and BACKUP/MASTER states, but *nothing* is noted. Does CARP simply not work that way with devd (i.e. only the creation of the CARP device, not any subsequent states, work )? Sven --=-kC4EcY14/3M6hMo0ky2x Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBIiOQeSnmnd8q3JGsRAi4+AJwPeO73vkU4eVE15tfWJ2DM5SnoWACgh/1P YsRoTmxWVtrzqTY/KxzhuCA= =8Bdm -----END PGP SIGNATURE----- --=-kC4EcY14/3M6hMo0ky2x-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:46:37 2008 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 AA5501065674 for ; Fri, 25 Jul 2008 07:46:36 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF028FC1D for ; Fri, 25 Jul 2008 07:46:35 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2388089fgb.35 for ; Fri, 25 Jul 2008 00:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=/S2A1ihMJ2F6KH3NBQGlDaDx0FC6A2NRYnClAgg8ySI=; b=GHSfAH5mfRAOdAV4vHgnlmJHWCxe36fubshyBriPGIKRjCTUnhRrW0u6gOOczfjoGz ebIiOKdIR0FaZ69bIrQO55WH8igjYADBISKqYIPPBBC5ZcMM1kOHJRvRFNB52NGRBRP2 Sl0BRuvLxrwwzo7DqGCgXdwyHQ1f9csYccJzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Q+MZmRRRJjFKqjqKfunJl2SbMNszLeaZp0Ox6PMrqM4Prs0afSPTGXey8x99+4f8cO FqeADPicgqavDbzV4K9mel5/iBseOngNFO1HK1m/fk1Y2PVv0osC1gSN3nYurNgRyGrU P+x1vVMNpQD1GUyNo8EQ6TUFOwL7zKq57fPOE= Received: by 10.86.4.14 with SMTP id 14mr1715781fgd.20.1216971994147; Fri, 25 Jul 2008 00:46:34 -0700 (PDT) Received: by 10.86.79.5 with HTTP; Fri, 25 Jul 2008 00:46:34 -0700 (PDT) Message-ID: Date: Fri, 25 Jul 2008 09:46:34 +0200 From: "Claus Guttesen" To: "FreeBSD Stable" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: zfs, raidz, spare and jbod 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, 25 Jul 2008 07:46:37 -0000 Hi. I installed FreeBSD 7 a few days ago and upgraded to the latest stable release using GENERIC kernel. I also added these entries to /boot/loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.prefetch_disable=1 Initially prefetch was enabled and I would experience hangs but after disabling prefetch copying large amounts of data would go along without problems. To see if FreeBSD 8 (current) had better (copy) performance I upgraded to current as of yesterday. After upgrading and rebooting the server responded fine. The server is a supermicro with a quad-core harpertown e5405 with two internal sata-drives and 8 GB of ram. I installed an areca arc-1680 sas-controller and configured it in jbod-mode. I attached an external sas-cabinet with 16 sas-disks at 1 TB (931 binary GB). I created a raidz2 pool with 10 disks and added one spare. I copied approx. 1 TB of small files (each approx. 1 MB) and during the copy I simulated a disk-crash by pulling one of the disks out of the cabinet. Zfs did not activate the spare and the copying stopped until I rebooted after 5-10 minutes. When I performed a 'zpool status' the command would not complete. I did not see any messages in /var/log/message. State in top showed 'ufs-'. A similar test on solaris express developer edition b79 activated the spare after zfs tried to write to the missing disk enough times and then marked it as faulted. Has any one else tried to simulate a disk-crash in raidz(2) and succeeded? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 09:18:41 2008 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 387551065672 for ; Fri, 25 Jul 2008 09:18:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 710DB8FC16; Fri, 25 Jul 2008 09:18:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48899A71.4040508@FreeBSD.org> Date: Fri, 25 Jul 2008 11:18:41 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Claus Guttesen References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: zfs, raidz, spare and jbod 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, 25 Jul 2008 09:18:41 -0000 Claus Guttesen wrote: > Hi. > > I installed FreeBSD 7 a few days ago and upgraded to the latest stable > release using GENERIC kernel. I also added these entries to > /boot/loader.conf: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > vfs.zfs.prefetch_disable=1 > > Initially prefetch was enabled and I would experience hangs but after > disabling prefetch copying large amounts of data would go along > without problems. To see if FreeBSD 8 (current) had better (copy) > performance I upgraded to current as of yesterday. After upgrading and > rebooting the server responded fine. > > The server is a supermicro with a quad-core harpertown e5405 with two > internal sata-drives and 8 GB of ram. I installed an areca arc-1680 > sas-controller and configured it in jbod-mode. I attached an external > sas-cabinet with 16 sas-disks at 1 TB (931 binary GB). > > I created a raidz2 pool with 10 disks and added one spare. I copied > approx. 1 TB of small files (each approx. 1 MB) and during the copy I > simulated a disk-crash by pulling one of the disks out of the cabinet. > Zfs did not activate the spare and the copying stopped until I > rebooted after 5-10 minutes. When I performed a 'zpool status' the > command would not complete. I did not see any messages in > /var/log/message. State in top showed 'ufs-'. That means that it was UFS that hung, not ZFS. What was the process backtrace, and what role does UFS play on this system? Kris > A similar test on solaris express developer edition b79 activated the > spare after zfs tried to write to the missing disk enough times and > then marked it as faulted. Has any one else tried to simulate a > disk-crash in raidz(2) and succeeded? > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 09:24:49 2008 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 ED9B91065675 for ; Fri, 25 Jul 2008 09:24:49 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB4E8FC0A for ; Fri, 25 Jul 2008 09:24:49 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2422073fgb.35 for ; Fri, 25 Jul 2008 02:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qtGC4cbMMy/sSeT6hmm0Ihz8fSPxZLbt+1zQmQYb+14=; b=Nc4KUBNiAxvQ66BKhAQ1GCJw3i78uRJnpBWRFfGoME6Tbijlhqib0qP7P+XvMR8A5P 3ozg0ZLz1kzO4Dgm4MzVJQAesz6pMg3ncpXFzyGBtrGLBE+zyh5G0o5yfyXBODMAuiuY rljdCJVX/l5jzTBqk9kmnXCc00SrMs546dVyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eZyF8uZAI6Mhj7reCqFXUO+Vqtl72TDrpUwzN+ppQ+vY3L6m39KiT9F92nJrfK7YgE +bbuPv6Lrw9HchuC9sp1bPe1l+uetRwy3+brb+t8wsGhagE8Eq3hpFUd60aa9abwVZmJ BrsR50/BWRE45xhfurujdWQ0oLAMvPG0xIkBw= Received: by 10.86.51.10 with SMTP id y10mr1800221fgy.6.1216977888030; Fri, 25 Jul 2008 02:24:48 -0700 (PDT) Received: by 10.86.79.5 with HTTP; Fri, 25 Jul 2008 02:24:47 -0700 (PDT) Message-ID: Date: Fri, 25 Jul 2008 11:24:47 +0200 From: "Claus Guttesen" To: "Kris Kennaway" In-Reply-To: <48899A71.4040508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48899A71.4040508@FreeBSD.org> Cc: FreeBSD Stable Subject: Re: zfs, raidz, spare and jbod 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, 25 Jul 2008 09:24:50 -0000 >> >> I installed FreeBSD 7 a few days ago and upgraded to the latest stable >> release using GENERIC kernel. I also added these entries to >> /boot/loader.conf: >> >> vm.kmem_size="1536M" >> vm.kmem_size_max="1536M" >> vfs.zfs.prefetch_disable=1 >> >> Initially prefetch was enabled and I would experience hangs but after >> disabling prefetch copying large amounts of data would go along >> without problems. To see if FreeBSD 8 (current) had better (copy) >> performance I upgraded to current as of yesterday. After upgrading and >> rebooting the server responded fine. >> >> The server is a supermicro with a quad-core harpertown e5405 with two >> internal sata-drives and 8 GB of ram. I installed an areca arc-1680 >> sas-controller and configured it in jbod-mode. I attached an external >> sas-cabinet with 16 sas-disks at 1 TB (931 binary GB). >> >> I created a raidz2 pool with 10 disks and added one spare. I copied >> approx. 1 TB of small files (each approx. 1 MB) and during the copy I >> simulated a disk-crash by pulling one of the disks out of the cabinet. >> Zfs did not activate the spare and the copying stopped until I >> rebooted after 5-10 minutes. When I performed a 'zpool status' the >> command would not complete. I did not see any messages in >> /var/log/message. State in top showed 'ufs-'. > > That means that it was UFS that hung, not ZFS. What was the process > backtrace, and what role does UFS play on this system? Arghh.. Typo, I meant 'zfs-'. Pardon. My boot-disk is plain ufs2 but the disk I pulled out was in the raidz2-pool. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 09:45:16 2008 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 72BA4106566B for ; Fri, 25 Jul 2008 09:45:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 485068FC12 for ; Fri, 25 Jul 2008 09:45:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 1D47E1CC0B3; Fri, 25 Jul 2008 02:45:16 -0700 (PDT) Date: Fri, 25 Jul 2008 02:45:16 -0700 From: Jeremy Chadwick To: Claus Guttesen Message-ID: <20080725094516.GA71385@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Stable Subject: Re: zfs, raidz, spare and jbod 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, 25 Jul 2008 09:45:16 -0000 On Fri, Jul 25, 2008 at 09:46:34AM +0200, Claus Guttesen wrote: > Hi. > > I installed FreeBSD 7 a few days ago and upgraded to the latest stable > release using GENERIC kernel. I also added these entries to > /boot/loader.conf: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > vfs.zfs.prefetch_disable=1 > > Initially prefetch was enabled and I would experience hangs but after > disabling prefetch copying large amounts of data would go along > without problems. To see if FreeBSD 8 (current) had better (copy) > performance I upgraded to current as of yesterday. After upgrading and > rebooting the server responded fine. With regards to RELENG_7, I completely agree with disabling prefetch. The overall performance (of the system and disk I/O) appears signicantly "smoother", e.g. less hard lock-ups and stalls, is better when prefetch is disabled. I have not tried CURRENT. I'm told the ZFS code in CURRENT is the same as RELENG_7, so I'm not sure what you were trying to test by switching from RELENG_7 to CURRENT. > The server is a supermicro with a quad-core harpertown e5405 with two > internal sata-drives and 8 GB of ram. I installed an areca arc-1680 > sas-controller and configured it in jbod-mode. I attached an external > sas-cabinet with 16 sas-disks at 1 TB (931 binary GB). > > I created a raidz2 pool with 10 disks and added one spare. I copied > approx. 1 TB of small files (each approx. 1 MB) and during the copy I > simulated a disk-crash by pulling one of the disks out of the cabinet. > Zfs did not activate the spare and the copying stopped until I > rebooted after 5-10 minutes. When I performed a 'zpool status' the > command would not complete. I did not see any messages in > /var/log/message. State in top showed 'ufs-'. > > A similar test on solaris express developer edition b79 activated the > spare after zfs tried to write to the missing disk enough times and > then marked it as faulted. Has any one else tried to simulate a > disk-crash in raidz(2) and succeeded? Is there any way to confirm the behaviour is specific to raidz2, or would it affect raidz1 as well? I have a raidz1 pool at home (3 disks though; pulling one will probably result in bad things) which I can pull a disk from, though it's off of an ICHx controller. I have no experience with Areca controllers or their driver, but I do have experience with standard onboard Intel ICHx chips. WRT those chips, "pulling disks" without administratively downing the ATA channel will cause a kernel panic. If the Areca controller/driver handles things better, great. I'm trying to say that I can offer to help with raidz1, but not on Areca controllers. The hardware is similar to yours; Supermicro PDSMi+, Intel E6600 (C2D), 4GB RAM, running RELENG_7 amd64. System contains 4 disks, ad6,8,10 are in a ZFS pool, ad4 is the OS disk: ad4: 190782MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA300 ad8: 476940MB at ata4-master SATA300 ad10: 476940MB at ata5-master SATA300 NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 -- | Jeremy Chadwick jdc at 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 Fri Jul 25 09:58:55 2008 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 347B21065674; Fri, 25 Jul 2008 09:58:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 756658FC16; Fri, 25 Jul 2008 09:58:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4889A3DD.8030801@FreeBSD.org> Date: Fri, 25 Jul 2008 11:58:53 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Jeremy Chadwick References: <20080725094516.GA71385@eos.sc1.parodius.com> In-Reply-To: <20080725094516.GA71385@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Claus Guttesen Subject: Re: zfs, raidz, spare and jbod 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, 25 Jul 2008 09:58:55 -0000 Jeremy Chadwick wrote: > On Fri, Jul 25, 2008 at 09:46:34AM +0200, Claus Guttesen wrote: >> Hi. >> >> I installed FreeBSD 7 a few days ago and upgraded to the latest stable >> release using GENERIC kernel. I also added these entries to >> /boot/loader.conf: >> >> vm.kmem_size="1536M" >> vm.kmem_size_max="1536M" >> vfs.zfs.prefetch_disable=1 >> >> Initially prefetch was enabled and I would experience hangs but after >> disabling prefetch copying large amounts of data would go along >> without problems. To see if FreeBSD 8 (current) had better (copy) >> performance I upgraded to current as of yesterday. After upgrading and >> rebooting the server responded fine. > > With regards to RELENG_7, I completely agree with disabling prefetch. > The overall performance (of the system and disk I/O) appears signicantly > "smoother", e.g. less hard lock-ups and stalls, is better when prefetch > is disabled. FYI I do not get "lock-ups" when running with prefetch. It is supposed to just affect performance, i.e. if you have few disks or they have low bandwidth or high seek times (e.g. crappy ATA) then it can saturate them and you will have poor response times. However if your hardware is more capable then it is a performance optimization. Someone needs to obtain the usual debugging information. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 20:06:29 2008 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 063CC1065673 for ; Fri, 25 Jul 2008 20:06:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E22788FC12 for ; Fri, 25 Jul 2008 20:06:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PJqAsG062230; Fri, 25 Jul 2008 15:52:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PJqAhJ061397; Fri, 25 Jul 2008 15:52:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 77F381B5078; Fri, 25 Jul 2008 15:52:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080725195210.77F381B5078@freebsd-stable.sentex.ca> Date: Fri, 25 Jul 2008 15:52:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7824/Thu Jul 24 21:48:33 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 20:06:29 -0000 TB --- 2008-07-25 18:36:41 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-25 18:36:41 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-07-25 18:36:41 - cleaning the object tree TB --- 2008-07-25 18:37:00 - cvsupping the source tree TB --- 2008-07-25 18:37:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-07-25 18:37:10 - building world (CFLAGS=-O2 -pipe) TB --- 2008-07-25 18:37:10 - cd /src TB --- 2008-07-25 18:37:10 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 25 18:37:11 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jul 25 19:42:06 UTC 2008 TB --- 2008-07-25 19:42:06 - generating LINT kernel config TB --- 2008-07-25 19:42:06 - cd /src/sys/i386/conf TB --- 2008-07-25 19:42:06 - /usr/bin/make -B LINT TB --- 2008-07-25 19:42:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-07-25 19:42:06 - cd /src TB --- 2008-07-25 19:42:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 25 19:42:06 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:928: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:939: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:948: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:950: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:953: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:956: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-25 19:52:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-25 19:52:10 - ERROR: failed to build lint kernel TB --- 2008-07-25 19:52:10 - tinderbox aborted TB --- 3718.28 user 390.68 system 4529.15 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 20:54:33 2008 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 9A9F81065675 for ; Fri, 25 Jul 2008 20:54:33 +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 3B1F88FC17 for ; Fri, 25 Jul 2008 20:54:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 27117 invoked by uid 399); 25 Jul 2008 20:54:32 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Jul 2008 20:54:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <488A3D86.8030808@FreeBSD.org> Date: Fri, 25 Jul 2008 13:54:30 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Brett Glass References: <20080721202418.7CF9B4500E@ptavv.es.net> <200807212219.QAA01486@lariat.net> In-Reply-To: <200807212219.QAA01486@lariat.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit 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, 25 Jul 2008 20:54:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Brett Glass wrote: | At 02:24 PM 7/21/2008, Kevin Oberman wrote: | |> Don't forget that ANY server that caches data, including an end |> system running a caching only server is vulnerable. | | Actually, there is an exception to this. A "forward only" | cache/resolver is only as vulnerable as its forwarder(s). This is a | workaround for the vulnerability for folks who have systems that | they cannot easily upgrade: point at a trusted forwarder that's | patched. This is true only so long as you have ZERO untrusted users on the network with the name server doing the forwarding. Given the incredibly huge number of windows boxes that have been trojaned, your threshold for measuring untrusted users needs to be really really low. The reason a forwarder is still vulnerable is that the attack has to do with response forgery. It would actually be _easier_ to poison a forwarder since all of the queries are going to/from known IP addresses. My point once again being, patch sooner rather than later, especially given that there are now exploits in the wild AND reports of actual systems being attacked. Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkiKPYYACgkQyIakK9Wy8Psp1gCgmFLRqVI7NEGMXUBPr4Cyd0BM wfEAnAtfIlndk9FfpVQGjClxHWAw3HHt =enmE -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 21:05:43 2008 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 ABC311065678; Fri, 25 Jul 2008 21:05:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 72F948FC1C; Fri, 25 Jul 2008 21:05:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PL5dqt074719; Fri, 25 Jul 2008 17:05:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PL5d47017036; Fri, 25 Jul 2008 17:05:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 5F5491B5078; Fri, 25 Jul 2008 17:05:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080725210539.5F5491B5078@freebsd-stable.sentex.ca> Date: Fri, 25 Jul 2008 17:05:39 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7824/Thu Jul 24 21:48:33 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 21:05:43 -0000 TB --- 2008-07-25 19:52:10 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-25 19:52:10 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-07-25 19:52:10 - cleaning the object tree TB --- 2008-07-25 19:52:33 - cvsupping the source tree TB --- 2008-07-25 19:52:33 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-07-25 19:52:42 - building world (CFLAGS=-O2 -pipe) TB --- 2008-07-25 19:52:42 - cd /src TB --- 2008-07-25 19:52:42 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 25 19:52:43 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jul 25 20:57:32 UTC 2008 TB --- 2008-07-25 20:57:32 - generating LINT kernel config TB --- 2008-07-25 20:57:32 - cd /src/sys/pc98/conf TB --- 2008-07-25 20:57:32 - /usr/bin/make -B LINT TB --- 2008-07-25 20:57:33 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-07-25 20:57:33 - cd /src TB --- 2008-07-25 20:57:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 25 20:57:33 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:928: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:939: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:948: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:950: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:953: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:956: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-25 21:05:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-25 21:05:39 - ERROR: failed to build lint kernel TB --- 2008-07-25 21:05:39 - tinderbox aborted TB --- 3591.30 user 387.79 system 4408.59 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 21:38:08 2008 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 126681065670; Fri, 25 Jul 2008 21:38:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E2D848FC1B; Fri, 25 Jul 2008 21:38:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PLc5pe079217; Fri, 25 Jul 2008 17:38:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PLc5Ki036544; Fri, 25 Jul 2008 17:38:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id D4CE91B5078; Fri, 25 Jul 2008 17:38:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080725213804.D4CE91B5078@freebsd-stable.sentex.ca> Date: Fri, 25 Jul 2008 17:38:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7824/Thu Jul 24 21:48:33 2008 clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 21:38:08 -0000 TB --- 2008-07-25 19:59:12 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-25 19:59:12 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2008-07-25 19:59:12 - cleaning the object tree TB --- 2008-07-25 19:59:28 - cvsupping the source tree TB --- 2008-07-25 19:59:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2008-07-25 19:59:35 - building world (CFLAGS=-O2 -pipe) TB --- 2008-07-25 19:59:35 - cd /src TB --- 2008-07-25 19:59:35 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 25 19:59:36 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jul 25 21:27:20 UTC 2008 TB --- 2008-07-25 21:27:20 - generating LINT kernel config TB --- 2008-07-25 21:27:20 - cd /src/sys/ia64/conf TB --- 2008-07-25 21:27:20 - /usr/bin/make -B LINT TB --- 2008-07-25 21:27:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-07-25 21:27:20 - cd /src TB --- 2008-07-25 21:27:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 25 21:27:20 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:925: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:928: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:939: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:948: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:950: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:953: error: dereferencing pointer to incomplete type /src/sys/kern/kern_cpuset.c:956: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-25 21:38:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-25 21:38:04 - ERROR: failed to build lint kernel TB --- 2008-07-25 21:38:04 - tinderbox aborted TB --- 5009.88 user 392.62 system 5932.12 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 22:04:07 2008 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 7D090106567A for ; Sat, 26 Jul 2008 22:04:07 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7628FC16 for ; Sat, 26 Jul 2008 22:04:06 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so90981uge.37 for ; Sat, 26 Jul 2008 15:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IhEwesOfaPpIYCWJ7mezXON4KttzljZQMUCmos/u6yQ=; b=lPVKapKfIFJh5s0gn9bdvlMEDiUK0xAHiDE0DPgRgtgqeWEI+mLNlGky+mNsZTQfFv u3375To0Suyq6rwQuHHCW0nTl7edaQP81+hJ1g47NsTCgX0N4+niLn0FUMnZKXkc7wT6 MCih7qCHUGmWNQTYFBoYO0HYOmMyWHcsWS/nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uLsZFDl3p+UFcojpjGwveP0eyaz/284p3HjV6IvKMr5kk51Rc7s1JrRkTAUaw4w2PH av9C6NpTf5Et97VPWdfUbJ1NeFrGY2+eTytnvxNl0FaJMqttlOWJSwWm7Hid3wgjKAfi yOHCNrT7WWRpAbbnUNBk3IEMB6hSAMq66V7k4= Received: by 10.67.101.17 with SMTP id d17mr1034256ugm.40.1217109845504; Sat, 26 Jul 2008 15:04:05 -0700 (PDT) Received: by 10.66.234.1 with HTTP; Sat, 26 Jul 2008 15:04:05 -0700 (PDT) Message-ID: Date: Sat, 26 Jul 2008 19:04:05 -0300 From: "Carlos A. M. dos Santos" To: Volker In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <482F31E7.7080000@vwsoft.com> Cc: FreeBSD Stable , bug-followup@freebsd.org Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error 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, 26 Jul 2008 22:04:07 -0000 On Mon, May 26, 2008 at 1:21 AM, Carlos A. M. dos Santos wrote: > On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos > wrote: >> On Sat, May 17, 2008 at 4:28 PM, Volker wrote: >>> Carlos, >>> >>> IMHO it's better to explicitly check for ioctl returning EBUSY and 5 >>> seconds may not fit every situation. >>> >>> Volker >> >> Ok, I will attempt the approach of checking for EBUSY. > > I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems > that there is no better solution. I was able to improve the delays, > however (see attachmet). Now they grow exponentially, limited to 31 > seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD > drive with one eject request per second. Any update on this issue? I'd suggest you to at least close the PR if the proposed patch is not acceptable. I must admit that it is only a tricky workaround, not a masterpiece, so I will not feel offended. :-) -- If you think things can't get worse it's probably only because you lack sufficient imagination.