From owner-freebsd-stable@FreeBSD.ORG Sun Aug 17 16:06: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 AE1081065673 for ; Sun, 17 Aug 2008 16:06:20 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.freebsd.org (Postfix) with ESMTP id 75AF48FC1D for ; Sun, 17 Aug 2008 16:06:20 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1602908wfg.7 for ; Sun, 17 Aug 2008 09:06: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=5RJvakbqAASyYNpQSkql1zV1Xi0D9jld5+zIoNm845I=; b=c528XmV8/Zot9wW2h9gMJbjjeiPB3Okkvfvz853jNCkSA4Y4lF0sPUR4ZPsy55ZFou tZljqRaa5W6jkLX4oY/ctDrg/3KaUhjuuRfYDyvOMbuAjT3co8yGGXbMVRU9O3y0H7wV 4OK7QzObCkGqVuWJXYDDxCbNYbFCNM2nuPtbA= 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=igkDmx2bm48AlKWUz/i5LoTl3kaRKD+fRQdMer5FbPtTwtQP5hdLjBJDMeAD0HwSip yhTBIWjj+hMU8sLvRh8gnqtkzrUi12Zpv6g8yhtEZFwhLmVnTGIOUElzsG89QoaALYqF GbfxQFrj5dwIpGnajsyyVw+0fJhfxzFt0+F08= Received: by 10.143.18.21 with SMTP id v21mr1725329wfi.185.1218989180220; Sun, 17 Aug 2008 09:06:20 -0700 (PDT) Received: by 10.142.204.17 with HTTP; Sun, 17 Aug 2008 09:06:20 -0700 (PDT) Message-ID: <47d0403c0808170906h22f11a03h524a5a50367d46a7@mail.gmail.com> Date: Sun, 17 Aug 2008 12:06:20 -0400 From: "Ben Kaduk" To: freebsd@hub.org In-Reply-To: <20080815235546.65415dg5hblf1oxu@webmail.hub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080301073329.GA1081@Alex1.kruijff.org> <47C93FD2.1010902@FreeBSD.org> <20080815235546.65415dg5hblf1oxu@webmail.hub.org> Cc: freebsd-stable@freebsd.org Subject: Re: Very large kernel 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, 17 Aug 2008 16:06:20 -0000 On Fri, Aug 15, 2008 at 7:55 PM, wrote: > Quoting "Kris Kennaway" : > >> Alex de Kruijff wrote: >>> >>> I noticed that the kernel directory was very large compaired to 6.1. Is >>> this for debugging and can I safely remove the symbols files I want to >>> save some space? >> >> Yes but if you encounter a panic and need to submit a bug report then you >> will need at least the kernel.debug and whatever modules you are using. > > Two questions for this ... > > a. can I move these to a larger partition temporarily, and if I have a > crash, move them back to do debugging? Yes. > > b. is there some setting I can use in make.conf to have it auto-install the > symbols files to a seperate directory on 'installkernel'? > I don't know of one, but that sounds like it could be useful. -Ben Kaduk From owner-freebsd-stable@FreeBSD.ORG Sun Aug 17 16:11: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 4319F1065684; Sun, 17 Aug 2008 16:11:32 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id B05E08FC28; Sun, 17 Aug 2008 16:11:31 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m7HGBSwp078959; Sun, 17 Aug 2008 20:11:28 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 17 Aug 2008 20:11:28 +0400 (MSD) From: Dmitry Morozovsky To: freebsd@hub.org In-Reply-To: <20080815235546.65415dg5hblf1oxu@webmail.hub.org> Message-ID: <20080817201018.G74207@woozle.rinet.ru> References: <20080301073329.GA1081@Alex1.kruijff.org> <47C93FD2.1010902@FreeBSD.org> <20080815235546.65415dg5hblf1oxu@webmail.hub.org> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Sun, 17 Aug 2008 20:11:28 +0400 (MSD) Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: Very large kernel 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, 17 Aug 2008 16:11:32 -0000 On Fri, 15 Aug 2008, freebsd@hub.org wrote: > > Alex de Kruijff wrote: > > > I noticed that the kernel directory was very large compaired to 6.1. Is > > > this for debugging and can I safely remove the symbols files I want to > > > save some space? > > > > Yes but if you encounter a panic and need to submit a bug report then you > > will need at least the kernel.debug and whatever modules you are using. > > Two questions for this ... > > a. can I move these to a larger partition temporarily, and if I have a crash, > move them back to do debugging? > > b. is there some setting I can use in make.conf to have it auto-install the > symbols files to a seperate directory on 'installkernel'? If you do not clean your /usr/obj regularly, you can simply use make installkernel KERNCONF=MYOWN INSTALL_NODEBUG= and later use .symbols files from /usr/obj/.../sys/MYOWN/* Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 07:45: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 4DEC4106564A for ; Mon, 18 Aug 2008 07:45:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C79728FC18 for ; Mon, 18 Aug 2008 07:45:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7I7jYuF058697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 17:15:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Eric Anholt Date: Mon, 18 Aug 2008 17:15:33 +0930 User-Agent: KMail/1.9.7 References: <200801152012.56683.doconnor@gsoft.com.au> <1200507078.1786.17.camel@localhost> <200801171556.39857.doconnor@gsoft.com.au> In-Reply-To: <200801171556.39857.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3026693.uX2afrzhli"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808181715.34390.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Fwd: FreeBSD 6.3 and Intel G33 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, 18 Aug 2008 07:45:42 -0000 --nextPart3026693.uX2afrzhli Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 17 Jan 2008, Daniel O'Connor wrote: > > DPMS should work with the VESA driver even, not to discourage you > > from the right solution. > > The X log file says DPMS is enabled but doing 'xset dpms force off' > doesn't do anything (although when you move the mouse or press a key > the whole display refreshes so it appears X thinks it's been off) I have found some more time & hardware to try and fix this problem.. I merged the AGP code from HEAD into my tree (and vga_pci.c) but I am=20 still getting "Couldn't bind memory for front buffer" from the ports=20 intel driver. I tried to build the GIT version but it wants libdrm 2.4.0 and ports=20 only has 2.3.0. It's CoB for today so I'll try installing that=20 tomorrow. If you have any input I'd be most appreciative :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3026693.uX2afrzhli Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIqSie5ZPcIHs/zowRAoxOAJ0WUzY33Vq32iOsch5WPJyq5VlwkQCfUCKR Qr2MV34JPPkGOi3U4EGW0/4= =Uwjg -----END PGP SIGNATURE----- --nextPart3026693.uX2afrzhli-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 07:46: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 5A39A1065681 for ; Mon, 18 Aug 2008 07:46:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id DCD088FC1D for ; Mon, 18 Aug 2008 07:46:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7I7kbCB058718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 17:16:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 18 Aug 2008 17:16:36 +0930 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1354758.hKlCqMBEdz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808181716.36906.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 07:46:40 -0000 --nextPart1354758.hKlCqMBEdz Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Does anyone have a G33 chipset system working in 7.x? I have a 6.3 install here and it isn't working with that so I have been=20 merging things from HEAD but it still doesn't work. It would be worth switching to 7.x if it worked there though :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1354758.hKlCqMBEdz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIqSjc5ZPcIHs/zowRAiLVAKCseGo35s0ayoarVPNuJGMVpiN9awCgoMe0 MF+xR4fEuSIBIU57P3iH77U= =4uIl -----END PGP SIGNATURE----- --nextPart1354758.hKlCqMBEdz-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 07:55: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 54F03106566C; Mon, 18 Aug 2008 07:55:40 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 16E798FC08; Mon, 18 Aug 2008 07:55:39 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id 5F7B25CCE; Mon, 18 Aug 2008 09:55:38 +0200 (CEST) Message-Id: <0681DEA1-93C8-4AEF-9D12-B95343E42299@SARENET.ES> From: Borja Marcos To: Tom Evans In-Reply-To: <1218641046.70002.6.camel@localhost> 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, 18 Aug 2008 09:56:05 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> <1218641046.70002.6.camel@localhost> X-Mailer: Apple Mail (2.928.1) Cc: Kris Kennaway , freebsd-stable@freebsd.org, Jeremy Chadwick , Ivan Voras Subject: Re: umtxn and Apache 2.2 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, 18 Aug 2008 07:55:40 -0000 On Aug 13, 2008, at 5:24 PM, Tom Evans wrote: > On Wed, 2008-08-13 at 16:56 +0200, Borja Marcos wrote: >> Personally, I find PHP far too troublesome to run threaded. These >> days, > I use an event MPM based front-end apache 2.2, which reverse proxies > to > either a prefork MPM apache 2.2 with mod_, or > directly connect to a fastcgi instance. Serve all your static content > from the front-end, and it's all quite fast - plus you can scale out > much much more simply. That's what I've done finally, using threaded Apache with mod_fcgid. I've seen that PHP is not ready to be used as a module in a multithreaded Apache. Now it's working great, and, indeed, the multithread Apache instances can serve all the static content (images, etc) blazingly fast. Thank you very much, Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 08:14:20 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 E473E106568A for ; Mon, 18 Aug 2008 08:14:20 +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 A34908FC2B for ; Mon, 18 Aug 2008 08:14:20 +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 1D61E46BA3 for ; Mon, 18 Aug 2008 04:14:20 -0400 (EDT) Date: Mon, 18 Aug 2008 09:14:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 08:14:21 -0000 On Sun, 3 Aug 2008, Robert Watson wrote: > This is an advance warning that, late next week, I will be merging a fairly > large set of changes to the IPv4 and IPv6 protocols layered over the > inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, > UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail > announcement along with patch set and schedule in a day or two once it's > prepared. FYI: This patch has now been committed to Subversion. I'll keep a close eye out for difficulties; if you run into issues, please send me an e-mail (and CC stable@). Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > The thrust of this change is to replace the mutexes protecting the inpcb and > inpcbinfo data structures with read-write locks (rwlocks). These structures > represent, respectively, particular sockets and the global socket lists for > all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, > inpcbinfo is the data structure referencing all connections, and each line in > the nestat output reflects the contents of a specific inpcb. > > In the current stage of this work, the intent is to improve performance for > datagram-related protocols on SMP systems by allowing concurrent acquisition > of both global and connection locks during receive and transmit. This is > possible because, in the common case, no connection or global state is > modified during UDP/raw receive and transmit at the IP layer, so a read lock > is sufficient to prevent data in those structures from unexpectedly changing. > For receive, socket layer state is modified, but this is separately protected > by socket layer locks. On transmit, no state is modified at any layer, so in > principle we will allow fully parallel transmit from multiple threads down to > about the routing and network interface layers, whereas previously they would > bottleneck in UDP. > > The applications targeted by this change are threaded UDP server > applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and > Paul Saab have done fairly extensive testing with the changes and > demonstrated significant performance improvements due to reduced contention > and overhead. Perhaps they can mention some of those numbers in a follow-up > to this post. > > The reason for the heads up is that, while carefully-tested, changes of this > sort do come with risks. We've carefully structured them so as to avoid > breaking the ABIs for netstat, etc, but it's not impossible that some > problems will arise as the changes settle. The goal, however, is to see > these performance improvements in 7.1, and since they've had a bit to shake > out in 8.x and seen some heavy use, I think now is the right time to merge > them. > > In any case, I will send out e-mail in a couple of days with a proposed merge > patch and schedule for merging, and perhaps if you are in a positition where > you might benefit from these improvements, or have interesting UDP or > raw-socket based applications running on 7.x, you could test the candidate > patch before it's merged, reporting any problems. Unless I receive negative > feedback, I will plan on merging the changes late in the week, and keep a > close eye on stable@ for any reports of problems. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 Aug 18 08:26: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 9EB611065671 for ; Mon, 18 Aug 2008 08:26:41 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 099518FC13 for ; Mon, 18 Aug 2008 08:26:40 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 4665D17222 for ; Mon, 18 Aug 2008 09:07:02 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id t1TBqMC1trF2 for ; Mon, 18 Aug 2008 09:06:57 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id 7CD7F17204 for ; Mon, 18 Aug 2008 09:06:57 +0100 (BST) Received: from dilbert.office.centralnic.com (office.centralnic.net [213.146.157.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id D9B3D171F9; Mon, 18 Aug 2008 09:06:56 +0100 (BST) Date: Mon, 18 Aug 2008 09:06:46 +0100 From: Oliver Peter To: "Daniel O'Connor" Message-ID: <20080818090646.421f7ecd@dilbert.office.centralnic.com> In-Reply-To: <200808181716.36906.doconnor@gsoft.com.au> References: <200808181716.36906.doconnor@gsoft.com.au> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@peter.de.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 08:26:41 -0000 On Mon, 18 Aug 2008 17:16:36 +0930 "Daniel O'Connor" wrote: > Does anyone have a G33 chipset system working in 7.x? I have a working Q35 chipset (which is using the same driver) under latest -STABLE. FreeBSD 7.0-STABLE #0: Sat Aug 16 17:36:46 BST 2008 > I have a 6.3 install here and it isn't working with that so I have > been merging things from HEAD but it still doesn't work. It has been in the source tree since 2007: http://en.wikipedia.org/wiki/Intel_GMA#FreeBSD http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html ... and was finally enabled in -STABLE about two weeks ago: http://lists.freebsd.org/pipermail/cvs-src/2008-August/093604.html dmesg[1] is attached. > It would be worth switching to 7.x if it worked there though :) It is worth it anyway! :-) (zfs, zfs, zfs...) Unfortunately, the drm module does not recognize my chipset (so I don't have DRI support under X.ORG) - could be a problem with my hardware. I would like to discuss that later this week on the list with more information. Cheers. [1] 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-STABLE #0: Sat Aug 9 22:33:30 BST 2008 root@delorean.geonosis.homeunix.org:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2407.11-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Logical CPUs per core: 4 usable memory = 4195328000 (4000 MB) avail memory = 4042981376 (3855 MB) ACPI APIC Table: 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: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2458-0x245f mem 0xe8200000-0xe827ffff,0xe0000000-0xe7ffffff,0xe8100000-0xe81fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 128M pci0: at device 3.0 (no driver attached) atapci0: port 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x2400-0x241f mem 0xe8280000-0xe829ffff,0xe82a4000-0xe82a4fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:19:d1:a5:03:a7 uhci0: port 0x20e0-0x20ff irq 18 at device 26.0 on pci0 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 0x20c0-0x20df irq 21 at device 26.1 on pci0 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 0x20a0-0x20bf irq 17 at device 26.2 on pci0 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 0xe82a6c00-0xe82a6fff irq 17 at device 26.7 on pci0 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 pci0: at device 27.0 (no driver attached) pcib2: at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 28.1 on pci0 pci3: on pcib3 pcib4: at device 28.2 on pci0 pci4: on pcib4 atapci1: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0xe8000000-0xe80001ff irq 18 at device 0.0 on pci4 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pcib5: at device 28.3 on pci0 pci5: on pcib5 pcib6: at device 28.4 on pci0 pci6: on pcib6 uhci3: port 0x2080-0x209f irq 23 at device 29.0 on pci0 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 0x2060-0x207f irq 19 at device 29.1 on pci0 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 0x2040-0x205f irq 18 at device 29.2 on pci0 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 0xe82a6800-0xe82a6bff irq 23 at device 29.7 on pci0 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 pcib7: at device 30.0 on pci0 pci7: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f mem 0xe82a6000-0xe82a67ff irq 21 at device 31.2 on pci0 atapci2: [ITHREAD] atapci2: AHCI called from vendor specific driver atapci2: AHCI Version 01.20 controller with 6 ports detected ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] ata9: on atapci2 ata9: [ITHREAD] ata10: on atapci2 ata10: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 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 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 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 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 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cryptosoft0: on motherboard atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub5 ums0: 3 buttons and Z dir. ukbd0: on uhub6 kbd2 at ukbd0 uhid0: on uhub6 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 6 ZFS storage pool version 6 ad12: 381554MB at ata6-master SATA300 ad20: 381554MB at ata10-master SATA300 ar0: 381551MB status: READY ar0: disk0 READY (master) using ad12 at ata6-master ar0: disk1 READY (mirror) using ad20 at ata10-master SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from zfs:tank -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 08: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 6C4731065677 for ; Mon, 18 Aug 2008 08:29:57 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 17CAE8FC1E for ; Mon, 18 Aug 2008 08:29:56 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id CBD7324D26; Mon, 18 Aug 2008 10:04:30 +0200 (SAST) Date: Mon, 18 Aug 2008 10:04:30 +0200 From: Aragon Gouveia To: Daniel O'Connor Message-ID: <20080818080430.GA18376@phat.za.net> References: <200808181716.36906.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808181716.36906.doconnor@gsoft.com.au> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 08:29:57 -0000 | By Daniel O'Connor | [ 2008-08-18 09:47 +0200 ] > Does anyone have a G33 chipset system working in 7.x? > > I have a 6.3 install here and it isn't working with that so I have been > merging things from HEAD but it still doesn't work. > > It would be worth switching to 7.x if it worked there though :) I'm using an Intel branded G33 board with 7.0-STABLE. Works better than the MSI G33 board I tried first... 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-STABLE #5: Thu May 15 21:13:01 SAST 2008 root@igor.geek.sh:/usr/obj/usr/src/sys/IGOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3185.32-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 8509808640 (8115 MB) avail memory = 8225095680 (7844 MB) ACPI APIC Table: Regards, Aragon From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 09:16: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 54B21106567A for ; Mon, 18 Aug 2008 09:16:15 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AC4F78FC21 for ; Mon, 18 Aug 2008 09:16:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-88-193.lns10.adl6.internode.on.net [121.45.88.193]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7I9GBR6061566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 18:46:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Aragon Gouveia Date: Mon, 18 Aug 2008 18:46:08 +0930 User-Agent: KMail/1.9.7 References: <200808181716.36906.doconnor@gsoft.com.au> <20080818080430.GA18376@phat.za.net> In-Reply-To: <20080818080430.GA18376@phat.za.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1416071.8p5lxsaIcG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808181846.09160.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 09:16:15 -0000 --nextPart1416071.8p5lxsaIcG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 18 Aug 2008, Aragon Gouveia wrote: > | By Daniel O'Connor > | [ 2008-08-18 09:47 +0200 ] > | > > Does anyone have a G33 chipset system working in 7.x? > > > > I have a 6.3 install here and it isn't working with that so I have > > been merging things from HEAD but it still doesn't work. > > > > It would be worth switching to 7.x if it worked there though :) > > I'm using an Intel branded G33 board with 7.0-STABLE. Works better > than the MSI G33 board I tried first... > > 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-STABLE #5: Thu May 15 21:13:01 SAST 2008 > root@igor.geek.sh:/usr/obj/usr/src/sys/IGOR > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3185.32-MHz > K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Stepping =3D 6 > Features=3D0xbfebfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PB >E> > Features2=3D0x8e3fdPR,PDCM,> AMD Features=3D0x20100800 > AMD Features2=3D0x1 > Cores per package: 2 > usable memory =3D 8509808640 (8115 MB) > avail memory =3D 8225095680 (7844 MB) > ACPI APIC Table: Guh sorry, I just realised that I asked the wrong question :-) Does anyone have a G33 onboard video working with FreeBSD with anything=20 better than VESA? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1416071.8p5lxsaIcG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIqT3Z5ZPcIHs/zowRAgE5AKCGsG4lzTsMYD4B78kWqoSCCzgSSwCeN8C6 z8HcyTRP3U/uDoNyi3q6/bU= =D2eQ -----END PGP SIGNATURE----- --nextPart1416071.8p5lxsaIcG-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 09:18: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 F03391065675 for ; Mon, 18 Aug 2008 09:18:20 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 883EA8FC25 for ; Mon, 18 Aug 2008 09:18:20 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by nf-out-0910.google.com with SMTP id h3so1344021nfh.33 for ; Mon, 18 Aug 2008 02:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=GakMyHhfWrughgxPBx0lUw9Rb2P11rzgJ73PeTBFeUk=; b=HweaUfNAwcxf6UG7ZdZg1q0QZmZkw0FQ2ECQi8vJ6C23Me7irJGMbaYDm5qwypX4/Z 5BuTuHeonH+r4iQ2NTc/4w4wA/uCsNMMXQOugBZLg+2IxxVVVqsWRJzOVwZwMb1vNn9v tzWIydtdnsLIOWovSAQcaxnYTqIAtzPsZj9CE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=bNGTZb4Jc417+uLRXk7UApYd9zf/0/nFJ5sNrol23yrUUS9CmFbjUCJB28V3XWa0nm QQ8jHLHnfT/k5qgSPxXsUytTnOmKceT8R7ABlhZK6k66XD5M9rHYm1M15AabGSvL1gvH zkd86zUaom1P5lav8l4CSvbsoe3QYIh0vyZpw= Received: by 10.210.30.10 with SMTP id d10mr678844ebd.6.1219051099283; Mon, 18 Aug 2008 02:18:19 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id g11sm25016595gve.8.2008.08.18.02.18.16 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Aug 2008 02:18:18 -0700 (PDT) From: Tom Evans To: lists@peter.de.com In-Reply-To: <20080818090646.421f7ecd@dilbert.office.centralnic.com> References: <200808181716.36906.doconnor@gsoft.com.au> <20080818090646.421f7ecd@dilbert.office.centralnic.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OzNDEQGz9nMfR5IKsHme" Date: Mon, 18 Aug 2008 10:18:14 +0100 Message-Id: <1219051094.70002.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 09:18:21 -0000 --=-OzNDEQGz9nMfR5IKsHme Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > On Mon, 18 Aug 2008 17:16:36 +0930 > "Daniel O'Connor" wrote: >=20 > > Does anyone have a G33 chipset system working in 7.x? > ... > Unfortunately, the drm module does not recognize my chipset > (so I don't have DRI support under X.ORG) - could be a problem with > my hardware. I would like to discuss that later this week on the > list with more information. >=20 > Cheers. Robert Noland posted last Wednesday on x11@ [1] that he had prepared an update to FreeBSD's drm kernel modules, which includes support for the G33 [2]. Cheers Tom [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D36408+0 +archive/2008/freebsd-x11/20080817.freebsd-x11 [2] http://people.freebsd.org/~rnoland --=-OzNDEQGz9nMfR5IKsHme Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkipPlAACgkQlcRvFfyds/eI+QCgvnbiv5wH0NilvSgul13fWEMe jNkAn1SdLL4gGDUao8QAwUye9BPr2i71 =mnj8 -----END PGP SIGNATURE----- --=-OzNDEQGz9nMfR5IKsHme-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 09:38: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 A95471065677 for ; Mon, 18 Aug 2008 09:38:17 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 690F28FC21 for ; Mon, 18 Aug 2008 09:38:17 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 68B581AE72 for ; Mon, 18 Aug 2008 10:38:25 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id e1IkrldI+uH4 for ; Mon, 18 Aug 2008 10:38:22 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id 73BC61AE1D for ; Mon, 18 Aug 2008 10:38:22 +0100 (BST) Received: from dilbert.office.centralnic.com (office.centralnic.net [213.146.157.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id E58CC1AE14; Mon, 18 Aug 2008 10:38:21 +0100 (BST) Date: Mon, 18 Aug 2008 10:38:11 +0100 From: Oliver Peter To: Tom Evans Message-ID: <20080818103811.3add121e@dilbert.office.centralnic.com> In-Reply-To: <1219051094.70002.52.camel@localhost> References: <200808181716.36906.doconnor@gsoft.com.au> <20080818090646.421f7ecd@dilbert.office.centralnic.com> <1219051094.70002.52.camel@localhost> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@peter.de.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 09:38:17 -0000 On Mon, 18 Aug 2008 10:18:14 +0100 Tom Evans wrote: > On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > [...] > > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > an update to FreeBSD's drm kernel modules, which includes support for > the G33 [2]. > > Cheers > > Tom > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 > +archive/2008/freebsd-x11/20080817.freebsd-x11 > [2] http://people.freebsd.org/~rnoland Excellent! I'll give it a try this evening and post some debug information here. Cheers. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 10:12:59 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 68F131065678 for ; Mon, 18 Aug 2008 10:12:59 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 294498FC18 for ; Mon, 18 Aug 2008 10:12:59 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 7A374130C39; Mon, 18 Aug 2008 11:56:25 +0200 (CEST) Date: Mon, 18 Aug 2008 11:56:25 +0200 From: Guido Falsi To: Daniel O'Connor Message-ID: <20080818095625.GA49772@megatron.madpilot.net> References: <200808181716.36906.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808181716.36906.doconnor@gsoft.com.au> X-Operating-System: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 10:12:59 -0000 On Mon, Aug 18, 2008 at 05:16:36PM +0930, Daniel O'Connor wrote: > Does anyone have a G33 chipset system working in 7.x? > > I have a 6.3 install here and it isn't working with that so I have been > merging things from HEAD but it still doesn't work. > > It would be worth switching to 7.x if it worked there though :) I'm using an HP DC7800, with a Q35 chip on it. It's working ok, and also drm should work on it. I still have a few error messages from Xorg whihc I could not diagnose, but they should be addressable. Had to uncomment some code in the kernel though. Look here: http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html my dmesg: vgapci0: port 0x1230-0x1237 mem 0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 10:22: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 4DE271065676 for ; Mon, 18 Aug 2008 10:22:31 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C0E9C8FC14 for ; Mon, 18 Aug 2008 10:22:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-88-193.lns10.adl6.internode.on.net [121.45.88.193]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7IAMSmn063319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 19:52:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Tom Evans Date: Mon, 18 Aug 2008 19:52:13 +0930 User-Agent: KMail/1.9.7 References: <200808181716.36906.doconnor@gsoft.com.au> <20080818090646.421f7ecd@dilbert.office.centralnic.com> <1219051094.70002.52.camel@localhost> In-Reply-To: <1219051094.70002.52.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2420618.zgJJPnUy99"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808181952.22994.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: lists@peter.de.com, freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 10:22:31 -0000 --nextPart2420618.zgJJPnUy99 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 18 Aug 2008, Tom Evans wrote: > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > an update to FreeBSD's drm kernel modules, which includes support for > the G33 [2]. Ahh excellent, thanks for the pointers! Something to try tomorrow :) > Cheers > > Tom > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D36408+0 > +archive/2008/freebsd-x11/20080817.freebsd-x11 > [2] http://people.freebsd.org/~rnoland =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2420618.zgJJPnUy99 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIqU1e5ZPcIHs/zowRApawAKCfYrqVGMNo8UiEJ4nTpuXxsn01sACgmWWR NwxYNaDWIzjo533Ij/a2wyw= =rwO8 -----END PGP SIGNATURE----- --nextPart2420618.zgJJPnUy99-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 10:32: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 EF01C106567A for ; Mon, 18 Aug 2008 10:32:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 53A3E8FC24 for ; Mon, 18 Aug 2008 10:32:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-88-193.lns10.adl6.internode.on.net [121.45.88.193]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7IAWKqd063988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2008 20:02:20 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: lists@peter.de.com Date: Mon, 18 Aug 2008 20:02:17 +0930 User-Agent: KMail/1.9.7 References: <200808181716.36906.doconnor@gsoft.com.au> <20080818090646.421f7ecd@dilbert.office.centralnic.com> In-Reply-To: <20080818090646.421f7ecd@dilbert.office.centralnic.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1958609.kL77P17sZk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808182002.18125.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 10:32:23 -0000 --nextPart1958609.kL77P17sZk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 18 Aug 2008, Oliver Peter wrote: > On Mon, 18 Aug 2008 17:16:36 +0930 > > "Daniel O'Connor" wrote: > > Does anyone have a G33 chipset system working in 7.x? > > I have a working Q35 chipset (which is using the same driver) > under latest -STABLE. > > FreeBSD 7.0-STABLE #0: Sat Aug 16 17:36:46 BST 2008 > > > I have a 6.3 install here and it isn't working with that so I have > > been merging things from HEAD but it still doesn't work. > > It has been in the source tree since 2007: > http://en.wikipedia.org/wiki/Intel_GMA#FreeBSD > http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html > > ... and was finally enabled in -STABLE about two weeks ago: > http://lists.freebsd.org/pipermail/cvs-src/2008-August/093604.html > > dmesg[1] is attached. Ta. I MFC'd the AGP driver although quite possibly I stuffed something up.=20 It does detect OK but X won't start with the ports intel driver. I tried the GIT one but I can't get that to compile due to an old libdrm=20 in ports :( > > It would be worth switching to 7.x if it worked there though :) > > It is worth it anyway! :-) (zfs, zfs, zfs...) :) > Unfortunately, the drm module does not recognize my chipset > (so I don't have DRI support under X.ORG) - could be a problem with > my hardware. I would like to discuss that later this week on the > list with more information. I'd be very happy with accelerated 2D at this stage :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1958609.kL77P17sZk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIqU+y5ZPcIHs/zowRAp2XAJ459fbqamJGTuD8gUiep3IoUol/NwCghPJW c+JqUK62wdqL7a7cAVNad4I= =EdeK -----END PGP SIGNATURE----- --nextPart1958609.kL77P17sZk-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 13:34: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 D21931065684 for ; Mon, 18 Aug 2008 13:34:44 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 927F18FC1D for ; Mon, 18 Aug 2008 13:34:44 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by gxk10 with SMTP id 10so4136590gxk.19 for ; Mon, 18 Aug 2008 06:34:43 -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=EdSH+BxgddfTK5H9NLzNjNinwOAh3IIS9j8lJRxkSCQ=; b=qpapYg11Ns0eh/fvz8yCNnhSL/6e70BVcnX1/o+WZc9kwebQANCcdKRYpsoqnq6Zj6 fXsZh1jLhgjOUmNv81fLr6BTP36VQKVj2Tz4mmw8olYN7FQaz7jNbVOevoWeAkTe69n7 DWfrQ7wZzt2uZfJgwDFMk6Z95E03siv++nykM= 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=E5CEaSFLb2TgmufPHt8FBEmqMQfIwgBEJfjHgJAlO2mhqRa3zPNy182G7ASPUs4po7 LfBJ/tnwEnLMBUqWIOMYaZrnfg97rlG6GgQ08IHCm0/ZNd+g1ztz3Kl2rMGQ420PyAyD 8qP/ZlbKZIe3PpgJGyXbZ4tDEAUzinm1iemuQ= Received: by 10.150.192.7 with SMTP id p7mr9712826ybf.91.1219066483659; Mon, 18 Aug 2008 06:34:43 -0700 (PDT) Received: by 10.150.140.11 with HTTP; Mon, 18 Aug 2008 06:34:43 -0700 (PDT) Message-ID: <84dead720808180634r7fa736a9nf08e1aa1ef79311@mail.gmail.com> Date: Mon, 18 Aug 2008 19:04:43 +0530 From: "Joseph Koshy" To: "Kris Kennaway" In-Reply-To: <489A1DE2.1020303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> <489A1DE2.1020303@FreeBSD.org> Cc: FreeBSD Stable , Eugene Kazarinov Subject: Re: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) 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, 18 Aug 2008 13:34:44 -0000 > This problem has been reported a couple of times but it is not clear what > change caused it. I upgraded my RELENG_6/amd64 system yesterday and ran into this bug. There's a fix (and an explanation of the bug) now in PR bin/124353. Koshy From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 13:37: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 656F91065672; Mon, 18 Aug 2008 13:37:55 +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 3560E8FC0C; Mon, 18 Aug 2008 13:37:55 +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 m7IDbqn2075806; Mon, 18 Aug 2008 09:37:53 -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 m7IDbqSC066670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 09:37:52 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808181337.m7IDbqSC066670@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 09:37:51 -0400 To: Robert Watson , stable@freebsd.org From: Mike Tancsa In-Reply-To: References: 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: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 13:37:55 -0000 At 04:14 AM 8/18/2008, Robert Watson wrote: >On Sun, 3 Aug 2008, Robert Watson wrote: > >>This is an advance warning that, late next week, I will be merging >>a fairly large set of changes to the IPv4 and IPv6 protocols >>layered over the inpcb/inpcbinfo kernel infrastructure. To be >>specific, this affects TCP, UDP, and raw sockets on both IPv4 and >>IPv6. I will post a further e-mail announcement along with patch >>set and schedule in a day or two once it's prepared. > >FYI: This patch has now been committed to Subversion. I'll keep a >close eye out for difficulties; if you run into issues, please send >me an e-mail (and CC stable@). Hi Robert, I just did a buildworld/kernel in case your commit fixed the routing bugs, but I am still seeing those bogus arp / routing table entries. I narrowed it down to the commits below. I dont think its the intel stuff, as another user reported the same issue using bce nics. date=2008.07.30.18.00.00 and date=2008.07.31.00.00.00 Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb ---Mike >Thanks, > >Robert N M Watson >Computer Laboratory >University of Cambridge > >> >>The thrust of this change is to replace the mutexes protecting the >>inpcb and inpcbinfo data structures with read-write locks >>(rwlocks). These structures represent, respectively, particular >>sockets and the global socket lists for all socket types in IPv4 >>and IPv6 except for SCTP. When you run netstat, inpcbinfo is the >>data structure referencing all connections, and each line in the >>nestat output reflects the contents of a specific inpcb. >> >>In the current stage of this work, the intent is to improve >>performance for datagram-related protocols on SMP systems by >>allowing concurrent acquisition of both global and connection locks >>during receive and transmit. This is possible because, in the >>common case, no connection or global state is modified during >>UDP/raw receive and transmit at the IP layer, so a read lock is >>sufficient to prevent data in those structures from unexpectedly >>changing. For receive, socket layer state is modified, but this is >>separately protected by socket layer locks. On transmit, no state >>is modified at any layer, so in principle we will allow fully >>parallel transmit from multiple threads down to about the routing >>and network interface layers, whereas previously they would bottleneck in UDP. >> >>The applications targeted by this change are threaded UDP server >>applications, such as BIND9, nsd, and UDP-based memcached. Kris >>Kennaway and Paul Saab have done fairly extensive testing with the >>changes and demonstrated significant performance improvements due >>to reduced contention and overhead. Perhaps they can mention some >>of those numbers in a follow-up to this post. >> >>The reason for the heads up is that, while carefully-tested, >>changes of this sort do come with risks. We've carefully >>structured them so as to avoid breaking the ABIs for netstat, etc, >>but it's not impossible that some problems will arise as the >>changes settle. The goal, however, is to see these performance >>improvements in 7.1, and since they've had a bit to shake out in >>8.x and seen some heavy use, I think now is the right time to merge them. >> >>In any case, I will send out e-mail in a couple of days with a >>proposed merge patch and schedule for merging, and perhaps if you >>are in a positition where you might benefit from these >>improvements, or have interesting UDP or raw-socket based >>applications running on 7.x, you could test the candidate patch >>before it's merged, reporting any problems. Unless I receive >>negative feedback, I will plan on merging the changes late in the >>week, and keep a close eye on stable@ for any reports of problems. >> >>Thanks, >> >>Robert N M Watson >>Computer Laboratory >>University of Cambridge >>_______________________________________________ >>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" >_______________________________________________ >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 Aug 18 13:52: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 776041065684 for ; Mon, 18 Aug 2008 13:52:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.cl.cam.ac.uk (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA3E8FC12; Mon, 18 Aug 2008 13:52:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48A97E9D.4050502@FreeBSD.org> Date: Mon, 18 Aug 2008 14:52:29 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Joseph Koshy References: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> <489A1DE2.1020303@FreeBSD.org> <84dead720808180634r7fa736a9nf08e1aa1ef79311@mail.gmail.com> In-Reply-To: <84dead720808180634r7fa736a9nf08e1aa1ef79311@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Eugene Kazarinov Subject: Re: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) 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, 18 Aug 2008 13:52:31 -0000 Joseph Koshy wrote: >> This problem has been reported a couple of times but it is not clear what >> change caused it. > > I upgraded my RELENG_6/amd64 system yesterday and ran into > this bug. > > There's a fix (and an explanation of the bug) now in PR bin/124353. > > Koshy > > Thanks very much for tracking this down! Kris From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 14: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 6A290106572E; Mon, 18 Aug 2008 14:47:06 +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 EE2D38FC1C; Mon, 18 Aug 2008 14:47:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7IEkWkR052949; Mon, 18 Aug 2008 10:46:59 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org, Mike Tancsa Date: Mon, 18 Aug 2008 10:24:39 -0400 User-Agent: KMail/1.9.7 References: <200808181337.m7IDbqSC066670@lava.sentex.ca> In-Reply-To: <200808181337.m7IDbqSC066670@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808181024.40038.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Mon, 18 Aug 2008 10:46:59 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8053/Mon Aug 18 08:42:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: Robert Watson Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 14:47:06 -0000 On Monday 18 August 2008 09:37:51 am Mike Tancsa wrote: > At 04:14 AM 8/18/2008, Robert Watson wrote: > >On Sun, 3 Aug 2008, Robert Watson wrote: > >>This is an advance warning that, late next week, I will be merging > >>a fairly large set of changes to the IPv4 and IPv6 protocols > >>layered over the inpcb/inpcbinfo kernel infrastructure. To be > >>specific, this affects TCP, UDP, and raw sockets on both IPv4 and > >>IPv6. I will post a further e-mail announcement along with patch > >>set and schedule in a day or two once it's prepared. > > > >FYI: This patch has now been committed to Subversion. I'll keep a > >close eye out for difficulties; if you run into issues, please send > >me an e-mail (and CC stable@). > > Hi Robert, > I just did a buildworld/kernel in case your commit fixed the > routing bugs, but I am still seeing those bogus arp / routing table > entries. I narrowed it down to the commits below. I dont think its > the intel stuff, as another user reported the same issue using bce nics. > > date=2008.07.30.18.00.00 > and > date=2008.07.31.00.00.00 > > Updating collection src-all/cvs > Checkout src/sys/dev/e1000/LICENSE > Checkout src/sys/dev/e1000/README > Checkout src/sys/dev/e1000/e1000_80003es2lan.c > Checkout src/sys/dev/e1000/e1000_80003es2lan.h > Checkout src/sys/dev/e1000/e1000_82540.c > Checkout src/sys/dev/e1000/e1000_82541.c > Checkout src/sys/dev/e1000/e1000_82541.h > Checkout src/sys/dev/e1000/e1000_82542.c > Checkout src/sys/dev/e1000/e1000_82543.c > Checkout src/sys/dev/e1000/e1000_82543.h > Checkout src/sys/dev/e1000/e1000_82571.c > Checkout src/sys/dev/e1000/e1000_82571.h > Checkout src/sys/dev/e1000/e1000_82575.c > Checkout src/sys/dev/e1000/e1000_82575.h > Checkout src/sys/dev/e1000/e1000_api.c > Checkout src/sys/dev/e1000/e1000_api.h > Checkout src/sys/dev/e1000/e1000_defines.h > Checkout src/sys/dev/e1000/e1000_hw.h > Checkout src/sys/dev/e1000/e1000_ich8lan.c > Checkout src/sys/dev/e1000/e1000_ich8lan.h > Checkout src/sys/dev/e1000/e1000_mac.c > Checkout src/sys/dev/e1000/e1000_mac.h > Checkout src/sys/dev/e1000/e1000_manage.c > Checkout src/sys/dev/e1000/e1000_manage.h > Checkout src/sys/dev/e1000/e1000_nvm.c > Checkout src/sys/dev/e1000/e1000_nvm.h > Checkout src/sys/dev/e1000/e1000_osdep.c > Checkout src/sys/dev/e1000/e1000_osdep.h > Checkout src/sys/dev/e1000/e1000_phy.c > Checkout src/sys/dev/e1000/e1000_phy.h > Checkout src/sys/dev/e1000/e1000_regs.h > Checkout src/sys/dev/e1000/if_em.c > Checkout src/sys/dev/e1000/if_em.h > Checkout src/sys/dev/e1000/if_igb.h Since are seeing this w/o em we can rule all of these out. > Edit src/sys/kern/kern_synch.c > Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson This is just a style change. > Edit src/sys/kern/sys_process.c > Add delta 1.145.2.1 2008.07.30.19.49.10 jhb This only affects userland reading memory of other process' userland (e.g. procfs 'mem' file, gdb, etc.). > Edit src/sys/conf/files > Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_subr.c > Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_syncache.c > Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy > Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy > Edit src/sys/netinet/tcp_syncache.h > Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy > Edit src/sys/netinet/tcp_usrreq.c > Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy These are changes by Kip to do TCP offload (181013, 181014). > Edit src/sys/netinet/udp_usrreq.c > Add delta 1.218.2.1 2008.07.30.21.23.21 bz > Edit src/sys/netinet6/ip6_input.c > Add delta 1.95.2.1 2008.07.30.21.23.21 bz > Edit src/sys/netinet6/ip6_var.h > Add delta 1.39.2.2 2008.07.30.21.23.21 bz These changes are all to #ifdef INET6 only code, so probably not relevant. > Edit src/sys/sys/socket.h > Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy More TCP offload stuff, though this just adds constants for new socket options. > Edit src/sys/ufs/ufs/ufs_lookup.c > Add delta 1.83.2.2 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vm_object.c > Add delta 1.385.2.2 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vm_object.h > Add delta 1.114.2.1 2008.07.30.21.43.42 jhb > Edit src/sys/vm/vnode_pager.c > Add delta 1.236.2.2 2008.07.30.21.43.42 jhb These are fixes to make UFS cache data from directories. Given that, I think the likeliest changes to cause this are the TCP offload changes. Note that Kip later MFC'd this change which changed ARP stuff: Author: kmacy Date: Thu Jul 31 22:42:27 2008 New Revision: 181075 URL: http://svn.freebsd.org/changeset/base/181075 Log: MFC ARP update hooks and change to arpresolve to do arp resolution without a pending mbuf to transmit Modified: stable/7/sys/net/route.c stable/7/sys/net/route.h stable/7/sys/netinet/if_ether.c stable/7/sys/netinet/if_ether.h However, I would stary by narrowing it down to see if Kip's commits cause the change. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 14:47: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 C997F1065845 for ; Mon, 18 Aug 2008 14:47:17 +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 0771A8FC1B for ; Mon, 18 Aug 2008 14:47:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7IEkWkS052949; Mon, 18 Aug 2008 10:47:05 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 18 Aug 2008 10:33:05 -0400 User-Agent: KMail/1.9.7 References: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808181033.05680.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Mon, 18 Aug 2008 10:47:06 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8053/Mon Aug 18 08:42:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: Torfinn Ingolfsen Subject: Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) 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, 18 Aug 2008 14:47:17 -0000 On Friday 15 August 2008 05:55:23 pm Torfinn Ingolfsen wrote: > Hello, > > Do you remember the zip[1] disks? The original 100 Mbyte ones? well > recently, I got a scsi zip drive (internal) with a scsi card (Adaptec > ava-2904) and some zip-100 disks, and a request to try to copy the data > from those disks. I found a cable, installed the card and zip drive > in a machine[2] running FreeBSd 7.0-stable, and luckily the zip disks could > be read. > > But during this process I discovered one thing; if I try to mount a > write protected zip disk without using the '-r' flag to the mount > command, my machine will panic a few seconds later. As there is no visual > indication to tell you that a zip disk is write protected, it is quite > easy to forget mounting it read only. > > Note: using zip disks that aren't write protected works fine. > > Details: > root@music1# uname -a > FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15 > 12:56:35 CEST 2008 root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC > i386 > > root@music1# dmesg | grep ahc > ahc0: port 0x1400-0x14ff mem > 0x5c100000-0x5c100fff irq 10 at device 15.0 on pci0 ahc0: Host Adapter Bios > disabled. Using default SCSI device parameters ahc0: [ITHREAD] > da0 at ahc0 bus 0 target 5 lun 0 > root@music1# dmesg | grep aic > aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs > > root@music1# dmesg | grep da0 > da0 at ahc0 bus 0 target 5 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 3.300MB/s transfers > da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C) > > This is what I got on the console (and in /var/log/messages) when I tried > to mount the disk: Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): > WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: > (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 > kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): Write protected > Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error > Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, > length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): > WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: > (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 > kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 > music1 kernel: (da0:ahc0:0:5:0): Write protected > Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error > Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, > length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: fsync: giving up on > dirty > Aug 15 20:14:33 music1 kernel: 0xc2988114: tag devfs, type VCHR > Aug 15 20:14:33 music1 kernel: usecount 1, writecount 0, refcount 27 > mountedhere 0xc2617700 Aug 15 20:14:33 music1 kernel: flags () > Aug 15 20:14:33 music1 kernel: v_object 0xc299707c ref 0 pages 25 > Aug 15 20:14:33 music1 kernel: > Aug 15 20:14:33 music1 kernel: dev da0s4 > Aug 15 20:14:34 music1 kernel: GEOM_LABEL: Label for provider da0s4 is > msdosfs/DIPLOM. > > A few seconds went by, and then the machine panic'ed with apage fault: > root@music1# more /var/crash/info.0 > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 60837888B (58 MB) > Blocksize: 512 > Dumptime: Fri Aug 15 20:15:03 2008 > Hostname: music1.kg4.no > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.0-STABLE #0: Fri Aug 15 12:56:35 CEST 2008 > root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC > Panic String: page fault > Dump Parity: 2682527093 > Bounds: 0 > Dump Status: good > > (crash dump, 58 Mbyte, available on request). > > Is this how it is supposed to be, or should I file a PR? Can you get the stack trace? > References: > 1) http://en.wikipedia.org/wiki/Zip_drive > 2) http://tingox.googlepages.com/dp-ep-c400_freebsd -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 15:09:12 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 5C8341065672 for ; Mon, 18 Aug 2008 15:09:12 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 09D838FC16 for ; Mon, 18 Aug 2008 15:09:11 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 3pC41a0060EZKEL56r9Bm9; Mon, 18 Aug 2008 15:09:11 +0000 Received: from daland.home ([24.61.21.4]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 3r9A1a00k05H7zL3Mr9BA6; Mon, 18 Aug 2008 15:09:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=EQi3qIMnYrsA:10 a=rITDv7nW5hcA:10 a=q2MSeDgXQc-nXTfRhloA:9 a=MZIqqZ0Za6Fh4m-4r2sA:7 a=qcZBCPgBS-xDA1DQ7SOVgb8uKgwA:4 a=si9q_4b84H0A:10 a=XF7b4UCPwd8A:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6M2-0005nl-LY for freebsd-stable@FreeBSD.org; Mon, 18 Aug 2008 11:09:10 -0400 From: Alex Goncharov To: freebsd-stable@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Mon, 18 Aug 2008 11:09:10 -0400 Cc: Subject: Groff is not working in the latest code X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 15:09:12 -0000 The following happens in 7.0-STABLE built from the source "csup"ed either yesterday's or this morning: ------------------------------------------------------------ $ groff -mm -t -Tascii tmp.mm groff: can't find `DESC' file groff:fatal error: invalid device `ascii' $ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC ++ [ ~/doc1/employ/ab-initio ] ++ truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC open("/usr/local/share/groff/site-font/devascii/DESC",O_RDONLY,0666) ERR#2 'No such file or directory' open("/usr/local/share/groff/1.19.2/font/devascii/DESC",O_RDONLY,0666) ERR#2 'No such file or directory' open("/usr/lib/font/devascii/DESC",O_RDONLY,0666) ERR#2 'No such file or directory' groff: can't find `DESC' file write(2,"groff: can't find `DESC' file\n",30) = 30 (0x1e) $ ls -l /usr/share/groff_font/devascii/DESC -r--r--r-- 1 root wheel 95 Aug 18 08:59 /usr/share/groff_font/devascii/DESC $ GROFF_FONT_PATH=/usr/share/groff_font groff -mm -t -Tascii tmp.mm troff: fatal error: can't find macro file m $ which groff /usr/bin/groff ------------------------------------------------------------ Note an attempt to look for a file under /usr/local, which should not happen for a program in "base". This behavior is very new -- no such problem existed in the code fetched last Saturday. There, I see: ------------------------------------------------------------ $ truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC open("/usr/share/groff_font/devascii/DESC",O_RDONLY,0666) = 3 (0x3) ------------------------------------------------------------ Anybody know of what happened? Thanks, -- Alex -- alex-goncharov@comcast.net -- /* * Machines that have broken down will work perfectly when the * repairman arrives. */ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 15:15: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 14EAD106566B for ; Mon, 18 Aug 2008 15:15:54 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id B30718FC0A for ; Mon, 18 Aug 2008 15:15:53 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 3nNP1a00A0SCNGk51rFPj3; Mon, 18 Aug 2008 15:15:23 +0000 Received: from daland.home ([24.61.21.4]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 3rFs1a00j05H7zL3VrFs50; Mon, 18 Aug 2008 15:15:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=mMiB1lh_xPEA:10 a=dNNx8KrexjgA:10 a=rITDv7nW5hcA:10 a=FQi0kuXPsLxewF6tFmoA:9 a=ND2dq-C8d8LGPlCEBY9TQyLaLIsA:4 a=si9q_4b84H0A:10 a=5K3QHU3FhZcA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6SW-0005pJ-AJ; Mon, 18 Aug 2008 11:15:52 -0400 From: Alex Goncharov To: freebsd-stable@FreeBSD.org In-reply-to: (message from Alex Goncharov on Mon, 18 Aug 2008 11:09:10 -0400) References: Message-Id: Sender: Alex Goncharov Date: Mon, 18 Aug 2008 11:15:52 -0400 Cc: Alex Goncharov Subject: An oops [Re: Groff is not working in the latest code] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 15:15:54 -0000 Oops, scratch (do not see) this piece in my previous message: ,--- I/Alex (Mon, 18 Aug 2008 11:09:10 -0400) ----* | $ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC | ++ [ ~/doc1/employ/ab-initio ] ++ `-------------------------------------------------* Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 15:16: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 B31911065692; Mon, 18 Aug 2008 15:16:19 +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 5CFE88FC28; Mon, 18 Aug 2008 15:16:18 +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 m7IFGGeA004301; Mon, 18 Aug 2008 11:16:17 -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 m7IFGGer067040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 11:16:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808181516.m7IFGGer067040@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 11:16:15 -0400 To: John Baldwin , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <200808181024.40038.jhb@freebsd.org> References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@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: Robert Watson Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 15:16:19 -0000 At 10:24 AM 8/18/2008, John Baldwin wrote: >Author: kmacy >Date: Thu Jul 31 22:42:27 2008 >New Revision: 181075 >URL: http://svn.freebsd.org/changeset/base/181075 > >Log: > MFC ARP update hooks and change to arpresolve to do arp > resolution without a >pending mbuf to transmit > >Modified: > stable/7/sys/net/route.c > stable/7/sys/net/route.h > stable/7/sys/netinet/if_ether.c > stable/7/sys/netinet/if_ether.h > >However, I would stary by narrowing it down to see if Kip's commits cause the >change. Thanks, I grabbed the versions just prior to those committed 0[smtp2]% cd /usr/src/sys 0[smtp2]% ident net/route.c net/route.c: $FreeBSD: src/sys/net/route.c,v 1.120.2.4 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident net/route.h net/route.h: $FreeBSD: src/sys/net/route.h,v 1.65.2.2 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident netinet/if_ether.c netinet/if_ether.c: $FreeBSD: src/sys/netinet/if_ether.c,v 1.162.2.1 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident netinet/if_ether.h netinet/if_ether.h: $FreeBSD: src/sys/netinet/if_ether.h,v 1.32 2005/02/22 13:04:03 glebius Exp $ 0[smtp2]% and still ? (199.212.134.1) at 00:15:17:3a:17:9d on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 16:13:02 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 847481065681 for ; Mon, 18 Aug 2008 16:13:02 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC158FC17 for ; Mon, 18 Aug 2008 16:13:02 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so4349753gxk.19 for ; Mon, 18 Aug 2008 09:13:01 -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:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=5SaHWu78cjhollOycKXRWgyc4r3C1YaX3fSM6GRmqds=; b=Rv3A1YQRiJTQyE531CHQElID6sFiT085Q621B3tG6P0oZQdag56U4UpLOUktu5dgVQ MgDZjIXpIxTlyFD2/zN91OLYXeDmC5KctPD26p/Gna6XXpIH3ZfSaed7yLAogK23EBMF 4fYnI33FaJTiZ3o5uKJ/J8CwFBAvNU/cIoRHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=cogHnXYDRZ2EOj8LiZnCCBivQOZSh3Ist6JD1ISgyH47Dt0boH8zNCSTPOQEEBdXPN IilRzVsK5E3wl8przuDU+TFzXtRJ8N+J4mWAfoQmMgg8/iBcsfQHqC8zTzE/zK/6LE4/ 49idkIOfvKqK8LhEw9pNul51kX3GRS2dfeDPI= Received: by 10.151.13.7 with SMTP id q7mr9910456ybi.123.1219074445340; Mon, 18 Aug 2008 08:47:25 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Mon, 18 Aug 2008 08:47:25 -0700 (PDT) Message-ID: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> Date: Mon, 18 Aug 2008 11:47:25 -0400 From: "Josh Carroll" To: "FreeBSD Stable" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 16:13:02 -0000 It's not really a problem, as the device and the SATA hard drives and DVD+RW attached to the bus operate properly, but I'm wondering why the ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up as: atapci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 The chip ID (0x29228086) from pciconf: atapci1@pci0:0:31:2: class=0x010601 card=0x82771043 chip=0x29228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' class = mass storage Matches in ata-pci.h: /usr/src/sys/dev/ata/ata-pci.h:#define ATA_I82801IB_AH6 0x29228086 And has an accompanying entry in ata-chipset.h: /usr/src/sys/dev/ata/ata-chipset.c: { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, Which correctly indicates it is AHCI compliant. However, ata_ahci_ident() still falls back on a "generic" identifier, which I guess means: /* is this PCI device flagged as an AHCI compliant chip ? */ if (pci_read_config(dev, PCIR_PROGIF, 1) != PCIP_STORAGE_SATA_AHCI_1_0) return ENXIO; Is returning 0 and falling through to: sprintf(buffer, "%s AHCI controller", ata_pcivendor2str(dev)); Just wondering why it is not properly detecting this as ICH9. Again, just something cosmetic that I'm curious about. I'm going to double check the BIOS settings now, but I am confident I have them set as AHCI in the BIOS. I suppose this could be a BIOS bug of some sort. I can also try upgrading to the latest BIOS. The system is 7.0-STABLE/amd64 as of August 16, 2008. Below is the full dmesg output, just in case it's pertinent. Thanks much! Josh 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-STABLE #0: Sat Aug 16 09:06:23 EDT 2008 root@pflog.net:/usr/jails/folsom/usr/obj/usr/src/sys/PFLOG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (3204.03-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 = 4286234624 (4087 MB) avail memory = 4124958720 (3933 MB) ACPI APIC Table: 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 netsmb_dev: loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 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 0xb880-0xb89f irq 21 at device 26.1 on pci0 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 0xbc00-0xbc1f irq 18 at device 26.2 on pci0 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 0xfbfffc00-0xfbffffff irq 18 at device 26.7 on pci0 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 pcib2: irq 17 at device 28.0 on pci0 pci4: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfeafe000-0xfeafffff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.5 on pci0 pci2: on pcib4 mskc0: port 0xc800-0xc8ff mem 0xfe9fc000-0xfe9fffff irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1d:60:bc:cc:39 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] uhci3: port 0xb080-0xb09f irq 23 at device 29.0 on pci0 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 0xb400-0xb41f irq 19 at device 29.1 on pci0 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 0xb480-0xb49f irq 18 at device 29.2 on pci0 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 0xfbfff800-0xfbfffbff irq 23 at device 29.7 on pci0 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 pcib5: at device 30.0 on pci0 pci5: on pcib5 em0: port 0xec00-0xec3f mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 17 at device 1.0 on pci5 em0: [FILTER] em0: Ethernet address: 00:0e:0c:6c:b9:16 fwohci0: mem 0xfeb9f000-0xfeb9ffff irq 19 at device 3.0 on pci5 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:11:d8:00:01:87:6f:c6 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] ata8: on atapci1 ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] ata10: on atapci1 ata10: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 8C, should be 84 [20070320] coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xcf000-0xcffff,0xd0000-0xd2fff 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 ugen0: on uhub5 ums0: on uhub6 ums0: 5 buttons and Z dir. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad10: 476940MB at ata5-master SATA300 ad12: 476940MB at ata6-master SATA300 ad14: 381553MB at ata7-master SATA150 acd0: DVDR at ata9-master SATA150 ad20: 381554MB at ata10-master SATA300 GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_LABEL: Label for provider ad12s1 is label/video. GEOM_LABEL: Label for provider ad10s1a is label/slash. GEOM_LABEL: Label for provider ad10s1b is label/swap. GEOM_LABEL: Label for provider ad10s1d is label/tmp. GEOM_LABEL: Label for provider ad10s1e is label/var. GEOM_LABEL: Label for provider mirror/gm0s1 is label/backup. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! cd0 at ata7 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/label/slash GEOM_LABE <118L>/dev/label/var: FILE SYSTEM CLEAN; SKIPPING CHECKS : L el label/backup removed. GEOM_LABEL: Label for provider mirror/gm0s1 is label/backup. WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. GEOM_LABEL: Label label/backup removed. em0: link state changed to UP From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 16:16: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 4AFB31065672 for ; Mon, 18 Aug 2008 16:16:03 +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 36D198FC19 for ; Mon, 18 Aug 2008 16:16:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 252161CC0BD; Mon, 18 Aug 2008 09:16:03 -0700 (PDT) Date: Mon, 18 Aug 2008 09:16:03 -0700 From: Jeremy Chadwick To: Josh Carroll Message-ID: <20080818161603.GA99293@eos.sc1.parodius.com> References: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Stable Subject: Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller" 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, 18 Aug 2008 16:16:03 -0000 On Mon, Aug 18, 2008 at 11:47:25AM -0400, Josh Carroll wrote: > It's not really a problem, as the device and the SATA hard drives and > DVD+RW attached to the bus operate properly, but I'm wondering why the > ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up > as: > > atapci1: port > 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f > mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 Because your motherboard allows for the enabling of AHCI on the ICH9. This is often a BIOS feature you can turn on/off. > Just wondering why it is not properly detecting this as ICH9. Again, > just something cosmetic that I'm curious about. I'm going to double > check the BIOS settings now, but I am confident I have them set as > AHCI in the BIOS. I suppose this could be a BIOS bug of some sort. I > can also try upgrading to the latest BIOS. I don't believe it's a bug. FreeBSD has a form of "generic AHCI" support, where for systems which indicate AHCI is available but has no direct AHCI chipset driver, will fall back to using a generic AHCI implementation that should work with most all AHCI implementations. I would say what you're seeing is good. AHCI == good. -- | 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 Aug 18 16:22:12 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 36BA71065674; Mon, 18 Aug 2008 16:22:12 +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 CEFE48FC1B; Mon, 18 Aug 2008 16:22:11 +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 m7IGM9Ae018862; Mon, 18 Aug 2008 12:22:10 -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 m7IGM9mk067285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 12:22:09 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808181622.m7IGM9mk067285@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 12:22:07 -0400 To: John Baldwin , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <200808181024.40038.jhb@freebsd.org> References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@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: Robert Watson , kmacy@freebsd.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 16:22:12 -0000 At 10:24 AM 8/18/2008, John Baldwin wrote: > > Edit src/sys/conf/files > > Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy > > Edit src/sys/netinet/tcp_subr.c > > Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy > > Edit src/sys/netinet/tcp_syncache.c > > Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy > > Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy > > Edit src/sys/netinet/tcp_syncache.h > > Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy > > Edit src/sys/netinet/tcp_usrreq.c > > Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy > >These are changes by Kip to do TCP offload (181013, 181014). > >Given that, I think the likeliest changes to cause this are the TCP offload >changes. Note that Kip later MFC'd this change which changed ARP stuff: > >However, I would stary by narrowing it down to see if Kip's commits cause the >change. As I dont have the skills to unwind Robert's patch, I have done the following csup with date=2008.08.01.00.00.00 which shows the problem. I then manually grabbed the prior versions of the above files 0[smtp2]% ident src/sys/conf/files src/sys/conf/files: $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ 0[smtp2]% ident src/sys/netinet/tcp_subr.c src/sys/netinet/tcp_subr.c: $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.c src/sys/netinet/tcp_syncache.c: $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 julian Exp $ 0[smtp2]% ident src/sys/netinet/tcp_syncache.h src/sys/netinet/tcp_syncache.h: $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby Exp $ 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c src/sys/netinet/tcp_usrreq.c: $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 rwatson Exp $ 0[smtp2]% All is OK. So it looks like the above introduced the bug. ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 16:55: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 50B6B106567B for ; Mon, 18 Aug 2008 16:55:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 16B268FC14 for ; Mon, 18 Aug 2008 16:55:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3443662rvf.43 for ; Mon, 18 Aug 2008 09:55:22 -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=X2jUWpJVh9TBD3NLixdau0VN/qEX9BWgNR92m8aZaYY=; b=bKUfevuc63ZXuy7M3yzUzqJ0P+ZHU7AfloMhkg08jEGyocokdOVu5pxpYwCjVi6t5U 1Ewx78eNiQ57s8vpRMMGR9uDsfRaF3xpeRIUv/DBt7aZmhwM4uuv2Vg3caluPyYwgG6f R/sbHiE2fLtaNy+uTYLtPjWxPSKp6EOuu2K4E= 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=XOvz0KYL3wEEt2d+u3qb8Lge7c7U7lP5/CX4IWvpJNad5G7W+i+wjuVjhKW3DOCOVQ S8A1eJve4ojFlctKF/27zjq1fjPEKTrxnc8ScXYdNwfrWYDTX3TAPn2d1raW+IoyRnkN LNHVpuahT7J5SHpFSVh0V6NRTHNiiKzRdek2M= Received: by 10.141.76.1 with SMTP id d1mr3416633rvl.269.1219078522556; Mon, 18 Aug 2008 09:55:22 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Mon, 18 Aug 2008 09:55:22 -0700 (PDT) Message-ID: <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> Date: Mon, 18 Aug 2008 09:55:22 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Mike Tancsa" In-Reply-To: <200808181622.m7IGM9mk067285@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> X-Google-Sender-Auth: b2da15e9c591f36d Cc: Robert Watson , freebsd-stable@freebsd.org, John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 16:55:23 -0000 got it On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa wrote: > At 10:24 AM 8/18/2008, John Baldwin wrote: > >> > Edit src/sys/conf/files >> > Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_subr.c >> > Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_syncache.c >> > Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >> > Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy >> > Edit src/sys/netinet/tcp_syncache.h >> > Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy >> > Edit src/sys/netinet/tcp_usrreq.c >> > Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy >> >> These are changes by Kip to do TCP offload (181013, 181014). >> >> Given that, I think the likeliest changes to cause this are the TCP >> offload >> changes. Note that Kip later MFC'd this change which changed ARP stuff: >> >> However, I would stary by narrowing it down to see if Kip's commits cause >> the >> change. > > > As I dont have the skills to unwind Robert's patch, I have done the > following > > csup with date=2008.08.01.00.00.00 > > which shows the problem. I then manually grabbed the prior versions of the > above files > > 0[smtp2]% ident src/sys/conf/files > src/sys/conf/files: > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_subr.c > src/sys/netinet/tcp_subr.c: > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c > src/sys/netinet/tcp_syncache.c: > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 01:13:22 > julian Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h > src/sys/netinet/tcp_syncache.h: > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 silby > Exp $ > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c > src/sys/netinet/tcp_usrreq.c: > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 > rwatson Exp $ > 0[smtp2]% > > All is OK. So it looks like the above introduced the bug. > > ---Mike > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 17:14: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 47070106567F; Mon, 18 Aug 2008 17:14:57 +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 F2BE88FC0C; Mon, 18 Aug 2008 17:14:56 +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 m7IHEsEt028946; Mon, 18 Aug 2008 13:14:54 -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 m7IHEsvc067471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 13:14:54 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808181714.m7IHEsvc067471@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 13:14:53 -0400 To: "Kip Macy" From: Mike Tancsa In-Reply-To: <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.co m> References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> 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: Robert Watson , freebsd-stable@freebsd.org, John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 17:14:58 -0000 At 12:55 PM 8/18/2008, Kip Macy wrote: >got it Thanks. The problem manifests itself soon after boot. There is nothing special about the box, it has 2 em network interfaces doing a lot of sendmail as well as local recursive DNS for itself and a few other sendmail boxes and also talks to a cluster of spam / virus scanning machines over tcp and UDP. ---Mike >On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa wrote: > > At 10:24 AM 8/18/2008, John Baldwin wrote: > > > >> > Edit src/sys/conf/files > >> > Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy > >> > Edit src/sys/netinet/tcp_subr.c > >> > Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy > >> > Edit src/sys/netinet/tcp_syncache.c > >> > Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy > >> > Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy > >> > Edit src/sys/netinet/tcp_syncache.h > >> > Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy > >> > Edit src/sys/netinet/tcp_usrreq.c > >> > Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy > >> > >> These are changes by Kip to do TCP offload (181013, 181014). > >> > >> Given that, I think the likeliest changes to cause this are the TCP > >> offload > >> changes. Note that Kip later MFC'd this change which changed ARP stuff: > >> > >> However, I would stary by narrowing it down to see if Kip's commits cause > >> the > >> change. > > > > > > As I dont have the skills to unwind Robert's patch, I have done the > > following > > > > csup with date=2008.08.01.00.00.00 > > > > which shows the problem. I then manually grabbed the prior versions of the > > above files > > > > 0[smtp2]% ident src/sys/conf/files > > src/sys/conf/files: > > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 > 17:46:01 jhb Exp $ > > 0[smtp2]% ident src/sys/netinet/tcp_subr.c > > src/sys/netinet/tcp_subr.c: > > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 > > julian Exp $ > > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c > > src/sys/netinet/tcp_syncache.c: > > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 > 2008/07/24 01:13:22 > > julian Exp $ > > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h > > src/sys/netinet/tcp_syncache.h: > > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 > 00:57:06 silby > > Exp $ > > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c > > src/sys/netinet/tcp_usrreq.c: > > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 11:50:00 > > rwatson Exp $ > > 0[smtp2]% > > > > All is OK. So it looks like the above introduced the bug. > > > > ---Mike > > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 17:44: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 913421065683 for ; Mon, 18 Aug 2008 17:44:41 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 43B008FC12 for ; Mon, 18 Aug 2008 17:44:41 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K5T006DA59DWY10@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 18 Aug 2008 19:44:01 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K5T00GXG59C2TA4@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 18 Aug 2008 19:44:01 +0200 (CEST) Date: Mon, 18 Aug 2008 19:44:00 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080818194400.70430d39.torfinn.ingolfsen@broadpark.no> In-reply-to: <200808181033.05680.jhb@freebsd.org> References: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> <200808181033.05680.jhb@freebsd.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) 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, 18 Aug 2008 17:44:41 -0000 On Mon, 18 Aug 2008 10:33:05 -0400 John Baldwin wrote: > > Can you get the stack trace? Like this? root@music1# kgdb kernel.debug /var/crash/vmcore.0 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0737b19 stack pointer = 0x28:0xceb9cbcc frame pointer = 0x28:0xceb9cbf8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 42 (syncer) trap number = 12 panic: page fault cpuid = 0 Uptime: 24m34s Physical memory: 307 MB Dumping 58 MB: 43 27 11 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc078eed7 in boot (howto=260) #at /usr/src/sys/kern/kern_shutdown.c:418 2 0xc078f199 in panic #(fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a9efbc in trap_fatal (frame=0xceb9cb8c, eva=0) #at /usr/src/sys/i386/i386/trap.c:899 4 0xc0a9f240 in trap_pfault #(frame=0xceb9cb8c, usermode=0, eva=0) #at /usr/src/sys/i386/i386/trap.c:812 5 0xc0a9fbec in trap #(frame=0xceb9cb8c) at /usr/src/sys/i386/i386/trap.c:490 6 0xc0a859ab #in calltrap () at /usr/src/sys/i386/i386/exception.s:139 7 0xc0737b19 #in g_io_request (bp=0xc299ba50, cp=0xc29b2e00) #at /usr/src/sys/geom/geom_io.c:364 8 0xc073c116 in g_vfs_strategy #(bo=0xc29881d4, bp=0xc88efc24) at /usr/src/sys/geom/geom_vfs.c:107 9 #0xc07f97b0 in bufwrite (bp=0xc88efc24) at buf.h:429 10 0xc07f2618 in #bawrite (bp=0xc88efc24) at buf.h:417 11 0xc07fddaa in vop_stdfsync #(ap=0xceb9ccd4) at /usr/src/sys/kern/vfs_default.c:479 12 0xc071cbbe #in devfs_fsync (ap=0xceb9ccd4) #at /usr/src/sys/fs/devfs/devfs_vnops.c:395 13 0xc0ab3ce2 in #VOP_FSYNC_APV (vop=0xc0bcf040, a=0xceb9ccd4) at vnode_if.c:1007 14 #0xc080dff8 in sched_sync () at vnode_if.h:538 15 0xc076bc59 in #fork_exit (callout=0xc080d8f0 , arg=0x0, frame=0xceb9cd38) at /usr/src/sys/kern/kern_fork.c:781 #16 0xc0a85a20 in fork_trampoline () #at /usr/src/sys/i386/i386/exception.s:205 Let me know if it was wrong, or if you need something else. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 17:52:36 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 57035106566C for ; Mon, 18 Aug 2008 17:52:36 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id DA6F88FC13 for ; Mon, 18 Aug 2008 17:52:35 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so4500949gxk.19 for ; Mon, 18 Aug 2008 10:52:35 -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:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ScCmcb4FVNZcjXROs6/jSaU6vO0HnVP15Tw7aHVSH7g=; b=WRfB9Sc1dUnglQ6XNxahXSHN0m42Q5PwfKCPWJoPsFRdyfl35wo1uT+4KmOIHZDRq0 fl2U3jrdWijh4nxRfS+FiKmN5qD5ih5+EAK7xd9gXwiEGiDHSO386q/kZvaS06S74bp0 7jPb3MUzCOowLTGAUqyWBB9TvbMyNZZjh8XOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=wJmf9ioj5Pu2JFtDWYrdZdEHX7v31KA/QDdcTgSzXlXbjScg54OG8/lb12cZarMJTl qO1S2eodRNEE1/GJanJ/LMIAB530TtpV2/prJuksro1lVPum/WijOwuQQYBGfmLhQDoK jugmOZWXfWOWyuQbQAM6ltsEfYUiOZnJi8pKA= Received: by 10.150.133.18 with SMTP id g18mr10102013ybd.3.1219081955364; Mon, 18 Aug 2008 10:52:35 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Mon, 18 Aug 2008 10:52:35 -0700 (PDT) Message-ID: <8cb6106e0808181052g2217fa13w5a53ce91fd13d46a@mail.gmail.com> Date: Mon, 18 Aug 2008 13:52:35 -0400 From: "Josh Carroll" To: "Jeremy Chadwick" In-Reply-To: <20080818161603.GA99293@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> <20080818161603.GA99293@eos.sc1.parodius.com> Cc: FreeBSD Stable Subject: Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 17:52:36 -0000 > Because your motherboard allows for the enabling of AHCI on the ICH9. > This is often a BIOS feature you can turn on/off. I double checked and it is indeed set properly to "AHCI mode" (instead of "enhanced" or "legacy"). I also upgrade the BIOS and it still shows up the same way. > I don't believe it's a bug. FreeBSD has a form of "generic AHCI" > support, where for systems which indicate AHCI is available but has no > direct AHCI chipset driver, will fall back to using a generic AHCI > implementation that should work with most all AHCI implementations. > > I would say what you're seeing is good. AHCI == good. Right, and it is operating nominally (as far as I can tell). When I enabled the JMicron controller, interestingly enough it showed up as "JMicron AHCI controller" when set to AHCI mode in the BIOS. There doesn't seem to be any ill effect running with a generic AHCI vs. Intel-specific AHCI driver. Perhaps it's supposed to show up this way, I'm not sure. As I said, this is purely cosmetic and just piqued my interest/curiosity as to why it'd show in a "generic" fashion. Thanks! Josh From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 19:32: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 93999106566B for ; Mon, 18 Aug 2008 19:32:03 +0000 (UTC) (envelope-from dpelleg@lawrence.libagent.org) Received: from lawrence.libagent.org (lawrence.libagent.org [69.60.120.231]) by mx1.freebsd.org (Postfix) with ESMTP id 352D68FC08 for ; Mon, 18 Aug 2008 19:32:03 +0000 (UTC) (envelope-from dpelleg@lawrence.libagent.org) Received: from localhost (unknown [127.0.0.1]) by lawrence.libagent.org (Postfix) with ESMTP id 8DB0FB2426 for ; Mon, 18 Aug 2008 22:14:09 +0300 (IDT) X-Virus-Scanned: amavisd-new at libagent.org Received: from lawrence.libagent.org ([127.0.0.1]) by localhost (lawrence.libagent.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zEI0Xxqlr1H2 for ; Mon, 18 Aug 2008 22:14:04 +0300 (IDT) Received: by lawrence.libagent.org (Postfix, from userid 1002) id 28047B241D; Mon, 18 Aug 2008 22:14:04 +0300 (IDT) Date: Mon, 18 Aug 2008 22:14:04 +0300 From: Dan Pelleg To: freebsd-stable@freebsd.org Message-ID: <20080818191404.GA44910@lawrence.libagent.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: nanobsd build problem 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, 18 Aug 2008 19:32:03 -0000 I'm trying to build nanobsd. I get the error below. Any ideas? ------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/nanobsd.soekris/ MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/nanobsd.soekris//usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/sbin:/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/bin:/usr/obj/nanobsd.soekris//usr/src/tmp/legacy/usr/games:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/sbin:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/bin:/usr/obj/nanobsd.soekris//usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/nanobsd.soekris//usr/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_NLS -DWITHOUT_PROFILE libraries cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libgcc (obj,depend,all,install) make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h TARGET_CPU_DEFAULT="" HEADERS="options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" DEFINES="" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h TARGET_CPU_DEFAULT="" HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > optionlist echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_muldi3 -o _muldi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_negdi2 -o _negdi2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c cc -c -O2 -fno-strict-aliasing -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -DL_lshrdi3 -o _lshrdi3.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c:33: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:20: error: stddef.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:48:19: error: float.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:87:20: error: stdarg.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:90:19: error: stdio.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:96:19: error: errno.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:103:20: error: string.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:105:20: error: unistd.h: No such file or directory In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c:33: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:20: error: stddef.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:48:19: error: float.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:87:20: error: stdarg.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:90:19: error: stdio.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:96:19: error: errno.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:103:20: error: string.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:105:20: error: unistd.h: No such file or directory In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc2.c:33: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:20: error: stddef.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:48:19: error: float.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:87:20: error: stdarg.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:90:19: error: stdio.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:96:19: error: errno.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:103:20: error: string.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:105:20: error: unistd.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:108:20: error: limits.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: time.h: No such file or directory *** Error code 1 /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:108:20: error: limits.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: time.h: No such file or directory *** Error code 1 /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:108:20: error: limits.h: No such file or directory /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: time.h: No such file or directory *** Error code 1 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 21:22: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 00918106567E for ; Mon, 18 Aug 2008 21:22:40 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from ianto.vadev.org (vadev.org [66.92.166.151]) by mx1.freebsd.org (Postfix) with ESMTP id 6D44B8FC17 for ; Mon, 18 Aug 2008 21:22:39 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from ianto.vadev.org (localhost [127.0.0.1]) by ianto.vadev.org (8.14.2/8.14.2) with ESMTP id m7IKhNhs017276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 20:43:28 GMT (envelope-from bkelly@vadev.org) Received: (from www@localhost) by ianto.vadev.org (8.14.2/8.14.2/Submit) id m7IKhMln017274; Mon, 18 Aug 2008 20:43:22 GMT (envelope-from bkelly@vadev.org) X-Authentication-Warning: ianto.vadev.org: www set sender to bkelly@vadev.org using -f To: Dan Pelleg MIME-Version: 1.0 Date: Mon, 18 Aug 2008 20:43:22 +0000 From: Ben Kelly In-Reply-To: <20080818191404.GA44910@lawrence.libagent.org> References: <20080818191404.GA44910@lawrence.libagent.org> Message-ID: <94ed778a15f2fa16bbcd0fa0d68128e0@mail.vadev.org> X-Sender: bkelly@vadev.org User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 192.168.1.110 Cc: freebsd-stable@freebsd.org Subject: Re: nanobsd build problem 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, 18 Aug 2008 21:22:40 -0000 On Mon, 18 Aug 2008 22:14:04 +0300, Dan Pelleg wrote: > I'm trying to build nanobsd. I get the error below. Any ideas? > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: > time.h: No such file or directory > *** Error code 1 Do you have WITHOUT_TOOLCHAIN set? That option currently only works for the install target, not the build target. Hope that helps. - Ben From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 22:32: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 999B91065673 for ; Mon, 18 Aug 2008 22:32:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 53FE08FC1C for ; Mon, 18 Aug 2008 22:32:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3633011rvf.43 for ; Mon, 18 Aug 2008 15:32:53 -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=wiJcsykNpmN9wQUqdcizzxelTYpKBYGoGuf2yfGWqYE=; b=vo9OB4My0aQq1JdMv4ip5QtuiSUBZtH/hdzVbv+I21d4YWjitCtbeLALREefYIdYgm WD8rZB8a20wR+SkUlNwFdAdRem5NW2pnH/JEUMFrpjPoVgbpTjha04DMDBCD3sFgDP88 vM6ZdpeQhgXW7FwJQinhCu4FE/u9V/vA2847Y= 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=f2N8O1HdzBES5W0K8B689FMg1hnUlws59xu244i1kDCO3VTKaDpfRavk6+L0T1NifQ /gqJHNyXLmS8vYxT8ftWIxZ3MaAwvW7VfEEuVW478so0oTsOWF9NVSS6WgY7UL+cdpIv X+aeE8r77epRXSCP2j7jsQ1UO6t0qN7L1hCrE= Received: by 10.140.126.14 with SMTP id y14mr3665499rvc.160.1219098773093; Mon, 18 Aug 2008 15:32:53 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Mon, 18 Aug 2008 15:32:53 -0700 (PDT) Message-ID: <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.com> Date: Mon, 18 Aug 2008 15:32:53 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Mike Tancsa" In-Reply-To: <200808181714.m7IHEsvc067471@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> <200808181714.m7IHEsvc067471@lava.sentex.ca> X-Google-Sender-Auth: f9de1861ddfacbf1 Cc: Robert Watson , freebsd-stable@freebsd.org, John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 22:32:53 -0000 Hi Mike, Could you please check that this doesn't happen on HEAD as well? This same code has been in 8 since shortly after the branch. Thanks, Kip On Mon, Aug 18, 2008 at 10:14 AM, Mike Tancsa wrote: > At 12:55 PM 8/18/2008, Kip Macy wrote: >> >> got it > > Thanks. The problem manifests itself soon after boot. There is nothing > special about the box, it has 2 em network interfaces doing a lot of > sendmail as well as local recursive DNS for itself and a few other sendmail > boxes and also talks to a cluster of spam / virus scanning machines over tcp > and UDP. > > ---Mike > >> On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa wrote: >> > At 10:24 AM 8/18/2008, John Baldwin wrote: >> > >> >> > Edit src/sys/conf/files >> >> > Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_subr.c >> >> > Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_syncache.c >> >> > Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy >> >> > Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy >> >> > Edit src/sys/netinet/tcp_syncache.h >> >> > Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy >> >> > Edit src/sys/netinet/tcp_usrreq.c >> >> > Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy >> >> >> >> These are changes by Kip to do TCP offload (181013, 181014). >> >> >> >> Given that, I think the likeliest changes to cause this are the TCP >> >> offload >> >> changes. Note that Kip later MFC'd this change which changed ARP >> >> stuff: >> >> >> >> However, I would stary by narrowing it down to see if Kip's commits >> >> cause >> >> the >> >> change. >> > >> > >> > As I dont have the skills to unwind Robert's patch, I have done the >> > following >> > >> > csup with date=2008.08.01.00.00.00 >> > >> > which shows the problem. I then manually grabbed the prior versions of >> > the >> > above files >> > >> > 0[smtp2]% ident src/sys/conf/files >> > src/sys/conf/files: >> > $FreeBSD: src/sys/conf/files,v 1.1243.2.30 2008/07/25 17:46:01 jhb >> > Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_subr.c >> > src/sys/netinet/tcp_subr.c: >> > $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.300.2.3 2008/07/24 01:13:22 >> > julian Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_syncache.c >> > src/sys/netinet/tcp_syncache.c: >> > $FreeBSD: src/sys/netinet/tcp_syncache.c,v 1.130.2.8 2008/07/24 >> > 01:13:22 >> > julian Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_syncache.h >> > src/sys/netinet/tcp_syncache.h: >> > $FreeBSD: src/sys/netinet/tcp_syncache.h,v 1.1 2007/07/27 00:57:06 >> > silby >> > Exp $ >> > 0[smtp2]% ident src/sys/netinet/tcp_usrreq.c >> > src/sys/netinet/tcp_usrreq.c: >> > $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.163.2.3 2008/03/01 >> > 11:50:00 >> > rwatson Exp $ >> > 0[smtp2]% >> > >> > All is OK. So it looks like the above introduced the bug. >> > >> > ---Mike >> > > > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 22:39:02 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 1A1EC106566C; Mon, 18 Aug 2008 22:39:02 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6058FC1E; Mon, 18 Aug 2008 22:39:01 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d26.q.ppp-pool.de [89.53.125.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 5FA6012883F; Tue, 19 Aug 2008 00:15:03 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 6B4932E90F; Tue, 19 Aug 2008 00:14:29 +0200 (CEST) Message-ID: <48A9F452.8020900@vwsoft.com> Date: Tue, 19 Aug 2008 00:14:42 +0200 From: Volker User-Agent: Thunderbird 2.0.0.16 (X11/20080727) MIME-Version: 1.0 To: FreeBSD Stable , "FreeBSD (PF)" X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1219702470.22674@lg3on696R3IlxuyqxZV9gg X-MailScanner-ID: 6B4932E90F.695CC X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Subject: LOR with pf + synproxy state 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, 18 Aug 2008 22:39:02 -0000 Hi! Last week I discovered an LOR on 7-STABLE (last build: 2008-Aug-17, RELENG_7). I can easily recreate the problem when running a synproxy state rule for incoming tcp connections and ssh'ing to my box. W/o using synproxy state (keep'ing state instead), no LOR takes place. lock order reversal: 1st 0xc575c92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 2nd 0xc521777c radix node head (radix node head) @ /usr/src/sys/net/route.c:278 KDB: stack backtrace: db_trace_self_wrapper(c0a2fa65,e557b890,c075f315,c0a30e10,c521777c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0a30e10,c521777c,c0a31129,c0a31129,c0a374a0,...) at kdb_backtrace+0x29 witness_checkorder(c521777c,9,c0a374a0,116,c507d000,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c521777c,0,c0a374a0,116,c5fe9a00,...) at _mtx_lock_flags+0x34 rtalloc1_fib(e557b998,1,100,0,e557b994,...) at rtalloc1_fib+0x76 rtalloc_ign_fib(e557b994,100,0,e557b9b4,c5734a38,...) at rtalloc_ign_fib+0xad in_rtalloc_ign(e557b994,100,0,692a1600,5b47f56,...) at in_rtalloc_ign+0x1f pf_calc_mss(c62a881c,2,5b4,2,e557bb4c,...) at pf_calc_mss+0x88 pf_test_tcp(e557bb68,e557bb64,1,c56e9400,c5fe9a00,...) at pf_test_tcp+0xdf6 pf_test(1,c507d000,e557bbc4,0,0,...) at pf_test+0x1028 pf_check_in(0,e557bbc4,c507d000,1,0,...) at pf_check_in+0x39 pfil_run_hooks(c0b79ec0,e557bc18,c507d000,1,0,...) at pfil_run_hooks+0x78 ip_input(c5fe9a00,14e,800,c507d000,800,...) at ip_input+0x265 netisr_dispatch(2,c5fe9a00,10,3,0,...) at netisr_dispatch+0x55 ether_demux(c507d000,c5fe9a00,3,0,3,...) at ether_demux+0x1c1 ether_input(c507d000,c5fe9a00,c0a0391b,c57,c507d000,...) at ether_input+0x323 bge_intr(c5084000,0,c0a2b122,4b6,c4ef84e8,...) at bge_intr+0x77a ithread_loop(c50814f0,e557bd38,c0a2af4a,305,c508cad0,...) at ithread_loop+0x155 fork_exit(c07102d0,c50814f0,e557bd38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe557bd70, ebp = 0 --- KDB: enter: witness_checkorder exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @ /usr/src/sys/net/pfil.c:73 exclusive sx so_rcv_sx r = 0 (0xc5db208c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx r = 0 (0xc551f22c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @ /usr/src/sys/net/pfil.c:73 pf rules used: ## Macros TCPSYN="S/SA" if_lan = "bge0" if_wlan = "ndis0" if_ipsec = "enc" ########################### tcp_in = "{ ssh http mdns 9102 49101 5900 }" udp_in = "{ mdns snmp 5029 }" passicmp = "{ 3 4 6 9 10 11 12 17 18 }" samba_tcp = "{ 139 445 }" samba_udp = "{ 137 1434 }" ###################################################### table { 127/8 10/8 172.16/12 192.168/16 } table { 224/8 239/8 } ###################################################### ## GLOBAL OPTIONS set block-policy drop set fingerprints "/etc/pf.os" set state-policy if-bound set skip on lo0 set optimization conservative ########################### ## TRAFFIC NORMALIZATION scrub all random-id fragment reassemble reassemble tcp ########################### ## TRANSLATION RULES (NAT) nat on $if_lan -> ($if_lan) nat on $if_wlan -> ($if_wlan) ###################################################### ## FILTER RULES block quick on lo0 proto {tcp udp} from any to any port biff pass quick on lo0 all antispoof log quick for { $if_lan $if_wlan } block drop log all block return in quick proto { tcp udp } from any to any port auth ########################### # IPSEC VPN ########################### pass log quick on {$if_lan $if_wlan} proto udp from any \ to any port isakmp keep state pass log quick on {$if_lan $if_wlan} proto udp from any \ to any port isakmp keep state pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \ to any keep state pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \ to any keep state pass quick log on $if_ipsec from any to any keep state ########################### # ICMP ########################### pass quick log on {$if_lan $if_wlan} proto icmp from any to any \ tag PASSOK keep state pass quick log inet proto icmp all icmp-type $passicmp keep state \ (max 2, max-src-states 1, max-src-nodes 1, source-track rule ) pass in quick log on {$if_lan $if_wlan} proto icmp from any to any \ keep state probability 50% ########################### # out traffic ########################### pass out log quick on {$if_lan $if_wlan} all flags $TCPSYN keep state ########################### # in traffic ########################### # allow broadcasts + samba - don't log pass quick on $if_lan from any to ($if_lan:broadcast) pass quick on $if_wlan from any to ($if_wlan:broadcast) pass quick on {$if_lan $if_wlan} from any to 255.255.255.255 pass in log on {$if_lan $if_wlan} proto tcp \ from any to any port $tcp_in \ flags $TCPSYN synproxy state # change to 'keep state' here to avoid LOR pass in log on {$if_lan $if_wlan} proto tcp from any port $tcp_in \ to any flags $TCPSYN synproxy state # change to 'keep state' here to avoid LOR pass in log on {$if_lan $if_wlan} proto udp from any \ to any port $udp_in keep state pass in log on {$if_lan $if_wlan} proto udp from any port $udp_in \ to any keep state pass quick on {$if_lan $if_wlan} from any to # EOF That LOR may be the same as reported here before (2007-12) - haven't checked the old sources (will verify if it's worth the time to confirm): http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-12/msg00150.html `uname -a`: FreeBSD cesar.sz.vwsoft.com 7.0-STABLE FreeBSD 7.0-STABLE #38: Sun Aug 17 15:12:10 CEST 2008 root@cesar.sz.vwsoft.com:/usr/obj/usr/src/sys/CESAR i386 Volker From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 22:42: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 CB0991065673; Mon, 18 Aug 2008 22:42:19 +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 7E5EE8FC0A; Mon, 18 Aug 2008 22:42:19 +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 m7IMgH5m097139; Mon, 18 Aug 2008 18:42:17 -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 m7IMgGvQ068692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2008 18:42:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808182242.m7IMgGvQ068692@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Aug 2008 18:42:16 -0400 To: "Kip Macy" From: Mike Tancsa In-Reply-To: <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.co m> References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> <200808181714.m7IHEsvc067471@lava.sentex.ca> <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.com> 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: Robert Watson , freebsd-stable@freebsd.org, John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 22:42:19 -0000 At 06:32 PM 8/18/2008, Kip Macy wrote: >Hi Mike, >Could you please check that this doesn't happen on HEAD as well? This >same code has been in 8 since shortly after the branch. Hi, I dont have any easy way to migrate the box to HEAD and then back. Can I just boot a kernel from HEAD ? I noticed on the commits prior to some of those files, (e.g. http://lists.freebsd.org/pipermail/cvs-src/2008-July/093223.html ) "MFC an ABI compatible implementation of Multiple routing tables." Is it possible your commit makes some assumptions that dont jive with that? ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 22:45:59 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 D28881065677 for ; Mon, 18 Aug 2008 22:45:59 +0000 (UTC) (envelope-from mat.macy@gmail.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 8E78E8FC14 for ; Mon, 18 Aug 2008 22:45:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3639961rvf.43 for ; Mon, 18 Aug 2008 15:45: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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=7OCXGlPjB7JGzAEUqyyCdHJlubrLRpYA9YQLlE5gosg=; b=w9F+8+LMY8Q4BFBHpjp/ejqJpMV30peiGzOmy9OSWp0MLzB94zeZhifELuMn0YOTeC oT5+1UkcRXOjYF1M6k4sP3p0VQxGAK2WPwm+Clf/9fdmq4NLf3dK0S4WkXiFUEwc7LqO jbmYwgt828OSdbLnSR5W9BDU46MYMZw4EozAg= 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=AHhy402gb2iVfDEqLssOWSlTSO4SlOgX64vWQv4ZT9/EhCWIpVl5MBoTaCd4lM7aPQ ftGnahcJadQ/QzO1U1PTM5LhdYUH230SCsgiS770dYlWHctKvBiWyin8vqK4yyllhQwx TUNsKKI9MADqT52Dibd/SQrO6O0t7UwF7DKp8= Received: by 10.140.199.3 with SMTP id w3mr3671091rvf.67.1219099559114; Mon, 18 Aug 2008 15:45:59 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Mon, 18 Aug 2008 15:45:59 -0700 (PDT) Message-ID: <3c1674c90808181545p654f86d5pf9a14ad8bb030c15@mail.gmail.com> Date: Mon, 18 Aug 2008 15:45:59 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Mike Tancsa" In-Reply-To: <200808182242.m7IMgGvQ068692@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> <200808181714.m7IHEsvc067471@lava.sentex.ca> <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.com> <200808182242.m7IMgGvQ068692@lava.sentex.ca> X-Google-Sender-Auth: ed2c6be5f8c7ca82 Cc: Robert Watson , freebsd-stable@freebsd.org, John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 22:45:59 -0000 On Mon, Aug 18, 2008 at 3:42 PM, Mike Tancsa wrote: > At 06:32 PM 8/18/2008, Kip Macy wrote: >> >> Hi Mike, >> Could you please check that this doesn't happen on HEAD as well? This >> same code has been in 8 since shortly after the branch. > > Hi, > I dont have any easy way to migrate the box to HEAD and then back. > Can I just boot a kernel from HEAD ? Yes. That should work fine. A couple of utilities won't work (ps and netstat) but other than that it should be testable. > I noticed on the commits prior to some of those files, > (e.g. > http://lists.freebsd.org/pipermail/cvs-src/2008-July/093223.html > ) > "MFC an ABI compatible implementation of Multiple routing tables." > > Is it possible your commit makes some assumptions that dont jive with that? It is indeed possible. That would make the most sense. Thanks, Kip From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 23:15:12 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 445691065679; Mon, 18 Aug 2008 23:15:12 +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 71FA48FC12; Mon, 18 Aug 2008 23:15:11 +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 34D4746BC2; Mon, 18 Aug 2008 19:15:11 -0400 (EDT) Date: Tue, 19 Aug 2008 00:15:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808182242.m7IMgGvQ068692@lava.sentex.ca> Message-ID: References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> <200808181714.m7IHEsvc067471@lava.sentex.ca> <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.com> <200808182242.m7IMgGvQ068692@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Kip Macy , John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 18 Aug 2008 23:15:12 -0000 On Mon, 18 Aug 2008, Mike Tancsa wrote: > At 06:32 PM 8/18/2008, Kip Macy wrote: > >> Could you please check that this doesn't happen on HEAD as well? This same >> code has been in 8 since shortly after the branch. > > I dont have any easy way to migrate the box to HEAD and then back. > Can I just boot a kernel from HEAD ? In general yes, but the uart changes in HEAD mean that you may need to tweak device.hints or change configurations. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Aug 18 23:48: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 0E84E1065671 for ; Mon, 18 Aug 2008 23:48:30 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 836E48FC17 for ; Mon, 18 Aug 2008 23:48:29 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id E0B8E2E50B for ; Tue, 19 Aug 2008 00:48:38 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id 8HjWh8eizzOn for ; Tue, 19 Aug 2008 00:48:36 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id 2962A2E4EE for ; Tue, 19 Aug 2008 00:48:36 +0100 (BST) Received: from delorean.geonosis.homeunix.org (host81-138-8-148.in-addr.btopenworld.com [81.138.8.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id 64F062E4E5; Tue, 19 Aug 2008 00:48:35 +0100 (BST) Date: Tue, 19 Aug 2008 00:48:22 +0100 From: Oliver Peter To: freebsd-stable@freebsd.org Message-ID: <20080819004822.5ab4ae05@delorean.geonosis.homeunix.org> In-Reply-To: <20080818103811.3add121e@dilbert.office.centralnic.com> References: <200808181716.36906.doconnor@gsoft.com.au> <20080818090646.421f7ecd@dilbert.office.centralnic.com> <1219051094.70002.52.camel@localhost> <20080818103811.3add121e@dilbert.office.centralnic.com> Organization: mouhaha X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tom Evans Subject: Re: Intel G33 & FreeBSD 7.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@peter.de.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 23:48:30 -0000 On Mon, 18 Aug 2008 10:38:11 +0100 Oliver Peter wrote: > On Mon, 18 Aug 2008 10:18:14 +0100 > Tom Evans wrote: > > > On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote: > > [...] > > > > Robert Noland posted last Wednesday on x11@ [1] that he had prepared > > an update to FreeBSD's drm kernel modules, which includes support > > for the G33 [2]. > > > > Cheers > > > > Tom > > > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=36408+0 > > +archive/2008/freebsd-x11/20080817.freebsd-x11 > > [2] http://people.freebsd.org/~rnoland > > Excellent! I'll give it a try this evening and post some debug > information here. Here we go: root@delorean /usr/src/sys % patch < /home/oliver/freebsd/src/drm-7-stable.20080813.patch ... root@delorean /usr/src % make -j4 buildkernel KERNCONF=DELOREAN ... -------------------------------------------------------------- >>> Kernel build for DELOREAN completed on Tue Aug 19 00:12:01 BST 2008 -------------------------------------------------------------- ... root@delorean /usr/src % make installkernel KERNCONF=DELOREAN ... root@delorean /usr/src % shutdown -r now ... oliver@delorean ~ % dmesg | grep drm drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080312 drm0: [ITHREAD] drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080312 drm0: [ITHREAD] drm0: [ITHREAD] ... oliver@delorean ~ % glxinfo | head name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer Unfortunately, the machine completely freezes up when trying a "X -config ..." and the throughput is not very satisfying as well... Example: oliver@delorean ~ % glxgears 727 frames in 5.0 seconds = 145.369 FPS 727 frames in 5.0 seconds = 145.272 FPS 720 frames in 5.0 seconds = 143.927 FPS ... I'll move that topic to freebsd-x11 tomorrow. :) -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 04:01: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 2B3AA1065673 for ; Tue, 19 Aug 2008 04:01:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp5.yandex.ru (smtp5.yandex.ru [77.88.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 79B2C8FC12 for ; Tue, 19 Aug 2008 04:01:22 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:62719 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1053252AbYHSEBK (ORCPT ); Tue, 19 Aug 2008 08:01:10 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp5 X-Yandex-TimeMark: 1219118470 X-MsgDayCount: 2 X-Comment: RFC 2476 MSA function at smtp5.yandex.ru logged sender identity as: bu7cher Message-ID: <48AA4583.4080005@yandex.ru> Date: Tue, 19 Aug 2008 08:01:07 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: josh.carroll@gmail.com References: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> In-Reply-To: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller" 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, 19 Aug 2008 04:01:23 -0000 Josh Carroll wrote: > atapci1: port > 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f > mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0 > > The chip ID (0x29228086) from pciconf: > > atapci1@pci0:0:31:2: class=0x010601 card=0x82771043 chip=0x29228086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' > class = mass storage As Jeremy said it is ok. In pciconf output you can see "class=0x010601". Your ICH9 controller has PCI subclass 0x06 (SATA) and PCI programming interface 0x01 (AHCI). Driver identified it as AHCI-compatible and used AHCI facilities. Some of PCI ids in ata_intel_ident can be removed today (generic AHCI support will be used for controllers which are identified as AHCI). Some controllers don't identified as AHCI, but can work as AHCI. And they will be handled by ata_xxx_ident. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 09:10: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 8AF60106564A; Tue, 19 Aug 2008 09:10:45 +0000 (UTC) (envelope-from shinjii@maydias.com) Received: from mail5.tpgi.com.au (mail5.tpgi.com.au [203.12.160.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1357C8FC28; Tue, 19 Aug 2008 09:10:44 +0000 (UTC) (envelope-from shinjii@maydias.com) X-TPG-Antivirus: Passed Received: from BLACKTHORN.maydias.com (123-243-239-97.static.tpgi.com.au [123.243.239.97]) by mail5.tpgi.com.au (envelope-from shinjii@maydias.com) (8.14.3/8.14.3) with ESMTP id m7J9APgp018178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 19:10:42 +1000 Message-Id: <200808190910.m7J9APgp018178@mail5.tpg.com.au> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Aug 2008 19:10:30 +1000 To: kde@mail.kde.org From: Warren Liddell Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3503C72 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Kopete, kplayer, kdelibs etc 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, 19 Aug 2008 09:10:45 -0000 I know there ar eknown issues about kopete and it being able to connect to MSN & Yahoo, im runnind KDE4 on AMD64 FreeBSD7.0-STABLE .. cvsupd today so all ports & SRC are upto date portupgrade done and yet kopete still refuses to connect to MSN or yahoo .. is the bug still on going or ? Since upgrading to KDE4 as well, kplayer refuses to run and i have had to goto VLC player to be able to watch vide files ... any reason why this would refuse to load ? When trying to re-compile things like Xchat and other various files that seem to be broken, i run into troubles with an error saying/mentioning kdelibs and QT .. excat error i couldnt say as i have now also lost complete internet access on the machine even though still able to communicate with the router and all other machines ironically running windows, seem to be running aok, so im trying to kill multiple birds using memory and booting from windows to FreeBSD etc At this point im frustrated enough to just fdisk the machine, and isntall everything from scratch with 7.0-STABLE & KDE4 .. so i ask for a lil assistance plz so as i can avoid having to do this drastic measure. -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.6.5/1619 - Release Date: 18/08/2008 5:39 PM From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 14:15: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 227281065676; Tue, 19 Aug 2008 14:15:09 +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 D9DFC8FC0A; Tue, 19 Aug 2008 14:15:08 +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 m7JEF3oY073346; Tue, 19 Aug 2008 10:15:03 -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 m7JEF3di072687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 10:15:03 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808191415.m7JEF3di072687@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Aug 2008 10:15:04 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808181337.m7IDbqSC066670@lava.sentex.ca> <200808181024.40038.jhb@freebsd.org> <200808181622.m7IGM9mk067285@lava.sentex.ca> <3c1674c90808180955w665476e0s9f37321cfcfd1eed@mail.gmail.com> <200808181714.m7IHEsvc067471@lava.sentex.ca> <3c1674c90808181532n741a7269g751f8f64e44c954c@mail.gmail.com> <200808182242.m7IMgGvQ068692@lava.sentex.ca> 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: freebsd-stable@freebsd.org, Kip Macy , John Baldwin Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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, 19 Aug 2008 14:15:09 -0000 At 07:15 PM 8/18/2008, Robert Watson wrote: >On Mon, 18 Aug 2008, Mike Tancsa wrote: > >>At 06:32 PM 8/18/2008, Kip Macy wrote: >> >>>Could you please check that this doesn't happen on HEAD as well? >>>This same code has been in 8 since shortly after the branch. >> >> I dont have any easy way to migrate the box to HEAD and >> then back. Can I just boot a kernel from HEAD ? > >In general yes, but the uart changes in HEAD mean that you may need >to tweak device.hints or change configurations. I booted with a kernel from HEAD (I grabbed one Kris built from zoo.freebsd.org, hopefully no strange things with it) and I see the same problems. Working with Kip last night, I added to the tcp_offload function int tcp_offload_connect(struct socket *so, struct sockaddr *nam) { struct ifnet *ifp; struct toedev *tdev; struct rtentry *rt; int error; return (EINVAL); and that eliminated the problem. 0[smtp2]% uname -a FreeBSD smtp2.sentex.ca 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Aug 18 15:14:54 UTC 2008 test@leopard1.netperf.freebsd.org:/zoo/kris/p4-nfs/sys/i386/compile/LEOPARD i386 0[smtp2]% arp -na ? (64.7.153.7) at 00:13:20:c6:86:30 on em1 [ethernet] ? (64.7.153.9) at 00:30:48:90:52:18 on em1 [ethernet] ? (64.7.153.9) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.12) at 00:0c:6e:fc:52:2d on em1 [ethernet] ? (64.7.153.18) at 00:14:2a:ad:37:70 on em1 [ethernet] ? (64.7.153.19) at 00:15:17:24:dc:bb on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at 00:14:2a:e0:c1:1c on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at 00:00:5e:00:01:06 on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.24) at 00:e0:81:5a:22:05 on em1 [ethernet] ? (64.7.153.24) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at 00:50:fc:a7:c9:d3 on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.26) at 00:14:2a:13:ea:00 on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.27) at 00:14:2a:99:b1:ad on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.27) at (incomplete) on em1 published (proxy only) [ethernet] ? (199.212.134.1) at 00:15:17:3a:17:9d on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] ? (199.212.134.4) at 00:02:b3:5d:ca:f6 on em0 [ethernet] ? (199.212.134.9) at 00:15:17:27:80:9f on em0 permanent [ethernet] ? (199.212.134.10) at 00:e0:81:5e:bd:6f on em0 [ethernet] ? (199.212.134.11) at 00:d0:b7:db:69:6a on em0 [ethernet] 0[smtp2]% From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 14:53: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 5A0F11065687 for ; Tue, 19 Aug 2008 14:53:14 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 14CE28FC25 for ; Tue, 19 Aug 2008 14:53:13 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so5783457gxk.19 for ; Tue, 19 Aug 2008 07:53:13 -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:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0YYOxjgHMeuNQvPSzOODsrZrzD66RsNwAlADQtSZAso=; b=gLeWjDA/YoE7YQTwTI4Ynjd7ChEU2g9qgMiDg61TMcMHLwEB2FoaHyC7IcJNWDZkK0 v/I3FXk3o6WhuwxGf7pUoJNxns30OxohVmYdbLN3Q1dCDNgLwY2nny/sA1iEpIMfiggd LIc0SS65HDN6dl3+eNECcRyGQu3iV+kgtM1tM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=GCIMLyz5mmvrL5yeVPLpbYX9N53zsjbzyuro3Rd/FFVJ5kdGPksY+QAzAZppMWKy7K 4+6pk/wwQR5st4UNZxWVGIitcUnSeh3LwQ86lwUq0nL8rxRjiwBH8vEAieCQGKqcXDp7 bpOAL4YZixxAuZhPEw2sXbUSLnLBtrAxM9yUY= Received: by 10.150.51.6 with SMTP id y6mr11960560yby.222.1219157593331; Tue, 19 Aug 2008 07:53:13 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Tue, 19 Aug 2008 07:53:13 -0700 (PDT) Message-ID: <8cb6106e0808190753v5c0a490fg28891a10afd68e8f@mail.gmail.com> Date: Tue, 19 Aug 2008 10:53:13 -0400 From: "Josh Carroll" To: "Andrey V. Elsukov" In-Reply-To: <48AA4583.4080005@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cb6106e0808180847s571d04cbr95c07e196c602742@mail.gmail.com> <48AA4583.4080005@yandex.ru> Cc: FreeBSD Stable Subject: Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 14:53:14 -0000 > As Jeremy said it is ok. In pciconf output you can see > "class=0x010601". Your ICH9 controller has PCI subclass 0x06 (SATA) > and PCI programming interface 0x01 (AHCI). Thank you both! I figured it was operating normally (I've noticed no performance problems or oddities from the controller or devices attached to it). I guess in trying to find out what was going on, I saw this comment: /* is this PCI device flagged as an AHCI compliant chip ? */ if (pci_read_config(dev, PCIR_PROGIF, 1) != PCIP_STORAGE_SATA_AHCI_1_0) Which if I read the comment literally makes me believe if that does not return non-zero/NULL, that my controller is not AHCI compliant. But if it's falling back on a perfectly working generic AHCI implementation, what it reports at boot time is moot. :) Thanks again guys! Josh From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 15:37: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 0D22C1065679 for ; Tue, 19 Aug 2008 15:37:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C896A8FC14 for ; Tue, 19 Aug 2008 15:37:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 32A607308B; Tue, 19 Aug 2008 17:40:27 +0200 (CEST) Date: Tue, 19 Aug 2008 17:40:27 +0200 From: Luigi Rizzo To: freebsd-stable@freebsd.org Message-ID: <20080819154027.GA24372@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894E8C3.5060004@freebsd.org> User-Agent: Mutt/1.4.2.3i Subject: busybox port available (was Re: busybox and small scripting languages on FreeBSD...) 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, 19 Aug 2008 15:37:57 -0000 replying to a thread of a couple of weeks ago... I managed to build a reasonable subset of busybox (1.11.1) on FreeBSD, you can find patches at http://info.iet.unipi.it/~luigi/FreeBSD/#busybox-port The linux-specific things (e.g. those relying on /proc or system APIs that we don't have) clearly do not work, and I did not bother trying to implement replacement for them. But many userland commands do work and maybe they are useful to have around in a small system. A sample of the file sizes (the 'dec' column from the 'size' command): 37136 work/busybox-1.11.1/shell/ash.o 18492 work/busybox-1.11.1/libbb/appletlib.o 18258 work/busybox-1.11.1/editors/vi.o 17995 work/busybox-1.11.1/editors/awk.o 9878 work/busybox-1.11.1/networking/httpd.o 9289 work/busybox-1.11.1/archival/bzip2.o 7609 work/busybox-1.11.1/editors/diff.o 6378 work/busybox-1.11.1/miscutils/less.o 6258 work/busybox-1.11.1/editors/sed.o 6170 work/busybox-1.11.1/archival/gzip.o 5367 work/busybox-1.11.1/editors/ed.o 5317 work/busybox-1.11.1/archival/libunarchive/decompress_unzip.o 5132 work/busybox-1.11.1/networking/wget.o 4485 work/busybox-1.11.1/networking/traceroute.o 4277 work/busybox-1.11.1/libbb/dump.o ... overall, the binary in this configuration is around 330kb. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Tue Aug 19 22:05: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 6544B106567C for ; Tue, 19 Aug 2008 22:05:01 +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 E8C758FC13 for ; Tue, 19 Aug 2008 22:05:00 +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 m7JM4ocW069334; Tue, 19 Aug 2008 18:04:51 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 19 Aug 2008 17:15:54 -0400 User-Agent: KMail/1.9.7 References: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> <200808181033.05680.jhb@freebsd.org> <20080818194400.70430d39.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20080818194400.70430d39.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808191715.54250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 19 Aug 2008 18:04:51 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8058/Tue Aug 19 11:20:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: Torfinn Ingolfsen Subject: Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) 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, 19 Aug 2008 22:05:01 -0000 On Monday 18 August 2008 01:44:00 pm Torfinn Ingolfsen wrote: > On Mon, 18 Aug 2008 10:33:05 -0400 > John Baldwin wrote: > > > > > Can you get the stack trace? > > Like this? > root@music1# kgdb kernel.debug /var/crash/vmcore.0 > 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 "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0737b19 > stack pointer = 0x28:0xceb9cbcc > frame pointer = 0x28:0xceb9cbf8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 42 (syncer) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 24m34s > Physical memory: 307 MB > Dumping 58 MB: 43 27 11 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols > from /boot/kernel/acpi.ko.symbols...done. done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0xc078eed7 in boot (howto=260) > #at /usr/src/sys/kern/kern_shutdown.c:418 2 0xc078f199 in panic > #(fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0a9efbc in trap_fatal (frame=0xceb9cb8c, eva=0) > #at /usr/src/sys/i386/i386/trap.c:899 4 0xc0a9f240 in trap_pfault > #(frame=0xceb9cb8c, usermode=0, eva=0) > #at /usr/src/sys/i386/i386/trap.c:812 5 0xc0a9fbec in trap > #(frame=0xceb9cb8c) at /usr/src/sys/i386/i386/trap.c:490 6 0xc0a859ab > #in calltrap () at /usr/src/sys/i386/i386/exception.s:139 7 0xc0737b19 > #in g_io_request (bp=0xc299ba50, cp=0xc29b2e00) > #at /usr/src/sys/geom/geom_io.c:364 8 0xc073c116 in g_vfs_strategy > #(bo=0xc29881d4, bp=0xc88efc24) at /usr/src/sys/geom/geom_vfs.c:107 9 > #0xc07f97b0 in bufwrite (bp=0xc88efc24) at buf.h:429 10 0xc07f2618 in > #bawrite (bp=0xc88efc24) at buf.h:417 11 0xc07fddaa in vop_stdfsync > #(ap=0xceb9ccd4) at /usr/src/sys/kern/vfs_default.c:479 12 0xc071cbbe > #in devfs_fsync (ap=0xceb9ccd4) > #at /usr/src/sys/fs/devfs/devfs_vnops.c:395 13 0xc0ab3ce2 in > #VOP_FSYNC_APV (vop=0xc0bcf040, a=0xceb9ccd4) at vnode_if.c:1007 14 > #0xc080dff8 in sched_sync () at vnode_if.h:538 15 0xc076bc59 in > #fork_exit (callout=0xc080d8f0 , arg=0x0, frame=0xceb9cd38) > at /usr/src/sys/kern/kern_fork.c:781 > #16 0xc0a85a20 in fork_trampoline () > #at /usr/src/sys/i386/i386/exception.s:205 > > Let me know if it was wrong, or if you need something else. That's right, but not the specific bug I am familiar with. :( -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 14:19: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 6867E1065679 for ; Wed, 20 Aug 2008 14:19:53 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id DF5A88FC28 for ; Wed, 20 Aug 2008 14:19:52 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id m7KEJpRK037614 for ; Wed, 20 Aug 2008 16:19:51 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id m7KEJovn017566 for ; Wed, 20 Aug 2008 16:19:50 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id m7KEJmMJ017565 for freebsd-stable@freebsd.org; Wed, 20 Aug 2008 16:19:48 +0200 (CEST) (envelope-from ry93) Date: Wed, 20 Aug 2008 16:19:48 +0200 From: "Patrick M. Hausen" To: freebsd-stable@freebsd.org Message-ID: <20080820141948.GB15673@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.17 (2007-11-01) Subject: boot0cfg and gmirror ... 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, 20 Aug 2008 14:19:53 -0000 Hi, all, I know about the "foot shooting" prevention in geom(4) when trying to update the MBR of a mounted disk. I have a system with ad4 and ad6 mirrored and fdisk partitions residing on the mirror to be booted alterningly: hd30# gmirror status Name Status Components mirror/m0 COMPLETE ad4 ad6 hd30# mount /dev/mirror/m0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) hd30# boot0cfg -v /dev/mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5 704:254:63 32852925 455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) OK, try to switch to slice 2: hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Known one, set debug flags and try again: hd30# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Er ... well, what now? Out of curiosity I tried: hd30# boot0cfg -s 2 -v /dev/ad4 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5 704:254:63 32852925 455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) hd30# boot0cfg -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5 704:254:63 32852925 455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) hd30# boot0cfg -s 2 -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5 704:254:63 32852925 455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) So, with the prevention removed it is possible to write to the single disks, but not to the mirror as a whole. Weird. Any ideas? What bad things can happen if I keep updating the MBRs of both individual disks seperately - besides bad karma and "See? I told you so!" in case I generate an inconsistent state? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 14:27: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 3C90F106564A for ; Wed, 20 Aug 2008 14:27:26 +0000 (UTC) (envelope-from css@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id AD3818FC12 for ; Wed, 20 Aug 2008 14:27:25 +0000 (UTC) (envelope-from css@alkar.net) Received: from while.alkar.net (account css@alkar.net [212.86.226.7] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 201510028; Wed, 20 Aug 2008 17:27:24 +0300 Date: Wed, 20 Aug 2008 17:27:23 +0300 From: Sergey Chumakov To: Eugene Grosbein Message-ID: <20080820172723.08840c30@while.alkar.net> In-Reply-To: <20080814073357.GA85637@svzserv.kemerovo.su> References: <20080814093000.4842b37c@while.alkar.net> <20080814073357.GA85637@svzserv.kemerovo.su> Organization: Optima Telecom ISP X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Process size. 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, 20 Aug 2008 14:27:26 -0000 îÁ Thu, 14 Aug 2008 15:33:57 +0800 Eugene Grosbein ÚÁÐÉÓÁÎÏ: > On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > > > $limits > > Resource limits (current): > > ... > > datasize 1048576 kB > > stacksize 131072 kB > > > > How and why is it possible for process to grow up to 1493M and even > > more? I suppose, it will be able to eat all available system memory (was > > killed). > > Try to eslablish 'vmemoryuse' limit also. It works well, thank you. -- Sincerely, Sergey Chumakov From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 15:48: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 2A33410656E5; Wed, 20 Aug 2008 15:48:37 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [IPv6:2001:4830:2407:8000:230:48ff:fe71:c2a2]) by mx1.freebsd.org (Postfix) with ESMTP id 724838FC1B; Wed, 20 Aug 2008 15:48:30 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id A560F8FDCF; Wed, 20 Aug 2008 09:48:23 -0600 (MDT) Date: Wed, 20 Aug 2008 09:48:23 -0600 From: Brad Davis To: freebsd-hackers@FreeBSD.org Message-ID: <20080820154823.GC61166@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: The FreeBSD Status Reports for the Second Quarter of 2008 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, 20 Aug 2008 15:48:38 -0000 The FreeBSD Status Reports for the Second Quarter of 2008 are now available at: http://www.freebsd.org/news/status/report-2008-04-2008-06.html For convenience I have included them below as well. Regards, Brad Davis ------------------------------- FreeBSD Quarterly Status Report Introduction This Status Report covers FreeBSD related projects between April and June 2008. During this period The FreeBSD Foundation has released their July Newsletter. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Google Summer of Code * Layer2 filtering * Porting BSD-licensed text-processing tools from OpenBSD Projects * Build cluster * finstall * FreeBSD Bugbusting Team * Graphics support for the boot loader * USB FreeBSD Architecture * ARM/Marvell port The Ports Collection * Ports Collection * Qt/KDE4 Status Report Documentation * FreeBSD FAQ Renovation * The FreeBSD Dutch Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project __________________________________________________________________ ARM/Marvell port URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/arm/src/sys/arm/orio n/&c=0h4@//depot/projects/arm/src/sys/arm/orion/?ac=83 Contact: Rafal Jaworowski Contact: Bartlomiej Sieka After the last couple of months of intensive development going on towards FreeBSD support for Marvell System-on-Chip devices, we have FreeBSD 8.0-CURRENT running on the following systems: * Orion (already available in Perforce): * 88F5281 * 88F5181 * 88F5182 Kirkwood - 88F6281 Discovery - MV78100 The above families of SOCs are built around CPU cores compliant with ARMv5TE instruction set architecture definition. They share a number of integrated peripherals, for most of which we already have operational and stable drivers: * UART * EHCI USB 2.0 * Ethernet * IDMA (general purpose DMA engine) * XOR * TWSI (I2C) * Timers, watchdog, RTC * GPIO * Interrupt controller * L1, L2 cache High level functional summary: * Production Quality * Error-free Operation * Multiuser * Self-hosted kernel/world builds * NFS- or USB-mounted root filesystem The code is partially available (Orion in Perforce), other variants will also be integrated with Perforce/SVN soon. Open tasks: 1. Drivers that are In-progress: PCI and PCIE. __________________________________________________________________ Build cluster Contact: Kris Kennaway For the past couple of months I have been working on generalizing the package build cluster to allow it to host other batch and interactive jobs. Currently we make an inefficient use of build machines because various projects have dedicated machines that are either underloaded or overloaded for their particular tasks. The goal is to provide a framework for combining all of these machine resources into a single cluster that can be shared by many users, reducing dead time and allowing distributed build tasks to take advantage of extra build resources when available. Developers will be able to obtain on-demand interactive access to a jail running on any of the available architectures, with root access. Similarly, batch jobs will specify their resource requirements and be dispatched to run on a suitable machine in the cluster. Current status: The job queue manager is working and is now being used to map package builds to machines. Various package build scripts have been rewritten to use it instead of the previous build scheduler. The generic job dispatcher is being prototyped and will be validated with several existing services such as INDEX builds. Various support services like ZFS snapshot replication have been written. __________________________________________________________________ finstall URL: http://wiki.freebsd.org/finstall URL: http://www.sf.net/projects/finstall Contact: Ivan Voras Between the last report and this one, the project has yielded a LiveCD installer for i386 containing FreeBSD 7.0-RELEASE. The project was presented at BSDCan 2008. The development is progressing slowly due to the lack of free time. I'm looking for funding that will allow me more involvement in the project. The big item currently in development is documentation and description of the protocol used between the front-end and the back-end, which will result in more robustness in the implementation and could support third-party clients. This sub-project is near completion. The project is currently hosted at SourceForge to allow contribution from non-FreeBSD developers. Open tasks: 1. Partition editor. 2. Package selection. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.freebsd.org/support.html#gnats URL: http://wiki.freebsd.org/BugBusting URL: http://people.freebsd.org/~linimon/studies/prs/pr_manpage_index.html URL: http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html URL: http://people.freebsd.org/~linimon/studies/prs/prs_possibly_committed.h tml URL: http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Contact: Ceri Davies Contact: Remko Lodder Contact: Mark Linimon We have granted Bruce Cran (bruce@) direct access to GNATS and Volker Werth (vwe@) has been released from mentorship. We appreciate their help! We had a third bugathon in June, which resulted in the closing of a number of bugs and the investigation/classification of several others. We are still trying to find ways to get more committers helping us with closing PRs that the team has already analyzed. We continue to make good progress in categorizing PRs as they arrive with 'tags' that correspond to manpages. (Special thanks go to Dylan Cochran for the help.) As a result, we now have created some prototype reports that allow browsing the database by manpage. In addition, another new report, oriented towards PR submitters, summarizes the most commonly reported issues. Many of these issues persist because they are difficult to fix. Before filing a PR, you may want to check through this list. Mark Linimon summarized the good technical suggestions from the bugathons so far this year to the wiki. As a part of this, he rearranged the wiki pages, so if you have not seen them for a while, please see BugBusting. In particular, the Resources page is much more complete. Jeremy Chadwick (koitsu@) is now maintaining a page that summarizes some of the commonly reported issues. This complements some of the reports, above, but includes a great deal more information, including how-tos. The overall PR count has been holding at around 5300 since the last release. Open tasks: 1. Think of some way for committers to only view PRs that have been in some way 'vetted' or 'confirmed'. 2. Generate more publicity for what we've already got in place, and for what we intend to do next. 3. Define new categories, classifications, and states for PRs, that will better match our workflow. __________________________________________________________________ FreeBSD FAQ Renovation URL: http://www.FreeBSD.org/doc/en/books/faq/ URL: http://wiki.freebsd.org/faq-renewal Contact: Gábor Páli Contact: Manolis Kiagias An extensive work on renovating the FreeBSD FAQ has been started to support its Greek and Hungarian translations. Further improvements and content changes are still possible, we hope other committers will help us to keep the FAQ updated and tuned further. We have launched a renewal proposal to collect and organize the ideas around a more interactive, accurate, open for comments, consistent across several views etc. FAQ document. We would like to experiment with methods to implement the goals mentioned before, and help is more than welcome. Open tasks: 1. Review the renovated FAQ. 2. Add more question and answers to the FAQ. 3. Refine the FAQ renewal proposal. __________________________________________________________________ Graphics support for the boot loader URL: http://wiki.freebsd.org/OliverFromme/BootLoader Contact: Oliver Fromme This project aims to implement graphics support for FreeBSD's boot loader. It will replace the existing ASCII menu. (Note that the ASCII menu will still be available when graphics mode cannot be used, such as on serial console or on unsupported hardware.) For a more detailed description and screen shots please refer to the project's Wiki URL above. Progress is slow (due to lack of time) but steady. The code currently lives in the Perforce repository. I'll try to prepare a first public CFT as soon as possible. Open tasks: 1. Implement a platform switch. 2. Implement "themes" support (in FORTH). 3. Documentation. __________________________________________________________________ Layer2 filtering URL: http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering URL: http://blogs.freebsdish.org/gleb/ Contact: Gleb Kurtsou Contact: Andrew Thompson Project aims to improve layer2 filtering in ipfw and pf. So far following project goals are achieved: pfil framework is extended to handle ethernet packets, ipfw layer2 filtering is greatly simplified, added l2filter and l2tag per interface flags. Both ipfw and pf firewalls support filtering by ethernet addresses, support stateful filtering with ethernet addresses and firewall's lookup tables are extended to contain ethernet addresses. Open tasks: 1. Implement ARP filtering options in IPFW. __________________________________________________________________ Porting BSD-licensed text-processing tools from OpenBSD URL: http://wiki.freebsd.org/G%C3%A1borSoC2008 URL: http://p4web.freebsd.org/@md=d&cd=//&c=Kqj@//depot/projects/soc2008/gab or_textproc/?ac=83 Contact: Gábor Kövesdán The grep utility is ready for a thorough test on the portbuild cluster. It is almost compatible with GNU grep, but there are differences in the regex handling at the level of the regex libraries of GNU and the base system one, thus a better compatibility is very hard to implement. Some progress has been made on diff, but some important options are still missing. The sort utility seems to be very problematic in the aspect of the wide character support by design, thus it was given a lower priority. Open tasks: 1. Finish the incomplete options of diff and optimize it. 2. Investigate about the opportunities to fix sort. __________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has jumped to over 19,000. The PR count has been holding steady at around 900. KDE has been updated to 4.1. Special thanks go to Martin Wilke for a great deal of pre-testing. GNOME has been updated three times, first to 2.22.1 and then to 2.22.2 and 2.22.3. Other notable updates are automake, gettext, libtool, and m4. Florent Thoumie has been working on some updates to the pkg_* tools. Ion-Mihai Tetcu has set up a tinderbox with several purposes: first, to quickly try to build packages as changes are committed; secondly, to build them with a non-standard set of environment variables; and thirdly, to build older packages with the non- standard set of environment variables. As a result of all this work, and work by various committers, we are much closer to building packages corrected in the NOPORTDOCS case. Kris Kennaway has done a substantial rewrite of the package building tools, including moving as a default to ZFS, which allows quick cloning of src and ports directories. It is now much easier to manage and monitor the builds. Work on this is continuing. See the commits to Tools/portbuild/scripts for more information. (Work is ongoing to update the Package Building article.) Related work has involved cleaning up some of the ports infrastructure; in particular, the INDEX builds are now much faster. We have been able to do many -exp runs since the last report, including those for bsd.cmake.mk, autotools update, CC environment passing, the KDE 4.1 pre-integration and post-integration checks, lockmgr changes, tty changes, and others. Although a number of PRs have been closed, we are still at 57 portmgr PRs, the same as the last report. The following large changes are in the pipeline: * Introduction of Perl 5.10 We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, sparc64-6, and sparc64-7. RELENG_5 has reached the end of its supported life. We have added 4 new committers since the last report. Open tasks: 1. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 2. Although we have added many maintainers, we still have over 4,000 unmaintained ports (see, for instance, the list on portsmon). We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ Qt/KDE4 Status Report URL: http://freebsd.kde.org Contact: Martin Wilke Contact: FreeBSD KDE Team Qt4 has been updated to 4.4.1 in our test repository. We ran into some runtime problems with Qt 4.4.0, so it was never committed it to the ports tree. Most of the problems have been fixed in 4.4.1 and we plan to commit it in a few days. At the moment, the KDE 4.1 ports are ready for testing before they are committed to the FreeBSD ports tree. We have already had the first Call for Public Testing on July 17th, 2008 with KDE 4.1 beta2. The feedback has been positive so far. If you want to help to test them to speed up the process, please visit the Wiki page and provide feedback. We plan to have it all committed by the middle of August. __________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd-nl.org URL: http://www.evilcoder.org/freebsd_nl/ Contact: Remko Lodder Contact: Rene Ladan The FreeBSD Dutch Documentation Project is an ongoing project to translate the FreeBSD Documentation resources to the Dutch language. The project is currently progressing very well in translating the FreeBSD Handbook to the Dutch language, the last chapter is being translated by the project members. Recent achievements include the translation of the Jails chapter, and the Virtualization chapter, as well as progression on the Advanced Networking chapter. Rene Ladan is a keyplayer in that region. We also started with the FAQ translation, which is another major target which we should be reaching at some point. If you care to helpout with the translation(s) and/or want to know something about it, please do not hesitate to contact us, we are glad to help where possible. Open tasks: 1. Finish the Handbook translation. 2. Finish the FAQ translation. 3. Finish the Website translation. 4. Keep the projects in sync with the English version(s). __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu_HU.ISO8859-2/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli Hungarian translation of the FreeBSD Handbook has been finally committed to the doc repository. The translation of the FreeBSD FAQ has also been started, however, the original document needed to be brought up to date first. Two other article translations has been added, compiz-fusion and linux-users. Our Perforce depot was reorganized for the better layout, giving newcomers more space to play. The checkupdate script written by Giorgos Keramidas, a new tool for checking translations has been adopted to help the project's work. Open tasks: 1. Translate release notes for -CURRENT and 7.X. 2. Translate more articles. 3. Translate books/fdp-primer. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://FreeBSD.org/es URL: http://www.FreeBSD.org/doc/es_ES.ISO8859-1/ URL: http://wiki.FreeBSD.org/SpanishDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_es/&c=S1s@// depot/projects/docproj_es/?ac=83 Contact: José Vicente Carrasco Vayá Contact: Gábor Kövesdán We have not made any significant progress in this period. We definitely need more active translators to progress with the translation project. Open tasks: 1. Complete renovation of the Spanish web site. 2. Update Handbook translation. 3. Translate release notes for -CURRENT and 7.X. __________________________________________________________________ USB URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/usb/src/sys/dev/usb2 /&c=oDu@//depot/projects/usb/src/sys/dev/usb2/?ac=83 URL: http://p4web.freebsd.org/@md=d&cd=//&cdf=//depot/projects/usb/src/sys/d ev/usb2/core/README.TXT&c=Vfw@//depot/projects/usb/src/sys/dev/usb2/cor e/README.TXT?ac=64&rev1=2 Contact: Hans Petter Sirevaag Selasky During the last three months there has been a number of changes. Most notably all global USB symbols have been renamed to "usb2_" to allow for co-existence with the old USB stack. Also there is now a completely new and reworked UGEN driver which allows multiple drivers to hook onto the same USB device. No more need to unload any kernel drivers. For example it is now possible to have a userland Mouse driver stealing half of the mouse events at the same time "ums" is loaded. The only disadvantage is that your mouse cursor will move slower on the screen. This is maybe not the most common use-case, but it illustrates that kernel USB drivers are no longer locking out other USB userland drivers. A new userland libusb is in the works for FreeBSD. The USB stack now also has support for independent USB BUS, USB Device, and USB Interface permissions. That means you can more easily give USB permissions to USB device drivers at either USB BUS, USB Device or USB Interface level. All USB modules have now been grouped into functional categories: usb2_bluetooth, usb2_ndis, usb2_controller, usb2_quirk, usb2_core, usb2_serial, usb2_ethernet, usb2_sound, usb2_image, usb2_storage, usb2_input, usb2_template, usb2_misc, and usb2_wlan. Ideas and comments with regard to the new USB API are welcome on the FreeBSD-USB Mailing List. __________________________________________________________________ From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 17:57: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 B3CC5106566B; Wed, 20 Aug 2008 17:57:08 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from kilimanjaro.scorpionshops.com (kilimanjaro.scorpionshops.com [83.140.32.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE898FC16; Wed, 20 Aug 2008 17:57:07 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from [192.168.1.128] (144.Red-83-49-238.dynamicIP.rima-tde.net [83.49.238.144]) by kilimanjaro.scorpionshops.com (Postfix) with ESMTP id 08CD0D3803B; Wed, 20 Aug 2008 19:57:05 +0200 (CEST) From: Johan Kuuse Organization: Red Antigua To: John Baldwin Date: Wed, 20 Aug 2008 19:56:58 +0200 User-Agent: KMail/1.9.7 References: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> <200808121439.48158.jhb@freebsd.org> In-Reply-To: <200808121439.48158.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808201956.58751.kuuse@redantigua.com> Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic 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, 20 Aug 2008 17:57:08 -0000 On Tuesday 12 August 2008 20:39:47 John Baldwin wrote: > On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote: > > > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > > >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: > > >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > >> > > Hi, > > >> > > > > >> > > I am a kgdb newbie, so please be patient. > > >> > > I suspect (just based on the fact that this is the 4th time I edit > text > > >> > > > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting > > >> > frequent I/O error messages inside Emacs, and then a kernel panic) that > > >> > this is a ntfs-3g related problem. > > >> > > > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you > > >> > > exactly > > >> > > > >> > (but see the kgdb output below). > > >> > > > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > >> > > > > >> > > Just a suggestion for a patch (without knowing the functionality > > >> > > > >> > of /usr/src/sys/kern/vfs_bio.c): > > >> > > The line where the kernel panics: > > >> > > /usr/src/sys/kern/vfs_bio.c: > > >> > > ---------------------------------- > > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Comparing to another file, which does error checking before calling > > >> > > > >> > VM_OBJECT_LOCK: > > >> > > /usr/src/sys/kern/vfs_aio.c: > > >> > > ---------------------------------- > > >> > > if (vp->v_object != NULL) { > > >> > > VM_OBJECT_LOCK(vp->v_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Perhaps the kernel panic could be avoided with the following patch? > > >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > >> > > ---------------------------------- > > >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Please let me know if you need more information. > > >> > > > > >> > > Regards, > > >> > > Johan Kuuse > > >> > > > > >> > > > ----------------------------------------------------------------------- > > >> > >------------------------------------ kgdb kernel.debug > > >> > > /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 "i386-marcel-freebsd". > > >> > > > > >> > > Unread portion of the kernel message buffer: > > >> > > > > >> > > > > >> > > Fatal trap 12: page fault while in kernel mode > > >> > > cpuid = 0; apic id = 00 > > >> > > fault virtual address = 0x34 > > >> > > fault code = supervisor read, page not present > > >> > > instruction pointer = 0x20:0xc07b6de4 > > >> > > stack pointer = 0x28:0xe79de7c8 > > >> > > frame pointer = 0x28:0xe79de7e8 > > >> > > code segment = base 0x0, limit 0xfffff, type 0x1b > > >> > > = DPL 0, pres 1, def32 1, gran 1 > > >> > > processor eflags = interrupt enabled, resume, IOPL = 0 > > >> > > current process = 1214 (opera) > > >> > > trap number = 12 > > >> > > panic: page fault > > >> > > cpuid = 0 > > >> > > Uptime: 5h20m30s > > >> > > Physical memory: 2035 MB > > >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > >> > > > > >> > > #0 doadump () at pcpu.h:195 > > >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > >> > > (kgdb) list *0xc07b6de4 > > >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > >> > > 1525 vfs_vmio_release(struct buf *bp) > > >> > > 1526 { > > >> > > 1527 int i; > > >> > > 1528 vm_page_t m; > > >> > > 1529 > > >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > 1531 vm_page_lock_queues(); > > >> > > 1532 for (i = 0; i < bp->b_npages; i++) { > > >> > > 1533 m = bp->b_pages[i]; > > >> > > 1534 bp->b_pages[i] = NULL; > > >> > > (kgdb) bt > > >> > > #0 doadump () at pcpu.h:195 > > >> > > #1 0xc0754457 in boot (howto=260) at > > >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > > >> > > (fmt=Variable "fmt" is not available. > > >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:899 > > >> > > > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:812 > > >> > > > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:490 > > >> > > > >> > > #6 0xc0a2fc0b in calltrap () > at /usr/src/sys/i386/i386/exception.s:139 > > >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > > >> > > > >> > at /usr/src/sys/kern/vfs_bio.c:1530 > > >> > > > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > > >> > > "size" is > > >> > > > >> > not available. > > >> > > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, > slpflag=0, > > >> > > > >> > slptimeo=0, flags=Variable "flags" is not available. > > >> > > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > > >> > > > >> > startoffset=Variable "startoffset" is not available. > > >> > > > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > > >> > > > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > >> > > > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > > >> > > > >> > vnode_if.c:691 > > >> > > > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > > >> > > > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > > >> > > > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > > >> > > > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > > >> > > > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > > >> > > > >> > at /usr/src/sys/kern/sys_generic.c:401 > > >> > > > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > > >> > > > >> > at /usr/src/sys/kern/sys_generic.c:317 > > >> > > > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:1035 > > >> > > > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () > > >> > > > >> > at /usr/src/sys/i386/i386/exception.s:196 > > >> > > > >> > > #19 0x00000033 in ?? () > > >> > > Previous frame inner to this frame (corrupt stack?) > > >> > > > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > > >> > 6.x with NFS with no clues on what causes it. You can start by going > to > > >> > frame 7 and doing 'p *bp'. > > >> > > >> Thanks for the hints. > > >> See below for more debug output. > > >> I recognize that the bp struct members b_data and b_kvabase both point to > a > > >> chunk of memory containing the text of the Opera web page I was reading > > >> when the kernel crashed. (This is indicated above: current process > > >> = 1214 (opera)) > > >> > > >> But what is most interesting is that b_bufobj = 0x0 > > >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a > > >> crash. So I think it would be a good idea to NULL-check the struct member > > >> before trying to access it. How should I proceed? Should I post this as a > > >> possible bug somewhere else, to another list? > > > > > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means > there > > > is a bug elsewhere. I'll look at this some more. > > > > > > Hmm, can you reproduce this at all? If so, can you try the patch below. > > > Hopefully it panics here which might help: > > > > > > Index: vfs_subr.c > > > =================================================================== > > > --- vfs_subr.c (revision 181629) > > > +++ vfs_subr.c (working copy) > > > @@ -1546,6 +1546,9 @@ > > > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > > > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > > > > > + if (bp->flags & B_VMIO) > > > + panic("brelvp of B_VMIO buffer"); > > > + > > > /* > > > * Delete from old vnode list, if on one. > > > */ > > > > > > -- > > > John Baldwin > > > > > > > Sorry, at the moment I don't know how to reproduce the crash. > > I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy > load > > on my box, but in the end, it was Opera which caused the crash (also causing > a > > heavy load, however). > > What I can do is to apply your patch and play around with CPU-consuming apps > to > > try if I can reproduce the crash during heavy load. > > Ok. > > > Currently I'm running 7.-0-RELEASE. > > Do you recommend me to upgrade to STABLE before applying the patch? > > No, you can just leave it as it is. At work I've seen this occasionally on > 6.x, so it's probably an older bug. > Hi again, Finally the kernel got panic again, with your patch applied. Anyhow, it seems like it crashed in some other function this time. Also, I wonder about the message "No source file for address 0xc0d11b14." when I tried to list the address for the instruction pointer. Does this mean I did something wrong in the kernel patch or rebuild? I added a backtrace, please tell me if you need some more info. Regards, Johan -------------------------------------------------------------------------------- Patch a kernel # cd /usr/src/sys/kern # patch < /usr/home/kuuse/doc/freebsd-7.0-kernel-patch-john-baldwin.patch Build a kernel # cd /usr/src # make buildkernel KERNCONF=MYDEBUGKERNEL # make installkernel KERNCONF=MYDEBUGKERNEL Debug after new kernel crash: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html -------------------------------------------------------------------------------- cd /usr/obj/usr/src/sys/MYDEBUGKERNEL kgdb kernel.debug /var/crash/vmcore.2 -------------------------------------------------------------------------------- [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 "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d11b14 stack pointer = 0x28:0xe7acebc8 frame pointer = 0x28:0xe7acec10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2319 (opera) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h51m36s Physical memory: 2035 MB Dumping 253 MB: 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); -------------------------------------------------------------------------------- (kgdb) list *0xc0d11b14 -------------------------------------------------------------------------------- No source file for address 0xc0d11b14. -------------------------------------------------------------------------------- (kgdb) bt -------------------------------------------------------------------------------- #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe7aceb88, eva=16) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe7aceb88, usermode=0, eva=16) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe7aceb88) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0d11b14 in ?? () Previous frame inner to this frame (corrupt stack?) -------------------------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 18:15: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 B550D1065683 for ; Wed, 20 Aug 2008 18:15:31 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 241F78FC29 for ; Wed, 20 Aug 2008 18:15:30 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id m7KIFTJk086545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Aug 2008 20:15:29 +0200 (CEST) (envelope-from h.schmalzbauer@OmniLAN.de) Message-ID: <48AC5F38.401@OmniLAN.de> Date: Wed, 20 Aug 2008 20:15:20 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.16 (X11/20080808) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1210965790.00070991.1210954202@10.7.7.3> <1210965791.00070995.1210954203@10.7.7.3> <1210965792.00070997.1210954803@10.7.7.3> <1210969383.00071003.1210956601@10.7.7.3> <48318B97.5090200@icyb.net.ua> In-Reply-To: <48318B97.5090200@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4EDDBF91E153EBEDCA042A81" Subject: Re: udf 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, 20 Aug 2008 18:15:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EDDBF91E153EBEDCA042A81 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon schrieb am 19.05.2008 16:15 (localtime): > on 16/05/2008 19:48 Scott Long said the following: >> There is no write support in UDF in FreeBSD. When I wrote the fs code= , Should mount_udf work for UDF 1.02 DVDs? Today I tried to check an unlabled DVD, which was suspected to be a=20 vista copy, but I couldn't mount it: mount_udf: /dev/cd0: Invalid argument /dev/acd is completely broken for me since SATA drives... And burncd=20 stopped working long time ago in FreeBSD 7 (ATAPI, ICHx). Any hope to see these optical media issues beeing fixed for 7.1? Thanks, -Harry >> packet writing was the only way to do discrete writes, and it's very >> hard to make that work with a traditional VM system. Now with DVD+R, >> it's probably worth someone's time to look at it (though the append-on= ly >> nature of +R means that there are still some nasty VM complications to= >> deal with). Until that happens, mkisofs can be used to create a stati= c >> UDF filesystem. >=20 > BTW, Remko has kindly notified me that Reinoud Zandijk has completed hi= s > long work on UDF write support in NetBSD. I think that porting his work= > is our best chance to get write support in FreeBSD too. --------------enig4EDDBF91E153EBEDCA042A81 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) iEYEARECAAYFAkisX0EACgkQLDqVQ9VXb8h7EgCgoBS6H959Ym+jjfQfH+5jv+GZ i3IAnROHcmtV/UsS1+NL2WKpmG7u3LBM =1D34 -----END PGP SIGNATURE----- --------------enig4EDDBF91E153EBEDCA042A81-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 22:29: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 44E9A1065684 for ; Wed, 20 Aug 2008 22:29:23 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A10C78FC13 for ; Wed, 20 Aug 2008 22:29:22 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 20 Aug 2008 22:02:40 -0000 Received: from g227205215.adsl.alicedsl.de (EHLO m2a2.dyndns.org) [92.227.205.215] by mail.gmx.net (mp006) with SMTP; 21 Aug 2008 00:02:40 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+X5KMbXyaXSFnY6bhn1UYXBM9laNekgwl+wZ3zxa z0HdSm772+Ui1V Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 1408520117E for ; Thu, 21 Aug 2008 00:02:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at emma.line.org Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0oCyAfqoe4p for ; Thu, 21 Aug 2008 00:02:38 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 6E800201184; Thu, 21 Aug 2008 00:02:38 +0200 (CEST) From: Matthias Andree To: freebsd-stable@freebsd.org User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Thu, 21 Aug 2008 00:02:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Subject: "make delete-old" misses files, breaking KRB5-related builds 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, 20 Aug 2008 22:29:23 -0000 Greetings, I am a long-time user of FreeBSD (I think my oldest installations used to be 4.0 and have been upgraded ever since). Not quite recently, the build targets for "make delete-old" and "make delete-old-libs" were added, and I thought there were sort of useful to get rid of crap after updates. However, something somehow somewhen dropped old gssapi_generic.h and related files into /usr/include/gssapi which sat there waiting to wreak havoc on port builds on later 6.X or 7.0 releases. Either some port installed outside $PREFIX, or these used to be part of the system and got removed before the "make delete-old" framework was put into place. "Wreak havoc" means mislead configure scripts of several packages (GNOME-related in my case) to believe some other installation was there, but it wouldn't work because some parts of the system were missing/changed... I ended up manually figuring out what got installed and kill everything that had no source... an enormous effort. What I would like to have is a means of "compare what gets installed into /bin /sbin /libexec /lib /usr/bin /usr/sbin /usr/include /usr/lib /usr/libexec and other standard system directories" to what's actually in those directories - such a comparison would have easily allowed me to spot the problem areas. Comparing file dates doesn't work properly, else a find /usr /lib* /*bin -name local -prune -or \( -mtime 30 -print \) after a "make installworld" would be the easiest thing to do... but some parts of the system use install -C (probably to avoid excessive recompiling or relinking). So what's the canonical way to "installworld" into a staging area so I can just compare or rsync --del system directories? -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Wed Aug 20 22:47: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 5AFEC106567C for ; Wed, 20 Aug 2008 22:47:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 128B18FC16 for ; Wed, 20 Aug 2008 22:47:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m7KMataV005885; Wed, 20 Aug 2008 15:36:55 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m7KMatox005884; Wed, 20 Aug 2008 15:36:55 -0700 (PDT) (envelope-from david) Date: Wed, 20 Aug 2008 15:36:55 -0700 From: David Wolfskill To: Matthias Andree Message-ID: <20080820223655.GI801@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Matthias Andree , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fmvA4kSBHQVZhkR6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: "make delete-old" misses files, breaking KRB5-related builds 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, 20 Aug 2008 22:47:23 -0000 --fmvA4kSBHQVZhkR6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2008 at 12:02:38AM +0200, Matthias Andree wrote: > ... > Not quite recently, the build targets for "make delete-old" and > "make delete-old-libs" were added, and I thought there were sort of > useful to get rid of crap after updates. >=20 > However, something somehow somewhen dropped old gssapi_generic.h and > related files into /usr/include/gssapi which sat there waiting to wreak > havoc on port builds on later 6.X or 7.0 releases. Either some port > installed outside $PREFIX, or these used to be part of the system and > got removed before the "make delete-old" framework was put into place. > "Wreak havoc" means mislead configure scripts of several packages > (GNOME-related in my case) to believe some other installation was there, > but it wouldn't work because some parts of the system were > missing/changed... > ...=20 > So what's the canonical way to "installworld" into a staging area so I > can just compare or rsync --del system directories? > ... I don't promise that it's "canonical," but an approach that has stood me in good stead for several years has been to precede "make installworld" with rm -fr /usr/include.old && mv /usr/include{,.old} thus causing the "make installword" step to completely re-create /usr/include from scratch. Granted, this will be of reduced utility if there are any other procedures you use to update /usr/include. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --fmvA4kSBHQVZhkR6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkisnIYACgkQmprOCmdXAD3ExACggy8QSqen5+OG8+OXXW05kIvp IeUAoIMFU2NIGZD4Rd4f+yiyAxl9tlKH =r4D4 -----END PGP SIGNATURE----- --fmvA4kSBHQVZhkR6-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 01:02: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 460D8106567E for ; Thu, 21 Aug 2008 01:02:46 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 16FE28FC17 for ; Thu, 21 Aug 2008 01:02:46 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from localhost (unknown [200.46.204.183]) by hub.org (Postfix) with ESMTP id 2D2151D0BCC5; Wed, 20 Aug 2008 22:02:45 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 84665-10; Wed, 20 Aug 2008 22:02:37 -0300 (ADT) Received: from [192.168.1.2] (blk-224-204-104.eastlink.ca [24.224.204.104]) by hub.org (Postfix) with ESMTPA id 49A2B1D0BC65; Wed, 20 Aug 2008 22:02:09 -0300 (ADT) Date: Wed, 20 Aug 2008 22:02:04 -0300 From: "Marc G. Fournier" To: Claus Guttesen , "Marat N.Afanasyev" Message-ID: <4DB6352FE851FFBE3E648D21@ganymede.hub.org> In-Reply-To: References: <480C696A.4010804@ksu.ru> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org Subject: Re: php5 and postgresql 8.2/8.3 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, 21 Aug 2008 01:02:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Setting ServerName fixed it for me ... thanks for the tip ... - --On Monday, April 21, 2008 12:53:24 +0200 Claus Guttesen wrote: >> this problem is very old for me. it goes, at least from >> http://www.freebsd.org/cgi/query-pr.cgi?pr=97272 >> >> I found a workaround: you simply should set >> >> ServerName foobar.emxample >> >> in httpd.conf >> >> i don't know why missing ServerName causes coredump of apache in case of >> php+php_pgsql, but this works for me > > Thank you for your tip. I will try that on a test-server. Maby some > reverse dns-lookup-issue which blocks correct unloading which then > leads to a core-dump? > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > 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" - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkisvowACgkQ4QvfyHIvDvMaAgCgnXDNXY7G0d4gC1JghHxxFfvt n2gAoNQn+EabU6zMLJt0uYKWifHENfg/ =bf+C -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 07:49: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 B52C1106564A for ; Thu, 21 Aug 2008 07:49:25 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.servoy.com (mail.servoy.com [87.233.173.130]) by mx1.freebsd.org (Postfix) with SMTP id E64418FC12 for ; Thu, 21 Aug 2008 07:49:24 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 42167 invoked from network); 21 Aug 2008 07:49:23 -0000 Received: from unknown (HELO ?10.0.0.6?) (sebster@85.147.225.232) by mail.servoy.com with SMTP; 21 Aug 2008 07:49:23 -0000 Message-ID: <48AD1E05.1040502@sebster.com> Date: Thu, 21 Aug 2008 09:49:25 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Cian Hughes References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> <48A3FCF7.9030905@sebster.com> <8B25287C-7336-492C-B62E-CB319B8B5DBB@nHugh.es> In-Reply-To: <8B25287C-7336-492C-B62E-CB319B8B5DBB@nHugh.es> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020002050402090708090803" Cc: freebsd-stable@freebsd.org Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 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, 21 Aug 2008 07:49:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020002050402090708090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Cian Hughes wrote: > Sebastiaan, > Have you tried connecting your 250GB drives to the troublesome > controller? If so, does "stressing" them cause the system to panic? > > ~Cian Hughes Thanks for you reply. I have not tried stress-testing the 250GB drives on the troublesome controller. The problem with those drives is, that even though they are mirrored, the data is very important to me and I do not want it to get corrupted. I do have backups of course, but the problem with data corruption is that it often takes very long to notice... I was thinking of buying the Promise SATA300 TX4 PCI Controller. I've searched on google, and I do see some negative posts on them in combination with FreeBSD, however they all date back at least 2 years... Does anybody have positive/negative experiences using this card? Regards, Sebastiaan > -- > University of Bristol Medical School > > On 14 Aug 2008, at 10:37, Sebastiaan van Erk wrote: > >> Thanks Jonathan, >> >> I'm starting to expect it has to be the controller as well. About 20 >> minutes after I posted this message yesterday (and thus 20 minutes >> after ad6 got disconnected - atacontrol list showed "no device >> present" for it) the machine crashed while writing to the remaining >> ad4 drive (kernel panic). I attached the logs below. I also ran the >> long smart self test on both drives, and no errors were found on >> either drive (logs also attached). >> >> Unfortunately I could not attach the new disks to my mainboard SATA >> because my mainboard SATA somehow hangs trying to detect them. So I >> cannot test if *not* using the controller is going to solve the >> problems, though I'm it seems logical at the moment it has to be the >> controller, especially if other people have had similar issues. >> >> I guess I'll be buying another controller. >> >> Regards, >> Sebastiaan >> >> Jonathan Groll wrote: >>> On Wed, Aug 13, 2008 at 03:10:56PM +0200, Sebastiaan van Erk wrote: >>>> Hi, >>>> >>>> Just an update on this issue. >>>> >>>> Quick summary: I fixed the BIOS issues, the hardware monitor issues, >>>> and the rl0/rl1 watchdog timeout issues (it seems). However I'm >>>> still having problems with my SATA drives (or at least one of them). >>>> More info below. >>>> >>>> BIOS: >>>> I flashed my BIOS to the latest version about a year ago, and never >>>> noticed that there was any problem, but it turns out there was. I >>>> never reset the BIOS to default factory settings after the upgrade, >>>> and it seems the settings were corrupt. After having reset the BIOS >>>> to the "default optimized factory settings" it stopped crashing when >>>> I go into the H/W monitor and also when using healthd -d (output below): >>>> >>>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>>> Vcore = 1.44, 3.14; Volt. = 3.33, 4.97, 1.95, -0.11, -1.54 >>>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>>> Vcore = 1.44, 3.12; Volt. = 3.34, 4.97, 1.95, -0.11, -1.54 >>>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>>> >>>> This also seems to have fixed the rl0 watchdog timeout problems. I >>>> no longer see those in my logs. >>>> >>>> SATA DRIVES: >>>> >>>> I'm still having problems with the SATA drives. >>>> >>>> I tried connecting the 1TB Samsung drives to my mainboard, but then >>>> the box hangs when booting with the "Detecting IDE drives" message. >>>> The regular (PATA) IDE drives are detected first, and then it >>>> repeats the "Detecting IDE drives" message to detect the sata >>>> drives, and hangs. When I connect my 250GB SATA drives to my >>>> mainboard they detect fine, and the box boots normally. >>>> >>>> I did another rsync of my old mirror (the 250GB disks) to the new >>>> mirror (1TB disks), but again one of the disks got detached. This >>>> time there are no other messages in the log, the only thing I see is >>>> the following: >>>> >>>> Aug 13 14:35:27 piglet su: sebster to root on /dev/ttyp5 >>>> Aug 13 14:55:38 piglet kernel: ad6: FAILURE - device detached >>>> Aug 13 14:55:38 piglet kernel: subdisk6: detached >>>> Aug 13 14:55:38 piglet kernel: ad6: detached >>>> Aug 13 14:55:38 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 >>>> disconnected. >>>> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to >>>> size>100K >>>> >>>> (unfortunate that the log file just got rotated, but in the new log >>>> file there is nothing execpt the one expected line: >>>> >>>> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to >>>> size>100K >>>> >>>> So, nothing after the disconnect... >>>> >>>> The questions I have now is: >>>> 1) Could an upgrade to FreeBSD 7-STABLE fix the issue (it's a LOT of >>>> work for me, but I'll do it if there are SATA driver issues fixed). >>> I suspect the problem may be the SiI driver in Freebsd. As a reference >>> point, I've had a similar problem, even on 7-STABLE, but with sparc64 >>> hardware (see earlier post in this thread). >>> It'll probably be simplest for you to just buy another controller of >>> another brand. On the other hand, it'll be worth knowing exactly what >>> is wrong with the SiI driver... >>> Cheers, >>> Jonathan >> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to >> size>100K >> Aug 13 15:11:26 piglet su: sebster to root on /dev/ttyp4 >> Aug 13 15:34:55 piglet kernel: >> mirror/gm1s1e[WRITE(offset=875450693632, length=2048)]error = 6 >> Aug 13 15:34:55 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450695680, >> length=2048)]error = 6 >> >> [snip 335750 similar lines] >> >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450931200, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450933248, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450935296, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450937344, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450939392, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450941440, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450943488, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450945536, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450947584, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450949632, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450951680, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450953728, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450955776, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450957824, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450959872, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450961920, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450963968, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450966016, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450968064, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450970112, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450972160, >> length=2048)]error = 6 >> Aug 13 15:36:30 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=875450974208, >> length=2048)]error = 6 >> Aug 13 15:42:23 piglet syslogd: kernel boot file is /boot/kernel/kernel >> Aug 13 15:42:23 piglet kernel: Copyright (c) 1992-2008 The FreeBSD >> Project. >> smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 >> Bruce Allen >> Home page is http://smartmontools.sourceforge.net/ >> >> === START OF INFORMATION SECTION === >> Device Model: SAMSUNG HD103UJ >> Serial Number: S13PJ1BQ606865 >> Firmware Version: 1AA01112 >> User Capacity: 1,000,204,886,016 bytes >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: 8 >> ATA Standard is: ATA-8-ACS revision 3b >> Local Time is: Thu Aug 14 11:28:13 2008 CEST >> >> ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual >> for details. >> >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> >> === START OF READ SMART DATA SECTION === >> SMART overall-health self-assessment test result: PASSED >> >> General SMART Values: >> Offline data collection status: (0x02) Offline data collection activity >> was completed without error. >> Auto Offline Data Collection: Disabled. >> Self-test execution status: ( 0) The previous self-test routine >> completed >> without error or no self-test has ever >> been run. >> Total time to complete Offline >> data collection: (11811) seconds. >> Offline data collection >> capabilities: (0x7b) SMART execute Offline immediate. >> Auto Offline data collection on/off support. >> Suspend Offline collection upon new >> command. >> Offline surface scan supported. >> Self-test supported. >> Conveyance Self-test supported. >> Selective Self-test supported. >> SMART capabilities: (0x0003) Saves SMART data before entering >> power-saving mode. >> Supports SMART auto save timer. >> Error logging capability: (0x01) Error logging supported. >> General Purpose Logging supported. >> Short self-test routine >> recommended polling time: ( 2) minutes. >> Extended self-test routine >> recommended polling time: ( 198) minutes. >> Conveyance self-test routine >> recommended polling time: ( 21) minutes. >> SCT capabilities: (0x003f) SCT Status supported. >> SCT Feature Control supported. >> SCT Data Table supported. >> >> SMART Attributes Data Structure revision number: 16 >> Vendor Specific SMART Attributes with Thresholds: >> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE >> UPDATED WHEN_FAILED RAW_VALUE >> 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail >> Always - 0 >> 3 Spin_Up_Time 0x0007 076 076 011 Pre-fail >> Always - 8010 >> 4 Start_Stop_Count 0x0032 100 100 000 Old_age >> Always - 8 >> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail >> Always - 0 >> 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail >> Always - 0 >> 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail >> Offline - 10255 >> 9 Power_On_Hours 0x0032 100 100 000 Old_age >> Always - 272 >> 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail >> Always - 0 >> 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age >> Always - 0 >> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age >> Always - 8 >> 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age >> Always - 0 >> 183 Unknown_Attribute 0x0032 100 100 000 Old_age >> Always - 0 >> 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail >> Always - 0 >> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age >> Always - 0 >> 188 Unknown_Attribute 0x0032 100 100 000 Old_age >> Always - 0 >> 190 Airflow_Temperature_Cel 0x0022 057 052 000 Old_age >> Always - 43 (Lifetime Min/Max 43/48) >> 194 Temperature_Celsius 0x0022 056 050 000 Old_age >> Always - 44 (Lifetime Min/Max 43/50) >> 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age >> Always - 195799724 >> 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age >> Always - 0 >> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age >> Always - 0 >> 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age >> Offline - 0 >> 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age >> Always - 0 >> 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age >> Always - 0 >> 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age >> Always - 0 >> >> SMART Error Log Version: 1 >> No Errors Logged >> >> SMART Self-test log structure revision number 0 >> Warning: ATA Specification requires self-test log structure revision >> number = 1 >> Num Test_Description Status Remaining >> LifeTime(hours) LBA_of_first_error >> # 1 Offline Completed without error 00% 261 >> - >> # 2 Offline Aborted by host 40% 251 >> - >> # 3 Short offline Aborted by host 00% 250 >> - >> >> SMART Selective Self-Test Log Data Structure Revision Number (0) >> should be 1 >> SMART Selective self-test log data structure revision number 0 >> Warning: ATA Specification requires selective self-test log data >> structure revision number = 1 >> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS >> 1 0 0 Not_testing >> 2 0 0 Not_testing >> 3 0 0 Not_testing >> 4 0 0 Not_testing >> 5 0 0 Not_testing >> Selective self-test flags (0x0): >> After scanning selected spans, do NOT read-scan remainder of disk. >> If Selective self-test is pending on power-up, resume after 0 minute >> delay. >> >> smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 >> Bruce Allen >> Home page is http://smartmontools.sourceforge.net/ >> >> === START OF INFORMATION SECTION === >> Device Model: SAMSUNG HD103UJ >> Serial Number: S13PJ1BQ607102 >> Firmware Version: 1AA01112 >> User Capacity: 1,000,204,886,016 bytes >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: 8 >> ATA Standard is: ATA-8-ACS revision 3b >> Local Time is: Thu Aug 14 11:28:39 2008 CEST >> >> ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual >> for details. >> >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> >> === START OF READ SMART DATA SECTION === >> SMART overall-health self-assessment test result: PASSED >> >> General SMART Values: >> Offline data collection status: (0x02) Offline data collection activity >> was completed without error. >> Auto Offline Data Collection: Disabled. >> Self-test execution status: ( 0) The previous self-test routine >> completed >> without error or no self-test has ever >> been run. >> Total time to complete Offline >> data collection: (12131) seconds. >> Offline data collection >> capabilities: (0x7b) SMART execute Offline immediate. >> Auto Offline data collection on/off support. >> Suspend Offline collection upon new >> command. >> Offline surface scan supported. >> Self-test supported. >> Conveyance Self-test supported. >> Selective Self-test supported. >> SMART capabilities: (0x0003) Saves SMART data before entering >> power-saving mode. >> Supports SMART auto save timer. >> Error logging capability: (0x01) Error logging supported. >> General Purpose Logging supported. >> Short self-test routine >> recommended polling time: ( 2) minutes. >> Extended self-test routine >> recommended polling time: ( 203) minutes. >> Conveyance self-test routine >> recommended polling time: ( 22) minutes. >> SCT capabilities: (0x003f) SCT Status supported. >> SCT Feature Control supported. >> SCT Data Table supported. >> >> SMART Attributes Data Structure revision number: 16 >> Vendor Specific SMART Attributes with Thresholds: >> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE >> UPDATED WHEN_FAILED RAW_VALUE >> 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail >> Always - 0 >> 3 Spin_Up_Time 0x0007 077 077 011 Pre-fail >> Always - 7810 >> 4 Start_Stop_Count 0x0032 100 100 000 Old_age >> Always - 10 >> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail >> Always - 0 >> 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail >> Always - 0 >> 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail >> Offline - 9978 >> 9 Power_On_Hours 0x0032 100 100 000 Old_age >> Always - 272 >> 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail >> Always - 0 >> 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age >> Always - 0 >> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age >> Always - 10 >> 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age >> Always - 0 >> 183 Unknown_Attribute 0x0032 100 100 000 Old_age >> Always - 0 >> 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail >> Always - 0 >> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age >> Always - 0 >> 188 Unknown_Attribute 0x0032 100 100 000 Old_age >> Always - 0 >> 190 Airflow_Temperature_Cel 0x0022 059 054 000 Old_age >> Always - 41 (Lifetime Min/Max 41/46) >> 194 Temperature_Celsius 0x0022 058 053 000 Old_age >> Always - 42 (Lifetime Min/Max 41/47) >> 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age >> Always - 31616 >> 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age >> Always - 0 >> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age >> Always - 0 >> 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age >> Offline - 0 >> 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age >> Always - 0 >> 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age >> Always - 0 >> 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age >> Always - 0 >> >> SMART Error Log Version: 1 >> No Errors Logged >> >> SMART Self-test log structure revision number 0 >> Warning: ATA Specification requires self-test log structure revision >> number = 1 >> Num Test_Description Status Remaining >> LifeTime(hours) LBA_of_first_error >> # 1 Offline Completed without error 00% 261 >> - >> # 2 Offline Aborted by host 40% 251 >> - >> # 3 Short offline Aborted by host 00% 250 >> - >> >> SMART Selective Self-Test Log Data Structure Revision Number (0) >> should be 1 >> SMART Selective self-test log data structure revision number 0 >> Warning: ATA Specification requires selective self-test log data >> structure revision number = 1 >> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS >> 1 0 0 Not_testing >> 2 0 0 Not_testing >> 3 0 0 Not_testing >> 4 0 0 Not_testing >> 5 0 0 Not_testing >> Selective self-test flags (0x0): >> After scanning selected spans, do NOT read-scan remainder of disk. >> If Selective self-test is pending on power-up, resume after 0 minute >> delay. >> > --------------ms020002050402090708090803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgyMTA3NDkyNVowIwYJKoZI hvcNAQkEMRYEFCc+b5BXg4m2PKX1o77PDSqBVoDbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQU3wNqsw264okMS1+zRRqpTCBhwYLKoZIhvcNAQkQAgsxeKB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQU3wNqsw2 64okMS1+zRRqpTANBgkqhkiG9w0BAQEFAASCAQCI+NihGjX0tE6KYrGMFAXj1ExxKwelmBYy f/3OzknviClbd2D5+MYGB1Lue6YdEbaJ/hCdeSPyblfYpGwNkY3dBylb0gPQE9yVxHfgVZME O9WCLjDjIFRsaOSzAafqQgeZTK7x7gRXqXs9DhhjgLOB2mY0kTQENAPXJCCiuyC1gVVM9LYq jfytO8rTht0EIOLkVjJEeG4GavfetZd8bJqUcdkPeZlnvoKudocyDmI2NKB1x2UBl74bMi0E ZZMKkywAXzQPL73nxOyeBmJb+GPp9AW2pu0TSENV5nFKgWcQvYTorIgLkhW0lqGuxfTWXi/p 2oYwFqxNRqyIdHmd9Ex/AAAAAAAA --------------ms020002050402090708090803-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 12:34: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 4D07D1065673 for ; Thu, 21 Aug 2008 12:34:57 +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 3929B8FC15 for ; Thu, 21 Aug 2008 12:34:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 22A4A1CC0BE; Thu, 21 Aug 2008 05:34:57 -0700 (PDT) Date: Thu, 21 Aug 2008 05:34:57 -0700 From: Jeremy Chadwick To: Sebastiaan van Erk Message-ID: <20080821123457.GA99701@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> <48A3FCF7.9030905@sebster.com> <8B25287C-7336-492C-B62E-CB319B8B5DBB@nHugh.es> <48AD1E05.1040502@sebster.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AD1E05.1040502@sebster.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Cian Hughes Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 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, 21 Aug 2008 12:34:57 -0000 On Thu, Aug 21, 2008 at 09:49:25AM +0200, Sebastiaan van Erk wrote: > I was thinking of buying the Promise SATA300 TX4 PCI Controller. I've > searched on google, and I do see some negative posts on them in > combination with FreeBSD, however they all date back at least 2 years... > > Does anybody have positive/negative experiences using this card? I have one of these cards (not currently in use; less stuff inside my FreeBSD box at home the better), and never ran into any oddities. That was with 4 disks connected, each disk its own UFS2 filesystem. ZFS wasn't available back then. -- | 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 Aug 21 12:58:36 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 55E1A106566C for ; Thu, 21 Aug 2008 12:58:36 +0000 (UTC) (envelope-from dpelleg@lawrence.libagent.org) Received: from lawrence.libagent.org (lawrence.libagent.org [69.60.120.231]) by mx1.freebsd.org (Postfix) with ESMTP id 22E428FC13 for ; Thu, 21 Aug 2008 12:58:36 +0000 (UTC) (envelope-from dpelleg@lawrence.libagent.org) Received: from localhost (unknown [127.0.0.1]) by lawrence.libagent.org (Postfix) with ESMTP id 45C13B2415; Thu, 21 Aug 2008 15:58:35 +0300 (IDT) X-Virus-Scanned: amavisd-new at libagent.org Received: from lawrence.libagent.org ([127.0.0.1]) by localhost (lawrence.libagent.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XT0tOjtSXMbW; Thu, 21 Aug 2008 15:58:29 +0300 (IDT) Received: by lawrence.libagent.org (Postfix, from userid 1002) id 3369EB2413; Thu, 21 Aug 2008 15:58:29 +0300 (IDT) Date: Thu, 21 Aug 2008 15:58:29 +0300 From: Dan Pelleg To: Ben Kelly Message-ID: <20080821125829.GA84028@lawrence.libagent.org> References: <20080818191404.GA44910@lawrence.libagent.org> <94ed778a15f2fa16bbcd0fa0d68128e0@mail.vadev.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94ed778a15f2fa16bbcd0fa0d68128e0@mail.vadev.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: nanobsd build problem 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, 21 Aug 2008 12:58:36 -0000 On Mon, Aug 18, 2008 at 08:43:22PM +0000, Ben Kelly wrote: > > On Mon, 18 Aug 2008 22:14:04 +0300, Dan Pelleg > wrote: > > I'm trying to build nanobsd. I get the error below. Any ideas? > > > > /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error: > > time.h: No such file or directory > > *** Error code 1 > > Do you have WITHOUT_TOOLCHAIN set? That option currently only works for > the install target, not the build target. > > Hope that helps. > > - Ben Bingo. Unsetting it fixed the issue. Thanks! -- Dan From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 13:55: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 AED2A106564A for ; Thu, 21 Aug 2008 13:55:04 +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 79B6C8FC1A for ; Thu, 21 Aug 2008 13:55:04 +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 m7LDsvYs030042 for ; Thu, 21 Aug 2008 09:54:57 -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 m7LDsvse084114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Aug 2008 09:54:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808211354.m7LDsvse084114@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Aug 2008 09:54:57 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: working around TOE bug 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, 21 Aug 2008 13:55:04 -0000 I dont have too many production RELENG_7 boxes post TOE MFC, but on the ones I do, apart from applying # diff -u src/sys/netinet/tcp_offload.c src/sys/netinet/tcp_offload.c.disable --- src/sys/netinet/tcp_offload.c 2008-07-31 18:25:51.000000000 -0400 +++ src/sys/netinet/tcp_offload.c.disable 2008-08-21 09:39:07.000000000 -0400 @@ -58,6 +58,8 @@ struct rtentry *rt; int error; + return (EINVAL); + /* * Look up the route used for the connection to * determine if it uses an interface capable of is there a better way to disable it ? Does having it in cause any performance issues ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 17:21: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 76E4F106566B for ; Thu, 21 Aug 2008 17:21:03 +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 DF18A8FC0C for ; Thu, 21 Aug 2008 17:21:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.2/8.14.2) with ESMTP id m7LHL01l010465; Thu, 21 Aug 2008 19:21:00 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.2/8.14.2/Submit) id m7LHKw27010464; Thu, 21 Aug 2008 19:20:58 +0200 (CEST) (envelope-from olli) Date: Thu, 21 Aug 2008 19:20:58 +0200 (CEST) Message-Id: <200808211720.m7LHKw27010464@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, h.schmalzbauer@omnilan.de In-Reply-To: <48AC5F38.401@OmniLAN.de> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-STABLE (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]); Thu, 21 Aug 2008 19:21:01 +0200 (CEST) Cc: Subject: Re: udf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, h.schmalzbauer@omnilan.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2008 17:21:03 -0000 Harald Schmalzbauer wrote: > /dev/acd is completely broken for me since SATA drives... And burncd > stopped working long time ago in FreeBSD 7 (ATAPI, ICHx). > Any hope to see these optical media issues beeing fixed for 7.1? I haven't tried using burncd in a long time, but cdrecord-devel and dvd+rw-tools (both from ports) work fine for me. Be sure to have options atapicam in your kernel. 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 "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 17:44: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 285741065676 for ; Thu, 21 Aug 2008 17:44:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 052EF8FC0C for ; Thu, 21 Aug 2008 17:44:26 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 31BEE1A011398; Thu, 21 Aug 2008 10:27:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xm8790ZFTnzL; Thu, 21 Aug 2008 10:27:00 -0700 (PDT) Received: from coal (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 3B3D21A009B00; Thu, 21 Aug 2008 10:27:00 -0700 (PDT) From: Freddie Cash To: freebsd-stable@freebsd.org, h.schmalzbauer@omnilan.de Date: Thu, 21 Aug 2008 10:26:59 -0700 User-Agent: KMail/1.9.9 References: <200808211720.m7LHKw27010464@lurza.secnetix.de> In-Reply-To: <200808211720.m7LHKw27010464@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808211026.59800.fjwcash@gmail.com> Cc: Subject: Re: udf 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, 21 Aug 2008 17:44:27 -0000 On August 21, 2008 10:20 am Oliver Fromme wrote: > Harald Schmalzbauer wrote: > > /dev/acd is completely broken for me since SATA drives... And burncd > > stopped working long time ago in FreeBSD 7 (ATAPI, ICHx). > > Any hope to see these optical media issues beeing fixed for 7.1? > > I haven't tried using burncd in a long time, but > cdrecord-devel and dvd+rw-tools (both from ports) > work fine for me. Be sure to have options atapicam > in your kernel. For FreeBSD 7+ (and I think 6.2+), atapicam can be loaded as a module. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 18:05: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 159531065672 for ; Thu, 21 Aug 2008 18:05:27 +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 E709A8FC13 for ; Thu, 21 Aug 2008 18:05:26 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 22230 invoked from network); 21 Aug 2008 17:38:45 -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 ; 21 Aug 2008 17:38:44 -0000 Message-ID: <48ADA81E.7090106@aldan.algebra.com> Date: Thu, 21 Aug 2008 13:38:38 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 18:05:27 -0000 Hello! A machine I manage remotely for a friend comes under a distributed ssh break-in attack every once in a while. Annoyed (and alarmed) by the messages like: Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 I wrote an awk-script, which adds a block of the attacking IP-address to the ipfw-rules after three such "invalid user" attempts with: ipfw add 550 deny ip from ip The script is fed by syslogd directly -- through a syslog.conf rule ("|/opt/sbin/auth-log-watch"). Once in a while I manually flush these rules... I this a good (safe) reaction? I'm asking, because the machine (currently running 7.0 as of July 7) hangs solid once every few weeks... My only guess is that a spike in attacks causes "too many" ipfw-entries created, which paralyzes the kernel due to some bug -- the machine is running natd and is the gateway for the rest of the network... The hangs could, of course, be caused by something else entirely, but my self-defense mechanism is my first suspect... Any comments? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 18:05: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 56FB51065687 for ; Thu, 21 Aug 2008 18:05:53 +0000 (UTC) (envelope-from baigsabeeh@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id DA5A78FC16 for ; Thu, 21 Aug 2008 18:05:52 +0000 (UTC) (envelope-from baigsabeeh@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so49229uge.39 for ; Thu, 21 Aug 2008 11:05:51 -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=ppEeHBT4qk4DcMCcFf0hXL4lEVkxKzSG6BRlA+Htpy0=; b=W3HxwRd65mwKcZbhcE7MYp4CX9RqwN93gvI9akvTqsjG7f25bGE9r3GvefrFe296IU 6o/dsl4c3ks4HQKyo4qPK8+GMKoXb+PYInoYdIRVSVF/5i1Ot/eEtlpsmZHllyG3xyK+ l1Qmd52fIByXo6J3DeBcCp6dz4G7upWAm6KeE= 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=RRo9crUz1FAvjKoUdQzMtqSM4Uml3XJBkvhRrVAT71Gau2Xhnkfqi2AGfa6rCQsR+f 9IbMlW0j5IEhVfyzYyYVbOTiib5z1PhEVEE4tRYdeLaGnvMNrCYV5ytBNgcmXuJMcSC7 1ip3NKnFdporz67ytwzwvqueNmaESK+Jur7dY= Received: by 10.67.28.14 with SMTP id f14mr1679125ugj.85.1219341950759; Thu, 21 Aug 2008 11:05:50 -0700 (PDT) Received: by 10.67.10.12 with HTTP; Thu, 21 Aug 2008 11:05:50 -0700 (PDT) Message-ID: Date: Thu, 21 Aug 2008 14:05:50 -0400 From: "Sabeeh Baig" 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: Memory Usage Stats 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, 21 Aug 2008 18:05:53 -0000 I've been noticing never-before-seen highs in memory usage, since the last time I rebuilt world a bout a week ago. I have 2GB of memory and 2GB of swap space. According to top, a little over 1GB of memory is active, 70MB free, 300MB wired, and the rest inactive. I also have 59MB of swap used. If I close an application, the amount of active memory never decreases and the other stats don't change either. The active figure can't be right even now, as I only have Xfce, Xorg, screen, two zsh session, slurm, irssi, pidgin, mpd, ncmpc, and irssi running. That's usually my normal session and usage has been better before I recompiled. Is it possible that top is displaying the wrong stats? Is there any other utility I could try? I've tried ps auxm, but that's not exactly what I'm looking for. -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Sabeeh Ahmed Baig From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 18:31:34 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 80CA61065673 for ; Thu, 21 Aug 2008 18:31:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDA98FC1D for ; Thu, 21 Aug 2008 18:31:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m7LIVVTr008995; Thu, 21 Aug 2008 11:31:31 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m7LIVUVj008994; Thu, 21 Aug 2008 11:31:30 -0700 (PDT) (envelope-from david) Date: Thu, 21 Aug 2008 11:31:30 -0700 From: David Wolfskill To: Mikhail Teterin Message-ID: <20080821183130.GQ801@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Mikhail Teterin , freebsd-security@freebsd.org, freebsd-stable@freebsd.org References: <48ADA81E.7090106@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+r+clu82y77Ss1pj" Content-Disposition: inline In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 18:31:34 -0000 --+r+clu82y77Ss1pj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2008 at 01:38:38PM -0400, Mikhail Teterin wrote: > ... > I wrote an awk-script, which adds a block of the attacking IP-address to= =20 > the ipfw-rules after three such "invalid user" attempts with: >=20 > ipfw add 550 deny ip from ip >=20 > The script is fed by syslogd directly -- through a syslog.conf rule=20 > ("|/opt/sbin/auth-log-watch"). > ...=20 At a previous employer, we were building mail relay boxen (FreeBSD 6.0 - 6.2 timeframe); at one point, It Was Decided that rather than having /var/log/maillog written directly by syslogd(8), syslogd(8) would feed a Perl script that would do some "Database Things" and then get around to appending to /var/log/maillog itself. While the amount of work involved was assuredly greater in that case than in yours, those of us who were actually building and running the relays in question were very unsurprised when Postfix performance improved significantly following a redesign of the application, so that /var/log/maillog was written by syslogd(8) and the Perl script was effectively fed via "tail -F". > Once in a while I manually flush these rules... I this a good (safe)=20 > reaction? I also see such things (on my home "firewall" machine); my approach is quite a bit different. If folks are interested, I could probably discuss it a bit, but I believe that would be, at best, tangential to your note, and thus ought not be crafted as if it were part of the thread -- and definitely does not warrant the cross-post. > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+r+clu82y77Ss1pj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkittIIACgkQmprOCmdXAD22uwCfbM1kpezwsRsPJt/4t20j0LBN HSUAnjLBhFMC02ACxdm8wk1QQH7WARup =Bmrv -----END PGP SIGNATURE----- --+r+clu82y77Ss1pj-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 18:49: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 874D9106568D for ; Thu, 21 Aug 2008 18:49:50 +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 3E9B18FC23 for ; Thu, 21 Aug 2008 18:49:50 +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 BAS71848; Thu, 21 Aug 2008 11:49:48 -0700 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id BAS79347; Thu, 21 Aug 2008 11:49:47 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BDAE94500F; Thu, 21 Aug 2008 11:49:47 -0700 (PDT) To: Mikhail Teterin In-Reply-To: Your message of "Thu, 21 Aug 2008 13:38:38 EDT." <48ADA81E.7090106@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1219344587_4113P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 21 Aug 2008 11:49:47 -0700 From: "Kevin Oberman" Message-Id: <20080821184947.BDAE94500F@ptavv.es.net> X-Sender-IP: 198.128.3.207 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Mikhail Teterin X-To_Domain: aldan.algebra.com X-To: Mikhail Teterin X-To_Email: mi+mill@aldan.algebra.com X-To_Alias: mi+mill Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 18:49:50 -0000 --==_Exmh_1219344587_4113P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Thu, 21 Aug 2008 13:38:38 -0400 > From: Mikhail Teterin > Sender: owner-freebsd-stable@freebsd.org > > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the gateway > for the rest of the network... > The hangs could, of course, be caused by something else entirely, but my > self-defense mechanism is my first suspect... > > Any comments? Thanks! Looks remarkably like sshguard (ports/security/sshguard-*). It does almost exactly what you are doing but is written in C and has command-line switches to set how long a system is blocked, how many attempts constitute an attack and how long it should remember failed attempts. It also allows the use of back-end scripts if you want it to do something else such as generate reports (beyond an entry in /var/log/messages). As far as the hangs, I don't believe it is from the large nu,ber of brute force attempts as they will stop for a given host as soon as the firewall is updated. I seldom see more than a handful of attack sources over any short period. Should you want to continue with your own tool, at least for IPv4, consider using tables rather than a raft of rules. With tables, you need only a single rule and it is there at boot time. -- 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_1219344587_4113P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIrbjLkn3rs5h7N1ERAr+5AKC6DasTJv7CXULO/qPN71qXh0/K5gCeMKPa ZXC9S7GRmW/vP4S03avkaZk= =u5hk -----END PGP SIGNATURE----- --==_Exmh_1219344587_4113P-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 19:42: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 109451065684 for ; Thu, 21 Aug 2008 19:42:49 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id DE3808FC0A for ; Thu, 21 Aug 2008 19:42:48 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 22298 invoked from network); 21 Aug 2008 19:42:48 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Aug 2008 19:42:48 -0000 Message-ID: <48ADC537.8030807@aldan.algebra.com> Date: Thu, 21 Aug 2008 15:42:47 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: David Wolfskill , freebsd-stable@freebsd.org References: <48ADA81E.7090106@aldan.algebra.com> <20080821183130.GQ801@bunrab.catwhisker.org> In-Reply-To: <20080821183130.GQ801@bunrab.catwhisker.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: feeding log-messages (Re: machine hangs on occasion - correlated with ssh break-in attempts) 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, 21 Aug 2008 19:42:49 -0000 David Wolfskill ÎÁÐÉÓÁ×(ÌÁ): > While the amount of work involved was assuredly greater in that case > than in yours, those of us who were actually building and running the > relays in question were very unsurprised when Postfix performance > improved significantly following a redesign of the application, so > that /var/log/maillog was written by syslogd(8) and the Perl script > was effectively fed via "tail -F". In my setup, syslogd does both -- append the message to the appropriate log-file (in this case -- /var/log/auth.log) and feed it to the script's stdin. From syslogd.conf: auth.info;authpriv.info /var/log/auth.log auth.info;authpriv.info |/opt/sbin/auth-log-watch "tail -F" seems just wrong :-) -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 19:54: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 EE5DF1065674 for ; Thu, 21 Aug 2008 19:54:17 +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 C7FA98FC15 for ; Thu, 21 Aug 2008 19:54:17 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 23375 invoked from network); 21 Aug 2008 19:54:17 -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 ; 21 Aug 2008 19:54:17 -0000 Message-ID: <48ADC7E7.9030907@aldan.algebra.com> Date: Thu, 21 Aug 2008 15:54:15 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Neil Neely References: <48ADA81E.7090106@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 19:54:18 -0000 Neil Neely ÎÁÐÉÓÁ×(ÌÁ): > I haven't explored this issue enough to speak with any authority - but > once upon a time I had an app doing tons of ipfw rule add/removes all > the time and we had no end of performance and stability problems on > that box (this would have been in 4.x or so timeline I expect). As > that approach wasn't really critical we abandoned it without really > digging into the details. > > Years later a need for lots of rapid firewall changes came up again > and I drilled into it and found the use of tables was excellent for > doing this and it does the job very well. This is approach is on a > FreeBSD 6.3 box. > > ipfw add 00550 deny ip from 'table(1)' to any > > Then just add remove entries to table 1 via: > ipfw table 1 add 10.1.1.22/32 > ipfw table 1 delete 10.1.1.22/32 > > show all entries in table 1 with: > ipfw table 1 list > > Clear out the whole of table 1 > ipfw table 1 flush > > I can't be sure if this relates to your particular issue, but I would > recommend trying it out. Thanks! I was not even aware of this functionality... Yes, I'll try that -- maybe, a bug in ipfw only hits once per 1000 invocations :-) -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 19:58: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 1F3AF106566C for ; Thu, 21 Aug 2008 19:58:03 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [213.239.213.48]) by mx1.freebsd.org (Postfix) with ESMTP id CD3688FC13 for ; Thu, 21 Aug 2008 19:58:02 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from dominion.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 681FC171EE; Thu, 21 Aug 2008 21:58:01 +0200 (CEST) Received: by dominion.borderworlds.dk (Postfix, from userid 2000) id E675E47D; Thu, 21 Aug 2008 21:58:00 +0200 (CEST) To: Mikhail Teterin References: <48ADA81E.7090106@aldan.algebra.com> From: Christian Laursen Date: Thu, 21 Aug 2008 21:58:00 +0200 In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> (Mikhail Teterin's message of "Thu\, 21 Aug 2008 13\:38\:38 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 19:58:03 -0000 Mikhail Teterin writes: > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address > to the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip I don't know if it will make your problem go away, but using ipfw tables for this seems to be a better idea than creating a new rule for every IP address. So you just need one rule: ipfw add 550 deny ip from table(1) And then when you want to add an IP address to the table: ipfw table 1 add You can add ranges too using the CIDR notation. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:00: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 DF8321065684 for ; Thu, 21 Aug 2008 20:00:18 +0000 (UTC) (envelope-from neil@neely.cx) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id A251C8FC23 for ; Thu, 21 Aug 2008 20:00:18 +0000 (UTC) (envelope-from neil@neely.cx) Received: by yx-out-2324.google.com with SMTP id 8so65801yxb.13 for ; Thu, 21 Aug 2008 13:00:18 -0700 (PDT) Received: by 10.114.113.14 with SMTP id l14mr229750wac.108.1219346915983; Thu, 21 Aug 2008 12:28:35 -0700 (PDT) Received: from ?10.10.130.4? ( [216.17.230.105]) by mx.google.com with ESMTPS id 4sm344763yxj.7.2008.08.21.12.28.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Aug 2008 12:28:34 -0700 (PDT) Message-Id: From: Neil Neely To: Mikhail Teterin In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 21 Aug 2008 13:28:30 -0600 References: <48ADA81E.7090106@aldan.algebra.com> X-Mailer: Apple Mail (2.926) Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:00:19 -0000 I haven't explored this issue enough to speak with any authority - but once upon a time I had an app doing tons of ipfw rule add/removes all the time and we had no end of performance and stability problems on that box (this would have been in 4.x or so timeline I expect). As that approach wasn't really critical we abandoned it without really digging into the details. Years later a need for lots of rapid firewall changes came up again and I drilled into it and found the use of tables was excellent for doing this and it does the job very well. This is approach is on a FreeBSD 6.3 box. ipfw add 00550 deny ip from 'table(1)' to any Then just add remove entries to table 1 via: ipfw table 1 add 10.1.1.22/32 ipfw table 1 delete 10.1.1.22/32 show all entries in table 1 with: ipfw table 1 list Clear out the whole of table 1 ipfw table 1 flush I can't be sure if this relates to your particular issue, but I would recommend trying it out. Neil Neely http://neil-neely.blogspot.com On Aug 21, 2008, at 11:38 AM, Mikhail Teterin wrote: > Hello! > > A machine I manage remotely for a friend comes under a distributed > ssh break-in attack every once in a while. Annoyed (and alarmed) by > the messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from > 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP- > address to the ipfw-rules after three such "invalid user" attempts > with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the > gateway for the rest of the network... > The hangs could, of course, be caused by something else entirely, > but my self-defense mechanism is my first suspect... > > Any comments? Thanks! > > -mi > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:03: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 93A43106566B for ; Thu, 21 Aug 2008 20:03:09 +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 7381F8FC1B for ; Thu, 21 Aug 2008 20:03:09 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 15E561CC0BF; Thu, 21 Aug 2008 13:03:09 -0700 (PDT) Date: Thu, 21 Aug 2008 13:03:09 -0700 From: Jeremy Chadwick To: Mikhail Teterin Message-ID: <20080821200309.GA19634@eos.sc1.parodius.com> References: <48ADA81E.7090106@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:03:09 -0000 On Thu, Aug 21, 2008 at 01:38:38PM -0400, Mikhail Teterin wrote: > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the gateway > for the rest of the network... > The hangs could, of course, be caused by something else entirely, but my > self-defense mechanism is my first suspect... > > Any comments? Thanks! Yes, I have quite a few comments on this matter: The above looks like sshguard. I've personally never trusted something that *automatically* adjusts firewall rules based on data read from text logs or packets coming in off the Internet. The risks involved are insanely high. Stop for a moment and think what would happen to your box if a distributed brute-force attack (e.g. 300,000 different IPs) was launched against it; someone executing 20-30 SSH login attempts per IP. I'm willing to bet adding 300,000 individual ipfw entries would cause some serious havok on your machine (speculative: exhausted kernel memory, or at a bare minimum, exhaust the number of remaining ipfw rule entries) And yes, the liklihood of someone doing this is quite high. Try re-thinking your firewall logic. Instead of "allow any, deny specific IPs dynamically", how about "allow specific IPs, deny all others"? Surely you don't have that many users who SSH into the NAT router from random public IPs all over the world, rather than via the LAN? Surely if you yourself often SSH into your NAT router from a Blackberry device, that you wouldn't have much of a problem adding a /19 to the allow list. That's a hell of a lot better than allowing 0/0 and denying individual /32s. A different approach: consider putting sshd on a different port, rather than the default of 22. A lot of people I know do this, solely to decrease the number of brute-force attempts you see above; I've never seen any of those brute-force attacking programs portscan, then attack against a port which returns a OpenSSH string. Finally, consider moving to pf instead, if you really feel ipfw is what's causing your machine to crash. You might be pleasantly surprised by the syntax, and overall administrative usability (it is significantly superior to ipfw, IMHO). -- | 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 Aug 21 20: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 723F6106566C for ; Thu, 21 Aug 2008 20:16:57 +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 5F2178FC20 for ; Thu, 21 Aug 2008 20:16:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 494881CC0C0; Thu, 21 Aug 2008 13:16:57 -0700 (PDT) Date: Thu, 21 Aug 2008 13:16:57 -0700 From: Jeremy Chadwick To: Sabeeh Baig Message-ID: <20080821201657.GA20481@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@freebsd.org Subject: Re: Memory Usage Stats 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, 21 Aug 2008 20:16:57 -0000 On Thu, Aug 21, 2008 at 02:05:50PM -0400, Sabeeh Baig wrote: > I've been noticing never-before-seen highs in memory usage, since the > last time I rebuilt world a bout a week ago. I have 2GB of memory and > 2GB of swap space. According to top, a little over 1GB of memory is > active, 70MB free, 300MB wired, and the rest inactive. I also have > 59MB of swap used. The swap in use is fine; memory which is often untouched (e.g. allocated but then not utilised for some time) is often swapped out to disk. > If I close an application, the amount of active memory never decreases > and the other stats don't change either. I think you may be reading top output incorrectly, which is a common problem these days. I hope you're not assuming that the "Free" column in top defines how much memory there is available for allocation on the system. > The active figure can't be right even now, as I only have > Xfce, Xorg, screen, two zsh session, slurm, irssi, pidgin, mpd, ncmpc, > and irssi running. That's usually my normal session and usage has > been better before I recompiled. > Is it possible that top is displaying the wrong stats? Possibly -- how exactly did you rebuild your system when you said you "rebuilt world"? Did you follow each and every step in src/Makefile, including booting into single user, etc. etc.? The reason I mention this is, lots of userland utilities rely on libkvm. For example, you rebuilt your kernel (and the KVM structure within the kernel changed due to CVS commits or whatever else), but you didn't rebuild userland (e.g. libkvm still refers to the old KVM structure), then you will see very odd numbers or possibly total breakage in top, ps, systat, etc... > Is there any other utility I could try? systat, vmstat, and procstat (the latter only available if you're using a fairly recent RELENG_7 or HEAD; and it may not be of much help here, since it just provides a break-down of memory usage within a process) > I've tried ps auxm, but that's not exactly what I'm looking for. You could start by: 1) Stating if you're on i386 or amd64 -- it matters, 2) Providing top output (sorted by "res") before and after said rebuild, 3) Providing top output (sorted by "res") before and after you terminate a process that uses a large amount of memory. -- | 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 Aug 21 20:19: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 82B8E106566C for ; Thu, 21 Aug 2008 20:19:58 +0000 (UTC) (envelope-from ebutusov@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 0B30A8FC1F for ; Thu, 21 Aug 2008 20:19:57 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so74263uge.39 for ; Thu, 21 Aug 2008 13:19:56 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EDuOhvDUm+gZQaGvsDadUB4J98BJ2sp8S2PPO8moSY0=; b=HGCWiE0t4RZdWGzncpMk98VEni7lJbFJdPA+xiRa1bANEKVMHq3fVa7DXWxje5TjOC bLjg9ASyFt52/XVn3ujOxZXghTJypSifANWBh46xpspgpf2y9Cdf0zOozYQlAs6ujqE9 LJGOZby3aQXurpZBiprjVhktRB+ukpUA9tZqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tm1MnpScRYCsLaCsOuQ/zghqqJV91SLoQtSMBaa9Lm4m6a+aN0j933IJpTDQv4n6yD Pi6li69L3H7eMomVOyvI5ZMQlWEi7OhofChoTpo47ftf5lsY4s2sIKOasWB8hQXGYm6o Z0Mssr128tkm2GsHdPqcmSKdWL4MgkTF1ToNk= Received: by 10.210.16.17 with SMTP id 17mr287674ebp.38.1219349996538; Thu, 21 Aug 2008 13:19:56 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id d23sm1981707nfh.11.2008.08.21.13.19.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Aug 2008 13:19:55 -0700 (PDT) Message-ID: <48ADCDAD.80507@gmail.com> Date: Thu, 21 Aug 2008 22:18:53 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Mikhail Teterin References: <48ADA81E.7090106@aldan.algebra.com> In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:19:58 -0000 Mikhail Teterin pisze: > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). Hi, You should look at 'bruteblock' (ports/security), it has similar fuctionality. It also provides daemon process, bruteblockd, which is responsible for removing entries from ipfw table. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:25: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 DE4F4106567C; Thu, 21 Aug 2008 20:25:00 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 99DC08FC1C; Thu, 21 Aug 2008 20:25:00 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 609B26D455; Thu, 21 Aug 2008 22:10:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNMVCXqmMilc; Thu, 21 Aug 2008 22:10:42 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id B19D56D454; Thu, 21 Aug 2008 22:10:42 +0200 (CEST) Date: Thu, 21 Aug 2008 22:10:42 +0200 From: Rink Springer To: Jeremy Chadwick Message-ID: <20080821201042.GA56182@rink.nu> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Mikhail Teterin , freebsd-stable@FreeBSD.org, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:25:01 -0000 On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). In fact, pf can already do this out-of-the-box, by doing something like: table persist pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 5/3, overload flush global) If that is not an option, I have found that security/denyhosts works pretty well too (it just adds IP's to /etc/hosts.deniedssh, and host_access(5) denies them based on this) Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:28: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 9EF7F1065679 for ; Thu, 21 Aug 2008 20:28:07 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3748FC0C for ; Thu, 21 Aug 2008 20:28:07 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 4556 invoked from network); 21 Aug 2008 20:28:06 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Aug 2008 20:28:06 -0000 Message-ID: <48ADCFD5.8020902@aldan.algebra.com> Date: Thu, 21 Aug 2008 16:28:05 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Jeremy Chadwick References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:28:07 -0000 Jeremy Chadwick ÎÁÐÉÓÁ×(ÌÁ): > The above looks like sshguard. Yes, several people have pointed this out. Thanks! > I've personally never trusted something that *automatically* adjusts firewall rules based on data read from text > logs or packets coming in off the Internet. The risks involved are insanely high. > An IP participating in a detected attack like this one, may also be the source of another problem, which may not be detected... I can't afford to monitor this system at all times, hence the reliance on automatic defenses -- better to crash/reboot than be taken over... > Stop for a moment and think what would happen to your box if a > distributed brute-force attack (e.g. 300,000 different IPs) was launched > against it; someone executing 20-30 SSH login attempts per IP. I'm > willing to bet adding 300,000 individual ipfw entries would cause some > serious havok on your machine (speculative: exhausted kernel memory, or > at a bare minimum, exhaust the number of remaining ipfw rule entries) > Yes, this is something I'm suspecting happening. But should not there be some frantic messages, when the system is getting closer to this point? There is nothing in the logs... > Surely you don't have that many users who SSH into the NAT router from > random public IPs all over the world, rather than via the LAN? Surely > if you yourself often SSH into your NAT router from a Blackberry device, > that you wouldn't have much of a problem adding a /19 to the allow list. > That's a hell of a lot better than allowing 0/0 and denying individual > /32s. > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" from anywhere in the world. Although we could, I suppose, find out the destination-country's IP-allocation and add it before leaving, that would be quite tedious to manage... > A different approach: consider putting sshd on a different port, rather > than the default of 22. A lot of people I know do this, solely to > decrease the number of brute-force attempts you see above; I've never > seen any of those brute-force attacking programs portscan, then attack > against a port which returns a OpenSSH string. > That's sounds kinda lame -- and temporary... Like buying an SUV to be higher (and heavier) than other cars, this only works, until everyone has an SUV :-) Once enough people move their sshd to different ports, the next release of the ssh-attack will be doing the portscanning, no doubt... Essential liberty vs. temporary security and all that :) > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). > Thanks for the suggestion... But would this solve the suspected problems with kernel memory exhaustion, etc.? Whatever the firewall method, it still needs to keep the rules memorized somewhere... Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:36: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 6CD2F1065674; Thu, 21 Aug 2008 20:36:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D87FD8FC14; Thu, 21 Aug 2008 20:36:30 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7LKb3oq047754; Thu, 21 Aug 2008 15:37:03 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7LKb3AZ047753; Thu, 21 Aug 2008 15:37:03 -0500 (CDT) (envelope-from brooks) Date: Thu, 21 Aug 2008 15:37:03 -0500 From: Brooks Davis To: Rink Springer Message-ID: <20080821203703.GA47728@lor.one-eyed-alien.net> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <20080821201042.GA56182@rink.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20080821201042.GA56182@rink.nu> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Mikhail Teterin , Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:36:31 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote: > On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > > Finally, consider moving to pf instead, if you really feel ipfw is > > what's causing your machine to crash. You might be pleasantly surprised > > by the syntax, and overall administrative usability (it is significantly > > superior to ipfw, IMHO). >=20 > In fact, pf can already do this out-of-the-box, by doing something like: >=20 > table persist > pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep > state \ > (max-src-conn 15, max-src-conn-rate 5/3, overload flush > global) >=20 > If that is not an option, I have found that security/denyhosts works > pretty well too (it just adds IP's to /etc/hosts.deniedssh, and > host_access(5) denies them based on this) You almost certainly don't want to rate limit ssh connections, only failed ones. If you rate limit connections and use svn, you're likely to lock your self out. -- Brooks --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIrdHuXY6L6fI4GtQRAnmFAJsHxkpSK8Zx3QWdr/ksFolpRXNtIgCgyEbc WqAu2UPpH5xE7+ZF0xj8b+U= =qS2/ -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:42: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 CFF2E1065682 for ; Thu, 21 Aug 2008 20:42:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id B2E838FC15 for ; Thu, 21 Aug 2008 20:42:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id EC99C24A9; Thu, 21 Aug 2008 13:31:10 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 173E22D607E; Thu, 21 Aug 2008 13:31:02 -0700 (PDT) Message-ID: <48ADD084.9070707@elischer.org> Date: Thu, 21 Aug 2008 13:31:00 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kevin Oberman References: <20080821184947.BDAE94500F@ptavv.es.net> In-Reply-To: <20080821184947.BDAE94500F@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mikhail Teterin , freebsd-stable@FreeBSD.org, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:42:44 -0000 Kevin Oberman wrote: >> Date: Thu, 21 Aug 2008 13:38:38 -0400 >> From: Mikhail Teterin >> Sender: owner-freebsd-stable@freebsd.org >> >> Hello! >> >> A machine I manage remotely for a friend comes under a distributed ssh >> break-in attack every once in a while. Annoyed (and alarmed) by the >> messages like: >> >> Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 >> >> I wrote an awk-script, which adds a block of the attacking IP-address to >> the ipfw-rules after three such "invalid user" attempts with: >> >> ipfw add 550 deny ip from ip >> >> The script is fed by syslogd directly -- through a syslog.conf rule >> ("|/opt/sbin/auth-log-watch"). >> >> Once in a while I manually flush these rules... I this a good (safe) >> reaction? >> I'm asking, because the machine (currently running 7.0 as of July 7) >> hangs solid once every few weeks... My only guess is that a spike in >> attacks causes "too many" ipfw-entries created, which paralyzes the >> kernel due to some bug -- the machine is running natd and is the gateway >> for the rest of the network... >> The hangs could, of course, be caused by something else entirely, but my >> self-defense mechanism is my first suspect... >> >> Any comments? Thanks! also, if you do this, have a single rule that uses a table and add the addresses to the table. > > Looks remarkably like sshguard (ports/security/sshguard-*). It does almost > exactly what you are doing but is written in C and has command-line > switches to set how long a system is blocked, how many attempts > constitute an attack and how long it should remember failed attempts. It > also allows the use of back-end scripts if you want it to do something > else such as generate reports (beyond an entry in /var/log/messages). > > As far as the hangs, I don't believe it is from the large nu,ber of > brute force attempts as they will stop for a given host as soon as the > firewall is updated. I seldom see more than a handful of attack sources > over any short period. > > Should you want to continue with your own tool, at least for IPv4, > consider using tables rather than a raft of rules. With tables, you need > only a single rule and it is there at boot time. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 20:42: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 7101E1065671; Thu, 21 Aug 2008 20:42:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 302A08FC14; Thu, 21 Aug 2008 20:42:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from [127.0.0.1] (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id BE34360E6; Thu, 21 Aug 2008 16:42:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1219351372; bh=KK+AEJnLLE33So DuAFoZRMzki8FZD0G1VmIC0D446oQ=; h=Message-ID:Date:From:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=BloMN3c0iSvGZGYIiUDkzNFlOdFLgbQ3be08c gKftgzv1kj3heN0GNw349ZhOgsJJU2kwsA5DaS+RExKss9PWpIRbsJNbheCfaDRgiBJ +RVl1Y/j6SjYx74cBPeeZ3Dl DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=d0N4S8yomGDcQ1T+g9LqIkleRT0oCpa3uxTLD3V41lIb1XBMELRWNCFwbfyLJtDnf 7EVTvBDgsxfCKextW0U/idxsfayTFayyYtYCIZY8E+FNyuFhXWfWqliS1s9D2iY Message-ID: <48ADD33A.9030907@protected-networks.net> Date: Thu, 21 Aug 2008 16:42:34 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <48ADA81E.7090106@aldan.algebra.com> <48ADCDAD.80507@gmail.com> In-Reply-To: <48ADCDAD.80507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 20:42:54 -0000 I do something related to this with fwlogwatch although it can probably be adapted to any similar tool; when I hit the 'block' threshold, I execute something like: #!/bin/sh HR=`date "+%-k"` /sbin/ipfw table 0 add $3 ${HR} .. so each entry has a tag indicating the hour at which the block was initiated. At 5 to the hour, I run a simple cron job which does this to clean out everything older than 24 hours .. #!/bin/sh HR=`date -v+1H "+%-k"` /sbin/ipfw table 0 list >/tmp/xx.$$ cat /tmp/xx.$$ | while read LINE do set $LINE case "$2" in ${HR}) /sbin/ipfw table 0 delete $1 echo -n `date +"%H:%M:%S"` >>/var/log/fwlw_clean_log echo " fwlw_clean: removed $1 from table 0" >>/var/log/fwlw_clean_log esac done rm /tmp/xx.$$ I also have a script in /usr/local/etc/rc.d which saves the current state in the event of an orderly shutdown and restores it on boot: #!/bin/sh case "$1" in start) cat /var/db/ipfw/cache0 | while read LINE do set $LINE /sbin/ipfw table 0 add $1 $2 done ;; stop) /sbin/ipfw table 0 list >/var/db/ipfw/cache0 ;; restart) $0 $DEBUG stop $0 $DEBUG start exit $? ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac exit 0 Of course, this only works for ipv4 because of the restriction on the ipfw table data but it's just an example, Michael From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 21:42: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 5B757106567B for ; Thu, 21 Aug 2008 21:42:56 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4E88FC2F for ; Thu, 21 Aug 2008 21:42:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so265185rvf.43 for ; Thu, 21 Aug 2008 14:42:55 -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:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=IVhD5Qe3C1FnBMl154NDB6PeAZbyoWChqWdRquzJ78I=; b=P1uPlwN8D5kGSAqNc5UKFR6tdrOS1+UMVM+LKbW+4YdahdDeuSP+oHWzJFNKR+apGY kCkolp/qRpOZtmJw3EQzUcCQNOEuLT/FHZghLrLLF1mS18yBcp/acksvl3qIPQbDyE7a oQg5xbnNLqeVRMC0+nR/Q20PFYo0WG6fGiqSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=eAGYBxzpqmDUdLsPzYLvqYOzLGdWoel1qDMK8IIyINBkizcqsIvIM5qWEth2whpYLL 4/P1HuHoQQJQvgrFbjYyhMtrBEHENBodMnPi/5mbqcYYbqMW15GzdhbVQdETil/cGLyE I7XvtgwjvZyV/xrU7hHWC046zzT/hcB2jM5c8= Received: by 10.140.193.16 with SMTP id q16mr151886rvf.109.1219354975507; Thu, 21 Aug 2008 14:42:55 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Thu, 21 Aug 2008 14:42:55 -0700 (PDT) Message-ID: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> Date: Thu, 21 Aug 2008 14:42:55 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: sun4v@freebsd.org, freebsd-stable@freebsd.org, "FreeBSD Current" , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 59689ae88137d2dd Cc: Subject: the future of sun4v 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, 21 Aug 2008 21:42:56 -0000 I apologise for cross-posting. I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Thanks, Kip From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 22:22: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 640D31065673 for ; Thu, 21 Aug 2008 22:22:21 +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 3AC8D8FC14 for ; Thu, 21 Aug 2008 22:22:21 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 24564 invoked from network); 21 Aug 2008 22:22:20 -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 ; 21 Aug 2008 22:22:20 -0000 Message-ID: <48ADEA96.70203@aldan.algebra.com> Date: Thu, 21 Aug 2008 18:22:14 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Ross Wheeler References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> <20080822074020.G32956@ali-syd-1.albury.net.au> In-Reply-To: <20080822074020.G32956@ali-syd-1.albury.net.au> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 22:22:21 -0000 Ross Wheeler ÎÁÐÉÓÁ×(ÌÁ): > I overcame these conflicting requirements with a 2-step process. They > "authorised" user first browsed to a website which asked their > username and password. When entered correctly, it opened a hole in the > firewall to allow that IP to their network. A timer ran every 15 > minutes to close the hole (but was over-ridden by the web page which > kept refreshing every 10 mins). The last part may not be necessary for > you, but this may be a possible workaround for your traveling access. > Leave a default of deny any except from trusted, fixed hosts, and add > transient access as required. This approach (or port-knocking of some sort) is good, but I'm not that worried about the sshd itself -- and the /detected/ attacks against it. It is the /undetected/ attacks against other services (such as apache), that worry me, and locking-out a rogue IP-address /completely/ is what I'd like to do. So your method would not work for me -- reaching the web-page (to allow myself a way back in) will be just as impossible as reaching the ssh-port... Thanks. Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 22:25: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 31D681065679; Thu, 21 Aug 2008 22:25:32 +0000 (UTC) (envelope-from rossw@albury.net.au) Received: from mail.albury.net.au (ali-syd-1.albury.net.au [202.3.36.15]) by mx1.freebsd.org (Postfix) with ESMTP id BCC6A8FC16; Thu, 21 Aug 2008 22:25:31 +0000 (UTC) (envelope-from rossw@albury.net.au) Received: from ali-syd-1.albury.net.au (ali-syd-1.albury.net.au [202.3.36.15]) by mail.albury.net.au (8.13.6/8.13.6) with ESMTP id m7LLmDqi090234; Fri, 22 Aug 2008 07:48:14 +1000 (EST) (envelope-from rossw@albury.net.au) Date: Fri, 22 Aug 2008 07:48:13 +1000 (EST) From: Ross Wheeler To: Mikhail Teterin In-Reply-To: <48ADCFD5.8020902@aldan.algebra.com> Message-ID: <20080822074020.G32956@ali-syd-1.albury.net.au> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.albury.net.au [202.3.36.15]); Fri, 22 Aug 2008 07:48:14 +1000 (EST) Cc: freebsd-security@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 21 Aug 2008 22:25:32 -0000 On Thu, 21 Aug 2008, Mikhail Teterin wrote: >> Surely you don't have that many users who SSH into the NAT router from >> random public IPs all over the world, rather than via the LAN? Surely >> if you yourself often SSH into your NAT router from a Blackberry device, >> that you wouldn't have much of a problem adding a /19 to the allow list. >> That's a hell of a lot better than allowing 0/0 and denying individual >> /32s. >> > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" from > anywhere in the world. Although we could, I suppose, find out the > destination-country's IP-allocation and add it before leaving, that would be > quite tedious to manage... One of my clients used to have a microwave link from my network to their office - and they were totally paranoid about remote access yet needed live IPs fr other reasons. They too needed frequent remote access from arbitary addresses. I overcame these conflicting requirements with a 2-step process. They "authorised" user first browsed to a website which asked their username and password. When entered correctly, it opened a hole in the firewall to allow that IP to their network. A timer ran every 15 minutes to close the hole (but was over-ridden by the web page which kept refreshing every 10 mins). The last part may not be necessary for you, but this may be a possible workaround for your traveling access. Leave a default of deny any except from trusted, fixed hosts, and add transient access as required. (The system did fail where your browser was proxied, but I catered for that for the "network guys" by lettig them enter an IP address to open along with their user/pass - it just defaulted to the requesting host to make it easy) YMMV. RossW From owner-freebsd-stable@FreeBSD.ORG Thu Aug 21 22:52:10 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 4B4F81065676 for ; Thu, 21 Aug 2008 22:52:10 +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 2BF5B8FC18 for ; Thu, 21 Aug 2008 22:52:10 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 19B101CC0C0; Thu, 21 Aug 2008 15:52:10 -0700 (PDT) Date: Thu, 21 Aug 2008 15:52:10 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20080821225210.GA30726@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: Memory Usage Stats 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, 21 Aug 2008 22:52:10 -0000 ----- Forwarded message from Sabeeh Baig ----- > From: Sabeeh Baig > To: Jeremy Chadwick > Date: Thu, 21 Aug 2008 16:51:13 -0400 > Subject: Re: Memory Usage Stats > > 1) I didn't know that about swap allocation. > > 2) I know what each of the categories of memory stand for and what > role they play and how they are used, so no I don't think of free > memory like that. Actually, total free memory includes inactive as > well, since inactive keeps inactive pages for future use to improve > performance, but dynamically reallocates them if necessary. > > 3) I followed standard update procedure listed in the handbook. I > don't deviate from that, as I don't want a broken mess to deal with. > > ------------------------------------------------------------------------------ > > 1) I run AMD64. > > 2) How would I get this information, as I rebuilt it over a week ago. > > 3) I will provide this information once I get home. > > On Thu, Aug 21, 2008 at 4:16 PM, Jeremy Chadwick wrote: > > On Thu, Aug 21, 2008 at 02:05:50PM -0400, Sabeeh Baig wrote: > >> I've been noticing never-before-seen highs in memory usage, since the > >> last time I rebuilt world a bout a week ago. I have 2GB of memory and > >> 2GB of swap space. According to top, a little over 1GB of memory is > >> active, 70MB free, 300MB wired, and the rest inactive. I also have > >> 59MB of swap used. > > > > The swap in use is fine; memory which is often untouched (e.g. allocated > > but then not utilised for some time) is often swapped out to disk. > > > >> If I close an application, the amount of active memory never decreases > >> and the other stats don't change either. > > > > I think you may be reading top output incorrectly, which is a common > > problem these days. I hope you're not assuming that the "Free" column > > in top defines how much memory there is available for allocation on the > > system. > > > >> The active figure can't be right even now, as I only have > >> Xfce, Xorg, screen, two zsh session, slurm, irssi, pidgin, mpd, ncmpc, > >> and irssi running. That's usually my normal session and usage has > >> been better before I recompiled. > > > >> Is it possible that top is displaying the wrong stats? > > > > Possibly -- how exactly did you rebuild your system when you said you > > "rebuilt world"? Did you follow each and every step in src/Makefile, > > including booting into single user, etc. etc.? > > > > The reason I mention this is, lots of userland utilities rely on libkvm. > > For example, you rebuilt your kernel (and the KVM structure within the > > kernel changed due to CVS commits or whatever else), but you didn't > > rebuild userland (e.g. libkvm still refers to the old KVM structure), > > then you will see very odd numbers or possibly total breakage in top, > > ps, systat, etc... > > > >> Is there any other utility I could try? > > > > systat, vmstat, and procstat (the latter only available if you're using > > a fairly recent RELENG_7 or HEAD; and it may not be of much help here, > > since it just provides a break-down of memory usage within a process) > > > >> I've tried ps auxm, but that's not exactly what I'm looking for. > > > > You could start by: > > > > 1) Stating if you're on i386 or amd64 -- it matters, > > 2) Providing top output (sorted by "res") before and after said > > rebuild, > > 3) Providing top output (sorted by "res") before and after you > > terminate a process that uses a large amount of memory. > > > > -- > > | 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 | > > > > > > > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to understand the simplicity." > > Sabeeh Ahmed Baig > ----- End forwarded message ----- OP forgot to CC the mailing list. -- | 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 Aug 21 23:52: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 47C441065673 for ; Thu, 21 Aug 2008 23:52:49 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from n72.bullet.mail.sp1.yahoo.com (n72.bullet.mail.sp1.yahoo.com [98.136.44.34]) by mx1.freebsd.org (Postfix) with SMTP id 221B28FC1C for ; Thu, 21 Aug 2008 23:52:49 +0000 (UTC) (envelope-from dewayne_freebsd@yahoo.com) Received: from [216.252.122.218] by n72.bullet.mail.sp1.yahoo.com with NNFMP; 21 Aug 2008 23:39:33 -0000 Received: from [69.147.65.182] by t3.bullet.sp1.yahoo.com with NNFMP; 21 Aug 2008 23:39:33 -0000 Received: from [127.0.0.1] by omp301.mail.sp1.yahoo.com with NNFMP; 21 Aug 2008 23:39:33 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 676375.99186.bm@omp301.mail.sp1.yahoo.com Received: (qmail 9852 invoked by uid 60001); 21 Aug 2008 23:39:33 -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=4vlmdkMM4wsVpLPfGfcwS/4rRFnljTj+vpR+qxfnB6WXDPsHtiTPmitcrtxZpuJ+76OwtfLQOZhaM1XMBkJf+oMHFuRGKgvtYr7SLjZBi2htz8SsfDSCVIbMip8VTFMXaX83y7jREjCvZRE/bs9vmZkorPtz4n4G+cHBR3dp22M=; Received: from [58.172.113.127] by web46413.mail.sp1.yahoo.com via HTTP; Thu, 21 Aug 2008 16:39:32 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Thu, 21 Aug 2008 16:39:32 -0700 (PDT) From: Dewayne Geraghty To: Rink Springer , Brooks Davis In-Reply-To: <20080821203703.GA47728@lor.one-eyed-alien.net> MIME-Version: 1.0 Message-ID: <446595.9807.qm@web46413.mail.sp1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mikhail Teterin , Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dewayne_freebsd@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2008 23:52:49 -0000 There are many excellent suggestions on how to deal with invalid/unauthoris= ed access attempts via ssh.=C2=A0 I'd used sshguard for around 8 months but= recently changed to bruteblock, both are in the ports/security.=C2=A0 sshg= uard was very easy to configure, via rc.conf arguments. =C2=A0=C2=A0 Bruteb= lock handled the same problem more elegantly: uses two processes one for mo= nitoring audit.log, via a pipe and one for maintaining the ipfw table entri= es, it uses the ipfw table value with the date/time entered, and the C code= is cleaner (some optimisations are possible but this is V0.5).=C2=A0=20 If you'd like to try it here are the steps I used to get it going: Install package Configure /usr/local/etc/bruteblock-ssh.conf (Using regexp from sample, but modify parameters to suite your environment.) regexp=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D sshd.*Illegal user \S+ from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) regexp1=C2=A0=C2=A0=C2=A0=C2=A0 =3D sshd.*Failed password for (?:illegal user )?\S+ from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} # three failures in 3 minutes is blocked for a day, using ipfw2 table 10max= _count=C2=A0=C2=A0 =3D 3 within_time =3D 180 reset_ip=C2=A0=C2=A0=C2=A0 =3D 86400 ipfw2_table_no =3D 10 =C2=A0 Insert into "/etc/syslog.conf" auth.info;authpriv.info |exec /usr/local/sbin/bruteblock =E2=80=93f /usr/lo= cal/etc/bruteblock-ssh.conf Add to firewall rules (and /etc/rc.firewall)ipfw add 4 deny ip from table\(= 10\) to any ipfw add 4 deny ip from any to table\(10\)=C2=A0Add into /etc/rc.confbruteb= lockd_enable=3D"YES" bruteblockd_table=3D"10" bruteblockd_flags=3D"-s 7200"=C2=A0 # How frequently to review the ipfw tab= le for entry removal=C2=A0Now restart syslog, and start bruteblockd/etc/rc.= d/syslogd restart /usr/local/etc/rc.d/bruteblockd.sh start =0A=0A=0A Win a MacBook Air or iPod touch with Yahoo!7. http://au.docs= ..yahoo.com/homepageset From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 00:27: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 979D41065682 for ; Fri, 22 Aug 2008 00:27:55 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 517738FC1F for ; Fri, 22 Aug 2008 00:27:55 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 20511 invoked from network); 21 Aug 2008 19:01:14 -0500 Received: from 124-170-190-142.dyn.iinet.net.au (HELO ayiin) (124.170.190.142) by sigma.octantis.com.au with (DHE-RSA-AES128-SHA encrypted) SMTP; 21 Aug 2008 19:01:14 -0500 Date: Fri, 22 Aug 2008 10:01:09 +1000 From: Norberto Meijome To: freebsd-stable@freebsd.org Message-ID: <20080822100109.2a85c431@ayiin> In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 22 Aug 2008 00:27:55 -0000 On Thu, 21 Aug 2008 13:03:09 -0700 Jeremy Chadwick wrote: > A different approach: consider putting sshd on a different port, rather > than the default of 22. A lot of people I know do this, solely to > decrease the number of brute-force attempts you see above; I've never > seen any of those brute-force attacking programs portscan, then attack > against a port which returns a OpenSSH string. +1 - obscurity definitely doesn't ADD to security , but it removes all the noise from your system. Alternatively, you try port knocking ;) > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). +1 _________________________ {Beto|Norberto|Numard} Meijome If Bill Gates had a dollar for every time a Windows box crashed... .. Oh, wait a minute, he already does. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 00: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 671EE1065675 for ; Fri, 22 Aug 2008 00:30:54 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 204588FC14 for ; Fri, 22 Aug 2008 00:30:54 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 20699 invoked from network); 21 Aug 2008 19:04:13 -0500 Received: from 124-170-190-142.dyn.iinet.net.au (HELO ayiin) (124.170.190.142) by sigma.octantis.com.au with (DHE-RSA-AES128-SHA encrypted) SMTP; 21 Aug 2008 19:04:12 -0500 Date: Fri, 22 Aug 2008 10:04:08 +1000 From: Norberto Meijome To: freebsd-stable@freebsd.org Message-ID: <20080822100408.4bee3751@ayiin> In-Reply-To: <48ADCFD5.8020902@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 22 Aug 2008 00:30:54 -0000 On Thu, 21 Aug 2008 16:28:05 -0400 Mikhail Teterin wrote: > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" > from anywhere in the world. why not setup a SSL-based vpn ? lock everything down except the port of the vpn. try openvpn. > Although we could, I suppose, find out the > destination-country's IP-allocation and add it before leaving, that > would be quite tedious to manage... geoip attached to pf rules :P has anyone done it? But I can tell you it isn't that reliable...you want to have a way to bypass it. b _________________________ {Beto|Norberto|Numard} Meijome "Why do you sit there looking like an envelope without any address on it?" Mark Twain I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 07:04: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 957321065671 for ; Fri, 22 Aug 2008 07:04:15 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 418178FC16 for ; Fri, 22 Aug 2008 07:04:15 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWQG3-0009R0-NQ for freebsd-stable@freebsd.org; Fri, 22 Aug 2008 08:36:30 +0200 Message-ID: <48AE5E6B.2070105@kkip.pl> Date: Fri, 22 Aug 2008 08:36:27 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> <48A3FCF7.9030905@sebster.com> <8B25287C-7336-492C-B62E-CB319B8B5DBB@nHugh.es> <48AD1E05.1040502@sebster.com> <20080821123457.GA99701@eos.sc1.parodius.com> In-Reply-To: <20080821123457.GA99701@eos.sc1.parodius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.6 X-Spam-Score-Int: -85 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-08-22 08:36:30 X-Connected-IP: 192.168.0.10:1149 X-Message-Linecount: 51 X-Body-Linecount: 38 X-Message-Size: 2271 X-Body-Size: 1380 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 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, 22 Aug 2008 07:04:15 -0000 Jeremy Chadwick pisze: > On Thu, Aug 21, 2008 at 09:49:25AM +0200, Sebastiaan van Erk wrote: > >> I was thinking of buying the Promise SATA300 TX4 PCI Controller. I've >> searched on google, and I do see some negative posts on them in >> combination with FreeBSD, however they all date back at least 2 years... >> >> Does anybody have positive/negative experiences using this card? >> > > I have one of these cards (not currently in use; less stuff inside my > FreeBSD box at home the better), and never ran into any oddities. That > was with 4 disks connected, each disk its own UFS2 filesystem. ZFS > wasn't available back then. > > Hello there. I have one SATA300 TX4 PCI Controller in use from about 2 years in my SMB serwer running celeron 1Ghz and 2 x WDC WD2500YS-01SHB0 (250GB each). Disks are under controll of gmirror with UFS2 fs.. When stable branch was 6.x I had problems similiar to described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2007-October/026137.html. In practice - at heavy load, after some timeouts, one of disk drives disconnects and controller doesn't recognize any disks at this sata channel untl reboot. Howewer, no problems occured since I've upgraded Freebsd to 7.x. -- Bartosz Stec - specjalista ds. IT AUXILIA Spółka z o.o. ul. WaÅ‚brzyska 43/2 52-314 WrocÅ‚aw tel. (71) 79 99 760 w. 69 GSM: 662171775 From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 08:04: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 D4929106564A; Fri, 22 Aug 2008 08:04:17 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3FB8FC14; Fri, 22 Aug 2008 08:04:17 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.14.2) with ESMTP id m7LISTQE047849; Thu, 21 Aug 2008 13:28:30 -0500 (CDT) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080821132630.026c6a48@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 21 Aug 2008 13:28:22 -0500 To: Mikhail Teterin , freebsd-security@freebsd.org, freebsd-stable@freebsd.org From: Derek Ragona In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Mime-Version: 1.0 X-Antivirus: avast! (VPS 080821-0, 08/21/2008), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV 0.93.3/8068/Thu Aug 21 10:50:39 2008 on betty.computinginnovations.com X-Virus-Status: Clean X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m7LISTQE047849 X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 22 Aug 2008 08:04:17 -0000 At 12:38 PM 8/21/2008, Mikhail Teterin wrote: >Hello! > >A machine I manage remotely for a friend comes under a distributed ssh >break-in attack every once in a while. Annoyed (and alarmed) by the >messages like: > >Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > >I wrote an awk-script, which adds a block of the attacking IP-address to >the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > >The script is fed by syslogd directly -- through a syslog.conf rule >("|/opt/sbin/auth-log-watch"). > >Once in a while I manually flush these rules... I this a good (safe) reaction? >I'm asking, because the machine (currently running 7.0 as of July 7) hangs >solid once every few weeks... My only guess is that a spike in attacks >causes "too many" ipfw-entries created, which paralyzes the kernel due to >some bug -- the machine is running natd and is the gateway for the rest of >the network... >The hangs could, of course, be caused by something else entirely, but my >self-defense mechanism is my first suspect... > >Any comments? Thanks! > > -mi I doubt it is your script, or syslog causing the crash. It is likely a hardware problem of some type if you have this server completely patched and up-to-date for security patches. I would look at the memory, ethernet, hard disk, or power supply as the most likely candidates. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 11:33: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 6313D1065676; Fri, 22 Aug 2008 11:33:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id E67918FC22; Fri, 22 Aug 2008 11:33:20 +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 mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7MBXIQ4020812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 21:33:18 +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 m7MBXIPh034594; Fri, 22 Aug 2008 21:33:18 +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 m7MBXHku034593; Fri, 22 Aug 2008 21:33:17 +1000 (EST) (envelope-from peter) Date: Fri, 22 Aug 2008 21:33:17 +1000 From: Peter Jeremy To: Kip Macy Message-ID: <20080822113317.GD32539@server.vk2pj.dyndns.org> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2YJj5f1P6Th4nBRw" Content-Disposition: inline In-Reply-To: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sun4v@freebsd.org, freebsd-hackers@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: the future of sun4v X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-sun4v@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 11:33:21 -0000 --2YJj5f1P6Th4nBRw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: >I believe that there is a general expectation by freebsd users and >developers that unsupported code should not be in CVS. Although sun4v >is a very interesting platform for developers doing SMP work, I simply >do not have the time or energy to maintain it. If someone else would >like to step up and try his hand I would be supportive of his efforts. >In the likely event that no one steps forward by the time that 7.1 is >released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. I don't have the knowledge or available time to maintain the sun4v port by myself but would be happy to be part of a team doing so. One impediment I have is that I don't have a T-1 or T-2 system that I can dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but since FreeBSD doesn't support either the virtual disk or virtual network, actually getting FreeBSD running there presents somewhat of a challenge. --=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. --2YJj5f1P6Th4nBRw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiuo/0ACgkQ/opHv/APuIdIQwCaAgOo6jkMtJjWZq6IblsdfjZJ v7cAnRilBTMhsEbCcqlHiGWbGMY9DFQX =6heT -----END PGP SIGNATURE----- --2YJj5f1P6Th4nBRw-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 11:44: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 6FF911065677; Fri, 22 Aug 2008 11:44:30 +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 6E8798FC1A; Fri, 22 Aug 2008 11:44:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48AEA699.10903@FreeBSD.org> Date: Fri, 22 Aug 2008 13:44:25 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-sun4v@freebsd.org References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> In-Reply-To: <20080822113317.GD32539@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sun4v@freebsd.org, freebsd-hackers@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, Kip Macy Subject: Re: the future of sun4v 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, 22 Aug 2008 11:44:30 -0000 Peter Jeremy wrote: > [Replies re-directed to freebsd-sun4v] > > On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: >> I believe that there is a general expectation by freebsd users and >> developers that unsupported code should not be in CVS. Although sun4v >> is a very interesting platform for developers doing SMP work, I simply >> do not have the time or energy to maintain it. If someone else would >> like to step up and try his hand I would be supportive of his efforts. >> In the likely event that no one steps forward by the time that 7.1 is >> released I will ask that it be moved to the Attic. > > Since there are no other current SPARC CPUs that FreeBSD can run on > (the US-II has been obsolete for about 6 years and FreeBSD won't run > on any more recent sun4u chips), that will also remove the > justification for maintaining a SPARC64 port. > > I don't have the knowledge or available time to maintain the sun4v > port by myself but would be happy to be part of a team doing so. One > impediment I have is that I don't have a T-1 or T-2 system that I can > dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > since FreeBSD doesn't support either the virtual disk or virtual > network, actually getting FreeBSD running there presents somewhat of a > challenge. > There are two t1000 systems in the freebsd.org cluster that are available for people to work on. Rink Springer has also expressed interest in this. Perhaps Kip can explain some more about what things he looked at, but the most serious bugs might be in pmap or perhaps trap handling. Operationally, things like buildworld -jN die quickly with random signals, kernel traps, etc. Kris P.S. It looks like marius has made progress on US III but sun4u is still an architectural dead end. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 12:11: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 A1E88106567E for ; Fri, 22 Aug 2008 12:11:48 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 848508FC17 for ; Fri, 22 Aug 2008 12:11:47 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m7MC6FKp017237; Fri, 22 Aug 2008 14:06:17 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 9DA7572; Fri, 22 Aug 2008 14:06:15 +0200 (CEST) Date: Fri, 22 Aug 2008 14:06:15 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: d@delphij.net Message-Id: <20080822140615.63db82e1.gerrit@pmp.uni-hannover.de> In-Reply-To: <489B7D62.4080606@delphij.net> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.8.22.114324 Cc: freebsd-stable@freebsd.org, Xin LI Subject: Re: Regression 7.0R -> 7-stable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 12:11:48 -0000 On Thu, 07 Aug 2008 15:55:30 -0700 Xin LI wrote about Re: Regression 7.0R -> 7-stable?: XL> Could you please try disabling ACPI and boot? Additionally a 'boot - XL> v' may reveal some useful information as well. Just some random XL> thoughts. Sorry for being so late, I almost completely forgot that I had not sent the verbose dmesg yet. Here it is: --- 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-p3 #0: Fri Aug 15 10:29:37 CEST 2008 root@arc.pmp.uni-hannover.de:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80c09000. Preloaded elf obj module "/boot/kernel/if_em.ko" at 0xffffffff80c09220. module_register: module pci/em already exists! Module pci/em failed to register: 17 Calibrating clock(s) ... i8254 clock: 1193195 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2100014603 Hz CPU: AMD Phenom(tm) 8400 Triple-Core Processor (2100.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f22 Stepping = 2 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800,RDTSCP,LM,3DNow! +,3DNow!> AMD Features2=0x7ff,,,Prefetch,,> Cores per package: 3 L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 4281212928 (4082 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x0000000000d07000 - 0x00000000cf43afff, 3463659520 bytes (845620 pages) 0x0000000100000000 - 0x0000000127feffff, 671023104 bytes (163824 pages) avail memory = 4123783168 (3932 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 ACPI: RSDP @ 0x0xf75d0/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0xd7f58f38/0x007C (v 1 FSC PC 0x00060000 LTP 0x00000000) ACPI: FACP @ 0x0xd7f60600/0x00F4 (v 3 FSC 0x00060000 PTL_ 0x000F4240) ACPI: DSDT @ 0x0xd7f58fb4/0x75D8 (v 1 FSC D2721/A1 0x00060000 MSFT 0x03000001) ACPI: FACS @ 0x0xd7f61fc0/0x0040 ACPI: TCPA @ 0x0xd7f606f4/0x0032 (v 1 Phoeni x 0x00060000 TL 0x00000000) ACPI: WDAT @ 0x0xd7f60726/0x0104 (v 1 PTLTD WDATTBL 0x00060000 LTP 0x00000001) ACPI: SSDT @ 0x0xd7f6082a/0x03FC (v 1 AMD POWERNOW 0x00060000 AMD 0x00000001) ACPI: SRAT @ 0x0xd7f60c26/0x00D8 (v 1 AMD HAMMER 0x00060000 AMD 0x00000001) ACPI: ASF! @ 0x0xd7f60cfe/0x0070 (v 32 OEMID OEMTBL 0x00060000 PTL 0x00000001) ACPI: SLIC @ 0x0xd7f60d6e/0x0176 (v 1 FSC PC 0x00060000 LTP 0x00000000) ACPI: MCFG @ 0x0xd7f60ee4/0x003C (v 1 PTLTD MCFG 0x00060000 LTP 0x00000000) ACPI: HPET @ 0x0xd7f60f20/0x0038 (v 1 PTLTD HPETTBL 0x00060000 LTP 0x00000001) ACPI: APIC @ 0x0xd7f60f58/0x0080 (v 1 PTLTD APIC 0x00060000 LTP 0x00000000) ACPI: BOOT @ 0x0xd7f60fd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x00060000 LTP 0x00000001) MADT: Found IO APIC ID 3, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 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 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: intpin 9 polarity: low MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan_amrr: wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Aug 15 2008 10:29:28) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SAT0.RDCC -> bus 0 dev 9 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.IMAP.PIRQ -> bus 0 dev 1 func 4 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.HPET.MMTB -> bus 0 dev 1 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 11 N 0 1 3 4 5 6 7 10 11 12 13 14 15 Validation 0 11 N 0 1 3 4 5 6 7 10 11 12 13 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 13 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link33: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link34: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link35: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link36: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link37: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link38: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link39: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link40: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link41: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link42: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link43: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link44: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link45: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link46: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link47: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link48: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link49: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link50: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link51: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link52: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link53: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link54: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link55: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 2 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x0754, revid=0xa2 domain=0, bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x075c, revid=0xa2 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0752, revid=0xa1 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x3080, size 6, enabled map[20]: type I/O Port, range 32, base 0x3040, size 6, enabled map[24]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.IMAP.LNKK:0) pci_link46: Picked IRQ 16 with weight 0 ioapic0: Changing polarity for pin 16 to high pcib0: slot 1 INTA routed to irq 16 via \\_SB_.PCI0.IMAP.LNKK found-> vendor=0x10de, dev=0x0751, revid=0xa1 domain=0, bus=0, slot=1, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0400, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0568, revid=0xa1 domain=0, bus=0, slot=1, func=4 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0400, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x077b, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf7f9000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.IMAP.LNKJ:0) pci_link45: Picked IRQ 17 with weight 0 ioapic0: Changing polarity for pin 17 to high pcib0: slot 2 INTA routed to irq 17 via \\_SB_.PCI0.IMAP.LNKJ found-> vendor=0x10de, dev=0x077c, revid=0xa1 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf7f6c00, size 8, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.IMAP.LNKI:0) pci_link44: Picked IRQ 18 with weight 0 ioapic0: Changing polarity for pin 18 to high pcib0: slot 2 INTB routed to irq 18 via \\_SB_.PCI0.IMAP.LNKI found-> vendor=0x10de, dev=0x077d, revid=0xa1 domain=0, bus=0, slot=4, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf7f8000, size 12, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.IMAP.LNKR:0) pci_link53: Picked IRQ 19 with weight 0 ioapic0: Changing polarity for pin 19 to high pcib0: slot 4 INTA routed to irq 19 via \\_SB_.PCI0.IMAP.LNKR found-> vendor=0x10de, dev=0x077e, revid=0xa1 domain=0, bus=0, slot=4, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf7f6800, size 8, enabled pcib0: matched entry for 0.4.INTB (src \\_SB_.PCI0.IMAP.LNKS:0) pci_link54: Picked IRQ 20 with weight 0 ioapic0: Changing polarity for pin 20 to high pcib0: slot 4 INTB routed to irq 20 via \\_SB_.PCI0.IMAP.LNKS found-> vendor=0x10de, dev=0x0774, revid=0xa1 domain=0, bus=0, slot=7, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks map[10]: type Memory, range 32, base 0xdf7fc000, size 14, enabled pcib0: matched entry for 0.7.INTA (src \\_SB_.PCI0.IMAP.LNKM:0) pci_link48: Picked IRQ 21 with weight 0 ioapic0: Changing polarity for pin 21 to high pcib0: slot 7 INTA routed to irq 21 via \\_SB_.PCI0.IMAP.LNKM found-> vendor=0x10de, dev=0x075a, revid=0xa1 domain=0, bus=0, slot=8, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0ad0, revid=0xa2 domain=0, bus=0, slot=9, func=0 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[20]: type I/O Port, range 32, base 0x30c0, size 4, enabled map[24]: type Memory, range 32, base 0xdf7fa000, size 13, enabled found-> vendor=0x10de, dev=0x0778, revid=0xa1 domain=0, bus=0, slot=16, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.IMAP.LKR0:0) pci_link36: Picked IRQ 22 with weight 0 ioapic0: Changing polarity for pin 22 to high pcib0: slot 16 INTA routed to irq 22 via \\_SB_.PCI0.IMAP.LKR0 found-> vendor=0x10de, dev=0x075b, revid=0xa1 domain=0, bus=0, slot=18, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.18.INTA (src \\_SB_.PCI0.IMAP.LKR2:0) pci_link38: Picked IRQ 23 with weight 0 ioapic0: Changing polarity for pin 23 to high pcib0: slot 18 INTA routed to irq 23 via \\_SB_.PCI0.IMAP.LKR2 found-> vendor=0x10de, dev=0x077a, revid=0xa1 domain=0, bus=0, slot=19, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.19.INTA (src \\_SB_.PCI0.IMAP.LKR3:0) pci_link39: Picked IRQ 16 with weight 1 pcib0: slot 19 INTA routed to irq 16 via \\_SB_.PCI0.IMAP.LKR3 found-> vendor=0x1022, dev=0x1200, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1201, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1202, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1203, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.4 (no driver attached) ohci0: mem 0xdf7f9000-0xdf7f9fff irq 17 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdf7f9000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 6 ports with 6 removable, self powered ehci0: mem 0xdf7f6c00-0xdf7f6cff irq 18 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xdf7f6c00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 50 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 15 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 6 ports with 6 removable, self powered ohci1: mem 0xdf7f8000-0xdf7f8fff irq 19 at device 4.0 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdf7f8000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci1 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ehci1: mem 0xdf7f6800-0xdf7f68ff irq 20 at device 4.1 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xdf7f6800 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 52 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controller, 15 ports each: usb2 usb3: on ehci1 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x4000-0x4fff pcib1: memory decode 0xdfe00000-0xdfefffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. ACPI: Found matching pin for 1.7.INTA at func 0: 11 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x107c, revid=0x05 domain=0, bus=1, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdfec0000, size 17, enabled pcib1: requested memory range 0xdfec0000-0xdfedffff: good map[14]: type Memory, range 32, base 0xdfee0000, size 17, enabled pcib1: requested memory range 0xdfee0000-0xdfefffff: good map[18]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib1: requested I/O range 0x4000-0x403f: in range pcib1: matched entry for 1.7.INTA (src \\_SB_.PCI0.IMAP.LNKA:0) ioapic0: Changing trigger for pin 11 to level pcib1: slot 7 INTA routed to irq 11 via \\_SB_.PCI0.IMAP.LNKA em0: port 0x4000-0x403f mem 0xdfec0000-0xdfedffff,0xdfee0000-0xdfefffff irq 11 at device 7.0 on pci1 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdfec0000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x4000 em0: bpf attached em0: Ethernet address: 00:0e:0c:c4:7c:a0 ioapic0: routing intpin 11 (ISA IRQ 11) to vector 53 em0: [FILTER] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf mem 0xdf7fa000-0xdf7fbfff at device 9.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30c0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=7f ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: stat1=0xff err=0xff lsb=0xff msb=0xff ata0: reset tp2 stat0=50 stat1=ff devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=7f ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: stat1=0xff err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=00 stat1=ff devices=0x4 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] ata1: [ITHREAD] pcib2: irq 22 at device 16.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x5000-0x5fff pcib2: memory decode 0xdfc00000-0xdfcfffff pcib2: prefetched decode 0xe0000000-0xefffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x7146, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib2: requested memory range 0xe0000000-0xefffffff: good map[18]: type Memory, range 64, base 0xdfcf0000, size 16, enabled pcib2: requested memory range 0xdfcf0000-0xdfcfffff: good map[20]: type I/O Port, range 32, base 0x5000, size 8, enabled pcib2: requested I/O range 0x5000-0x50ff: in range pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.IMAP.LK0A:0) pci_link4: Picked IRQ 17 with weight 1 pcib2: slot 0 INTA routed to irq 17 via \\_SB_.PCI0.IMAP.LK0A found-> vendor=0x1002, dev=0x7166, revid=0x00 domain=0, bus=2, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 64, base 0xdfce0000, size 16, enabled pcib2: requested memory range 0xdfce0000-0xdfceffff: good vgapci0: port 0x5000-0x50ff mem 0xe0000000-0xefffffff,0xdfcf0000-0xdfcfffff irq 17 at device 0.0 on pci2 vgapci1: mem 0xdfce0000-0xdfceffff at device 0.1 on pci2 pcib3: irq 23 at device 18.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: irq 16 at device 19.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xf000-0xfff pcib4: memory decode 0xdfa00000-0xdfafffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14e4, dev=0x169b, revid=0x02 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0x800dfaf0000, size 16, enabled pcib4: memory: end (dfafffff) < start (800dfaf0000) pcib4: requested unsupported memory range 0-0 (decoding 0xdfa00000-0xdfafffff, 0xfff00000-0xfffff) pcib4: matched entry for 4.0.INTA (src \\_SB_.PCI0.IMAP.LK3A:0) pci_link16: Picked IRQ 18 with weight 1 pcib4: slot 0 INTA routed to irq 18 via \\_SB_.PCI0.IMAP.LK3A bge0: mem 0x800dfaf0000-0x800dfafffff irq 18 at device 0.0 on pci4 pcib4: memory: end (dfafffff) < start (800dfaf0000) pcib4: bge0 requested unsupported memory range 0-0 (decoding 0xdfa00000-0xdfafffff, 0xfff00000-0xfffff) bge0: couldn't map memory device_attach: bge0 attach returned 6 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0xffffffff (1) atkbd: failed to reset the keyboard. kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), 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:0047 psm0: failed to reset the aux device. ppc0: using extended I/O port range ppc0: EPP SPP ppc0: port 0x378-0x37b irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 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] 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 ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] ahc_isa_probe 1: ioport 0x1c00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 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 0xcf800-0xd07ff,0xd0800-0xd17ff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) 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: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices ukbd0: on uhub0 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ums0: on uhub0 ums0: 3 buttons. Device configuration finished. Reducing kern.maxvnodes 238312 -> 100000 procfs registered lapic: Divisor 2, Frequency 100000701 hz Timecounter "TSC" frequency 2100014603 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad0: 152627MB at ata0-master UDMA33 ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: nVidia check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire acd0: DVDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB 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: no/blank disc ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 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 4 to local APIC 1 ioapic0: Assigning ISA IRQ 7 to local APIC 2 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 11 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 2 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 2 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted start_init: trying /sbin/init WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 Linux ELF exec handler installed em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP arp: 130.75.117.30 moved from 00:30:05:c5:e5:02 to 00:04:23:c5:41:00 on em0 arp: 10.117.0.10 moved from 00:30:05:c5:e5:02 to 00:04:23:c5:41:00 on em0 arp: 10.117.0.12 moved from 00:0e:0c:5f:c4:a7 to 00:0e:0c:06:42:bc on em0 --- Problems: 1. 7-stable locks up after launching cpu#1 and cpu#2. 2. onboard nic (broadcom BCM5787) does not work 3. onboard nvidia graphics card is not identified and works only in vesa mode Any help (especially on 1.) is heartly welcome. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 12:51: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 BEC081065675; Fri, 22 Aug 2008 12:51:37 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 86E9B8FC1C; Fri, 22 Aug 2008 12:51:37 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m7MCpasG001146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 08:51:37 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fCQmo+x/wOcKZugswJKf" Organization: U. Buffalo CSE Department Date: Fri, 22 Aug 2008 08:51:36 -0400 Message-Id: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: Subject: Upcoming Releases Schedule... 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, 22 Aug 2008 12:51:37 -0000 --=-fCQmo+x/wOcKZugswJKf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We're about to start the release cycle for FreeBSD-7.1 and FreeBSD-6.4. The proposed schedule for the "major events" of the cycle is: Freeze August 29=20 BETA September 1=20 Branch September 6=20 6.4-RC1 September 8 7.1-RC1 September 15 6.4-RC2 September 22=20 7.1-RC2 September 29=20 6.4-REL October 6 7.1-REL October 13 I haven't posted the schedule on the Web site yet, I'll try to get that done over the weekend. On Monday I'll switch RELENG_7 and RELENG_6 over to say they are 7.1-PRERELEASE and 6.4-PRERELEASE respectively as a heads-up that there will likely be higher-than-normal developer activity MFC-ing stuff before code freeze starts. Odds get higher that if you do updates using RELENG_7/RELENG_6 branches during this period you *might* wind up with a tree that isn't quite right because you happened to catch it part way through a developer doing a multi-step commit. We had been procrastinating on saying definitively whether we thought 6.4-REL would be the last of the RELENG_6 releases to see how well things went with 7.X (if 7.0-REL was a total disaster we'd have considered doing a 6.5-REL). It seems that 7.0-REL went well and RELENG_7 in general seems to be in good shape so we now expect 6.4-REL to be the last of the RELENG_6 releases. Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-fCQmo+x/wOcKZugswJKf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkiutlgACgkQ/G14VSmup/Z7WwCeJDgNCq0BfAj/o/DxRZuylwc/ Y6UAnAy7YEIBAyaVCML5cax+1IF1MLcd =IaeS -----END PGP SIGNATURE----- --=-fCQmo+x/wOcKZugswJKf-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 13:48: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 9F41B1065672 for ; Fri, 22 Aug 2008 13:48:07 +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 4BF078FC08 for ; Fri, 22 Aug 2008 13:48:07 +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 m7MDlxVm006045; Fri, 22 Aug 2008 09:47:59 -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 m7MDlwaN089762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 09:47:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808221347.m7MDlwaN089762@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Aug 2008 09:48:00 -0400 To: Brooks Davis From: Mike Tancsa In-Reply-To: <20080821203703.GA47728@lor.one-eyed-alien.net> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <20080821201042.GA56182@rink.nu> <20080821203703.GA47728@lor.one-eyed-alien.net> 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: Mikhail Teterin , freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts 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, 22 Aug 2008 13:48:07 -0000 At 04:37 PM 8/21/2008, Brooks Davis wrote: >On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote: > > On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > > > Finally, consider moving to pf instead, if you really feel ipfw is > > > what's causing your machine to crash. You might be pleasantly surprised > > > by the syntax, and overall administrative usability (it is significantly > > > superior to ipfw, IMHO). > > > > In fact, pf can already do this out-of-the-box, by doing something like: > > > > table persist > > pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep > > state \ > > (max-src-conn 15, max-src-conn-rate 5/3, overload flush > > global) > > > > If that is not an option, I have found that security/denyhosts works > > pretty well too (it just adds IP's to /etc/hosts.deniedssh, and > > host_access(5) denies them based on this) > >You almost certainly don't want to rate limit ssh connections, only failed >ones. If you rate limit connections and use svn, you're likely to lock your >self out. I find a happy balance is to exclude trusted CIDR blocks from the rate limiting and let everything else be limited. e.g. table persist table {192.168.0.0/16,1.0.0.0/24} block log quick proto tcp from to any port 22 block in log on $ext_if all pass log quick proto { tcp } from {!} to $myaddress port ssh \ flags S/SA keep state \ (max-src-conn 6, max-src-conn-rate 3/30, \ overload flush global) pass in on $ext_if inet proto tcp from to $ext_if port ssh keep state and then a crontab entry */5 * * * * /usr/local/sbin/expiretable -v -t 5m bruteforce ---Mike From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 14:48: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 B71FB1065671 for ; Fri, 22 Aug 2008 14:48:45 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4C97B8FC27 for ; Fri, 22 Aug 2008 14:48:45 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so157027gve.39 for ; Fri, 22 Aug 2008 07:48:45 -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:mime-version:content-type:content-transfer-encoding :content-disposition; bh=+T5PF4KR6vJqz8ODrodCqz2XQ9ycUAJMVQJhKQrMTV4=; b=madhTNGUtMsFV9LF/IG+sHuRehL+ehpokF65surb63u8afO8DZz3XaGtrbicnWw88p f1ad6dmrbUvPUcmV6ltpEtV2SXG93lhukUFyvvMRUu5zZPS1AjhSUeioeUavMyvzghKN SEUo5n6VkdVXKQabkqs0vjO/KNqBAHnIS/p+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=gfowjEOSv5S3W9ABlm7m06koAF2pPLb2GYbVWwba4Z2ctYVkc/oJyduNDqoo2QSbLd bo6ixS3YW5zq2Ob7saVeWJw357xv1EHJLZ/YNgGGJs2noCceUU1iBp1aIaMm0yghtMhk Svgx1JefzJnzMlwubTk6n24F1P841QTbzgRko= Received: by 10.187.240.1 with SMTP id s1mr96843far.61.1219414753656; Fri, 22 Aug 2008 07:19:13 -0700 (PDT) Received: by 10.187.222.15 with HTTP; Fri, 22 Aug 2008 07:19:13 -0700 (PDT) Message-ID: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> Date: Fri, 22 Aug 2008 17:19:13 +0300 From: "Nikolay Kalev" To: freebsd-sun4v@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: sun4v@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, kmacy@freebsd.org Subject: sun4v arch 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, 22 Aug 2008 14:48:45 -0000 I would also like to help as well. As KMacy knows before i asked a lot of questions for T2 types of servers but unfortunately i have no more access to those kind of hardware as well. I;m willing to participate if a team will be formated. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 15:04: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 CB7D010656D8; Fri, 22 Aug 2008 15:04:06 +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 18D4F8FC16; Fri, 22 Aug 2008 15:04:03 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48AED560.8010001@FreeBSD.org> Date: Fri, 22 Aug 2008 17:04:00 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Nikolay Kalev References: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> In-Reply-To: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sun4v@freebsd.org, freebsd-stable@freebsd.org, kmacy@freebsd.org, freebsd-hackers@freebsd.org, freebsd-sun4v@freebsd.org, freebsd-current@freebsd.org Subject: Re: sun4v arch 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, 22 Aug 2008 15:04:07 -0000 Nikolay Kalev wrote: > I would also like to help as well. > As KMacy knows before i asked a lot of questions for T2 types of > servers but unfortunately i have no more access to those kind of > hardware as well. > I;m willing to participate if a team will be formated. Just so everyone is on the same page, what is needed to keep sun4v viable are people with experience with (or intention to learn about) low level architectural and implementation details of the FreeBSD kernel and the sun4v hardware platform, who know their way around things like pmap.c and other MD places where the kernel interfaces with the "bare metal", and who are willing to make a long term (multi-year) commitment to supporting the platform. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 18:26: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 D6B4710656BF; Fri, 22 Aug 2008 18:26:31 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8928FC1D; Fri, 22 Aug 2008 18:26:31 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from 80-218-191-31.dclient.hispeed.ch ([80.218.191.31] helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KWZqU-0000Od-R2; Fri, 22 Aug 2008 18:50:42 +0200 Message-ID: <48AEEE3C.7030006@FreeBSD.org> Date: Fri, 22 Aug 2008 18:50:04 +0200 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080807) MIME-Version: 1.0 To: Kris Kennaway References: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> <48AED560.8010001@FreeBSD.org> In-Reply-To: <48AED560.8010001@FreeBSD.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: sun4v@freebsd.org, freebsd-stable@freebsd.org, kmacy@freebsd.org, freebsd-hackers@freebsd.org, freebsd-sun4v@freebsd.org, Nikolay Kalev , freebsd-current@freebsd.org Subject: Re: sun4v arch 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, 22 Aug 2008 18:26:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Kris Kennaway wrote: | Just so everyone is on the same page, what is needed to keep sun4v | viable are people with experience with (or intention to learn about) low | level architectural and implementation details of the FreeBSD kernel and | the sun4v hardware platform, who know their way around things like | pmap.c and other MD places where the kernel interfaces with the "bare | metal", and who are willing to make a long term (multi-year) commitment | to supporting the platform. If we had docs... | Kris - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkiu7jsACgkQwMJqmJVx946SjgCeMIDO6Q6hZSVlsfPQTJhkM3Vk BIUAmwWDU4IAqv+nyFvGRhSxblsrVh4Q =y3qu -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 19:00: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 8FDF9106567E; Fri, 22 Aug 2008 19:00:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 205AA8FC2D; Fri, 22 Aug 2008 19:00:21 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K6000K1AKNMSYA0@asmtp014.mac.com>; Fri, 22 Aug 2008 10:59:47 -0700 (PDT) Message-id: <477C6946-2540-4122-AD66-B769A623FE01@mac.com> From: Marcel Moolenaar To: freebsd-sun4v@freebsd.org In-reply-to: <20080822113317.GD32539@server.vk2pj.dyndns.org> Date: Fri, 22 Aug 2008 10:59:44 -0700 References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.928.1) Cc: sun4v@freebsd.org, freebsd-hackers@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, Kip Macy Subject: Re: the future of sun4v 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, 22 Aug 2008 19:00:24 -0000 On Aug 22, 2008, at 4:33 AM, Peter Jeremy wrote: > [Replies re-directed to freebsd-sun4v] > > On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: >> I believe that there is a general expectation by freebsd users and >> developers that unsupported code should not be in CVS. Although sun4v >> is a very interesting platform for developers doing SMP work, I >> simply >> do not have the time or energy to maintain it. If someone else would >> like to step up and try his hand I would be supportive of his >> efforts. >> In the likely event that no one steps forward by the time that 7.1 is >> released I will ask that it be moved to the Attic. > > Since there are no other current SPARC CPUs that FreeBSD can run on > (the US-II has been obsolete for about 6 years and FreeBSD won't run > on any more recent sun4u chips), that will also remove the > justification for maintaining a SPARC64 port. Marius has been doing some great work towards US-III support. I have FreeBSD/sparc64 running on Netra SMP with US-III CPUs. While the code is not in SVN, It's in Perforce and from what I can see, it's in a very good shape. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 20: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 45092106567E; Fri, 22 Aug 2008 20:37:29 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BDCDC8FC0C; Fri, 22 Aug 2008 20:37:28 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id m7MKG3qr024447; Fri, 22 Aug 2008 22:16:03 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id m7MKG39Y024446; Fri, 22 Aug 2008 22:16:03 +0200 (CEST) (envelope-from marius) Date: Fri, 22 Aug 2008 22:16:03 +0200 From: Marius Strobl To: Kris Kennaway Message-ID: <20080822201603.GA14444@alchemy.franken.de> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AEA699.10903@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: sun4v@freebsd.org, freebsd-stable@freebsd.org, Kip Macy , freebsd-hackers@freebsd.org, freebsd-sun4v@freebsd.org, FreeBSD Current Subject: Re: the future of sun4v 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, 22 Aug 2008 20:37:29 -0000 On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: > Peter Jeremy wrote: > >[Replies re-directed to freebsd-sun4v] > > > >On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: > >>I believe that there is a general expectation by freebsd users and > >>developers that unsupported code should not be in CVS. Although sun4v > >>is a very interesting platform for developers doing SMP work, I simply > >>do not have the time or energy to maintain it. If someone else would > >>like to step up and try his hand I would be supportive of his efforts. > >>In the likely event that no one steps forward by the time that 7.1 is > >>released I will ask that it be moved to the Attic. > > > >Since there are no other current SPARC CPUs that FreeBSD can run on > >(the US-II has been obsolete for about 6 years and FreeBSD won't run > >on any more recent sun4u chips), that will also remove the > >justification for maintaining a SPARC64 port. > > > >I don't have the knowledge or available time to maintain the sun4v > >port by myself but would be happy to be part of a team doing so. One > >impediment I have is that I don't have a T-1 or T-2 system that I can > >dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > >since FreeBSD doesn't support either the virtual disk or virtual > >network, actually getting FreeBSD running there presents somewhat of a > >challenge. > > > > There are two t1000 systems in the freebsd.org cluster that are > available for people to work on. Rink Springer has also expressed > interest in this. > > Perhaps Kip can explain some more about what things he looked at, but > the most serious bugs might be in pmap or perhaps trap handling. > Operationally, things like buildworld -jN die quickly with random > signals, kernel traps, etc. > > Kris > > P.S. It looks like marius has made progress on US III but sun4u is still > an architectural dead end. Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) Marius From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 20:41: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 EBD9E1065674 for ; Fri, 22 Aug 2008 20:41:46 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id B7DC28FC3A for ; Fri, 22 Aug 2008 20:41:46 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1073725rvf.43 for ; Fri, 22 Aug 2008 13:41:46 -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=VwIvVV9UTm+WX5L+17nrBjX7Tfwfqxy+YNwzRM9uvOc=; b=VEYeOYKPPNNqsQCzleVkZE67DWo4pHINQkk0o9JUbtrlp6jhBrwlZZ3qVDJJNSbtiL tD1dwbFqW0KFYEHOVwKjBLmkCZf+YFOobEzpO1sMXNiq2J+ul5jCi4P0hmpUoBoB/KZD IXBR25VAhS9SLSjMVANXjXhuuwa5i9zaL08jI= 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=cKQHxCn3AaicvsnGK4yStzxOyyY2MC2AD19oa8KOYw7CO23RrvAVoZI+MeTiDYGBvX fR9UlA4KP3leBizuSyPWsOZy4Sp36T3TIgpBUVEGWrznjbr80D68Z1iXFpRIr07kN5hR aMDuT4/Yxi76SIy9pO9VLSODdWcLsO2afKzd8= Received: by 10.141.36.10 with SMTP id o10mr747111rvj.176.1219437706340; Fri, 22 Aug 2008 13:41:46 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Fri, 22 Aug 2008 13:41:46 -0700 (PDT) Message-ID: <3c1674c90808221341i6c97be59wcfb10979305ffdb0@mail.gmail.com> Date: Fri, 22 Aug 2008 13:41:46 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Marius Strobl" In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> X-Google-Sender-Auth: 1cdec45359df961b Cc: sun4v@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org, Kris Kennaway , freebsd-sun4v@freebsd.org, FreeBSD Current Subject: Re: the future of sun4v 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, 22 Aug 2008 20:41:47 -0000 > Well, let's see what architecture the upcoming Rock CPUs are; > judging their feature list they appear to be a continuation of > the Fujitsu sun4u line rather than a successor of UST1/2 :) That is not what I've heard. -Kip From owner-freebsd-stable@FreeBSD.ORG Fri Aug 22 22:55: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 BBBBE106566C; Fri, 22 Aug 2008 22:55:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 490048FC12; Fri, 22 Aug 2008 22:55: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 mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7MMtBnn015778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 08:55:12 +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 m7MMtBbW007210; Sat, 23 Aug 2008 08:55:11 +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 m7MMtALg007209; Sat, 23 Aug 2008 08:55:10 +1000 (EST) (envelope-from peter) Date: Sat, 23 Aug 2008 08:55:10 +1000 From: Peter Jeremy To: Kris Kennaway Message-ID: <20080822225510.GI32539@server.vk2pj.dyndns.org> References: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> <48AED560.8010001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WoqaC9TUMqqIOlla" Content-Disposition: inline In-Reply-To: <48AED560.8010001@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, kmacy@freebsd.org, freebsd-sun4v@freebsd.org Subject: Re: sun4v arch 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, 22 Aug 2008 22:55:14 -0000 --WoqaC9TUMqqIOlla Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Aug-22 17:04:00 +0200, Kris Kennaway wrote: >Just so everyone is on the same page, what is needed to keep sun4v=20 >viable are people with experience with (or intention to learn about) low= =20 >level architectural and implementation details of the FreeBSD kernel What documentation is currently accurate for this beyond the source code? The only things I can quickly find are: "Design & Implementation of FreeBSD 5.2" and "FreeBSD Architecture Handbook". The former is getting quite old and I'm not sure how up-to-date the latter is kept. >the sun4v hardware platform, Is the documentation at http://www.opensparc.net/opensparc-t1/index.html and http://www.opensparc.net/opensparc-t2/index.html adequate for this or is there additional information that is needed? Is there any tutorial style documentation on the low-level T1/T2 details? > who know their way around things like=20 >pmap.c and other MD places where the kernel interfaces with the "bare=20 >metal", I've poked around the low-level details of FreeBSD/i386 and /Alpha in the past, though I'm nothing like an expert at it. sun4v/sun4v is only about twice the size of a 6th Edition kernel... > and who are willing to make a long term (multi-year) commitment >to supporting the platform. Yes. Is there a summary of the open issues somewhere? There are no sun4v PRs open. http://wiki.freebsd.org/FreeBSD/sun4v effectively hasn't been touched since November 2006 and suggests that the only critical issue is lack of serial port support. --=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. --WoqaC9TUMqqIOlla Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkivQ84ACgkQ/opHv/APuIdZuwCglKH8AiGskbfJXqdbFd9PVipt OeMAnA4v40rQalNO/rEi9s5fDfq/+9IQ =CDvj -----END PGP SIGNATURE----- --WoqaC9TUMqqIOlla-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 06:53: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 A04471065671; Sat, 23 Aug 2008 06:53:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0AB8FC08; Sat, 23 Aug 2008 06:53:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7N6pSNC087402; Sat, 23 Aug 2008 00:51:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 23 Aug 2008 00:52:00 -0600 (MDT) Message-Id: <20080823.005200.-335188553.imp@bsdimp.com> To: gahr@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <48AEEE3C.7030006@FreeBSD.org> References: <136a340a0808220719t3a170786s7fd4bcb662d0b981@mail.gmail.com> <48AED560.8010001@FreeBSD.org> <48AEEE3C.7030006@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sun4v@FreeBSD.org, freebsd-stable@FreeBSD.org, kmacy@FreeBSD.org, freebsd-hackers@FreeBSD.org, kris@FreeBSD.org, freebsd-sun4v@FreeBSD.org, nkalev@gmail.com, freebsd-current@FreeBSD.org Subject: Re: sun4v arch 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, 23 Aug 2008 06:53:16 -0000 In message: <48AEEE3C.7030006@FreeBSD.org> Pietro Cerutti writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA512 : : Kris Kennaway wrote: : | Just so everyone is on the same page, what is needed to keep sun4v : | viable are people with experience with (or intention to learn about) low : | level architectural and implementation details of the FreeBSD kernel and : | the sun4v hardware platform, who know their way around things like : | pmap.c and other MD places where the kernel interfaces with the "bare : | metal", and who are willing to make a long term (multi-year) commitment : | to supporting the platform. : : If we had docs... There's a bunch of sun4v docs available. See http://www.sun.com/processors/documentation.html for example. Warner From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 09:29:45 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 619A71065677; Sat, 23 Aug 2008 09:29:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 292508FC15; Sat, 23 Aug 2008 09:29:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9Thm8075101; Sat, 23 Aug 2008 05:29:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9Tgh4017987; Sat, 23 Aug 2008 05:29:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 77DAF241A2; Sat, 23 Aug 2008 05:29:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080823092947.77DAF241A2@freebsd-legacy.sentex.ca> Date: Sat, 23 Aug 2008 05:29:47 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_6 tinderbox] failure on amd64/amd64 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: Sat, 23 Aug 2008 09:29:45 -0000 TB --- 2008-08-23 09:21:47 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-23 09:21:47 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2008-08-23 09:21:47 - cleaning the object tree TB --- 2008-08-23 09:22:16 - cvsupping the source tree TB --- 2008-08-23 09:22:16 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2008-08-23 09:22:24 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-23 09:22:24 - cd /src TB --- 2008-08-23 09:22:24 - /usr/bin/make -B buildworld >>> 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 [...] ===> lib/libpam/modules/pam_rootok (buildincludes) ===> lib/libpam/modules/pam_securetty (buildincludes) ===> lib/libpam/modules/pam_self (buildincludes) ===> lib/libpam/modules/pam_ssh (buildincludes) ===> lib/libpam/modules/pam_tacplus (buildincludes) ===> lib/libpam/modules/pam_unix (buildincludes) ===> lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-23 09:29:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-23 09:29:47 - ERROR: failed to build world TB --- 2008-08-23 09:29:47 - tinderbox aborted TB --- 356.13 user 40.32 system 480.31 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 09:37: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 80A2F1065678; Sat, 23 Aug 2008 09:37:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 481838FC19; Sat, 23 Aug 2008 09:37:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9b0b9075778; Sat, 23 Aug 2008 05:37:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9b07x023058; Sat, 23 Aug 2008 05:37:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 57917241A2; Sat, 23 Aug 2008 05:37:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080823093705.57917241A2@freebsd-legacy.sentex.ca> Date: Sat, 23 Aug 2008 05:37:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_6 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: Sat, 23 Aug 2008 09:37:02 -0000 TB --- 2008-08-23 09:29:47 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-23 09:29:47 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2008-08-23 09:29:47 - cleaning the object tree TB --- 2008-08-23 09:30:13 - cvsupping the source tree TB --- 2008-08-23 09:30:13 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/i386/supfile TB --- 2008-08-23 09:30:21 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-23 09:30:21 - cd /src TB --- 2008-08-23 09:30:21 - /usr/bin/make -B buildworld >>> 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 [...] ===> lib/libpam/modules/pam_rootok (buildincludes) ===> lib/libpam/modules/pam_securetty (buildincludes) ===> lib/libpam/modules/pam_self (buildincludes) ===> lib/libpam/modules/pam_ssh (buildincludes) ===> lib/libpam/modules/pam_tacplus (buildincludes) ===> lib/libpam/modules/pam_unix (buildincludes) ===> lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-23 09:37:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-23 09:37:05 - ERROR: failed to build world TB --- 2008-08-23 09:37:05 - tinderbox aborted TB --- 327.26 user 32.47 system 437.70 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 09: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 EBF58106567C; Sat, 23 Aug 2008 09:44:32 +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 B18008FC15; Sat, 23 Aug 2008 09:44:32 +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 m7N9iTXO032585; Sat, 23 Aug 2008 05:44:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9iTe1034672; Sat, 23 Aug 2008 05:44:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 0EEB7241A2; Sat, 23 Aug 2008 05:44:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080823094434.0EEB7241A2@freebsd-legacy.sentex.ca> Date: Sat, 23 Aug 2008 05:44:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_6 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: Sat, 23 Aug 2008 09:44:33 -0000 TB --- 2008-08-23 09:37:05 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-23 09:37:05 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-08-23 09:37:05 - cleaning the object tree TB --- 2008-08-23 09:37:29 - cvsupping the source tree TB --- 2008-08-23 09:37:29 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-08-23 09:37:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-23 09:37:37 - cd /src TB --- 2008-08-23 09:37:37 - /usr/bin/make -B buildworld >>> 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 [...] ===> lib/libpam/modules/pam_rootok (buildincludes) ===> lib/libpam/modules/pam_securetty (buildincludes) ===> lib/libpam/modules/pam_self (buildincludes) ===> lib/libpam/modules/pam_ssh (buildincludes) ===> lib/libpam/modules/pam_tacplus (buildincludes) ===> lib/libpam/modules/pam_unix (buildincludes) ===> lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-23 09:44:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-23 09:44:34 - ERROR: failed to build world TB --- 2008-08-23 09:44:34 - tinderbox aborted TB --- 328.09 user 32.62 system 448.51 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 09:46:04 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 41D211065675; Sat, 23 Aug 2008 09:46:04 +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 E221B8FC27; Sat, 23 Aug 2008 09:46:03 +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 m7N9k2Ol032633; Sat, 23 Aug 2008 05:46:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m7N9k1jb035647; Sat, 23 Aug 2008 05:46:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 9B05D241A2; Sat, 23 Aug 2008 05:46:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080823094606.9B05D241A2@freebsd-legacy.sentex.ca> Date: Sat, 23 Aug 2008 05:46:06 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, 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_6 tinderbox] failure on sparc64/sparc64 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: Sat, 23 Aug 2008 09:46:04 -0000 TB --- 2008-08-23 09:39:44 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-23 09:39:44 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2008-08-23 09:39:44 - cleaning the object tree TB --- 2008-08-23 09:40:05 - cvsupping the source tree TB --- 2008-08-23 09:40:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile TB --- 2008-08-23 09:40:16 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-23 09:40:16 - cd /src TB --- 2008-08-23 09:40:16 - /usr/bin/make -B buildworld >>> 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 [...] ===> lib/libpam/modules/pam_rootok (buildincludes) ===> lib/libpam/modules/pam_securetty (buildincludes) ===> lib/libpam/modules/pam_self (buildincludes) ===> lib/libpam/modules/pam_ssh (buildincludes) ===> lib/libpam/modules/pam_tacplus (buildincludes) ===> lib/libpam/modules/pam_unix (buildincludes) ===> lib/libpam/libpam (buildincludes) make: don't know how to make security/openpam_attr.h. Stop *** Error code 2 Stop in /src/lib/libpam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-23 09:46:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-23 09:46:06 - ERROR: failed to build world TB --- 2008-08-23 09:46:06 - tinderbox aborted TB --- 281.35 user 31.88 system 381.98 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 23 20:31: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 279A7106567A for ; Sat, 23 Aug 2008 20:31:44 +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 B7FCB8FC37 for ; Sat, 23 Aug 2008 20:31:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7NKVNZg020490; Sat, 23 Aug 2008 16:31:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Sat, 23 Aug 2008 07:50:09 -0400 User-Agent: KMail/1.9.7 References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808230750.09774.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Sat, 23 Aug 2008 16:31:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8079/Sat Aug 23 12:49:14 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,NO_RELAYS autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Gerrit =?iso-8859-1?q?K=FChn?= , d@delphij.net Subject: Re: Regression 7.0R -> 7-stable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 20:31:44 -0000 On Thursday 14 August 2008 02:46:37 am Gerrit K=FChn wrote: > On Thu, 07 Aug 2008 15:55:30 -0700 Xin LI wrote > about Re: Regression 7.0R -> 7-stable?: > > XL> Could you please try disabling ACPI and boot? Additionally a 'boot - > XL> v' may reveal some useful information as well. Just some random > XL> thoughts. > > Disabling ACPI does not help, either (forgot to mention that earlier, > sorry). I will post a boot -v log as soon as I have a working 7.0R on the > system again. What about disabling apic? Also, are you using a serial console? If so, c= an=20 you put DDB in your kernel and when it hangs break into ddb and do a 'ps' a= nd=20 capture the output. =2D-=20 John Baldwin