From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 21 17:39:38 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03DCF16A418 for ; Sun, 21 Oct 2007 17:39:38 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id F04A713C4B3 for ; Sun, 21 Oct 2007 17:39:37 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 40528 invoked by uid 1001); 21 Oct 2007 01:39:17 -0000 Date: Sat, 20 Oct 2007 18:39:17 -0700 From: "David E. Thiel" To: freebsd-hackers@freebsd.org Message-ID: <20071021013917.GB86865@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg User-Agent: Mutt/1.5.16 (2007-06-09) Subject: packages, libfetch, and SSL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 17:39:38 -0000 Hello, I've been doing some thinking about the security of the packages and ports system, and have noticed that there is something of a weak link when it comes to fetch/libfetch in general, and the way we do pkg_adds in particular. While updates to the ports tree happen in a pretty secure manner over portsnap, and distfiles are verified during the build process, packages added over pkg_add -r happen over plain FTP or HTTP without any verification, allowing packages to be swapped or corrupted by a network attacker. The lowest-impact way to fix this, I think, is to use SSL for pkg_adds. There are a couple of things that would need to change to make this happen. * Package distribution sites should use SSL over HTTP. Yes, this costs money. We can either find a way to use a free solution or get people to chip in - I'd gladly put some money up for this. * libfetch needs patched to verify SSL certificate CNs and to use SSL_CTX_set_verify on SSL contexts. It should really be considered a vulnerability that this currently doesn't happen, since SSL is meaningless without this. This is easy enough to fix (about 10 lines in libfetch/common.c), but is currently not feasible because: * CA certificates are not in the base system. CA certs are currently available in the security/ca_root_nss port. Is this suitable for importing to base? If not, why not? Now, we could take another approach of PGP-signing packages instead, but all the efforts I've seen to integrate PGP with the package management system in the past haven't gone anywhere. The changes above seem to be a bit more trivial than inventing a package-signing infrastructure and putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign packages and having a baked-in key would work as well. If we don't want to do any of this, I at least think that the current SSL support in libfetch should be removed entirely, or be accompanied by a very noisy error. Any thoughts? Cheers, David From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 21 17:42:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9337616A420 for ; Sun, 21 Oct 2007 17:42:42 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id 51AD413C494 for ; Sun, 21 Oct 2007 17:42:41 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1IjeoW-0000co-Kg for freebsd-hackers@freebsd.org; Sun, 21 Oct 2007 13:42:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=0UTmdFI+DxdhBifRUQbVZi7nicSrtl7FfGoKrI9ZFNIAdBw+fqicHBXlJqBg+Lmy DqjGaSeCTqDr+bKeugK5Q1mQwySnxKlBYeuoAKqC24WK6bfPv7IjpPGOlfjwWd4D V7TVTWpI4jk39s0rKOBjqqGour1QfZk3UesdgVVRzFI=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Sun, 21 Oct 2007 13:42:12 -0400 From: dexterclarke@Safe-mail.net To: freebsd-hackers@freebsd.org X-SMType: Regular X-SMRef: N1-GaMaRiCtWF Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: LDjtUI/5oJ2s53stgCDM0IOeLV6LHLNdGoHsf7MCVtzOPWaN1ijR7etgJTTYMAW4 Y1zHHQFKd5UjK4Iyp339OZA68p+jeZCYPj0znCs8czzOwCQsAFdkx9a34lg4yV1U c4ISHJDPnTR/NM3vfOK5MyfldmoEGNLPrjJ91u3D9cw= Subject: Segfault in praudit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 17:42:42 -0000 FreeBSD 6.2-RELEASE-p8 #2, i386 sudo auditreduce -m AUE_REBOOT /dev/auditpipe | praudit auditreduce in free(): error: junk pointer, too high to make sense Abort trap (core dumped) sudo auditreduce -m AUE_CONNECT /dev/auditpipe | praudit auditreduce in free(): error: junk pointer, too high to make sense Abort trap (core dumped) Not-exactly-helpful backtrace: #0 0x28146ecb in kill () from /lib/libc.so.6 #1 0x28146e68 in raise () from /lib/libc.so.6 #2 0x28145b78 in abort () from /lib/libc.so.6 #3 0x280e2fdb in _UTF8_init () from /lib/libc.so.6 #4 0xbfbfea28 in ?? () #5 0x2814cdd3 in sys_nsig () from /lib/libc.so.6 #6 0x2814ccd3 in sys_nsig () from /lib/libc.so.6 #7 0x2814cdf0 in sys_nsig () from /lib/libc.so.6 #8 0x00000000 in ?? () #9 0x28157d80 in ?? () from /lib/libc.so.6 #10 0xbfbfe6d8 in ?? () #11 0x280e3009 in _UTF8_init () from /lib/libc.so.6 #12 0x28157d80 in ?? () from /lib/libc.so.6 #13 0x2816da24 in _nsyyin () from /lib/libc.so.6 #14 0xbfbfe788 in ?? () #15 0x280e3d69 in _UTF8_init () from /lib/libc.so.6 #16 0x2808a6c0 in ?? () from /usr/lib/libbsm.so.1 #17 0x2808a6da in ?? () from /usr/lib/libbsm.so.1 #18 0x2806f558 in ?? () from /libexec/ld-elf.so.1 #19 0x08048574 in ?? () #20 0x00000001 in ?? () #21 0xbfbfe724 in ?? () #22 0x28051863 in find_symdef () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) Is this a known problem? It occurs when specifying any valid event name. -- dc From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 21 17:43:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C70916A41A for ; Sun, 21 Oct 2007 17:43:44 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2CC3E13C481 for ; Sun, 21 Oct 2007 17:43:44 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1Ijepr-0000xH-LU for freebsd-hackers@freebsd.org; Sun, 21 Oct 2007 13:43:35 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=XAgviH6UCccARv/gHe9kyvOGRbg/kDTc6lG5695moIZYb8GkiTUhXbbt/vt7Eolj G4AHPZsMHGL+AyTHgYvYdLM+4XOHUU5FtWKTkWKG2H9OjyMsuc0bFWgv3J4s9pvx RRgxOB1oNQBS8oMuXFpvkYG8Hgi1qa64ZOLwCsx7Q2s=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Sun, 21 Oct 2007 13:43:35 -0400 From: dexterclarke@Safe-mail.net To: freebsd-hackers@freebsd.org X-SMType: Regular X-SMRef: N1-_iHJxsOow0 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: 0RrdpBX0qx/nsUCu1VVbFr4ADQNyw1KKV/Vb/fIkItRxw25OssITmM1X2UsCCJs2 KrpDyIKW4YKGGHm6Tg4X/dFvjYzVBdgFe+OLFdj9Sc1DvAmU6gslNOfaT51GrEec yEnfARX7B7/xCZEOF9qaasyjElYxmL1YOPleY/CRIxM= Subject: Segfault in _auditreduce_ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 17:43:44 -0000 Sorry about that, see the corrected subject - the segmentation fault was not in praudit but in auditreduce. __ dc From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 21 17:48:17 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459B516A417 for ; Sun, 21 Oct 2007 17:48:17 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id 059DF13C4BB for ; Sun, 21 Oct 2007 17:48:16 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1IjetV-0001mt-OT for freebsd-hackers@freebsd.org; Sun, 21 Oct 2007 13:47:21 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=T0rqK2oxY3rB5mTixp8smtV9BFf0heIfHrnR3yfOT8S8Gq7goex4yVH+nh3tVeyS gPSecvyai+Hu0A6gz7zeArMpF6VQ01tLLRRxPhgvy4Le16IIq3rEd+b6mouP7r36 Ijs0bZUO7KueQGEzgtI7eI10hNnVEZ1GlAEz0oOS5xg=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Sun, 21 Oct 2007 13:47:21 -0400 From: dexterclarke@Safe-mail.net To: freebsd-hackers@freebsd.org X-SMType: Regular X-SMRef: N1-XZ6XLHAihD Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: CzxJQFaYMSavrbSyevK/l/REGJkWmoCROE9+NwSKaaVzVTHBdhxiLoHfYV6mwniq taLgiRmtwpT7j6eiisyRrnOyUzhLr+n7IVrZ9gwR7WqPJFzUKZsEYWQLc0QeJCSh t4FS3316AxDUWsG+IaGkMOFxoajej1s66la6qI9AgEM= Subject: auditpipe leak? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 17:48:17 -0000 If I repeatedly do: # praudit /dev/auditpipe ^C I end up with rather a lot of /dev/auditpipe* crw------- 1 root wheel 0, 137 21 Oct 17:51 /dev/auditpipe0 crw------- 1 root wheel 0, 138 21 Oct 17:51 /dev/auditpipe1 crw------- 1 root wheel 0, 141 21 Oct 17:51 /dev/auditpipe2 crw------- 1 root wheel 0, 142 21 Oct 17:51 /dev/auditpipe3 crw------- 1 root wheel 0, 143 21 Oct 17:51 /dev/auditpipe4 The numbers seem to increment forever, in testing, I got up to /dev/auditpipe50 before rebooting to clean them up (I expect just restarting devfs would've been enough, in retrospect). Is this a known issue? FreeBSD 6.2-RELEASE-p8 #2 i386 -- dc From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 02:34:21 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD29D16A417 for ; Mon, 22 Oct 2007 02:34:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id AB7A313C4C1 for ; Mon, 22 Oct 2007 02:34:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1185957waf for ; Sun, 21 Oct 2007 19:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=3GoEEOL3wdkhxrQBE7a/jkLnIFGKvLLlaGOk3Qojpgc=; b=VkvFlKG6hA5QP1+1odHSfg14UD8JhKUw9CYAI+wrBN2eMWRAcufH5BpWQajgVJBTyNBB7Cs7+UBrSFzn4/p9+avEDFsYA9SMygRC2NImcNCw5x1sYl4YpfYJ3qMgDYqfMsC2XNgPnP6TZslVtxXCLG1dxJe8fhxwgk4Xx/7MxFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=nennmxGQchibdk1gTnkor6WKWnbPGwt87nGqTnL3klG3W0TZTPgPbciuzWqU+H+VUeGcwu6MSOf0n/8rHottwyvJATMoPVoFhqPaF2fgEHDaHHluEOt1fRDuu8lmv3Kl/VHFXi/RFbqiMf5RxydVp3dg/w4buUZgSZ0otaBHhzY= Received: by 10.114.67.2 with SMTP id p2mr4871023waa.1193018853516; Sun, 21 Oct 2007 19:07:33 -0700 (PDT) Received: by 10.114.67.19 with HTTP; Sun, 21 Oct 2007 19:07:33 -0700 (PDT) Message-ID: Date: Mon, 22 Oct 2007 10:07:33 +0800 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "David E. Thiel" In-Reply-To: <20071021013917.GB86865@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071021013917.GB86865@redundancy.redundancy.org> X-Google-Sender-Auth: 934b225760acc791 Cc: freebsd-hackers@freebsd.org Subject: Re: packages, libfetch, and SSL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 02:34:21 -0000 On 21/10/2007, David E. Thiel wrote: > > The lowest-impact way to fix this, I think, is to use SSL for pkg_adds. > There are a couple of things that would need to change to make this > happen. You can't (easily) cache data over SSL. Well, you can't use a HTTP proxy that doesn't break the SSL conversation and cache the updates. As someone who occasionally makes sure that distribution updates through a Squid proxy actually caches said updates, I'd really prefer you didn't stick package contents behind SSL. > Now, we could take another approach of PGP-signing packages instead, but > all the efforts I've seen to integrate PGP with the package management > system in the past haven't gone anywhere. The changes above seem to be > a bit more trivial than inventing a package-signing infrastructure and > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign > packages and having a baked-in key would work as well. Considering its a solved problem (mostly!) in other distributions, and their updates are very cachable, why not do this? Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 03:28:03 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5187116A417 for ; Mon, 22 Oct 2007 03:28:03 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id 2792E13C4BB for ; Mon, 22 Oct 2007 03:28:03 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 10410 invoked by uid 1001); 22 Oct 2007 03:28:20 -0000 Date: Sun, 21 Oct 2007 20:28:19 -0700 From: "David E. Thiel" To: Adrian Chadd Message-ID: <20071022032819.GE75639@redundancy.redundancy.org> References: <20071021013917.GB86865@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg X-Face: %H~{$1~NOw1y#%mM6{|4:/ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 03:28:03 -0000 On Mon, Oct 22, 2007 at 10:07:33AM +0800, Adrian Chadd wrote: > You can't (easily) cache data over SSL. Well, you can't use a HTTP > proxy that doesn't break the SSL conversation and cache the updates. > > As someone who occasionally makes sure that distribution updates > through a Squid proxy actually caches said updates, I'd really prefer > you didn't stick package contents behind SSL. Fair enough. > > Now, we could take another approach of PGP-signing packages instead, but > > all the efforts I've seen to integrate PGP with the package management > > system in the past haven't gone anywhere. The changes above seem to be > > a bit more trivial than inventing a package-signing infrastructure and > > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign > > packages and having a baked-in key would work as well. > > Considering its a solved problem (mostly!) in other distributions, and > their updates are very cachable, why not do this? Sounds fine to me - I'll take a closer look at this. I'd still like to see the root CA certs merged into base so libfetch can be fixed. Does anyone object to just using the ones currently provided by the ca_root_nss port? From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 16:17:20 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C3616A419; Mon, 22 Oct 2007 16:17:20 +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 BEDE813C494; Mon, 22 Oct 2007 16:17:19 +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.13.8/8.13.8) with ESMTP id l9MGHINx021747; Mon, 22 Oct 2007 11:17:18 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l9MGHIX5021746; Mon, 22 Oct 2007 11:17:18 -0500 (CDT) (envelope-from brooks) Date: Mon, 22 Oct 2007 11:17:18 -0500 From: Brooks Davis To: "David E. Thiel" Message-ID: <20071022161718.GB21096@lor.one-eyed-alien.net> References: <20071021013917.GB86865@redundancy.redundancy.org> <20071022032819.GE75639@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline In-Reply-To: <20071022032819.GE75639@redundancy.redundancy.org> User-Agent: Mutt/1.5.15 (2007-04-06) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 22 Oct 2007 11:17:18 -0500 (CDT) Cc: freebsd-hackers@freebsd.org, Adrian Chadd Subject: Re: packages, libfetch, and SSL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 16:17:20 -0000 --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2007 at 08:28:19PM -0700, David E. Thiel wrote: > On Mon, Oct 22, 2007 at 10:07:33AM +0800, Adrian Chadd wrote: > > You can't (easily) cache data over SSL. Well, you can't use a HTTP > > proxy that doesn't break the SSL conversation and cache the updates. > >=20 > > As someone who occasionally makes sure that distribution updates > > through a Squid proxy actually caches said updates, I'd really prefer > > you didn't stick package contents behind SSL. >=20 > Fair enough. >=20 > > > Now, we could take another approach of PGP-signing packages instead, = but > > > all the efforts I've seen to integrate PGP with the package management > > > system in the past haven't gone anywhere. The changes above seem to be > > > a bit more trivial than inventing a package-signing infrastructure and > > > putting gpg or a BSD-licensed clone into base. Perhaps using SSL to s= ign > > > packages and having a baked-in key would work as well. > >=20 > > Considering its a solved problem (mostly!) in other distributions, and > > their updates are very cachable, why not do this? >=20 > Sounds fine to me - I'll take a closer look at this. I'd still like > to see the root CA certs merged into base so libfetch can be fixed. > Does anyone object to just using the ones currently provided by the > ca_root_nss port? If we're going to have a default set, this is the right one since it's the = one everyone already trusts. It would be useful to know what the security team thinks of the idea. -- Brooks --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHHM0NXY6L6fI4GtQRAmoiAJsEtJU6xN8MOvWoUZM4Lot8959SIgCg5OKJ ElxIQ2RPTiGCgI3R4SuG+oM= =MTYR -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 20:00:38 2007 Return-Path: Delivered-To: Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133AC16A417 for ; Mon, 22 Oct 2007 20:00:38 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8D11613C4A8 for ; Mon, 22 Oct 2007 20:00:37 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([217.166.176.2]) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id l9MJjAsR058533 for ; Mon, 22 Oct 2007 21:45:10 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.46.137] (dhcp-077-248-238-249.chello.nl [77.248.238.249]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id l9MJkT9J013026 for ; Mon, 22 Oct 2007 21:46:29 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: Hackers@FreeBSD.org Date: Mon, 22 Oct 2007 21:46:17 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710222146.17262.Danovitsch@vitsch.net> Cc: Subject: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 20:00:38 -0000 Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 10000 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 10000 I now have a function that gets called 10000 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, &fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, &fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 20:30:34 2007 Return-Path: Delivered-To: FreeBSD-Hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 900DD16A477 for ; Mon, 22 Oct 2007 20:30:34 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id D57A813C4C2 for ; Mon, 22 Oct 2007 20:30:33 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([217.166.176.2]) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id l9MKAi8h058732 for ; Mon, 22 Oct 2007 22:10:45 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.46.137] (dhcp-077-248-238-249.chello.nl [77.248.238.249]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id l9MKC36F013098 for ; Mon, 22 Oct 2007 22:12:03 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: FreeBSD-Hackers@freebsd.org User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 22 Oct 2007 22:11:51 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710222211.51590.Danovitsch@vitsch.net> Cc: Subject: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 20:30:34 -0000 Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 10000 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 10000 I now have a function that gets called 10000 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, &fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, &fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 22 20:40:04 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAE9316A418 for ; Mon, 22 Oct 2007 20:40:04 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8CD13C4BC for ; Mon, 22 Oct 2007 20:40:03 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1Ik43K-0003TR-Db for freebsd-hackers@freebsd.org; Mon, 22 Oct 2007 16:39:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=qAwp0racryAGcUSCjSg7NQ3HT5ehJpueTghe+JT+97SCuCPZMy721syjuCVDUOLh 68XZ0DjDj0kxVwrkJjd2qf9Q69DfOEqYEOoIEQ5Hz+z3etewYJmgCtq2ZRafkptv o7as6DLKs3QKR3aTD6iJR3ZaRrlLDv83zPDVHErW8/M=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Mon, 22 Oct 2007 16:39:10 -0400 From: dexterclarke@Safe-mail.net To: freebsd-hackers@freebsd.org X-SMType: Regular X-SMRef: N1-veZSUWkeZs Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: YzQQwuxcLRxwM/LFKM5SjLXUdl5MAHNB7ka/z63GTfC99sxF1CZiBgnpZxHRxGqh LUDVraKYjTKbZjIhA2c1Izu7C+Seqx4r3UX/6T1rrlobc1SALpwfc/Zzu8NGFqjv C40ho+sAMUfEVWF3i/GSUF/hI2cWS7vbYJJHIeUEqK8= Subject: Re: Segfault in _auditreduce_ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2007 20:40:04 -0000 Patch for the issue: --- auditreduce.c.orig Mon Oct 22 21:32:07 2007 +++ auditreduce.c Mon Oct 22 21:30:13 2007 @@ -719,7 +719,6 @@ if (n == NULL) usage("Incorrect event name"); p_evtype = *n; - free(n); } SETOPT(opttochk, OPT_m); break; getauevnonam() returns a statically allocated event that the main function then attempts to free() for some reason. This patch is against 6.2-RELEASE so it's probably already out of date. -- dc From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 06:05:36 2007 Return-Path: Delivered-To: FreeBSD-Hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D21B16A417 for ; Tue, 23 Oct 2007 06:05:36 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id D89F613C4A5 for ; Tue, 23 Oct 2007 06:05:35 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([217.166.176.2]) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id l9N63O48063455; Tue, 23 Oct 2007 08:03:25 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.45.230] (dhcp-077-250-050-082.chello.nl [77.250.50.82]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id l9N64oSX014811; Tue, 23 Oct 2007 08:04:51 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: soralx@cydem.org Date: Tue, 23 Oct 2007 08:04:33 +0200 User-Agent: KMail/1.9.7 References: <200710222211.51590.Danovitsch@vitsch.net> <20071022183509.3bdbc65d@soralx> In-Reply-To: <20071022183509.3bdbc65d@soralx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710230804.33120.Danovitsch@vitsch.net> Cc: FreeBSD-Hackers@freebsd.org Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 06:05:36 -0000 Hi SorAlx On Tuesday 23 October 2007 03:35:09 you wrote: > > As a first test I've created a simple loop that uses integer > > arithmetic and a lookup table to create a sine wave on one of the DAC > > outputs. This works like a charm, but I really would like to be able > > to use floating point instructions to create more advanced control > > loops. So I've added asm inline functions to use the FPU's fsin and > > fcos operands. At the start of my loop function I (try to) save the > > FPU state with the following code : > > why do you need floating point? Your ADCs and DACs are probably no more > than 16 bit anyway. Because of several reasons. The most important one being that it's a work related project. I'm the one developing the driver, not the one that's going to write the control loop. I need this driver to be usable by anyone with basic mathematical/programming skills. The second reason would be : "because I know it can be done". The code I currently have successfully uses floating point instructions in the kernel. Any modern CPU can execute extreme amounts of floating point instructions per second. Please lets not try to discuss the (dis)advantages of integer math vs. floating point. I know how to write integer math, but it's not what I'm looking for for this project. Thanks, -- Daan From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 06:20:44 2007 Return-Path: Delivered-To: FreeBSD-Hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC4716A468 for ; Tue, 23 Oct 2007 06:20:44 +0000 (UTC) (envelope-from issei.suzuki@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id B07D913C4B3 for ; Tue, 23 Oct 2007 06:20:43 +0000 (UTC) (envelope-from issei.suzuki@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1442025wxd for ; Mon, 22 Oct 2007 23:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=2RmW/2S85IAOk9PNaN1tW7D0nwrjPA2XI8zbOa9igig=; b=lL0d5t9LGqViEC5CLjHpSEAHrNezUi12++QQgDVrZPBoGK9KVJObU5oskB3Emitx1WtRBBj/FFvs82aa7X5VpnFzWfYgiN4b/uUcgZyE1/++iqhfGQGlRDoO4RqgtLoM/DBOOSzFP5RZ8kPpWyyasEyHBpKyklO45B7P2pO5Rdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=V4L1MY9fZTO4mJI1kf+q+N+nSUiKqEVxELoAMAztwX7kR5GmYq/JBOr0oVFy+QEE92VerlipYE4Yk9Oa3mEAVf/qdvQEsb6li6YqN45HN4QuwZGbngRrDkKxxZWc5c9GQCuwoaS2iF/wsP+RpoiTPNk0E6+bmbHiAhNm030VYNY= Received: by 10.90.97.19 with SMTP id u19mr1820716agb.1193118761673; Mon, 22 Oct 2007 22:52:41 -0700 (PDT) Received: by 10.90.71.9 with HTTP; Mon, 22 Oct 2007 22:52:41 -0700 (PDT) Message-ID: <337dbc4d0710222252o1817e359k393a398de2315677@mail.gmail.com> Date: Tue, 23 Oct 2007 14:52:41 +0900 From: "Issei Suzuki" Sender: issei.suzuki@gmail.com To: FreeBSD-Hackers@freebsd.org In-Reply-To: <200710222211.51590.Danovitsch@vitsch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710222211.51590.Danovitsch@vitsch.net> X-Google-Sender-Auth: 92c39ce98fa8fce0 Cc: Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 06:20:44 -0000 2007/10/23, Daan Vreeken [PA4DAN] : > So I've added asm inline functions to use the FPU's fsin and fcos operands. At > the start of my loop function I (try to) save the FPU state with the > following code : > td = curthread; > npxgetregs(td, &fpu_state); > At the end of the function I restore the FPU state with : > npxsetregs(td, &fpu_state); > > In between I currently have : > // create a 500Hz sine wave, modulate it with a 2Hz sine wave and > // let it have a 10.0 Volt amplitude > t += 0.0001; > set_dac_voltage(card, 0, > fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); > > As uggly as the code may seem, it works and the output of the acquisition > board shows the expected signal on a scope. While the code seems to do what > it should, the kernel floods the console with the following message : > kernel trap 22 with interrupts disabled In FreeBSD, FPU context switch is delayed until FPU is used for the first time after user thread is switched. To achieve this, T_DNA (FPU device not available trap) is used as follows. (Before switching thread) 1. Save FPU state and enable DNA trap (npxsave() @ /sys/i386/isa/npx.c). After this, DNA trap occurs when you access FPU. (Switch to another user thread) 2. User thread accesses FPU. 3. T_DNA trap occurs, and npxdna() @ /sys/i386/isa/npx.c is called. 4. Initialize FPU state (1st time) or restore FPU state (2nd times or later). 5. Return to user mode, and user thread access FPU again. So, to use FPU in kernel, you must clear T_DNA trap and initialize FPU registers first. Reading these functions may help you, I think. /sys/i386/isa/npx.c start_emulating() stop_emulating() npxdna() Regards, -- Issei Suzuki From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 11:47:26 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EC9D16A41B for ; Tue, 23 Oct 2007 11:47:26 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.freebsd.org (Postfix) with ESMTP id D9C4B13C465 for ; Tue, 23 Oct 2007 11:47:25 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [192.168.0.242] (host-84-9-12-193.bulldogdsl.com [84.9.12.193]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id l9NBT6nY034344 for ; Tue, 23 Oct 2007 12:29:06 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: hackers@freebsd.org From: Bob Bishop Date: Tue, 23 Oct 2007 12:29:12 +0100 X-Mailer: Apple Mail (2.752.3) Cc: Subject: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 11:47:26 -0000 Hi, The whole USB kit and caboodle is nodevice'd out in the PAE config. Can anyone give a succinct summary of what needs fixing? (EVERYTHING! is an acceptable answer) Thanks -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 12:00:53 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA7D816A417 for ; Tue, 23 Oct 2007 12:00:53 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 665A113C481 for ; Tue, 23 Oct 2007 12:00:52 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([217.166.176.2]) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id l9NBwOlN066107; Tue, 23 Oct 2007 13:58:25 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.72.251] (81-171-30-78.dsl.fiberworld.nl [81.171.30.78] (may be forged)) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id l9NBxlUa015665; Tue, 23 Oct 2007 13:59:49 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: "Issei Suzuki" Date: Tue, 23 Oct 2007 13:59:32 +0200 User-Agent: KMail/1.9.7 References: <200710222211.51590.Danovitsch@vitsch.net> <337dbc4d0710222252o1817e359k393a398de2315677@mail.gmail.com> In-Reply-To: <337dbc4d0710222252o1817e359k393a398de2315677@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710231359.32979.Danovitsch@vitsch.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 12:00:53 -0000 On Tuesday 23 October 2007 07:52:41 Issei Suzuki wrote: > 2007/10/23, Daan Vreeken [PA4DAN] : > > So I've added asm inline functions to use the FPU's fsin and fcos > > operands. At the start of my loop function I (try to) save the FPU state > > with the following code : > > td = curthread; > > npxgetregs(td, &fpu_state); > > At the end of the function I restore the FPU state with : > > npxsetregs(td, &fpu_state); > > > > In between I currently have : > > // create a 500Hz sine wave, modulate it with a 2Hz sine wave and > > // let it have a 10.0 Volt amplitude > > t += 0.0001; > > set_dac_voltage(card, 0, > > fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); > > > > As uggly as the code may seem, it works and the output of the acquisition > > board shows the expected signal on a scope. While the code seems to do > > what it should, the kernel floods the console with the following message > > : kernel trap 22 with interrupts disabled > > In FreeBSD, FPU context switch is delayed until FPU is used for the > first time after user thread is switched. To achieve this, T_DNA > (FPU device not available trap) is used as follows. > > (Before switching thread) > 1. Save FPU state and enable DNA trap (npxsave() @ /sys/i386/isa/npx.c). > After this, DNA trap occurs when you access FPU. > (Switch to another user thread) > 2. User thread accesses FPU. > 3. T_DNA trap occurs, and npxdna() @ /sys/i386/isa/npx.c is called. > 4. Initialize FPU state (1st time) or restore FPU state (2nd times or > later). 5. Return to user mode, and user thread access FPU again. > > So, to use FPU in kernel, you must clear T_DNA trap and initialize FPU > registers first. > > Reading these functions may help you, I think. > > /sys/i386/isa/npx.c > start_emulating() > stop_emulating() > npxdna() Thanks for the insights, this has helped a lot. If I understand the code correctly, there are 2 options when the kernel arrives at hardclock() : o The current process is using the FPU (fpcurthread != NULL) o The current process hasn't used the FPU (yet) since it has been switched to (fpcurthread == NULL) In the first case, FPU instructions can be used and will not result in a trap, but we should save/restore the FPU state before using them so userland doesn't get confused. In the last case FPU instructions result in a trap, so we need stop/start_emulating(), but as no one is using the FPU, there is no need to save/restore it's state. With this in mind I've come up with the following code : At the start of the function : // check FPU state on entry if (PCPU_GET(fpcurthread) != NULL) { // someone is using the FPU // save it's state and remember to put it back later restore = 1; fpusave(&fpu_state); } else { // no one is using the FPU // enable use of FPU instructions, no need to save it's state restore = 0; stop_emulating(); } // init FPU state every time we get here, as we don't know who has // been playing with it in between calls fninit(); control = __INITIAL_NPXCW__; fldcw(&control); Then we do some floating point arithmetic. And at the end of the function : // restore FPU state before we leave if (restore) { // restore FPU registers to what they were fpurstor(&fpu_state); } else { // no one was using the FPU, so re-enable the FPU trap start_emulating(); } With this code trap-22 has stopped to trigger within my function. The FPU instructions still seem to be executed correctly in my function and when adding a couple of printf()'s I can see it fpusave() and fpurstor() when interrupting a userland process that uses the FPU. Does this look reasonable to everyone? Thanks, -- Daan From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 14:43:54 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 257DB16A419 for ; Tue, 23 Oct 2007 14:43:54 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9448413C4B2 for ; Tue, 23 Oct 2007 14:43:53 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1546475wxd for ; Tue, 23 Oct 2007 07:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=ENxGIz6LYjPvM4GD33tmP4N9zAwgl/ENqyj26yzijR8=; b=NcHeszlqPLCyg176y2q8+PtCHpKHbXjjaH1N0BJuIhv56dVcFcSLMeD2aMFl9YHkBm3srCeXScOkDtquq3Yroynhm+IZGcu9wJH6jldD6RK4NxcdFUgkFnWbr0dBNfU6g6zWhEkm43Bnr5IYFClcwRmuYYvyTVGoj0iZ3QXVALM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rSjQnATihJOMzGa8qovOo9/uJX1rKF966QK+4473JPbcq1AX/uTR1USWfVW0JdCTwiWz8hJhrYmt/tq70pvXFoyeUrJlAFQ86tL+zyfZBDPr8rz5jVCHYdT6eYQMW9cmW7l3LJt6nVTblSVd/Bx6Ix6zIlVANWBwCmerb/HaN+4= Received: by 10.90.83.14 with SMTP id g14mr601972agb.1193148924520; Tue, 23 Oct 2007 07:15:24 -0700 (PDT) Received: from ?192.168.2.2? ( [67.85.89.184]) by mx.google.com with ESMTPS id z26sm8950657ele.2007.10.23.07.15.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Oct 2007 07:15:23 -0700 (PDT) Message-ID: <471E00FE.6030903@gmail.com> Date: Tue, 23 Oct 2007 10:11:10 -0400 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.6 (X11/20071016) MIME-Version: 1.0 To: Bob Bishop References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> In-Reply-To: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 14:43:54 -0000 Bob Bishop wrote: > Hi, > > The whole USB kit and caboodle is nodevice'd out in the PAE config. > Can anyone give a succinct summary of what needs fixing? (EVERYTHING! > is an acceptable answer) This may not be related but xorg had real difficulty findind cards with pae (e6850 4 gig)... amd64 fixed this From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 20:15:01 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D03C916A419 for ; Tue, 23 Oct 2007 20:15:01 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 96B2213C481 for ; Tue, 23 Oct 2007 20:15:01 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IkPhJ-0006sK-B2 for freebsd-hackers@freebsd.org; Tue, 23 Oct 2007 19:45:53 +0000 Received: from 89-172-60-98.adsl.net.t-com.hr ([89.172.60.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 19:45:53 +0000 Received: from ivoras by 89-172-60-98.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2007 19:45:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 23 Oct 2007 21:45:32 +0200 Lines: 36 Message-ID: References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70C083930B97499D163D413B" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-60-98.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 20:15:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70C083930B97499D163D413B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bob Bishop wrote: > Hi, >=20 > The whole USB kit and caboodle is nodevice'd out in the PAE config. Can= > anyone give a succinct summary of what needs fixing? (EVERYTHING! is an= > acceptable answer) Thanks I'm running USB keyboard and mouse under PAE without problems. Don't know about other USB devices. AFAIK everything that is 64-bit clean (i.e. works on AMD64 and other architectures) should work ok with PAE, so try compiling it in and see for yourself. --------------enig70C083930B97499D163D413B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHk9nldnAQVacBcgRAmHFAJ0VUDabxTU6KzyKB5BkoNhuE6Po9QCgvtgZ dSvtGV3Nky5ChTB8g2zOBK0= =9kwH -----END PGP SIGNATURE----- --------------enig70C083930B97499D163D413B-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 22:30:46 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9656E16A417 for ; Tue, 23 Oct 2007 22:30:46 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6C52C13C4B3 for ; Tue, 23 Oct 2007 22:30:46 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 2285317338; Tue, 23 Oct 2007 17:27:39 -0500 (CDT) Date: Tue, 23 Oct 2007 17:27:39 -0500 From: "Christian S.J. Peron" To: dexterclarke@Safe-mail.net Message-ID: <20071023222739.GA4815@sub.vaned.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: Segfault in praudit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 22:30:46 -0000 I have fixed this issue in the vendor branch. We expect to do an vendor import soon. On Sun, Oct 21, 2007 at 01:42:12PM -0400, dexterclarke@Safe-mail.net wrote: > FreeBSD 6.2-RELEASE-p8 #2, i386 > > sudo auditreduce -m AUE_REBOOT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > sudo auditreduce -m AUE_CONNECT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > Not-exactly-helpful backtrace: > > #0 0x28146ecb in kill () from /lib/libc.so.6 > #1 0x28146e68 in raise () from /lib/libc.so.6 > #2 0x28145b78 in abort () from /lib/libc.so.6 > #3 0x280e2fdb in _UTF8_init () from /lib/libc.so.6 > #4 0xbfbfea28 in ?? () > #5 0x2814cdd3 in sys_nsig () from /lib/libc.so.6 > #6 0x2814ccd3 in sys_nsig () from /lib/libc.so.6 > #7 0x2814cdf0 in sys_nsig () from /lib/libc.so.6 > #8 0x00000000 in ?? () > #9 0x28157d80 in ?? () from /lib/libc.so.6 > #10 0xbfbfe6d8 in ?? () > #11 0x280e3009 in _UTF8_init () from /lib/libc.so.6 > #12 0x28157d80 in ?? () from /lib/libc.so.6 > #13 0x2816da24 in _nsyyin () from /lib/libc.so.6 > #14 0xbfbfe788 in ?? () > #15 0x280e3d69 in _UTF8_init () from /lib/libc.so.6 > #16 0x2808a6c0 in ?? () from /usr/lib/libbsm.so.1 > #17 0x2808a6da in ?? () from /usr/lib/libbsm.so.1 > #18 0x2806f558 in ?? () from /libexec/ld-elf.so.1 > #19 0x08048574 in ?? () > #20 0x00000001 in ?? () > #21 0xbfbfe724 in ?? () > #22 0x28051863 in find_symdef () from /libexec/ld-elf.so.1 > Previous frame inner to this frame (corrupt stack?) > > Is this a known problem? It occurs when specifying any valid > event name. > > -- > dc > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 23 22:32:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4402E16A41B for ; Tue, 23 Oct 2007 22:32:59 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 21D4113C4B3 for ; Tue, 23 Oct 2007 22:32:58 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 018CA173B3; Tue, 23 Oct 2007 17:29:44 -0500 (CDT) Date: Tue, 23 Oct 2007 17:29:43 -0500 From: "Christian S.J. Peron" To: dexterclarke@Safe-mail.net Message-ID: <20071023222943.GB4815@sub.vaned.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: auditpipe leak? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 22:32:59 -0000 On Sun, Oct 21, 2007 at 01:47:21PM -0400, dexterclarke@Safe-mail.net wrote: [..] > > crw------- 1 root wheel 0, 137 21 Oct 17:51 /dev/auditpipe0 > crw------- 1 root wheel 0, 138 21 Oct 17:51 /dev/auditpipe1 > crw------- 1 root wheel 0, 141 21 Oct 17:51 /dev/auditpipe2 > crw------- 1 root wheel 0, 142 21 Oct 17:51 /dev/auditpipe3 > crw------- 1 root wheel 0, 143 21 Oct 17:51 /dev/auditpipe4 > > The numbers seem to increment forever, in testing, I got up to > /dev/auditpipe50 before rebooting to clean them up (I expect > just restarting devfs would've been enough, in retrospect). > This is not a leak, this is a side effect of how device cloning works in devfs. IIRC these will be garbaged collected at some point, and faster if the system requires the resources. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 01:47:51 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29CB16A418 for ; Wed, 24 Oct 2007 01:47:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.freebsd.org (Postfix) with ESMTP id D375A13C4B2 for ; Wed, 24 Oct 2007 01:47:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 22F02153882; Tue, 23 Oct 2007 15:47:40 -1000 (HST) Date: Tue, 23 Oct 2007 15:47:40 -1000 From: Clifton Royston To: soralx@cydem.org, freebsd-hackers@freebsd.org Message-ID: <20071024014737.GE19536@lava.net> Mail-Followup-To: soralx@cydem.org, freebsd-hackers@freebsd.org References: <20071014203736.GB2677@lava.net> <20071014160520.07ad521d@soralx> <20071014231917.GB29405@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071014231917.GB29405@lava.net> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: A more tenuously package-related question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 01:47:52 -0000 On Sun, Oct 14, 2007 at 01:19:17PM -1000, Clifton Royston wrote: > On Sun, Oct 14, 2007 at 04:05:20PM -0700, soralx@cydem.org wrote: > > > I used to use pkg_update from the 'pkg_install-devel' toolset to > > > upgrade systems via replacement of binary packages. ... > > > Is there any better equivalent tool at the moment, or should I just > > > resuscitate the old "pkg_update"? > > > > Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P` > > for binary updates. Besides actual 'portupgrade', it has a set of > > useful tools, too. But be warned -- the utility is snail-slow. > > I did look at it, but it appeared that it needed to run off the > FreeBSD ports tree, whereas I'm building packages from a separate > instance of the ports tree in our own CVS, with local modifications, > and then deploying these packages on multiple servers. (This time > around, I'm planning to not even install the ports tree on servers > other than the build server.) I therefore need to use a utility which > can operate using only the dependency information in the pkgdb and > embedded in the package files themselves. > > After posting before, I decided to explore pkg_replace, and it > appears that it might be able to do what I want with the right options. I got a request to summarize my results to the list, so here's a quick write-up. Based on my preliminary testing last week, pkg_replace looks like the right tool for package-based server maintenance. One invaluable feature which was not immediately obvious from the description and man page is that if you give it a list of binary packages on the command line, it orders the updates correctly based on the dependencies between those packages. Thus updating my test server with the recently security-fixed versions of the packages for png and ImageMagick was just a matter of executing: sudo pkg_replace png-1.2.22.tbz ImageMagick-nox11-6.3.5.10_1.tbz in my package repository directory. Updating all of my locally written software packages from 1.99 to 2.00 was as simple as: sudo pkg_replace *-2.00.tbz Given this command line, pkg_replace ordered the dependencies properly, and then pkg_deleted each old package and replaced it with the updated version in correct dependency order, and fixed the requirements and dependency links in the package DB. This is much better than pkg_update could do in my experience; if you tried to pkg_update a package in which the newer version had a dependency which had not yet been satisfied, it would simply fail with the old version deleted and the new one not yet installed. (I have not yet checked how pkg_replace works if you are replacing a package with a newer version which has additional dependencies not present in the old one, so I don't know whether it will invoke pkg_add to recursively add the new requirements, but as long as all the packages you want to replace are in one command line it appears to DTRT.) I've confirmed you can also sudo pkg_replace -f foo-1.2.3.tbz to force version 1.2.3 of foo to replace some version x.y.z >= 1.2.3. Without the -f it will balk at replacing a package which has the same or higher version # than the one you're installing. (I had a interim version of a package where I had omitted an item from its packing list, and so wanted to replace it without revving the version.) All good behavior IMHO. Another interesting feature is that its default behavior is to use pkg_create to backup the package you're replacing, according to its packing list, before deleting it. This means by default you should find it trivially easy to roll back the change you just made. It would be really nice to have a tool with this capability in the base system some day (I'm just saying...) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 03:47:15 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB6616A468; Wed, 24 Oct 2007 03:47:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx01.syd.optusnet.com.au (fallbackmx01.syd.optusnet.com.au [211.29.132.93]) by mx1.freebsd.org (Postfix) with ESMTP id BDC5C13C4B3; Wed, 24 Oct 2007 03:47: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 fallbackmx01.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l9NJVoLs012698; Wed, 24 Oct 2007 05:31:50 +1000 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l9NJVeUX008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 05:31:41 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9NJVedJ024424; Wed, 24 Oct 2007 05:31:40 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9NJVeOG024423; Wed, 24 Oct 2007 05:31:40 +1000 (EST) (envelope-from peter) Date: Wed, 24 Oct 2007 05:31:40 +1000 From: Peter Jeremy To: "David E. Thiel" Message-ID: <20071023193140.GP81509@server.vk2pj.dyndns.org> References: <20071021013917.GB86865@redundancy.redundancy.org> <20071022032819.GE75639@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <20071022032819.GE75639@redundancy.redundancy.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org, Adrian Chadd Subject: Re: packages, libfetch, and SSL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 03:47:15 -0000 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2007 at 08:28:19PM -0700, David E. Thiel wrote: >Sounds fine to me - I'll take a closer look at this. I'd still like >to see the root CA certs merged into base so libfetch can be fixed. So would I. >Does anyone object to just using the ones currently provided by the >ca_root_nss port? I would like to have CAcert (www.cacert.org) included. It is not currently in the Mozilla root set but is included in various Linux and other BSD distributions. See http://wiki.cacert.org/wiki/InclusionStatus (which lists FreeBSD on the basis of the now-removed caroot port). I agree that the final decision should be up to the Security team. --=20 Peter --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHHkwc/opHv/APuIcRAlyvAJ0XkleFL9SKetKnP6AulJO7Fj259gCcCe32 KX1w+yMWWZVly8msSSKiyqM= =EJT4 -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 06:28:35 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E928F16A418; Wed, 24 Oct 2007 06:28:35 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8676B13C4C8; Wed, 24 Oct 2007 06:28:34 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 9623933; Wed, 24 Oct 2007 10:24:38 +0400 Received: from [80.68.244.40] (adm40.relax.ru [80.68.244.40]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id 859E3289DD; Wed, 24 Oct 2007 10:24:47 +0400 (MSD) Message-ID: <471EE4D9.5080307@chistydom.ru> Date: Wed, 24 Oct 2007 10:23:21 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> In-Reply-To: <4715C5D7.7060806@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020108020005080507060303" X-Mailman-Approved-At: Wed, 24 Oct 2007 11:56:22 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 06:28:36 -0000 This is a multi-part message in MIME format. --------------020108020005080507060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kris Kennaway wrote: >>>> So I can conclude that FreeBSD has a long standing bug in VM that >>>> could be triggered when serving large amount of static data (much >>>> bigger than memory size) on high rates. Possibly this only applies >>>> to large files like mp3 or video. >>> It is possible, we have further work to do to conclude this though. >> I forgot to mention I have pmc and kgmon profiling for good and bad >> times. But I have not enough knowledge to interpret it right and not >> sure if it can help. > pmc would be useful. pmc profiling attached. I tried to increase BUCKET_MAX from 128 to 256, but it didn't help. Also I found out that multi-process HTTP servers survives better. You can see graphs at http://83.167.98.162/gprof/graph/ What else can I try to solve the problem? With best regards, Alexey Popov --------------020108020005080507060303 Content-Type: text/plain; name="pmc-gprof-bad.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pmc-gprof-bad.txt" None flat profile: % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this seconds function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/call function per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/call function and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. granularity: each sample hit covers 4 byte(s) for 0.01% of 14240.00 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 7.5 1068.00 1068.00 in_cksumdata [1] 4.5 1702.00 634.00 SHA256_Transform [2] 3.8 2237.00 535.00 fr_check [3] 3.7 2762.00 525.00 tcp_output [4] 3.6 3273.00 511.00 ipfw_chk [5] 3.3 3743.00 470.00 lockmgr [6] 2.0 4023.00 280.00 cache_lookup [7] 1.9 4291.00 268.00 lookup [8] 1.9 4558.00 267.00 uma_zfree_arg [9] 1.9 4823.00 265.00 uma_zfree_internal [10] 1.8 5075.00 252.00 bus_dmamap_load_mbuf_sg [11] 1.8 5326.00 251.00 em_start_locked [12] 1.7 5570.00 244.00 sched_switch [13] 1.6 5801.00 231.00 spinlock_exit [14] 1.6 6024.00 223.00 tcp_input [15] 1.6 6245.00 221.00 uma_zalloc_arg [16] 1.4 6446.00 201.00 fr_makefrip [17] 1.4 6644.00 198.00 in_cksum_skip [18] 1.4 6837.00 193.00 mi_switch [19] 1.3 7027.00 190.00 ip_output [20] 1.3 7217.00 190.00 pfil_run_hooks [21] 1.3 7396.00 179.00 m_copym [22] 1.2 7567.00 171.00 callout_reset [23] 1.2 7732.00 165.00 bzero [24] 1.2 7896.00 164.00 lockstatus [25] 1.1 8057.00 161.00 rn_match [26] 1.0 8193.00 136.00 ithread_loop [27] 0.9 8322.00 129.00 critical_exit [28] 0.9 8445.00 123.00 spinlock_enter [29] 0.9 8567.00 122.00 _mtx_lock_spin [30] 0.8 8688.00 121.00 bcopy [31] 0.8 8800.00 112.00 kern_sendfile [32] 0.8 8908.00 108.00 cpu_switch [33] 0.7 9003.00 95.00 uma_slab_alloc [34] 0.7 9096.00 93.00 hpet_get_timecount [35] 0.7 9189.00 93.00 rtalloc1 [36] 0.7 9282.00 93.00 syscall [37] 0.6 9366.00 84.00 choosethread [38] 0.6 9448.00 82.00 vget [39] 0.6 9527.00 79.00 vdropl [40] 0.6 9606.00 79.00 vn_lock [41] 0.5 9683.00 77.00 ip_input [42] 0.5 9758.00 75.00 bcmp [43] 0.5 9830.00 72.00 _mtx_lock_sleep [44] 0.5 9901.00 71.00 rt_check [45] 0.5 9970.00 69.00 maybe_preempt [46] 0.5 10039.00 69.00 vput [47] 0.5 10106.00 67.00 sched_add [48] 0.5 10172.00 66.00 ufs_access [49] 0.5 10238.00 66.00 vinactive [50] 0.5 10303.00 65.00 ether_output_frame [51] 0.4 10366.00 63.00 acquire [52] 0.4 10429.00 63.00 copyinstr [53] 0.4 10492.00 63.00 em_start [54] 0.4 10554.00 62.00 runq_choose [55] 0.4 10615.00 61.00 dummynet_task [56] 0.4 10675.00 60.00 in_broadcast [57] 0.4 10734.00 59.00 mb_ctor_mbuf [58] 0.4 10793.00 59.00 memcpy [59] 0.4 10852.00 59.00 ufs_inactive [60] 0.4 10910.00 58.00 vmtotal [61] 0.4 10966.00 56.00 Xfast_syscall [62] 0.4 11020.00 54.00 binuptime [63] 0.4 11073.00 53.00 arpresolve [64] 0.4 11126.00 53.00 critical_enter [65] 0.4 11178.00 52.00 VOP_UNLOCK_APV [66] 0.4 11228.00 50.00 vref [67] 0.3 11277.00 49.00 kern_open [68] 0.3 11324.00 47.00 _mtx_lock_spin_flags [71] 0.3 11371.00 47.00 fr_checkv4sum [69] 0.3 11418.00 47.00 softclock [70] 0.3 11463.00 45.00 kqueue_register [72] 0.3 11507.00 44.00 VOP_LOCK_APV [73] 0.3 11550.00 43.00 acpi_cpu_idle [74] 0.3 11593.00 43.00 ioapic_enable_source [75] 0.3 11636.00 43.00 vfs_cache_lookup [76] 0.3 11678.00 42.00 knote [77] 0.3 11720.00 42.00 rtfree [78] 0.3 11761.00 41.00 intr_event_schedule_thread [79] 0.3 11801.00 40.00 ether_output [80] 0.3 11840.00 39.00 _mtx_trylock [83] 0.3 11879.00 39.00 ioapic_disable_source [81] 0.3 11918.00 39.00 sleepq_lookup [82] 0.3 11956.00 38.00 mb_free_ext [84] 0.3 11994.00 38.00 vaccess [85] 0.3 12030.00 36.00 VOP_ISLOCKED_APV [86] 0.3 12066.00 36.00 cpu_idle [87] 0.3 12102.00 36.00 sleepq_signal [88] 0.2 12137.00 35.00 kern_kevent [89] 0.2 12170.00 33.00 sbdrop_locked [90] 0.2 12202.00 32.00 VOP_LOOKUP_APV [91] 0.2 12234.00 32.00 falloc [92] 0.2 12265.00 31.00 in_pcblookup_hash [93] 0.2 12294.00 29.00 netisr_processqueue [94] 0.2 12323.00 29.00 rtalloc_ign [95] 0.2 12352.00 29.00 tc_windup [96] 0.2 12380.00 28.00 random_process_event [97] 0.2 12407.00 27.00 _mtx_unlock_spin_flags [102] 0.2 12434.00 27.00 doselwakeup [98] 0.2 12461.00 27.00 fr_dolog [99] 0.2 12488.00 27.00 intr_execute_handlers [100] 0.2 12515.00 27.00 sleepq_wait [101] 0.2 12541.00 26.00 fdrop [103] 0.2 12567.00 26.00 sched_userret [104] 0.2 12592.00 25.00 fdrop_locked [105] 0.2 12616.00 24.00 namei [106] 0.2 12640.00 24.00 vm_page_splay [107] 0.2 12663.00 23.00 acpi_cpu_c1 [108] 0.2 12686.00 23.00 malloc [109] 0.2 12709.00 23.00 rn_satisfies_leaf [110] 0.2 12732.00 23.00 sleepq_add [111] 0.2 12755.00 23.00 userret [112] 0.1 12776.00 21.00 fr_checknatout [113] 0.1 12797.00 21.00 sched_runnable [114] 0.1 12817.00 20.00 taskqueue_enqueue [115] 0.1 12837.00 20.00 tcp_xmit_bandwidth_limit [116] 0.1 12856.00 19.00 msleep_spin [117] 0.1 12875.00 19.00 runq_remove [118] 0.1 12893.00 18.00 ffs_sync [119] 0.1 12911.00 18.00 swi_net [120] 0.1 12928.00 17.00 copyin [121] 0.1 12945.00 17.00 fget [122] 0.1 12962.00 17.00 fr_checkstate [123] 0.1 12979.00 17.00 frpr_pullup [124] 0.1 12996.00 17.00 in_delayed_cksum [125] 0.1 13012.00 16.00 doreti [126] 0.1 13028.00 16.00 hardclock_process [127] 0.1 13044.00 16.00 kqueue_aquire [128] 0.1 13060.00 16.00 lapic_handle_timer [129] 0.1 13076.00 16.00 sowakeup [130] 0.1 13092.00 16.00 tcp_dooptions [131] 0.1 13107.00 15.00 filt_sowrite [132] 0.1 13122.00 15.00 fr_acctpkt [133] 0.1 13137.00 15.00 m_extadd [134] 0.1 13152.00 15.00 tcp_usr_send [135] 0.1 13167.00 15.00 vrele [136] 0.1 13181.00 14.00 SHA256_Update [137] 0.1 13195.00 14.00 malloc_type_freed [138] 0.1 13209.00 14.00 rman_get_bustag [139] 0.1 13223.00 14.00 runq_check [140] 0.1 13237.00 14.00 sleepq_lock [141] 0.1 13251.00 14.00 taskqueue_run [142] 0.1 13265.00 14.00 vfs_msync [143] 0.1 13278.00 13.00 ffs_lock [144] 0.1 13291.00 13.00 free [145] 0.1 13304.00 13.00 msleep [146] 0.1 13317.00 13.00 pmc_cpu_is_logical [147] 0.1 13330.00 13.00 sleepq_catch_signals [148] 0.1 13343.00 13.00 vop_stdislocked [149] 0.1 13355.00 12.00 _callout_stop_safe [156] 0.1 13367.00 12.00 kqueue_release [150] 0.1 13379.00 12.00 mb_dtor_pack [151] 0.1 13391.00 12.00 sbcompress [152] 0.1 13403.00 12.00 setrunqueue [153] 0.1 13415.00 12.00 sf_buf_mext [154] 0.1 13427.00 12.00 uma_zone_slab [155] 0.1 13438.00 11.00 VOP_ACCESS_APV [157] 0.1 13449.00 11.00 Xapic_isr1 [158] 0.1 13460.00 11.00 __mnt_vnode_next [167] 0.1 13471.00 11.00 fgetsock [159] 0.1 13482.00 11.00 fr_check_wrapper [160] 0.1 13493.00 11.00 hardclock [161] 0.1 13504.00 11.00 ipfw_check_out [162] 0.1 13515.00 11.00 runq_add [163] 0.1 13526.00 11.00 sleepq_resume_thread [164] 0.1 13537.00 11.00 vm_page_wire [165] 0.1 13548.00 11.00 vnode_create_vobject_off [166] 0.1 13558.00 10.00 compute_cn_lkflags [168] 0.1 13568.00 10.00 sbappendstream [169] 0.1 13578.00 10.00 setrunnable [170] 0.1 13588.00 10.00 sleepq_switch [171] 0.1 13598.00 10.00 vfs_hash_get [172] 0.1 13608.00 10.00 vm_object_clear_flag [173] 0.1 13618.00 10.00 vn_start_write [174] 0.1 13627.00 9.00 copyout [175] 0.1 13636.00 9.00 fgetvp_read [176] 0.1 13645.00 9.00 in_matroute [177] 0.1 13654.00 9.00 kevent [178] 0.1 13663.00 9.00 knote_fdclose [179] 0.1 13672.00 9.00 lapic_handle_intr [180] 0.1 13681.00 9.00 m_freem [181] 0.1 13690.00 9.00 maybe_resched [182] 0.1 13699.00 9.00 scanc [183] 0.1 13708.00 9.00 sleepq_release [184] 0.1 13717.00 9.00 sysctl_find_oid [185] 0.1 13726.00 9.00 vm_pageq_enqueue [186] 0.1 13735.00 9.00 vn_open_cred [187] 0.1 13743.00 8.00 closef [188] 0.1 13751.00 8.00 in_pseudo [189] 0.1 13759.00 8.00 kern_close [190] 0.1 13767.00 8.00 m_tag_delete_chain [191] 0.1 13775.00 8.00 pmap_kextract [192] 0.1 13783.00 8.00 vfs_busy [193] 0.1 13791.00 8.00 vm_page_alloc [194] 0.0 13798.00 7.00 fputsock [195] 0.0 13805.00 7.00 malloc_type_zone_allocated [196] 0.0 13812.00 7.00 sleepq_broadcast [197] 0.0 13819.00 7.00 ufs_root [198] 0.0 13826.00 7.00 uhci_intr1 [199] 0.0 13833.00 7.00 vm_pageq_remove [200] 0.0 13839.00 6.00 Xtimerint [201] 0.0 13845.00 6.00 fdalloc [202] 0.0 13851.00 6.00 groupmember [203] 0.0 13857.00 6.00 mb_dtor_clust [204] 0.0 13863.00 6.00 tvtohz [205] 0.0 13869.00 6.00 uma_zone_exhausted_nolock [206] 0.0 13874.00 5.00 apic_idt_to_irq [207] 0.0 13879.00 5.00 dev_lock [208] 0.0 13884.00 5.00 frpr_short [209] 0.0 13889.00 5.00 ipfw_check_in [210] 0.0 13894.00 5.00 knlist_mtx_unlock [211] 0.0 13899.00 5.00 rijndaelEncrypt [212] 0.0 13904.00 5.00 sbdrop [213] 0.0 13909.00 5.00 sleepq_check_timeout [214] 0.0 13914.00 5.00 smp_tlb_shootdown [215] 0.0 13919.00 5.00 tc_ticktock [216] 0.0 13924.00 5.00 trap [217] 0.0 13929.00 5.00 vfs_ref [218] 0.0 13934.00 5.00 vm_page_sleep_if_busy [219] 0.0 13939.00 5.00 vn_finished_write [220] 0.0 13943.00 4.00 VOP_CLOSE_APV [221] 0.0 13947.00 4.00 VOP_GETWRITEMOUNT_APV [222] 0.0 13951.00 4.00 brelse [223] 0.0 13955.00 4.00 dev_unlock [224] 0.0 13959.00 4.00 fd_first_free [225] 0.0 13963.00 4.00 idle_proc [226] 0.0 13967.00 4.00 knote_enqueue [227] 0.0 13971.00 4.00 lapic_eoi [228] 0.0 13975.00 4.00 m_tag_locate [229] 0.0 13979.00 4.00 microtime [230] 0.0 13983.00 4.00 open [231] 0.0 13987.00 4.00 pmap_is_prefaultable [232] 0.0 13991.00 4.00 strcmp [233] 0.0 13995.00 4.00 sysctl_sysctl_name2oid [234] 0.0 13999.00 4.00 tcp_sack_doack [235] 0.0 14003.00 4.00 vfs_rel [236] 0.0 14007.00 4.00 vm_map_entry_splay [237] 0.0 14011.00 4.00 vm_page_free_toq [238] 0.0 14015.00 4.00 vm_page_select_cache [239] 0.0 14019.00 4.00 vm_page_set_validclean [240] 0.0 14023.00 4.00 vm_page_unwire [241] 0.0 14027.00 4.00 vn_closefile [242] 0.0 14031.00 4.00 vop_lock_pre [243] 0.0 14034.00 3.00 SHA256_Final [244] 0.0 14037.00 3.00 VOP_INACTIVE_APV [245] 0.0 14040.00 3.00 _sx_xunlock [264] 0.0 14043.00 3.00 atomic_clear_int [246] 0.0 14046.00 3.00 crhold [247] 0.0 14049.00 3.00 cursig [248] 0.0 14052.00 3.00 fdunused [249] 0.0 14055.00 3.00 ffs_clusteralloc [250] 0.0 14058.00 3.00 fr_checknatin [251] 0.0 14061.00 3.00 mb_dtor_mbuf [252] 0.0 14064.00 3.00 pagecopy [253] 0.0 14067.00 3.00 rman_get_bushandle [254] 0.0 14070.00 3.00 sleepq_timedwait_sig [255] 0.0 14073.00 3.00 tcpip_fillheaders [256] 0.0 14076.00 3.00 timevalsub [257] 0.0 14079.00 3.00 ufs_close [258] 0.0 14082.00 3.00 uhci_intr [259] 0.0 14085.00 3.00 vholdl [260] 0.0 14088.00 3.00 vm_object_deallocate [261] 0.0 14091.00 3.00 vm_object_vndeallocate [262] 0.0 14094.00 3.00 vn_close [263] 0.0 14096.00 2.00 DELAY [265] 0.0 14098.00 2.00 VOP_OPEN_APV [266] 0.0 14100.00 2.00 VOP_READ_APV [267] 0.0 14102.00 2.00 Xdna [268] 0.0 14104.00 2.00 _sx_xlock [298] 0.0 14106.00 2.00 bqrelse [269] 0.0 14108.00 2.00 breadn [270] 0.0 14110.00 2.00 crfree [271] 0.0 14112.00 2.00 devstat_end_transaction [272] 0.0 14114.00 2.00 dummynet [273] 0.0 14116.00 2.00 ffs_vget [274] 0.0 14118.00 2.00 fpu_clean_state [275] 0.0 14120.00 2.00 hardclock_device_poll [276] 0.0 14122.00 2.00 in_clsroute [277] 0.0 14124.00 2.00 ioapic_write [278] 0.0 14126.00 2.00 knlist_mtx_lock [279] 0.0 14128.00 2.00 kqueue_fo_release [280] 0.0 14130.00 2.00 mb_zfini_pack [281] 0.0 14132.00 2.00 mtx_pool_alloc [282] 0.0 14134.00 2.00 nfsrv_timer [283] 0.0 14136.00 2.00 pmap_remove_pages [284] 0.0 14138.00 2.00 sbappendstream_locked [285] 0.0 14140.00 2.00 sleepq_timeout [286] 0.0 14142.00 2.00 soreceive [287] 0.0 14144.00 2.00 swi_sched [288] 0.0 14146.00 2.00 sysctl_old_user [289] 0.0 14148.00 2.00 taskqueue_thread_loop [290] 0.0 14150.00 2.00 tcp_xmit_timer [291] 0.0 14152.00 2.00 tdsignal [292] 0.0 14154.00 2.00 ufs_open [293] 0.0 14156.00 2.00 userland_sysctl [294] 0.0 14158.00 2.00 vm_fault [295] 0.0 14160.00 2.00 vm_page_lookup [296] 0.0 14162.00 2.00 vop_stdunlock [297] 0.0 14163.00 1.00 __sysctl [372] 0.0 14164.00 1.00 _mtx_unlock_sleep [373] 0.0 14165.00 1.00 _pmap_unwire_pte_hold [374] 0.0 14166.00 1.00 _vm_map_clip_start [375] 0.0 14167.00 1.00 _vm_map_unlock_read [376] 0.0 14168.00 1.00 amr_done [299] 0.0 14169.00 1.00 amr_quartz_get_work [300] 0.0 14170.00 1.00 arplookup [301] 0.0 14171.00 1.00 atkbd_timeout [302] 0.0 14172.00 1.00 bdwrite [303] 0.0 14173.00 1.00 bus_dmamap_load [304] 0.0 14174.00 1.00 close [305] 0.0 14175.00 1.00 do_sendfile [306] 0.0 14176.00 1.00 fdused [307] 0.0 14177.00 1.00 ffs_clusteracct [308] 0.0 14178.00 1.00 fget_write [309] 0.0 14179.00 1.00 g_bioq_lock [310] 0.0 14180.00 1.00 g_io_deliver [311] 0.0 14181.00 1.00 gettimeofday [312] 0.0 14182.00 1.00 if_slowtimo [313] 0.0 14183.00 1.00 itimerfix [314] 0.0 14184.00 1.00 kern_select [315] 0.0 14185.00 1.00 kevent_copyin [316] 0.0 14186.00 1.00 knlist_empty [317] 0.0 14187.00 1.00 lapic_ipi_wait [318] 0.0 14188.00 1.00 m_dup_pkthdr [319] 0.0 14189.00 1.00 m_tag_copy_chain [320] 0.0 14190.00 1.00 mp_grab_cpu_hlt [321] 0.0 14191.00 1.00 nfs_curusec [322] 0.0 14192.00 1.00 pmap_allocpte [323] 0.0 14193.00 1.00 pmap_clear_modify [324] 0.0 14194.00 1.00 pmap_copy [325] 0.0 14195.00 1.00 pmap_qenter [326] 0.0 14196.00 1.00 pmap_qremove [327] 0.0 14197.00 1.00 pmap_try_insert_pv_entry [328] 0.0 14198.00 1.00 pmap_unuse_pt [329] 0.0 14199.00 1.00 poll [330] 0.0 14200.00 1.00 random_kthread [331] 0.0 14201.00 1.00 rijndaelKeySetupEnc [332] 0.0 14202.00 1.00 rijndael_blockEncrypt [333] 0.0 14203.00 1.00 sched_clock [334] 0.0 14204.00 1.00 sched_wakeup [335] 0.0 14205.00 1.00 schedcpu_thread [336] 0.0 14206.00 1.00 selrecord [337] 0.0 14207.00 1.00 selwakeuppri [338] 0.0 14208.00 1.00 sleepq_check_signals [339] 0.0 14209.00 1.00 sleepq_timedwait [340] 0.0 14210.00 1.00 softdep_process_worklist [341] 0.0 14211.00 1.00 soo_ioctl [342] 0.0 14212.00 1.00 statclock [343] 0.0 14213.00 1.00 strlen [344] 0.0 14214.00 1.00 sysctl_root [345] 0.0 14215.00 1.00 taskqueue_thread_enqueue [346] 0.0 14216.00 1.00 tcp_isn_tick [347] 0.0 14217.00 1.00 timevaladd [348] 0.0 14218.00 1.00 turnstile_lock [349] 0.0 14219.00 1.00 turnstile_lookup [350] 0.0 14220.00 1.00 turnstile_release [351] 0.0 14221.00 1.00 turnstile_unpend [352] 0.0 14222.00 1.00 uiomove [353] 0.0 14223.00 1.00 uipc_attach [354] 0.0 14224.00 1.00 uma_zalloc_internal [355] 0.0 14225.00 1.00 vfs_busy_pages [356] 0.0 14226.00 1.00 vfs_page_set_valid [357] 0.0 14227.00 1.00 vfs_vmio_release [358] 0.0 14228.00 1.00 vm_map_insert [359] 0.0 14229.00 1.00 vm_object_terminate [360] 0.0 14230.00 1.00 vm_page_insert [361] 0.0 14231.00 1.00 vm_page_io_finish [362] 0.0 14232.00 1.00 vm_page_rename [363] 0.0 14233.00 1.00 vm_pageq_find [364] 0.0 14234.00 1.00 vm_pageq_remove_nowakeup [365] 0.0 14235.00 1.00 vmspace_resident_count [366] 0.0 14236.00 1.00 vn_isdisk [367] 0.0 14237.00 1.00 vop_lock_post [368] 0.0 14238.00 1.00 vop_stdlock [369] 0.0 14239.00 1.00 wakeup [370] 0.0 14240.00 1.00 yarrow_hash_iterate [371] Index by function name [265] DELAY [177] in_matroute [164] sleepq_resume_threa [244] SHA256_Final [93] in_pcblookup_hash [88] sleepq_signal [2] SHA256_Transform [189] in_pseudo [171] sleepq_switch [137] SHA256_Update [79] intr_event_schedule [340] sleepq_timedwait [157] VOP_ACCESS_APV [100] intr_execute_handle [255] sleepq_timedwait_si [221] VOP_CLOSE_APV [81] ioapic_disable_sour [286] sleepq_timeout [222] VOP_GETWRITEMOUNT_A [75] ioapic_enable_sourc [101] sleepq_wait [245] VOP_INACTIVE_APV [278] ioapic_write [215] smp_tlb_shootdown [86] VOP_ISLOCKED_APV [42] ip_input [70] softclock [73] VOP_LOCK_APV [20] ip_output [341] softdep_process_wor [91] VOP_LOOKUP_APV [210] ipfw_check_in [342] soo_ioctl [266] VOP_OPEN_APV [162] ipfw_check_out [287] soreceive [267] VOP_READ_APV [5] ipfw_chk [130] sowakeup [66] VOP_UNLOCK_APV [27] ithread_loop [29] spinlock_enter [158] Xapic_isr1 [314] itimerfix [14] spinlock_exit [268] Xdna [190] kern_close [343] statclock [62] Xfast_syscall [89] kern_kevent [233] strcmp [201] Xtimerint [68] kern_open [344] strlen [167] __mnt_vnode_next [315] kern_select [120] swi_net [372] __sysctl [32] kern_sendfile [288] swi_sched [156] _callout_stop_safe [178] kevent [37] syscall [44] _mtx_lock_sleep [316] kevent_copyin [185] sysctl_find_oid [30] _mtx_lock_spin [317] knlist_empty [289] sysctl_old_user [71] _mtx_lock_spin_flag [279] knlist_mtx_lock [345] sysctl_root [83] _mtx_trylock [211] knlist_mtx_unlock [234] sysctl_sysctl_name2 [373] _mtx_unlock_sleep [77] knote [115] taskqueue_enqueue [102] _mtx_unlock_spin_fl [227] knote_enqueue [142] taskqueue_run [374] _pmap_unwire_pte_ho [179] knote_fdclose [346] taskqueue_thread_en [298] _sx_xlock [128] kqueue_aquire [290] taskqueue_thread_lo [264] _sx_xunlock [280] kqueue_fo_release [216] tc_ticktock [375] _vm_map_clip_start [72] kqueue_register [96] tc_windup [376] _vm_map_unlock_read [150] kqueue_release [131] tcp_dooptions [108] acpi_cpu_c1 [228] lapic_eoi [15] tcp_input [74] acpi_cpu_idle [180] lapic_handle_intr [347] tcp_isn_tick [52] acquire [129] lapic_handle_timer [4] tcp_output [299] amr_done [318] lapic_ipi_wait [235] tcp_sack_doack [300] amr_quartz_get_work [6] lockmgr [135] tcp_usr_send [207] apic_idt_to_irq [25] lockstatus [116] tcp_xmit_bandwidth_ [301] arplookup [8] lookup [291] tcp_xmit_timer [64] arpresolve [22] m_copym [256] tcpip_fillheaders [302] atkbd_timeout [319] m_dup_pkthdr [292] tdsignal [246] atomic_clear_int [134] m_extadd [348] timevaladd [43] bcmp [181] m_freem [257] timevalsub [31] bcopy [320] m_tag_copy_chain [217] trap [303] bdwrite [191] m_tag_delete_chain [349] turnstile_lock [63] binuptime [229] m_tag_locate [350] turnstile_lookup [269] bqrelse [109] malloc [351] turnstile_release [270] breadn [138] malloc_type_freed [352] turnstile_unpend [223] brelse [196] malloc_type_zone_al [205] tvtohz [304] bus_dmamap_load [46] maybe_preempt [49] ufs_access [11] bus_dmamap_load_mbu [182] maybe_resched [258] ufs_close [24] bzero [58] mb_ctor_mbuf [60] ufs_inactive [7] cache_lookup [204] mb_dtor_clust [293] ufs_open [23] callout_reset [252] mb_dtor_mbuf [198] ufs_root [38] choosethread [151] mb_dtor_pack [259] uhci_intr [305] close [84] mb_free_ext [199] uhci_intr1 [188] closef [281] mb_zfini_pack [353] uiomove [168] compute_cn_lkflags [59] memcpy [354] uipc_attach [121] copyin [19] mi_switch [34] uma_slab_alloc [53] copyinstr [230] microtime [16] uma_zalloc_arg [175] copyout [321] mp_grab_cpu_hlt [355] uma_zalloc_internal [87] cpu_idle [146] msleep [9] uma_zfree_arg [33] cpu_switch [117] msleep_spin [10] uma_zfree_internal [271] crfree [282] mtx_pool_alloc [206] uma_zone_exhausted_ [247] crhold [106] namei [155] uma_zone_slab [65] critical_enter [94] netisr_processqueue [294] userland_sysctl [28] critical_exit [322] nfs_curusec [112] userret [248] cursig [283] nfsrv_timer [85] vaccess [208] dev_lock [231] open [40] vdropl [224] dev_unlock [253] pagecopy [193] vfs_busy [272] devstat_end_transac [21] pfil_run_hooks [356] vfs_busy_pages [306] do_sendfile [323] pmap_allocpte [76] vfs_cache_lookup [126] doreti [324] pmap_clear_modify [172] vfs_hash_get [98] doselwakeup [325] pmap_copy [143] vfs_msync [273] dummynet [232] pmap_is_prefaultabl [357] vfs_page_set_valid [56] dummynet_task [192] pmap_kextract [218] vfs_ref [54] em_start [326] pmap_qenter [236] vfs_rel [12] em_start_locked [327] pmap_qremove [358] vfs_vmio_release [80] ether_output [284] pmap_remove_pages [39] vget [51] ether_output_frame [328] pmap_try_insert_pv_ [260] vholdl [92] falloc [329] pmap_unuse_pt [50] vinactive [225] fd_first_free [147] pmc_cpu_is_logical [295] vm_fault [202] fdalloc [330] poll [237] vm_map_entry_splay [103] fdrop [331] random_kthread [359] vm_map_insert [105] fdrop_locked [97] random_process_even [173] vm_object_clear_fla [249] fdunused [212] rijndaelEncrypt [261] vm_object_deallocat [307] fdused [332] rijndaelKeySetupEnc [360] vm_object_terminate [308] ffs_clusteracct [333] rijndael_blockEncry [262] vm_object_vndealloc [250] ffs_clusteralloc [254] rman_get_bushandle [194] vm_page_alloc [144] ffs_lock [139] rman_get_bustag [238] vm_page_free_toq [119] ffs_sync [26] rn_match [361] vm_page_insert [274] ffs_vget [110] rn_satisfies_leaf [362] vm_page_io_finish [122] fget [45] rt_check [296] vm_page_lookup [309] fget_write [36] rtalloc1 [363] vm_page_rename [159] fgetsock [95] rtalloc_ign [239] vm_page_select_cach [176] fgetvp_read [78] rtfree [240] vm_page_set_validcl [132] filt_sowrite [163] runq_add [219] vm_page_sleep_if_bu [275] fpu_clean_state [140] runq_check [107] vm_page_splay [195] fputsock [55] runq_choose [241] vm_page_unwire [133] fr_acctpkt [118] runq_remove [165] vm_page_wire [3] fr_check [169] sbappendstream [186] vm_pageq_enqueue [160] fr_check_wrapper [285] sbappendstream_lock [364] vm_pageq_find [251] fr_checknatin [152] sbcompress [200] vm_pageq_remove [113] fr_checknatout [213] sbdrop [365] vm_pageq_remove_now [123] fr_checkstate [90] sbdrop_locked [366] vmspace_resident_co [69] fr_checkv4sum [183] scanc [61] vmtotal [99] fr_dolog [48] sched_add [263] vn_close [17] fr_makefrip [334] sched_clock [242] vn_closefile [145] free [114] sched_runnable [220] vn_finished_write [124] frpr_pullup [13] sched_switch [367] vn_isdisk [209] frpr_short [104] sched_userret [41] vn_lock [310] g_bioq_lock [335] sched_wakeup [187] vn_open_cred [311] g_io_deliver [336] schedcpu_thread [174] vn_start_write [312] gettimeofday [337] selrecord [166] vnode_create_vobjec [203] groupmember [338] selwakeuppri [368] vop_lock_post [161] hardclock [170] setrunnable [243] vop_lock_pre [276] hardclock_device_po [153] setrunqueue [149] vop_stdislocked [127] hardclock_process [154] sf_buf_mext [369] vop_stdlock [35] hpet_get_timecount [111] sleepq_add [297] vop_stdunlock [226] idle_proc [197] sleepq_broadcast [47] vput [313] if_slowtimo [148] sleepq_catch_signal [67] vref [57] in_broadcast [339] sleepq_check_signal [136] vrele [18] in_cksum_skip [214] sleepq_check_timeou [370] wakeup [1] in_cksumdata [141] sleepq_lock [371] yarrow_hash_iterate [277] in_clsroute [82] sleepq_lookup [125] in_delayed_cksum [184] sleepq_release --------------020108020005080507060303 Content-Type: text/plain; name="pmc-gprof-good.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pmc-gprof-good.txt" None flat profile: % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this seconds function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/call function per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/call function and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. granularity: each sample hit covers 4 byte(s) for 0.00% of 37884.00 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 6.7 2525.00 2525.00 in_cksumdata [1] 5.2 4488.00 1963.00 SHA256_Transform [2] 4.0 6022.00 1534.00 lockmgr [3] 3.6 7393.00 1371.00 fr_check [4] 3.4 8684.00 1291.00 tcp_output [5] 3.2 9912.00 1228.00 ipfw_chk [6] 2.3 10782.00 870.00 lookup [7] 2.2 11613.00 831.00 cache_lookup [8] 1.7 12270.00 657.00 tcp_input [9] 1.7 12924.00 654.00 bus_dmamap_load_mbuf_sg [10] 1.7 13557.00 633.00 uma_zalloc_arg [11] 1.7 14183.00 626.00 em_start_locked [12] 1.6 14782.00 599.00 spinlock_exit [13] 1.5 15337.00 555.00 uma_zfree_arg [14] 1.4 15860.00 523.00 fr_makefrip [15] 1.3 16363.00 503.00 lockstatus [16] 1.3 16863.00 500.00 uma_zfree_internal [17] 1.3 17349.00 486.00 pfil_run_hooks [18] 1.2 17818.00 469.00 mi_switch [19] 1.2 18271.00 453.00 in_cksum_skip [20] 1.2 18722.00 451.00 sched_switch [21] 1.1 19157.00 435.00 bzero [22] 1.1 19589.00 432.00 rn_match [23] 1.1 20019.00 430.00 m_copym [24] 1.1 20437.00 418.00 ip_output [25] 0.9 20795.00 358.00 ithread_loop [26] 0.9 21142.00 347.00 callout_reset [27] 0.9 21465.00 323.00 bcopy [28] 0.8 21783.00 318.00 spinlock_enter [29] 0.8 22093.00 310.00 critical_exit [30] 0.8 22396.00 303.00 cpu_switch [31] 0.8 22694.00 298.00 vget [32] 0.8 22991.00 297.00 syscall [33] 0.7 23271.00 280.00 vn_lock [34] 0.7 23541.00 270.00 _mtx_lock_spin [35] 0.7 23802.00 261.00 kern_sendfile [36] 0.7 24054.00 252.00 copyinstr [37] 0.7 24301.00 247.00 ip_input [38] 0.6 24539.00 238.00 vdropl [39] 0.6 24775.00 236.00 acquire [40] 0.6 25007.00 232.00 vinactive [41] 0.6 25227.00 220.00 rtalloc1 [42] 0.6 25443.00 216.00 _mtx_lock_spin_flags [43] 0.6 25656.00 213.00 Xfast_syscall [44] 0.6 25867.00 211.00 bcmp [45] 0.5 26072.00 205.00 VOP_UNLOCK_APV [46] 0.5 26276.00 204.00 vput [47] 0.5 26478.00 202.00 ufs_access [48] 0.5 26675.00 197.00 hpet_get_timecount [49] 0.5 26870.00 195.00 maybe_preempt [50] 0.5 27061.00 191.00 choosethread [51] 0.5 27236.00 175.00 memcpy [52] 0.4 27402.00 166.00 uma_slab_alloc [53] 0.4 27567.00 165.00 ufs_inactive [54] 0.4 27730.00 163.00 in_broadcast [55] 0.4 27890.00 160.00 critical_enter [56] 0.4 28049.00 159.00 rt_check [57] 0.4 28205.00 156.00 ether_output_frame [58] 0.4 28360.00 155.00 em_start [59] 0.4 28515.00 155.00 mb_ctor_mbuf [60] 0.4 28665.00 150.00 kern_open [61] 0.4 28808.00 143.00 binuptime [62] 0.4 28950.00 142.00 runq_choose [63] 0.4 29088.00 138.00 vfs_cache_lookup [64] 0.4 29225.00 137.00 sched_add [65] 0.4 29361.00 136.00 vaccess [66] 0.4 29496.00 135.00 ether_output [67] 0.4 29631.00 135.00 kern_kevent [68] 0.3 29762.00 131.00 intr_event_schedule_thread [69] 0.3 29889.00 127.00 arpresolve [70] 0.3 30016.00 127.00 vref [71] 0.3 30135.00 119.00 ioapic_disable_source [72] 0.3 30250.00 115.00 VOP_LOCK_APV [73] 0.3 30364.00 114.00 kqueue_register [74] 0.3 30476.00 112.00 netisr_processqueue [75] 0.3 30585.00 109.00 VOP_ISLOCKED_APV [76] 0.3 30692.00 107.00 fr_checkv4sum [77] 0.3 30798.00 106.00 sbdrop_locked [78] 0.3 30899.00 101.00 intr_execute_handlers [79] 0.3 31000.00 101.00 rtfree [80] 0.3 31100.00 100.00 random_process_event [81] 0.3 31199.00 99.00 fdrop_locked [82] 0.3 31296.00 97.00 fr_dolog [83] 0.3 31392.00 96.00 VOP_LOOKUP_APV [84] 0.3 31488.00 96.00 cpu_idle [85] 0.3 31584.00 96.00 ioapic_enable_source [86] 0.2 31677.00 93.00 mb_free_ext [87] 0.2 31769.00 92.00 _mtx_lock_sleep [88] 0.2 31858.00 89.00 namei [89] 0.2 31946.00 88.00 acpi_cpu_idle [90] 0.2 32034.00 88.00 dummynet_task [91] 0.2 32115.00 81.00 fget [92] 0.2 32195.00 80.00 rtalloc_ign [93] 0.2 32274.00 79.00 falloc [94] 0.2 32351.00 77.00 in_pcblookup_hash [95] 0.2 32428.00 77.00 knote [96] 0.2 32502.00 74.00 fr_checknatout [97] 0.2 32575.00 73.00 pmc_cpu_is_logical [98] 0.2 32648.00 73.00 softclock [99] 0.2 32719.00 71.00 _mtx_unlock_spin_flags [100] 0.2 32786.00 67.00 fgetsock [101] 0.2 32853.00 67.00 sched_runnable [102] 0.2 32919.00 66.00 sleepq_lookup [103] 0.2 32983.00 64.00 fdrop [104] 0.2 33047.00 64.00 msleep [105] 0.2 33110.00 63.00 swi_net [106] 0.2 33172.00 62.00 acpi_cpu_c1 [107] 0.2 33234.00 62.00 copyin [108] 0.2 33296.00 62.00 sleepq_add [109] 0.2 33357.00 61.00 free [110] 0.2 33418.00 61.00 vm_page_splay [111] 0.2 33478.00 60.00 filt_sowrite [112] 0.2 33537.00 59.00 ffs_lock [113] 0.2 33594.00 57.00 fr_check_wrapper [114] 0.1 33650.00 56.00 VOP_ACCESS_APV [115] 0.1 33706.00 56.00 sched_userret [116] 0.1 33761.00 55.00 kqueue_aquire [117] 0.1 33816.00 55.00 sleepq_lock [118] 0.1 33871.00 55.00 tcp_usr_send [119] 0.1 33926.00 55.00 userret [120] 0.1 33979.00 53.00 in_delayed_cksum [121] 0.1 34032.00 53.00 kern_close [122] 0.1 34084.00 52.00 doreti [123] 0.1 34136.00 52.00 runq_remove [124] 0.1 34188.00 52.00 tcp_xmit_bandwidth_limit [125] 0.1 34239.00 51.00 m_extadd [126] 0.1 34289.00 50.00 sleepq_catch_signals [127] 0.1 34338.00 49.00 fr_acctpkt [128] 0.1 34386.00 48.00 fr_checkstate [129] 0.1 34434.00 48.00 malloc [130] 0.1 34481.00 47.00 tcp_dooptions [131] 0.1 34527.00 46.00 kqueue_release [132] 0.1 34571.00 44.00 sbcompress [133] 0.1 34614.00 43.00 copyout [134] 0.1 34657.00 43.00 fdalloc [135] 0.1 34700.00 43.00 knote_fdclose [136] 0.1 34743.00 43.00 sleepq_wait [137] 0.1 34784.00 41.00 rn_satisfies_leaf [138] 0.1 34824.00 40.00 lapic_handle_timer [139] 0.1 34863.00 39.00 Xapic_isr1 [140] 0.1 34902.00 39.00 doselwakeup [141] 0.1 34941.00 39.00 vop_stdislocked [142] 0.1 34979.00 38.00 frpr_pullup [143] 0.1 35016.00 37.00 sleepq_resume_thread [144] 0.1 35053.00 37.00 taskqueue_run [145] 0.1 35089.00 36.00 runq_add [146] 0.1 35125.00 36.00 tc_windup [147] 0.1 35161.00 36.00 vfs_hash_get [148] 0.1 35197.00 36.00 vn_start_write [149] 0.1 35231.00 34.00 sleepq_signal [150] 0.1 35265.00 34.00 uma_zone_slab [151] 0.1 35298.00 33.00 in_pseudo [152] 0.1 35330.00 32.00 _callout_stop_safe [156] 0.1 35362.00 32.00 sbappendstream [153] 0.1 35394.00 32.00 uhci_intr1 [154] 0.1 35426.00 32.00 vn_finished_write [155] 0.1 35457.00 31.00 SHA256_Update [157] 0.1 35488.00 31.00 ipfw_check_out [158] 0.1 35519.00 31.00 vm_page_set_validclean [159] 0.1 35549.00 30.00 in_matroute [160] 0.1 35579.00 30.00 malloc_type_freed [161] 0.1 35609.00 30.00 sleepq_switch [162] 0.1 35638.00 29.00 hardclock [163] 0.1 35667.00 29.00 sowakeup [164] 0.1 35696.00 29.00 taskqueue_enqueue [165] 0.1 35724.00 28.00 fgetvp_read [166] 0.1 35752.00 28.00 fputsock [167] 0.1 35780.00 28.00 groupmember [168] 0.1 35808.00 28.00 hardclock_process [169] 0.1 35836.00 28.00 msleep_spin [170] 0.1 35863.00 27.00 fd_first_free [171] 0.1 35890.00 27.00 malloc_type_zone_allocated [172] 0.1 35917.00 27.00 runq_check [173] 0.1 35944.00 27.00 tcp_sack_doack [174] 0.1 35971.00 27.00 vn_open_cred [175] 0.1 35998.00 27.00 vrele [176] 0.1 36024.00 26.00 kevent [177] 0.1 36050.00 26.00 rman_get_bustag [178] 0.1 36076.00 26.00 sf_buf_mext [179] 0.1 36101.00 25.00 ipfw_check_in [180] 0.1 36126.00 25.00 vm_page_alloc [181] 0.1 36150.00 24.00 mb_dtor_pack [182] 0.1 36174.00 24.00 pmap_kextract [183] 0.1 36198.00 24.00 sleepq_broadcast [184] 0.1 36221.00 23.00 idle_proc [185] 0.1 36244.00 23.00 sleepq_release [186] 0.1 36267.00 23.00 vn_closefile [187] 0.1 36289.00 22.00 m_freem [188] 0.1 36310.00 21.00 Xtimerint [189] 0.1 36331.00 21.00 brelse [190] 0.1 36352.00 21.00 maybe_resched [191] 0.1 36373.00 21.00 setrunnable [192] 0.1 36394.00 21.00 vm_pageq_remove [193] 0.1 36414.00 20.00 VOP_GETWRITEMOUNT_APV [194] 0.1 36434.00 20.00 fpudna [195] 0.1 36454.00 20.00 vm_page_wire [196] 0.1 36474.00 20.00 vm_pageq_enqueue [197] 0.1 36494.00 20.00 vop_stdunlock [198] 0.1 36513.00 19.00 VOP_INACTIVE_APV [199] 0.1 36532.00 19.00 knlist_mtx_unlock [200] 0.1 36551.00 19.00 knote_enqueue [201] 0.1 36570.00 19.00 setrunqueue [202] 0.0 36588.00 18.00 compute_cn_lkflags [203] 0.0 36606.00 18.00 trap [204] 0.0 36624.00 18.00 vm_page_unwire [205] 0.0 36641.00 17.00 crhold [206] 0.0 36658.00 17.00 dev_lock [207] 0.0 36675.00 17.00 kqueue_fo_release [208] 0.0 36692.00 17.00 m_tag_delete_chain [209] 0.0 36709.00 17.00 vn_close [210] 0.0 36725.00 16.00 lapic_handle_intr [211] 0.0 36741.00 16.00 tcp_xmit_timer [212] 0.0 36757.00 16.00 tvtohz [213] 0.0 36773.00 16.00 uma_zone_exhausted_nolock [214] 0.0 36789.00 16.00 vfs_rel [215] 0.0 36804.00 15.00 VOP_OPEN_APV [216] 0.0 36819.00 15.00 atomic_clear_int [217] 0.0 36834.00 15.00 cursig [218] 0.0 36849.00 15.00 ffs_vget [219] 0.0 36864.00 15.00 vm_page_sleep_if_busy [220] 0.0 36878.00 14.00 frpr_short [221] 0.0 36892.00 14.00 pagecopy [222] 0.0 36906.00 14.00 pmap_clear_modify [223] 0.0 36920.00 14.00 vm_fault [224] 0.0 36933.00 13.00 knlist_mtx_lock [225] 0.0 36946.00 13.00 microtime [226] 0.0 36959.00 13.00 smp_tlb_shootdown [227] 0.0 36972.00 13.00 vfs_busy [228] 0.0 36984.00 12.00 getblk [229] 0.0 36996.00 12.00 m_tag_locate [230] 0.0 37008.00 12.00 mb_dtor_mbuf [231] 0.0 37020.00 12.00 ufs_root [232] 0.0 37032.00 12.00 vm_page_lookup [233] 0.0 37044.00 12.00 vm_pageq_remove_nowakeup [234] 0.0 37055.00 11.00 VOP_CLOSE_APV [235] 0.0 37066.00 11.00 bufdone [236] 0.0 37077.00 11.00 rijndaelKeySetupEnc [237] 0.0 37088.00 11.00 tcp_sack_output [238] 0.0 37099.00 11.00 vm_page_free_toq [239] 0.0 37110.00 11.00 vnode_create_vobject_off [240] 0.0 37121.00 11.00 vop_lock_pre [241] 0.0 37131.00 10.00 bdwrite [242] 0.0 37141.00 10.00 sleepq_timedwait_sig [243] 0.0 37151.00 10.00 tcpip_fillheaders [244] 0.0 37161.00 10.00 ufs_close [245] 0.0 37171.00 10.00 ufs_open [246] 0.0 37181.00 10.00 vm_object_vndeallocate [247] 0.0 37190.00 9.00 _mtx_trylock [256] 0.0 37199.00 9.00 fdused [248] 0.0 37208.00 9.00 pagezero [249] 0.0 37217.00 9.00 pmap_is_prefaultable [250] 0.0 37226.00 9.00 rman_get_bushandle [251] 0.0 37235.00 9.00 timevaladd [252] 0.0 37244.00 9.00 vfs_page_set_valid [253] 0.0 37253.00 9.00 vm_map_entry_splay [254] 0.0 37262.00 9.00 vop_lookup_pre [255] 0.0 37270.00 8.00 devstat_end_transaction [257] 0.0 37278.00 8.00 do_sendfile [258] 0.0 37286.00 8.00 pmap_enter [259] 0.0 37294.00 8.00 pmap_remove_all [260] 0.0 37302.00 8.00 pmap_remove_pages [261] 0.0 37310.00 8.00 taskqueue_thread_loop [262] 0.0 37318.00 8.00 vm_object_deallocate [263] 0.0 37325.00 7.00 allocbuf [264] 0.0 37332.00 7.00 fget_write [265] 0.0 37339.00 7.00 in_clsroute [266] 0.0 37346.00 7.00 mb_dtor_clust [267] 0.0 37353.00 7.00 mb_zfini_pack [268] 0.0 37360.00 7.00 pmap_try_insert_pv_entry [269] 0.0 37367.00 7.00 random_kthread [270] 0.0 37374.00 7.00 vfs_ref [271] 0.0 37381.00 7.00 vm_page_insert [272] 0.0 37388.00 7.00 vm_page_select_cache [273] 0.0 37395.00 7.00 vm_pageout [274] 0.0 37401.00 6.00 apic_idt_to_irq [275] 0.0 37407.00 6.00 bintime [276] 0.0 37413.00 6.00 cluster_read [277] 0.0 37419.00 6.00 fr_checkauth [278] 0.0 37425.00 6.00 fr_checknatin [279] 0.0 37431.00 6.00 open [280] 0.0 37437.00 6.00 pmap_is_modified [281] 0.0 37443.00 6.00 sbappendstream_locked [282] 0.0 37449.00 6.00 sched_wakeup [283] 0.0 37455.00 6.00 sendfile [284] 0.0 37461.00 6.00 sleepq_check_timeout [285] 0.0 37467.00 6.00 soreceive [286] 0.0 37473.00 6.00 vm_page_flag_clear [287] 0.0 37478.00 5.00 buf_splay [288] 0.0 37483.00 5.00 close [289] 0.0 37488.00 5.00 crfree [290] 0.0 37493.00 5.00 ffs_balloc_ufs2 [291] 0.0 37498.00 5.00 ffs_write [292] 0.0 37503.00 5.00 getmicrouptime [293] 0.0 37508.00 5.00 gettimeofday [294] 0.0 37513.00 5.00 knote_alloc [295] 0.0 37518.00 5.00 rijndaelEncrypt [296] 0.0 37523.00 5.00 statclock [297] 0.0 37528.00 5.00 timevalsub [298] 0.0 37533.00 5.00 vfs_busy_pages [299] 0.0 37538.00 5.00 vfs_setdirty [300] 0.0 37543.00 5.00 vop_lock_post [301] 0.0 37547.00 4.00 atomic_add_int [302] 0.0 37551.00 4.00 bqrelse [303] 0.0 37555.00 4.00 closef [304] 0.0 37559.00 4.00 dev_unlock [305] 0.0 37563.00 4.00 dummynet [306] 0.0 37567.00 4.00 ffs_clusteralloc [307] 0.0 37571.00 4.00 fget_read [308] 0.0 37575.00 4.00 gbincore [309] 0.0 37579.00 4.00 hardclock_device_poll [310] 0.0 37583.00 4.00 pmap_allocpte [311] 0.0 37587.00 4.00 pmap_copy [312] 0.0 37591.00 4.00 sbdrop [313] 0.0 37595.00 4.00 scanc [314] 0.0 37599.00 4.00 selwakeuppri [315] 0.0 37603.00 4.00 sopoll [316] 0.0 37607.00 4.00 suser [317] 0.0 37611.00 4.00 swi_sched [318] 0.0 37615.00 4.00 tcp_isn_tick [319] 0.0 37619.00 4.00 timevalfix [320] 0.0 37623.00 4.00 ufs_getlbns [321] 0.0 37627.00 4.00 vholdl [322] 0.0 37631.00 4.00 vm_page_remove [323] 0.0 37635.00 4.00 vm_page_zero_check [324] 0.0 37639.00 4.00 vmtotal [325] 0.0 37643.00 4.00 vn_write [326] 0.0 37647.00 4.00 vop_stdlock [327] 0.0 37650.00 3.00 SHA256_Final [328] 0.0 37653.00 3.00 VOP_LEASE_APV [329] 0.0 37656.00 3.00 amr_done [330] 0.0 37659.00 3.00 buf_vlist_add [331] 0.0 37662.00 3.00 fdunused [332] 0.0 37665.00 3.00 g_bioq_unlock [333] 0.0 37668.00 3.00 g_disk_start [334] 0.0 37671.00 3.00 g_io_schedule_down [335] 0.0 37674.00 3.00 getnanotime [336] 0.0 37677.00 3.00 intr_lookup_source [337] 0.0 37680.00 3.00 lockcount [338] 0.0 37683.00 3.00 pmap_protect [339] 0.0 37686.00 3.00 pmap_qremove [340] 0.0 37689.00 3.00 poll [341] 0.0 37692.00 3.00 reseed [342] 0.0 37695.00 3.00 sleepq_check_signals [343] 0.0 37698.00 3.00 taskqueue_thread_enqueue [344] 0.0 37701.00 3.00 tc_ticktock [345] 0.0 37704.00 3.00 tcp_usr_rcvd [346] 0.0 37707.00 3.00 uhci_intr [347] 0.0 37710.00 3.00 uiomove [348] 0.0 37713.00 3.00 vfs_unbusy [349] 0.0 37716.00 3.00 vop_stdgetwritemount [350] 0.0 37718.00 2.00 DELAY [351] 0.0 37720.00 2.00 NDFREE [352] 0.0 37722.00 2.00 amr_completeio [353] 0.0 37724.00 2.00 amr_startio [354] 0.0 37726.00 2.00 arpintr [355] 0.0 37728.00 2.00 atomic_subtract_int [356] 0.0 37730.00 2.00 bus_dmamap_load [357] 0.0 37732.00 2.00 cluster_wbuild [358] 0.0 37734.00 2.00 ffs_read [359] 0.0 37736.00 2.00 ffs_sync [360] 0.0 37738.00 2.00 forward_roundrobin [361] 0.0 37740.00 2.00 getnewbuf [362] 0.0 37742.00 2.00 ioapic_write [363] 0.0 37744.00 2.00 ip_slowtimo [364] 0.0 37746.00 2.00 itimerfix [365] 0.0 37748.00 2.00 kevent_copyin [366] 0.0 37750.00 2.00 lapic_eoi [367] 0.0 37752.00 2.00 mp_grab_cpu_hlt [368] 0.0 37754.00 2.00 nfsrv_timer [369] 0.0 37756.00 2.00 obreak [370] 0.0 37758.00 2.00 reassignbuf [371] 0.0 37760.00 2.00 sleepq_timedwait [372] 0.0 37762.00 2.00 suser_cred [373] 0.0 37764.00 2.00 trap_pfault [374] 0.0 37766.00 2.00 turnstile_lock [375] 0.0 37768.00 2.00 ufs_itimes [376] 0.0 37770.00 2.00 v_incr_usecount [377] 0.0 37772.00 2.00 vm_page_cache [378] 0.0 37774.00 2.00 vm_page_flash [379] 0.0 37776.00 2.00 vm_page_io_finish [380] 0.0 37778.00 2.00 vn_isdisk [381] 0.0 37780.00 2.00 vn_read [382] 0.0 37782.00 2.00 vnode_pager_setsize [383] 0.0 37784.00 2.00 vop_unlock_pre [384] 0.0 37785.00 1.00 VOP_GETATTR_APV [385] 0.0 37786.00 1.00 Xdna [386] 0.0 37787.00 1.00 __mnt_vnode_markerfree [481] 0.0 37788.00 1.00 _pmap_allocpte [482] 0.0 37789.00 1.00 _pmap_unwire_pte_hold [483] 0.0 37790.00 1.00 _sx_xlock [484] 0.0 37791.00 1.00 alltraps [387] 0.0 37792.00 1.00 arplookup [388] 0.0 37793.00 1.00 bdirty [389] 0.0 37794.00 1.00 biodone [390] 0.0 37795.00 1.00 breadn [391] 0.0 37796.00 1.00 bremfreel [392] 0.0 37797.00 1.00 bufbdflush [393] 0.0 37798.00 1.00 bufobj_wref [394] 0.0 37799.00 1.00 bufwrite [395] 0.0 37800.00 1.00 bwillwrite [396] 0.0 37801.00 1.00 cache_enter [397] 0.0 37802.00 1.00 cluster_callback [398] 0.0 37803.00 1.00 cv_wait_sig [399] 0.0 37804.00 1.00 default_pager_haspage [400] 0.0 37805.00 1.00 dofileread [401] 0.0 37806.00 1.00 dofilewrite [402] 0.0 37807.00 1.00 exec_copyout_strings [403] 0.0 37808.00 1.00 fcntl [404] 0.0 37809.00 1.00 ffs_bdflush [405] 0.0 37810.00 1.00 ffs_isblock [406] 0.0 37811.00 1.00 ffs_realloccg [407] 0.0 37812.00 1.00 ffs_update [408] 0.0 37813.00 1.00 fpu_clean_state [409] 0.0 37814.00 1.00 fpusetregs [410] 0.0 37815.00 1.00 fr_authexpire [411] 0.0 37816.00 1.00 g_bioq_first [412] 0.0 37817.00 1.00 g_bioq_lock [413] 0.0 37818.00 1.00 g_clone_bio [414] 0.0 37819.00 1.00 g_io_deliver [415] 0.0 37820.00 1.00 g_io_request [416] 0.0 37821.00 1.00 g_io_schedule_up [417] 0.0 37822.00 1.00 g_slice_start [418] 0.0 37823.00 1.00 g_trace [419] 0.0 37824.00 1.00 g_vfs_done [420] 0.0 37825.00 1.00 kern_select [421] 0.0 37826.00 1.00 kern_wait [422] 0.0 37827.00 1.00 kevent_copyout [423] 0.0 37828.00 1.00 knlist_empty [424] 0.0 37829.00 1.00 ktrprocexit [425] 0.0 37830.00 1.00 lapic_ipi_vectored [426] 0.0 37831.00 1.00 lapic_ipi_wait [427] 0.0 37832.00 1.00 lim_rlimit [428] 0.0 37833.00 1.00 m_dup_pkthdr [429] 0.0 37834.00 1.00 m_tag_copy_chain [430] 0.0 37835.00 1.00 mb_ctor_pack [431] 0.0 37836.00 1.00 pmap_clear_reference [432] 0.0 37837.00 1.00 pmap_enter_quick [433] 0.0 37838.00 1.00 pmap_invalidate_range [434] 0.0 37839.00 1.00 pmap_remove [435] 0.0 37840.00 1.00 pmap_unuse_pt [436] 0.0 37841.00 1.00 rijndael_blockEncrypt [437] 0.0 37842.00 1.00 sbrelease [438] 0.0 37843.00 1.00 sched_clock [439] 0.0 37844.00 1.00 sched_prio [440] 0.0 37845.00 1.00 sched_priority [441] 0.0 37846.00 1.00 schedcpu_thread [442] 0.0 37847.00 1.00 scrn_timer [443] 0.0 37848.00 1.00 selrecord [444] 0.0 37849.00 1.00 signotify [445] 0.0 37850.00 1.00 sleepq_timeout [446] 0.0 37851.00 1.00 softdep_disk_io_initiation [447] 0.0 37852.00 1.00 softdep_setup_allocindir_page [448] 0.0 37853.00 1.00 soo_poll [449] 0.0 37854.00 1.00 strncmp [450] 0.0 37855.00 1.00 syncache_add [451] 0.0 37856.00 1.00 tcp_reass [452] 0.0 37857.00 1.00 tcp_sackhole_insert [453] 0.0 37858.00 1.00 tcp_sackhole_remove [454] 0.0 37859.00 1.00 ufs_bmaparray [455] 0.0 37860.00 1.00 ufs_setattr [456] 0.0 37861.00 1.00 ufs_strategy [457] 0.0 37862.00 1.00 ufsdirhash_hash [458] 0.0 37863.00 1.00 unlock_and_deallocate [459] 0.0 37864.00 1.00 v_decr_usecount [460] 0.0 37865.00 1.00 vfs_bio_clrbuf [461] 0.0 37866.00 1.00 vfs_vmio_release [462] 0.0 37867.00 1.00 vm_map_entry_link [463] 0.0 37868.00 1.00 vm_map_entry_unlink [464] 0.0 37869.00 1.00 vm_map_findspace [465] 0.0 37870.00 1.00 vm_map_inherit [466] 0.0 37871.00 1.00 vm_map_lookup [467] 0.0 37872.00 1.00 vm_map_lookup_entry [468] 0.0 37873.00 1.00 vm_map_protect [469] 0.0 37874.00 1.00 vm_object_backing_scan [470] 0.0 37875.00 1.00 vm_object_clear_flag [471] 0.0 37876.00 1.00 vm_object_page_remove [472] 0.0 37877.00 1.00 vm_object_shadow [473] 0.0 37878.00 1.00 vm_object_terminate [474] 0.0 37879.00 1.00 vm_page_activate [475] 0.0 37880.00 1.00 vm_page_free [476] 0.0 37881.00 1.00 vm_page_is_valid [477] 0.0 37882.00 1.00 vm_pageq_find [478] 0.0 37883.00 1.00 vmspace_fork [479] 0.0 37884.00 1.00 vn_rdwr [480] Index by function name [351] DELAY [336] getnanotime [118] sleepq_lock [352] NDFREE [362] getnewbuf [103] sleepq_lookup [328] SHA256_Final [294] gettimeofday [186] sleepq_release [2] SHA256_Transform [168] groupmember [144] sleepq_resume_threa [157] SHA256_Update [163] hardclock [150] sleepq_signal [115] VOP_ACCESS_APV [310] hardclock_device_po [162] sleepq_switch [235] VOP_CLOSE_APV [169] hardclock_process [372] sleepq_timedwait [385] VOP_GETATTR_APV [49] hpet_get_timecount [243] sleepq_timedwait_si [194] VOP_GETWRITEMOUNT_A [185] idle_proc [446] sleepq_timeout [199] VOP_INACTIVE_APV [55] in_broadcast [137] sleepq_wait [76] VOP_ISLOCKED_APV [20] in_cksum_skip [227] smp_tlb_shootdown [329] VOP_LEASE_APV [1] in_cksumdata [99] softclock [73] VOP_LOCK_APV [266] in_clsroute [447] softdep_disk_io_ini [84] VOP_LOOKUP_APV [121] in_delayed_cksum [448] softdep_setup_alloc [216] VOP_OPEN_APV [160] in_matroute [449] soo_poll [46] VOP_UNLOCK_APV [95] in_pcblookup_hash [316] sopoll [140] Xapic_isr1 [152] in_pseudo [286] soreceive [386] Xdna [69] intr_event_schedule [164] sowakeup [44] Xfast_syscall [79] intr_execute_handle [29] spinlock_enter [189] Xtimerint [337] intr_lookup_source [13] spinlock_exit [481] __mnt_vnode_markerf [72] ioapic_disable_sour [297] statclock [156] _callout_stop_safe [86] ioapic_enable_sourc [450] strncmp [88] _mtx_lock_sleep [363] ioapic_write [317] suser [35] _mtx_lock_spin [38] ip_input [373] suser_cred [43] _mtx_lock_spin_flag [25] ip_output [106] swi_net [256] _mtx_trylock [364] ip_slowtimo [318] swi_sched [100] _mtx_unlock_spin_fl [180] ipfw_check_in [451] syncache_add [482] _pmap_allocpte [158] ipfw_check_out [33] syscall [483] _pmap_unwire_pte_ho [6] ipfw_chk [165] taskqueue_enqueue [484] _sx_xlock [26] ithread_loop [145] taskqueue_run [107] acpi_cpu_c1 [365] itimerfix [344] taskqueue_thread_en [90] acpi_cpu_idle [122] kern_close [262] taskqueue_thread_lo [40] acquire [68] kern_kevent [345] tc_ticktock [264] allocbuf [61] kern_open [147] tc_windup [387] alltraps [421] kern_select [131] tcp_dooptions [353] amr_completeio [36] kern_sendfile [9] tcp_input [330] amr_done [422] kern_wait [319] tcp_isn_tick [354] amr_startio [177] kevent [5] tcp_output [275] apic_idt_to_irq [366] kevent_copyin [452] tcp_reass [355] arpintr [423] kevent_copyout [174] tcp_sack_doack [388] arplookup [424] knlist_empty [238] tcp_sack_output [70] arpresolve [225] knlist_mtx_lock [453] tcp_sackhole_insert [302] atomic_add_int [200] knlist_mtx_unlock [454] tcp_sackhole_remove [217] atomic_clear_int [96] knote [346] tcp_usr_rcvd [356] atomic_subtract_int [295] knote_alloc [119] tcp_usr_send [45] bcmp [201] knote_enqueue [125] tcp_xmit_bandwidth_ [28] bcopy [136] knote_fdclose [212] tcp_xmit_timer [389] bdirty [117] kqueue_aquire [244] tcpip_fillheaders [242] bdwrite [208] kqueue_fo_release [252] timevaladd [276] bintime [74] kqueue_register [320] timevalfix [62] binuptime [132] kqueue_release [298] timevalsub [390] biodone [425] ktrprocexit [204] trap [303] bqrelse [367] lapic_eoi [374] trap_pfault [391] breadn [211] lapic_handle_intr [375] turnstile_lock [190] brelse [139] lapic_handle_timer [213] tvtohz [392] bremfreel [426] lapic_ipi_vectored [48] ufs_access [288] buf_splay [427] lapic_ipi_wait [455] ufs_bmaparray [331] buf_vlist_add [428] lim_rlimit [245] ufs_close [393] bufbdflush [338] lockcount [321] ufs_getlbns [236] bufdone [3] lockmgr [54] ufs_inactive [394] bufobj_wref [16] lockstatus [376] ufs_itimes [395] bufwrite [7] lookup [246] ufs_open [357] bus_dmamap_load [24] m_copym [232] ufs_root [10] bus_dmamap_load_mbu [429] m_dup_pkthdr [456] ufs_setattr [396] bwillwrite [126] m_extadd [457] ufs_strategy [22] bzero [188] m_freem [458] ufsdirhash_hash [397] cache_enter [430] m_tag_copy_chain [347] uhci_intr [8] cache_lookup [209] m_tag_delete_chain [154] uhci_intr1 [27] callout_reset [230] m_tag_locate [348] uiomove [51] choosethread [130] malloc [53] uma_slab_alloc [289] close [161] malloc_type_freed [11] uma_zalloc_arg [304] closef [172] malloc_type_zone_al [14] uma_zfree_arg [398] cluster_callback [50] maybe_preempt [17] uma_zfree_internal [277] cluster_read [191] maybe_resched [214] uma_zone_exhausted_ [358] cluster_wbuild [60] mb_ctor_mbuf [151] uma_zone_slab [203] compute_cn_lkflags [431] mb_ctor_pack [459] unlock_and_dealloca [108] copyin [267] mb_dtor_clust [120] userret [37] copyinstr [231] mb_dtor_mbuf [460] v_decr_usecount [134] copyout [182] mb_dtor_pack [377] v_incr_usecount [85] cpu_idle [87] mb_free_ext [66] vaccess [31] cpu_switch [268] mb_zfini_pack [39] vdropl [290] crfree [52] memcpy [461] vfs_bio_clrbuf [206] crhold [19] mi_switch [228] vfs_busy [56] critical_enter [226] microtime [299] vfs_busy_pages [30] critical_exit [368] mp_grab_cpu_hlt [64] vfs_cache_lookup [218] cursig [105] msleep [148] vfs_hash_get [399] cv_wait_sig [170] msleep_spin [253] vfs_page_set_valid [400] default_pager_haspa [89] namei [271] vfs_ref [207] dev_lock [75] netisr_processqueue [215] vfs_rel [305] dev_unlock [369] nfsrv_timer [300] vfs_setdirty [257] devstat_end_transac [370] obreak [349] vfs_unbusy [258] do_sendfile [280] open [462] vfs_vmio_release [401] dofileread [222] pagecopy [32] vget [402] dofilewrite [249] pagezero [322] vholdl [123] doreti [18] pfil_run_hooks [41] vinactive [141] doselwakeup [311] pmap_allocpte [224] vm_fault [306] dummynet [223] pmap_clear_modify [463] vm_map_entry_link [91] dummynet_task [432] pmap_clear_referenc [254] vm_map_entry_splay [59] em_start [312] pmap_copy [464] vm_map_entry_unlink [12] em_start_locked [259] pmap_enter [465] vm_map_findspace [67] ether_output [433] pmap_enter_quick [466] vm_map_inherit [58] ether_output_frame [434] pmap_invalidate_ran [467] vm_map_lookup [403] exec_copyout_string [281] pmap_is_modified [468] vm_map_lookup_entry [94] falloc [250] pmap_is_prefaultabl [469] vm_map_protect [404] fcntl [183] pmap_kextract [470] vm_object_backing_s [171] fd_first_free [339] pmap_protect [471] vm_object_clear_fla [135] fdalloc [340] pmap_qremove [263] vm_object_deallocat [104] fdrop [435] pmap_remove [472] vm_object_page_remo [82] fdrop_locked [260] pmap_remove_all [473] vm_object_shadow [332] fdunused [261] pmap_remove_pages [474] vm_object_terminate [248] fdused [269] pmap_try_insert_pv_ [247] vm_object_vndealloc [291] ffs_balloc_ufs2 [436] pmap_unuse_pt [475] vm_page_activate [405] ffs_bdflush [98] pmc_cpu_is_logical [181] vm_page_alloc [307] ffs_clusteralloc [341] poll [378] vm_page_cache [406] ffs_isblock [270] random_kthread [287] vm_page_flag_clear [113] ffs_lock [81] random_process_even [379] vm_page_flash [359] ffs_read [371] reassignbuf [476] vm_page_free [407] ffs_realloccg [342] reseed [239] vm_page_free_toq [360] ffs_sync [296] rijndaelEncrypt [272] vm_page_insert [408] ffs_update [237] rijndaelKeySetupEnc [380] vm_page_io_finish [219] ffs_vget [437] rijndael_blockEncry [477] vm_page_is_valid [292] ffs_write [251] rman_get_bushandle [233] vm_page_lookup [92] fget [178] rman_get_bustag [323] vm_page_remove [308] fget_read [23] rn_match [273] vm_page_select_cach [265] fget_write [138] rn_satisfies_leaf [159] vm_page_set_validcl [101] fgetsock [57] rt_check [220] vm_page_sleep_if_bu [166] fgetvp_read [42] rtalloc1 [111] vm_page_splay [112] filt_sowrite [93] rtalloc_ign [205] vm_page_unwire [361] forward_roundrobin [80] rtfree [196] vm_page_wire [409] fpu_clean_state [146] runq_add [324] vm_page_zero_check [195] fpudna [173] runq_check [274] vm_pageout [410] fpusetregs [63] runq_choose [197] vm_pageq_enqueue [167] fputsock [124] runq_remove [478] vm_pageq_find [128] fr_acctpkt [153] sbappendstream [193] vm_pageq_remove [411] fr_authexpire [282] sbappendstream_lock [234] vm_pageq_remove_now [4] fr_check [133] sbcompress [479] vmspace_fork [114] fr_check_wrapper [313] sbdrop [325] vmtotal [278] fr_checkauth [78] sbdrop_locked [210] vn_close [279] fr_checknatin [438] sbrelease [187] vn_closefile [97] fr_checknatout [314] scanc [155] vn_finished_write [129] fr_checkstate [65] sched_add [381] vn_isdisk [77] fr_checkv4sum [439] sched_clock [34] vn_lock [83] fr_dolog [440] sched_prio [175] vn_open_cred [15] fr_makefrip [441] sched_priority [480] vn_rdwr [110] free [102] sched_runnable [382] vn_read [143] frpr_pullup [21] sched_switch [149] vn_start_write [221] frpr_short [116] sched_userret [326] vn_write [412] g_bioq_first [283] sched_wakeup [240] vnode_create_vobjec [413] g_bioq_lock [442] schedcpu_thread [383] vnode_pager_setsize [333] g_bioq_unlock [443] scrn_timer [301] vop_lock_post [414] g_clone_bio [444] selrecord [241] vop_lock_pre [334] g_disk_start [315] selwakeuppri [255] vop_lookup_pre [415] g_io_deliver [284] sendfile [350] vop_stdgetwritemoun [416] g_io_request [192] setrunnable [142] vop_stdislocked [335] g_io_schedule_down [202] setrunqueue [327] vop_stdlock [417] g_io_schedule_up [179] sf_buf_mext [198] vop_stdunlock [418] g_slice_start [445] signotify [384] vop_unlock_pre [419] g_trace [109] sleepq_add [47] vput [420] g_vfs_done [184] sleepq_broadcast [71] vref [309] gbincore [127] sleepq_catch_signal [176] vrele [229] getblk [343] sleepq_check_signal [293] getmicrouptime [285] sleepq_check_timeou --------------020108020005080507060303-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 15:14:22 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26D216A417 for ; Wed, 24 Oct 2007 15:14:22 +0000 (UTC) (envelope-from gelun@awax.ru) Received: from awax.ru (mail.awax.ru [83.69.240.5]) by mx1.freebsd.org (Postfix) with ESMTP id 439C013C4B3 for ; Wed, 24 Oct 2007 15:14:21 +0000 (UTC) (envelope-from gelun@awax.ru) Received: from [83.69.240.13] (helo=orladm11) by awax.ru with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ikgbw-0006HE-08 for hackers@FreeBSD.org; Wed, 24 Oct 2007 17:49:28 +0400 From: "Artem Gelun" To: Date: Wed, 24 Oct 2007 17:49:35 +0400 Message-ID: <021301c81644$b671fd10$2355f730$@ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgWRKyqzxteMhq1RtG4PRz6e0TcVQ== Content-Language: ru x-cr-hashedpuzzle: AMIZ CqG/ DPQ8 ER9z FIEV FnlW G6VA HWDo HW+F HfBj IO1N JrV9 J4Xq KF3w LLGD MSUh; 1; aABhAGMAawBlAHIAcwBAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA=; Sosha1_v1; 7; {828F116C-73A4-4B96-A828-067C6477861E}; ZwBlAGwAdQBuAEAAYQB3AGEAeAAuAHIAdQA=; Wed, 24 Oct 2007 13:49:19 GMT; TABvAG8AawAgAGwAaQBrAGUAIABJAFAARgBpAGwAdABlAHIAIABwAHIAbwBiAGwAZQBtAA== x-cr-puzzleid: {828F116C-73A4-4B96-A828-067C6477861E} X-Mailman-Approved-At: Wed, 24 Oct 2007 16:15:41 +0000 Cc: Subject: Look like IPFilter problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 15:14:22 -0000 IPNat and IPFilter are enabled. IPFW rules are empty. #uname -a FreeBSD gw1.awax.corp 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #15: Wed Oct 24 10:05:34 MSD 2007 gelun@gw1.awax.corp:/usr/src/sys/i386/compile/GW i386 OPTIONS Part of kernel config file makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB options KDB_UNATTENDED options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options SCSI_DELAY=5 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. ## options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFILTER options IPFILTER_LOG #options SC_DISABLE_REBOOT options MAXUSERS=1024 options TCP_DROP_SYNFIN kgdb (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc057ff0c in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc058028d in panic (fmt=0xc077e63f "sleeping thread") at ../../../kern/kern_shutdown.c:565 #3 0xc05a8a0c in propagate_priority (td=0xc55b9a80) at ../../../kern/subr_turnstile.c:209 #4 0xc05a93ef in turnstile_wait (lock=0xc07f58c0, owner=0x0, queue=0) at ../../../kern/subr_turnstile.c:715 #5 0xc05744ac in _mtx_lock_sleep (m=0xc07f58c0, tid=3311114112, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:579 #6 0xc0443648 in fr_check (ip=0xc5e7d740, hlen=20, ifp=0x0, out=1, mp=0xdd9a6b20) at ../../../contrib/ipfilter/netinet/fil.c:2320 #7 0xc0448f6c in fr_check_wrapper (arg=0x0, mp=0x0, ifp=0x0, dir=2) at ../../../contrib/ipfilter/netinet/ip_fil_freebsd.c:171 #8 0xc0618008 in pfil_run_hooks (ph=0xc0804fa0, mp=0xdd9a6b94, ifp=0xc5735c00, dir=2, inp=0xc5db1924) at ../../../net/pfil.c:139 #9 0xc06349c0 in ip_output (m=0xc5e7d700, opt=0xc5735c00, ro=0xdd9a6b60, flags=0, imo=0x0, inp=0xc5db1924) at ../../../netinet/ip_output.c:679 #10 0xc063ef11 in tcp_output (tp=0xc5de3000) at ../../../netinet/tcp_output.c:1080 #11 0xc0644e2a in tcp_timer_rexmt (xtp=0xc5de3000) at ../../../netinet/tcp_timer.c:537 #12 0xc058fa16 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:290 #13 0xc0564098 in ithread_execute_handlers (p=0xc55b8a78, ie=0xc5660280) at ../../../kern/kern_intr.c:682 #14 0xc0564216 in ithread_loop (arg=0xc55816b0) at ../../../kern/kern_intr.c:765 #15 0xc0562b0f in fork_exit (callout=0xc05641a0 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:830 #16 0xc072d86c in fork_trampoline () at ../../../i386/i386/exception.s:208 (kgdb) up 3 #3 0xc05a8a0c in propagate_priority (td=0xc55b9a80) at ../../../kern/subr_turnstile.c:209 209 panic("sleeping thread"); (kgdb) up 1 #4 0xc05a93ef in turnstile_wait (lock=0xc07f58c0, owner=0x0, queue=0) at ../../../kern/subr_turnstile.c:715 715 propagate_priority(td); (kgdb) p td $1 = (struct thread *) 0xc55b9780 (kgdb) up 1 #5 0xc05744ac in _mtx_lock_sleep (m=0xc07f58c0, tid=3311114112, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:579 579 turnstile_wait(&m->mtx_object, mtx_owner(m), (kgdb) p m->mtx_object $2 = {lo_class = 0xc07d3404, lo_name = 0xc076a034 "ipf filter load/unload mutex", lo_type = 0xc076a034 "ipf filter load/unload mutex", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0} (kgdb) p m $3 = (struct mtx *) 0xc07f58c0 (kgdb) p *m $4 = {mtx_object = {lo_class = 0xc07d3404, lo_name = 0xc076a034 "ipf filter load/unload mutex", lo_type = 0xc076a034 "ipf filter load/unload mutex", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 3311114882, mtx_recurse = 0} (kgdb) up 1 #6 0xc0443648 in fr_check (ip=0xc5e7d740, hlen=20, ifp=0x0, out=1, mp=0xdd9a6b20) at ../../../contrib/ipfilter/netinet/fil.c:2320 2320 READ_ENTER(&ipf_global); (kgdb) p ipf_global $5 = {ipf_lkun_s = {ipf_slk = {mtx_object = {lo_class = 0xc07d3404, lo_name = 0xc076a034 "ipf filter load/unload mutex", lo_type = 0xc076a034 "ipf filter load/unload mutex", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 3311114882, mtx_recurse = 0}, ipf_lname = 0x0, ipf_sr = 0, ipf_sw = 0, ipf_magic = 0}, ipf_emu = {eMrw_owner = 0xc07d3404 "s-x-\t", eMrw_heldin = 0xc076a034 "ipf filter load/unload mutex", eMrw_magic = 3228999732, eMrw_read = 0, eMrw_write = 3, eMrw_heldat = 0}} (kgdb) quit Thank you. Artem Gelun Awax Telecom system administrator. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 17:02:58 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C89116A418; Wed, 24 Oct 2007 17:02:58 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.freebsd.org (Postfix) with ESMTP id 3C37413C4B8; Wed, 24 Oct 2007 17:02:58 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] (host-83-146-60-88.bulldogdsl.com [83.146.60.88]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id l9OGen5I054281; Wed, 24 Oct 2007 17:40:49 +0100 (BST) (envelope-from rb@gid.co.uk) In-Reply-To: References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Bishop Date: Wed, 24 Oct 2007 17:40:55 +0100 To: Ivan Voras X-Mailer: Apple Mail (2.752.3) Cc: freebsd-hackers@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 17:02:58 -0000 Hi, On 23 Oct 2007, at 20:45, Ivan Voras wrote: > Bob Bishop wrote: >> Hi, >> >> The whole USB kit and caboodle is nodevice'd out in the PAE >> config. Can >> anyone give a succinct summary of what needs fixing? (EVERYTHING! >> is an >> acceptable answer) Thanks > > I'm running USB keyboard and mouse under PAE without problems. Don't > know about other USB devices. AFAIK everything that is 64-bit clean > (i.e. works on AMD64 and other architectures) should work ok with PAE, > so try compiling it in and see for yourself. Yes. Keyboard and umass (CDROM and memory stick) seem to work here on 6.2R. Thanks! -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 17:51:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9896816A473 for ; Wed, 24 Oct 2007 17:51:44 +0000 (UTC) (envelope-from patrick_dkt@yahoo.com.hk) Received: from web54304.mail.re2.yahoo.com (web54304.mail.re2.yahoo.com [206.190.49.114]) by mx1.freebsd.org (Postfix) with SMTP id 513F613C4C8 for ; Wed, 24 Oct 2007 17:51:43 +0000 (UTC) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 26521 invoked by uid 60001); 24 Oct 2007 17:24:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hyEABJDwuT0i5xVyA+L3jUM+EFEusXVF5E8pybuuJbWGSBMftj078MDASMBd/rQ1yy7SUxT9dYCZBPg/cMubURBaRX/Lu5FUqDWhDhWCFMpcbCKKaEumOI1KIFMBIZT0gTY82pvfZgvcKhSXsXxyDXLqhF3y+sqmp0g1mQ2rBPM=; X-YMail-OSG: 10lf9FwVM1nlOwMvmdR1lnQLi5gh3atueUFoUrVi2qzfCu18wDLQ8KedCZzV9jqv9f07FyG7kY3DmDGjv5xqDYEumNwg92e0voCzEP70sOSr36mzvgrPNNV37y8T Received: from [61.15.61.52] by web54304.mail.re2.yahoo.com via HTTP; Wed, 24 Oct 2007 10:24:42 PDT Date: Wed, 24 Oct 2007 10:24:42 -0700 (PDT) From: Patrick Dung To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <238725.26120.qm@web54304.mail.re2.yahoo.com> X-Mailman-Approved-At: Wed, 24 Oct 2007 18:00:07 +0000 Cc: Subject: kernel panic at shutdown with freebsd 7.0 current snapshot (oct-2007) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 17:51:44 -0000 Hi I have ZFS (and snapshot) mounted. Then shutdown by `shutdown -p now`. There is the dump: # kgdb /boot/kernel/kernel.symbols vmcore.0 [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: panic: vrele: negative ref cnt cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 8h44m12s Physical memory: 507 MB Dumping 120 MB: 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc074d98e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc074dc4b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc048cab7 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc048d4a5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc048ec15 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc07748e6 in kdb_trap (type=3, code=0, tf=0xd53d7984) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0a02dfb in trap (frame=0xd53d7984) at /usr/src/sys/i386/i386/trap.c:621 #8 0xc09e87eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0774a62 in kdb_enter (msg=0xc0a996bc "panic") at cpufunc.h:60 #10 0xc074dc34 in panic (fmt=0xc0aa528a "vrele: negative ref cnt") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc07cb0a1 in vrele (vp=0xc2fccaa0) at /usr/src/sys/kern/vfs_subr.c:2117 #12 0xc0725905 in fdfree (td=0xc2f29a50) at /usr/src/sys/kern/kern_descrip.c:1694 #13 0xc072ea53 in exit1 (td=0xc2f29a50, rv=1) at /usr/src/sys/kern/kern_exit.c:272 #14 0xc07508bf in sigexit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_sig.c:2876 #15 0xc0750c99 in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:2748 #16 0xc077eb78 in ast (framep=0xd53d7d38) at /usr/src/sys/kern/subr_trap.c:250 #17 0xc09e910d in doreti_ast () at /usr/src/sys/i386/i386/exception.s:290 #18 0xd53d7d38 in ?? () #19 0x0000003b in ?? () #20 0x0000003b in ?? () #21 0x0000003b in ?? () #22 0x00000000 in ?? () #23 0xffffffff in ?? () #24 0xbfbfee58 in ?? () #25 0xd53d7d64 in ?? () #26 0x00000000 in ?? () #27 0x0804fb20 in ?? () #28 0x00000000 in ?? () #29 0x00000004 in ?? () #30 0x0000000c in ?? () #31 0x00000002 in ?? () #32 0x28167553 in ?? () #33 0x00000033 in ?? () #34 0x00000247 in ?? () #35 0xbfbfee1c in ?? () #36 0x0000003b in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0x0116c000 in ?? () #42 0xc2f5bd48 in ?? () ---Type to continue, or q to quit--- #43 0xc31e1000 in ?? () #44 0xd53d7878 in ?? () #45 0xd53d7854 in ?? () #46 0xc2f29a50 in ?? () #47 0xc076a756 in sched_switch (td=0x0, newtd=0xffffffff, flags=Cannot access memory at address 0xbfbfee68 ) at /usr/src/sys/kern/sched_4bsd.c:907 Previous frame inner to this frame (corrupt stack?) (kgdb) Regards Patrick __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 19:03:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860F116A417 for ; Wed, 24 Oct 2007 19:03:44 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB0F13C465 for ; Wed, 24 Oct 2007 19:03:43 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id 3CE4316C86DF for ; Wed, 24 Oct 2007 09:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.002, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUViPGU7gJ2L for ; Wed, 24 Oct 2007 09:53:06 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id D3AE316C86DE for ; Wed, 24 Oct 2007 09:53:06 -0700 (PDT) Date: Wed, 24 Oct 2007 09:53:06 -0700 (PDT) From: Brooks Talley To: freebsd-hackers@freebsd.org Message-ID: <6511247.119521193244786830.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.168.65.79] Subject: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 19:03:44 -0000 Hi, everyone. I'm pulling my hair out in great chunks. I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 250000 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) So far, I have applied these patches to uftdi.c and uftdireg.h: http://tinyurl.com/2yye2l Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B250000, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. Any ideas on how to get this to work? It doesn't seem like it should be this difficult! Thanks -Brooks From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 19:12:45 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF6C116A41B for ; Wed, 24 Oct 2007 19:12:45 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id B843E13C48E for ; Wed, 24 Oct 2007 19:12:45 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so229675rvb for ; Wed, 24 Oct 2007 12:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=JB5veMv49cNS0R5RiKetDyILQvEe+qDcwMNkeT10JUo=; b=gtnxJev5Xkkqc/U00ymUffgLtLyqON3/mr4pJ09KX4G8GHelFnSMXeBQNLd1aVEB6HCKK9RQhL3mKI0dhHBwLyQ2+CGLjPSqUPxN6pU0Bk8VfswDTIYdhv5yPFiop4vEF6s+r91zffBo7qqfFR7RMUhxh/VAj4m5m/5gn3f8OIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=rthVwA9aLAmF7FOuQtLcPYlKEJeJlYK9PexkR3cescZmbr6b9ROkj5XHnMkxupVpLW5wuHRwvDlAVZBx56m8vmqm8UTS+YPbFd4O622RdcYFewHwcMNVe6iTwAsBFTsi27yQi5V5vOCj1VpCH5FVqISrQF7xN42XHX3U/4drCaA= Received: by 10.140.199.19 with SMTP id w19mr465002rvf.1193251476118; Wed, 24 Oct 2007 11:44:36 -0700 (PDT) Received: by 10.141.194.16 with HTTP; Wed, 24 Oct 2007 11:44:36 -0700 (PDT) Message-ID: <9bbcef730710241144o95a32f1yc4aa6477eb488c1e@mail.gmail.com> Date: Wed, 24 Oct 2007 20:44:36 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Bob Bishop" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> X-Google-Sender-Auth: 03489a177836f21f Cc: freebsd-hackers@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 19:12:46 -0000 On 24/10/2007, Bob Bishop wrote: > Yes. Keyboard and umass (CDROM and memory stick) seem to work here on > 6.2R. Thanks! I just saw it is officially ok'ed for PAE in future versions (commit by John Baldwin). From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 19:20:22 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FCF16A420 for ; Wed, 24 Oct 2007 19:20:22 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id E5DA913C48A for ; Wed, 24 Oct 2007 19:20:21 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id 28BC416C86E1 for ; Wed, 24 Oct 2007 10:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.002, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZHiKSMpHa7e for ; Wed, 24 Oct 2007 10:11:29 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id 9CAA816C86DE for ; Wed, 24 Oct 2007 10:11:29 -0700 (PDT) Date: Wed, 24 Oct 2007 10:11:29 -0700 (PDT) From: Brooks Talley To: freebsd-hackers Message-ID: <2297017.119571193245889606.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [71.37.13.44] Subject: Getting nonstandard baud rates w/FTDI + python X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 19:20:22 -0000 Hi, everyone. I'm pulling my hair out in great chunks. I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 250000 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) So far, I have applied these patches to uftdi.c and uftdireg.h: http://tinyurl.com/2yye2l Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B250000, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. Any ideas on how to get this to work? It doesn't seem like it should be this difficult! Thanks -Brooks From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 19:57:50 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DCE916A418 for ; Wed, 24 Oct 2007 19:57:50 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id EF7FE13C4D3 for ; Wed, 24 Oct 2007 19:57:49 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 3C8C41E002F for ; Wed, 24 Oct 2007 10:50:22 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27114-04 for ; Wed, 24 Oct 2007 10:50:21 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id B41CC1E002D for ; Wed, 24 Oct 2007 10:50:21 -0700 (PDT) Message-ID: <471F85DD.1070906@miralink.com> Date: Wed, 24 Oct 2007 10:50:21 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Oct 24 10:50:22 2007 X-DSPAM-Confidence: 0.9989 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 471f85de54061804284693 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=-0.000, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Subject: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 19:57:50 -0000 I have a drive that contains two seperate bootable partitions(ad0s1a and ad0s2a). The boot device selection menu(boot0?) appears to only be able to support 9600 8N1. I wanted to run the serial console at 115200, but I currently have to switch to 9600 if I need to change the boot device. Is there a way around this that I can't see? Could I get around this with a BIOS that can do console redirection? Sean From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 20:57:24 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B095416A417 for ; Wed, 24 Oct 2007 20:57:24 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8A02A13C480 for ; Wed, 24 Oct 2007 20:57:24 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B78833B78B; Wed, 24 Oct 2007 16:40:39 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 24 Oct 2007 16:40:39 -0400 X-Sasl-enc: RH/T4O3WLp4RpfjGeNFxYyIjw5YO9wzIEfoClQLj65Iz 1193258439 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 31CC9243C1; Wed, 24 Oct 2007 16:40:39 -0400 (EDT) Message-ID: <471FADC0.6030301@freebsd.org> Date: Wed, 24 Oct 2007 13:40:32 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Artem Gelun References: <021301c81644$b671fd10$2355f730$@ru> In-Reply-To: <021301c81644$b671fd10$2355f730$@ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: Re: Look like IPFilter problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 20:57:24 -0000 Please file a PR. Darren From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 21:08:53 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB6F716A418; Wed, 24 Oct 2007 21:08:53 +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 6618113C4A6; Wed, 24 Oct 2007 21:08:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9OL4ESq021134; Wed, 24 Oct 2007 15:04:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 24 Oct 2007 15:07:05 -0600 (MDT) Message-Id: <20071024.150705.1159135282.imp@bsdimp.com> To: ivoras@freebsd.org From: "M. Warner Losh" In-Reply-To: <9bbcef730710241144o95a32f1yc4aa6477eb488c1e@mail.gmail.com> References: <9bbcef730710241144o95a32f1yc4aa6477eb488c1e@mail.gmail.com> 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: freebsd-hackers@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 21:08:53 -0000 In message: <9bbcef730710241144o95a32f1yc4aa6477eb488c1e@mail.gmail.com> "Ivan Voras" writes: : On 24/10/2007, Bob Bishop wrote: : : > Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : > 6.2R. Thanks! : : I just saw it is officially ok'ed for PAE in future versions (commit : by John Baldwin). 6.x doesn't have the scatter/gather code merged yet, so still is unsafe. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 21:09:52 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E664E16A469; Wed, 24 Oct 2007 21:09:52 +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 A844E13C4A7; Wed, 24 Oct 2007 21:09:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9OL3n1Z021131; Wed, 24 Oct 2007 15:03:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 24 Oct 2007 15:06:39 -0600 (MDT) Message-Id: <20071024.150639.63053209.imp@bsdimp.com> To: rb@gid.co.uk From: "M. Warner Losh" In-Reply-To: References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> 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: freebsd-hackers@freebsd.org, ivoras@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 21:09:53 -0000 In message: Bob Bishop writes: : Hi, : : On 23 Oct 2007, at 20:45, Ivan Voras wrote: : : > Bob Bishop wrote: : >> Hi, : >> : >> The whole USB kit and caboodle is nodevice'd out in the PAE : >> config. Can : >> anyone give a succinct summary of what needs fixing? (EVERYTHING! : >> is an : >> acceptable answer) Thanks : > : > I'm running USB keyboard and mouse under PAE without problems. Don't : > know about other USB devices. AFAIK everything that is 64-bit clean : > (i.e. works on AMD64 and other architectures) should work ok with PAE, : > so try compiling it in and see for yourself. : : : Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : 6.2R. Thanks! In 6.x the big problem is busdma support. USB doesn't use it quite right, which means that buffers that it uses must be in the lower 4GB. If not, then it won't work. Current does proper scatter/gather, so should work without issue. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 21:17:57 2007 Return-Path: Delivered-To: FreeBSD-Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A53DF16A41B for ; Wed, 24 Oct 2007 21:17:57 +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 6391A13C4B7 for ; Wed, 24 Oct 2007 21:17:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9OLCMqp021268; Wed, 24 Oct 2007 15:12:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 24 Oct 2007 15:15:13 -0600 (MDT) Message-Id: <20071024.151513.-713548131.imp@bsdimp.com> To: Danovitsch@vitsch.net From: "M. Warner Losh" In-Reply-To: <200710222211.51590.Danovitsch@vitsch.net> References: <200710222211.51590.Danovitsch@vitsch.net> 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: FreeBSD-Hackers@FreeBSD.org Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 21:17:57 -0000 In message: <200710222211.51590.Danovitsch@vitsch.net> "Daan Vreeken [PA4DAN]" writes: : But what I haven't found is a description of exactly what the kernel is : missing to allow floating point operations to be done there. FPU context is assumed to only change in user processes. You'd have to fix the FPU state saving code to cope with it changing everywhere, or you'd have to explicitly put the goo to save/restore it around the FP you want to do in the kernel. You had also make sure that the floating point exceptions never trap, since trapping inside the kernel has very limited support. You'll have to fix the problems that this would cause, or force the FPU into a state where it never traps. Sure, maybe you can make it happen. However, you are in for much pain and suffering. The kernel isn't a general purpose computing environment, and trying to pretend it is will lead to suffering. Especially inside of an interrupt handler. It is less bad if this is an ithread, but could be quite painful if you want to do this inside of a fast interrupt handler to reduce latency. I'd recommend strongly against trying this and revaluate your true need for FP in the kernel. From your other mail, you don't seem open to this answer. If you don't take it, you are setting yourself up for a lot of pain and suffering. It is your choice, however. If you do manage to pull it of, I'd be very interested in see what things I didn't know to warn you about... Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 24 23:22:37 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1044216A418 for ; Wed, 24 Oct 2007 23:22:37 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 78F7E13C480 for ; Wed, 24 Oct 2007 23:22:36 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l9OMxHVG082478; Thu, 25 Oct 2007 00:59:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l9OMxBmS064800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 00:59:12 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l9OMxB1I065254; Thu, 25 Oct 2007 00:59:11 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l9OMxBhV065253; Thu, 25 Oct 2007 00:59:11 +0200 (CEST) (envelope-from ticso) Date: Thu, 25 Oct 2007 00:59:11 +0200 From: Bernd Walter To: Brooks Talley Message-ID: <20071024225910.GU46533@cicely12.cicely.de> References: <6511247.119521193244786830.JavaMail.root@zmail.illuminati.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6511247.119521193244786830.JavaMail.root@zmail.illuminati.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 23:22:37 -0000 On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote: > > Hi, everyone. I'm pulling my hair out in great chunks. > > I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 250000 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. > > The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: > ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) > > So far, I have applied these patches to uftdi.c and uftdireg.h: > http://tinyurl.com/2yye2l > > Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B250000, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. termios.h is not important - they are just constants, you should be able to use raw values in software. > Any ideas on how to get this to work? It doesn't seem like it should be this difficult! You need to add support in the uftdi driver itself. There is an enum containing ftdi_8u232am_* fields and a switch/case in the driver. The hex value divides the 48MHz clock and leaves a factor 8. So 0x0018 should be the right value for 250000bps. There is an OpenBSD patch to calculate the rates dynamically: http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975 Something similar (but in better style IMHO) is commited to OpenBSD, which we should merge into our source. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 00:25:18 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC16016A418 for ; Thu, 25 Oct 2007 00:25:18 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) Received: from outbound.icp-qv1-irony-out3.iinet.net.au (outbound.icp-qv1-irony-out3.iinet.net.au [203.59.1.148]) by mx1.freebsd.org (Postfix) with ESMTP id 39BAA13C4BF for ; Thu, 25 Oct 2007 00:25:18 +0000 (UTC) (envelope-from fbsd-hackers@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKd8H0fLzq3r/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,326,1188748800"; d="scan'208";a="171703989" Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 25 Oct 2007 08:13:07 +0800 Message-ID: <471FDF38.7070702@mawer.org> Date: Thu, 25 Oct 2007 10:11:36 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ticso@cicely.de References: <6511247.119521193244786830.JavaMail.root@zmail.illuminati.org> <20071024225910.GU46533@cicely12.cicely.de> In-Reply-To: <20071024225910.GU46533@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Brooks Talley Subject: Re: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 00:25:18 -0000 On 25/10/2007 8:59 AM, Bernd Walter wrote: > On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote: >> Hi, everyone. I'm pulling my hair out in great chunks. >> >> I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 250000 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. >> >> The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: >> ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) ... >> Any ideas on how to get this to work? It doesn't seem like it should be this difficult! > > You need to add support in the uftdi driver itself. > There is an enum containing ftdi_8u232am_* fields and a switch/case in > the driver. > > The hex value divides the 48MHz clock and leaves a factor 8. > So 0x0018 should be the right value for 250000bps. > > There is an OpenBSD patch to calculate the rates dynamically: > http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975 > Something similar (but in better style IMHO) is commited to OpenBSD, > which we should merge into our source. There looks to me to be an issue with an assignment operation (=) rather than equality test (==) in the following section of the patch: + /* Special cases for 2M and 3M. */ + if ((speed >= UI(3000000 * 0.97)) && (speed = UI(2000000 * 0.97)) \ && (speed <= UI(2000000 * 1.03))) { result = 1; goto done; } I would imagine the "(speed = UI(2000000 * 0.97))" should be == rather than = for this to make sense...? --Antony From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 01:01:49 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE1616A419 for ; Thu, 25 Oct 2007 01:01:49 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id BD27713C480 for ; Thu, 25 Oct 2007 01:01:48 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l9P11diA087997; Thu, 25 Oct 2007 03:01:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l9P11Xc8065942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 03:01:34 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l9P11XNK065826; Thu, 25 Oct 2007 03:01:33 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l9P11X04065825; Thu, 25 Oct 2007 03:01:33 +0200 (CEST) (envelope-from ticso) Date: Thu, 25 Oct 2007 03:01:33 +0200 From: Bernd Walter To: Antony Mawer Message-ID: <20071025010133.GV46533@cicely12.cicely.de> References: <6511247.119521193244786830.JavaMail.root@zmail.illuminati.org> <20071024225910.GU46533@cicely12.cicely.de> <471FDF38.7070702@mawer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471FDF38.7070702@mawer.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org, ticso@cicely.de, Brooks Talley Subject: Re: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 01:01:49 -0000 On Thu, Oct 25, 2007 at 10:11:36AM +1000, Antony Mawer wrote: > On 25/10/2007 8:59 AM, Bernd Walter wrote: > >On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote: > >>Hi, everyone. I'm pulling my hair out in great chunks. > >> > >>I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to > >>serial port at 250000 baud. The FTDI chip definitely supports this rate. > >>The port mounts at /dev/cuaU0. > >> > >>The problem is that > >>/usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on > >>this line: > >>ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) > ... > >>Any ideas on how to get this to work? It doesn't seem like it should be > >>this difficult! > > > >You need to add support in the uftdi driver itself. > >There is an enum containing ftdi_8u232am_* fields and a switch/case in > >the driver. > > > >The hex value divides the 48MHz clock and leaves a factor 8. > >So 0x0018 should be the right value for 250000bps. > > > >There is an OpenBSD patch to calculate the rates dynamically: > >http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975 > >Something similar (but in better style IMHO) is commited to OpenBSD, > >which we should merge into our source. > > > There looks to me to be an issue with an assignment operation (=) rather > than equality test (==) in the following section of the patch: > > > + /* Special cases for 2M and 3M. */ > + if ((speed >= UI(3000000 * 0.97)) && (speed = UI(2000000 * 0.97)) \ > && (speed <= UI(2000000 * 1.03))) { result = 1; goto done; } > > > I would imagine the "(speed = UI(2000000 * 0.97))" should be == rather > than = for this to make sense...? Use the OpenBSD code instead - it is tested and generaly looks better. You can easily get their diffs via cvs. Rev 1.11 of uftdireg.h and 1.29 of uftdi.c -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 03:55:01 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5119C16A46B for ; Thu, 25 Oct 2007 03:55:01 +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 3578613C4A5 for ; Thu, 25 Oct 2007 03:55:01 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 8D3DB1CC071; Wed, 24 Oct 2007 20:54:54 -0700 (PDT) Date: Wed, 24 Oct 2007 20:54:54 -0700 From: Jeremy Chadwick To: Sean Bruno Message-ID: <20071025035454.GA28174@eos.sc1.parodius.com> References: <471F85DD.1070906@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471F85DD.1070906@miralink.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 03:55:01 -0000 On Wed, Oct 24, 2007 at 10:50:21AM -0700, Sean Bruno wrote: > I have a drive that contains two seperate bootable partitions(ad0s1a and > ad0s2a). The boot device selection menu(boot0?) appears to only be able to > support 9600 8N1. I wanted to run the serial console at 115200, but I > currently have to switch to 9600 if I need to change the boot device. Is > there a way around this that I can't see? Could I get around this with a > BIOS that can do console redirection? Which "boot device selection menu" are you referring to? "boot0?" implies you don't know. Here's the difference: boot0 is this stage: F1 FreeBSD F5 Drive 1 Default: F1 boot2 is this stage: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: If you want serial capability in boot0, you should set BOOT_COMCONSOLE_SPEED=115200 in your make.conf. After you do that, you'll need to rebuild the boot blocks. The procedure for doing that is step 4 of Section 24.6.5.2 in the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html You'll also need to update the MBR boot code on-disk to use the new serial version (called boot0sio). boot0cfg -b /boot/boot0sio should do the trick. If you want serial capability in boot2, it's much easier. All you have to do is make a file called /boot.config and place -S115200 in it. You may also want to consider using -S115200 -Dh. See the boot(8) manpage for details on what -S, -D, and -h do. Make sure you don't have a CONSPEED setting in your kernel config as well. All that said, chances are the boot blocks you're using are likely configured to use data from ad0s1a (for booting). So that would be the place to put the /boot.config file. -- | 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-hackers@FreeBSD.ORG Thu Oct 25 09:37:27 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D1716A41A for ; Thu, 25 Oct 2007 09:37:27 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id D50E513C4A6 for ; Thu, 25 Oct 2007 09:37:26 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-210.yandex.ru ([87.250.250.210]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1Ikyd1-000B5l-S5 for freebsd-hackers@freebsd.org; Thu, 25 Oct 2007 13:03:47 +0400 Message-ID: <47205B91.80408@FreeBSD.org> Date: Thu, 25 Oct 2007 13:02:09 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: How to get a kthread ID? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 09:37:27 -0000 Is there a possibility to get a kthread ID inside a kthread? Just like pthread_self(3). -- Dixi. Sem. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 10:04:34 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B10116A420 for ; Thu, 25 Oct 2007 10:04:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E00D213C4BC for ; Thu, 25 Oct 2007 10:04:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 38FFC2098; Thu, 25 Oct 2007 12:04:24 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 283822092; Thu, 25 Oct 2007 12:04:24 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 1765F84499; Thu, 25 Oct 2007 12:04:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Sergey Matveychuk References: <47205B91.80408@FreeBSD.org> Date: Thu, 25 Oct 2007 12:04:23 +0200 In-Reply-To: <47205B91.80408@FreeBSD.org> (Sergey Matveychuk's message of "Thu\, 25 Oct 2007 13\:02\:09 +0400") Message-ID: <867ilbtsrc.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: How to get a kthread ID? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 10:04:34 -0000 Sergey Matveychuk writes: > Is there a possibility to get a kthread ID inside a kthread? > Just like pthread_self(3). curthread? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 10:29:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26D616A41A; Thu, 25 Oct 2007 10:29:59 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5532E13C48A; Thu, 25 Oct 2007 10:29:59 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.hob.de (Postfix) with ESMTP id 9D7BF280FA; Thu, 25 Oct 2007 11:59:41 +0200 (CEST) Received: from mailgate.hob.de ([127.0.0.1]) by localhost (mailgate.hob.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32008-02; Thu, 25 Oct 2007 11:59:41 +0200 (CEST) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 2E1A8280EA; Thu, 25 Oct 2007 11:59:41 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B26A0C6782; Thu, 25 Oct 2007 11:59:40 +0200 (CEST) From: Marc =?utf-8?q?L=C3=B6rner?= Organization: hob To: freebsd-hackers@freebsd.org Date: Thu, 25 Oct 2007 12:01:21 +0200 User-Agent: KMail/1.6.2 References: <47205B91.80408@FreeBSD.org> In-Reply-To: <47205B91.80408@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200710251201.21900.marc.loerner@hob.de> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hob.de Cc: Sergey Matveychuk Subject: Re: How to get a kthread ID? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 10:29:59 -0000 On Thursday 25 October 2007 11:02, Sergey Matveychuk wrote: > Is there a possibility to get a kthread ID inside a kthread? > Just like pthread_self(3). In function kthread_exit there you see that you can obtain the thread-structure with curthread. And then in this thread-structure is the field td_tid. HTH, Marc From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 15:53:01 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39D116A419 for ; Thu, 25 Oct 2007 15:53:01 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id BD3F613C4C2 for ; Thu, 25 Oct 2007 15:53:01 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id 348F516C86DE for ; Thu, 25 Oct 2007 08:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb3RmeJzJBrU for ; Thu, 25 Oct 2007 08:52:48 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id 9322116C86DF for ; Thu, 25 Oct 2007 08:52:48 -0700 (PDT) Date: Thu, 25 Oct 2007 08:52:48 -0700 (PDT) From: Brooks Talley To: freebsd-hackers@freebsd.org Message-ID: <31953061.121491193327568521.JavaMail.root@zmail.illuminati.org> In-Reply-To: <20071025010133.GV46533@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.168.65.79] Subject: Re: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 15:53:01 -0000 Thanks to everyone who applied. The OpenBSD approach to setting UFTDI baud rates is definitely superior. However, the root of my problem turned out to be Python. Even with the new baud rate hardcoded in the UFTDI kernel module and manually added to termios.h, Python was refusing to admit that it was a valid baud rate. The issue is that Python (2.5.1) compiles its own termios interface module, which builds a list of allowed baud rates from the defines in termios.h. Python's termios.c does something like this: include termios_constants[] = { {"B300",B300}, {"B1200",B1200}, {"B2400",B2400}, . . . #ifdef B115200 {"B115200",B115200} #endif #ifdef B230400 {"B230400",B230400} #endif So of course my new buad rate never got added to the list. It's a fairly ugly problem, because the valud baud rates are set in #defines in termios.h and Python wants an array of them, and of course there's no way (that I know of) to enumerate defines and get a list of those that start with "B" followed by numbers (and, of course, for all I know there's some other BXXXXX define somewhere that is not intended to indicate an allowed baud rate). The real solution would be to use the OpenBSD UFTDI baud rate generator and update Python's termios.c to avoid the list of valid baud rates and have it just ask the serial port to set the requested rate and report back any error. But that requires far more than my meager skills. I just added another hardcoded #ifdef to Python's termios.c and it is all working now. -Brooks From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 17:36:29 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97B016A475 for ; Thu, 25 Oct 2007 17:36:29 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8C33413C4CE for ; Thu, 25 Oct 2007 17:36:29 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 612D21E002E for ; Thu, 25 Oct 2007 10:36:29 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15066-05 for ; Thu, 25 Oct 2007 10:36:28 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id DA1261E002D for ; Thu, 25 Oct 2007 10:36:28 -0700 (PDT) Message-ID: <4720D41C.4030606@miralink.com> Date: Thu, 25 Oct 2007 10:36:28 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <471F85DD.1070906@miralink.com> <20071025035454.GA28174@eos.sc1.parodius.com> In-Reply-To: <20071025035454.GA28174@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Oct 25 10:36:29 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4720d41d104852362839998 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Subject: Re: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 17:36:29 -0000 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html > > Thanks for the pointers. I am currently unable to access www.freebsd.org for some reason. It appears that I get a timeout trying to retrieve anything from the web site. Other folks in my office seem to have the same problem, yet I can access the web site from my home network. Any ideas what the connection issues might be? Sean From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 17:56:54 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F63D16A419; Thu, 25 Oct 2007 17:56:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9E16A13C4B8; Thu, 25 Oct 2007 17:56:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 216066962-1834499 for multiple; Thu, 25 Oct 2007 13:59:12 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l9PHuYL9023899; Thu, 25 Oct 2007 13:56:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 25 Oct 2007 13:50:55 -0400 User-Agent: KMail/1.9.6 References: <0F0DFE71-3A14-4A3D-BBF8-6FAEA9245F3A@gid.co.uk> <20071024.150639.63053209.imp@bsdimp.com> In-Reply-To: <20071024.150639.63053209.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710251350.56208.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 25 Oct 2007 13:56:35 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: ivoras@freebsd.org Subject: Re: USB vs PAE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 17:56:54 -0000 On Wednesday 24 October 2007 05:06:39 pm M. Warner Losh wrote: > In message: > Bob Bishop writes: > : Hi, > : > : On 23 Oct 2007, at 20:45, Ivan Voras wrote: > : > : > Bob Bishop wrote: > : >> Hi, > : >> > : >> The whole USB kit and caboodle is nodevice'd out in the PAE > : >> config. Can > : >> anyone give a succinct summary of what needs fixing? (EVERYTHING! > : >> is an > : >> acceptable answer) Thanks > : > > : > I'm running USB keyboard and mouse under PAE without problems. Don't > : > know about other USB devices. AFAIK everything that is 64-bit clean > : > (i.e. works on AMD64 and other architectures) should work ok with PAE, > : > so try compiling it in and see for yourself. > : > : > : Yes. Keyboard and umass (CDROM and memory stick) seem to work here on > : 6.2R. Thanks! > > In 6.x the big problem is busdma support. USB doesn't use it quite > right, which means that buffers that it uses must be in the lower > 4GB. If not, then it won't work. > > Current does proper scatter/gather, so should work without issue. Ah, ok. How does USB on 6.x work with amd64? Also, any idea when the USB stuff will be MFC'd to 6? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 18:26:08 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0718616A41A for ; Thu, 25 Oct 2007 18:26:08 +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 DF37513C4B5 for ; Thu, 25 Oct 2007 18:26:07 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 4D4B71CC030; Thu, 25 Oct 2007 11:26:04 -0700 (PDT) Date: Thu, 25 Oct 2007 11:26:04 -0700 From: Jeremy Chadwick To: Sean Bruno Message-ID: <20071025182604.GA72040@eos.sc1.parodius.com> References: <471F85DD.1070906@miralink.com> <20071025035454.GA28174@eos.sc1.parodius.com> <4720D41C.4030606@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4720D41C.4030606@miralink.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 18:26:08 -0000 On Thu, Oct 25, 2007 at 10:36:28AM -0700, Sean Bruno wrote: > Thanks for the pointers. I am currently unable to access www.freebsd.org > for some reason. It appears that I get a timeout trying to retrieve > anything from the web site. Other folks in my office seem to have the same > problem, yet I can access the web site from my home network. > > Any ideas what the connection issues might be? Someone else recently reported similar on their FreeBSD box, and the fix for them was to disable RFC1323 TCP window scaling. Try this: sysctl -w net.inet.tcp.rfc1323=0 If this works for you, you can place the variable=value portion in /etc/sysctl.conf for application upon start-up. If your FreeBSD box acts as a gateway for the rest of your office, and the then that might explain why others are seeing the same thing. Otherwise the problem is likely not FreeBSD-related, and you should talk to your office networking folks to find out what's going on. -- | 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-hackers@FreeBSD.ORG Thu Oct 25 18:56:43 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F260316A418 for ; Thu, 25 Oct 2007 18:56:43 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id B2D4F13C481 for ; Thu, 25 Oct 2007 18:56:43 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 98FD01E002E for ; Thu, 25 Oct 2007 11:56:43 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03701-10 for ; Thu, 25 Oct 2007 11:56:42 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id A6CD91E002D for ; Thu, 25 Oct 2007 11:56:42 -0700 (PDT) Message-ID: <4720E6EA.50409@miralink.com> Date: Thu, 25 Oct 2007 11:56:42 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <471F85DD.1070906@miralink.com> <20071025035454.GA28174@eos.sc1.parodius.com> <4720D41C.4030606@miralink.com> <20071025182604.GA72040@eos.sc1.parodius.com> In-Reply-To: <20071025182604.GA72040@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Oct 25 11:56:43 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4720e6eb161488539715904 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=-0.000, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Subject: FreeBSD.org website problems was: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 18:56:44 -0000 Jeremy Chadwick wrote: > On Thu, Oct 25, 2007 at 10:36:28AM -0700, Sean Bruno wrote: > >> Thanks for the pointers. I am currently unable to access www.freebsd.org >> for some reason. It appears that I get a timeout trying to retrieve >> anything from the web site. Other folks in my office seem to have the same >> problem, yet I can access the web site from my home network. >> >> Any ideas what the connection issues might be? >> > > Someone else recently reported similar on their FreeBSD box, and the fix > for them was to disable RFC1323 TCP window scaling. Try this: > > sysctl -w net.inet.tcp.rfc1323=0 > > If this works for you, you can place the variable=value portion in > /etc/sysctl.conf for application upon start-up. > > If your FreeBSD box acts as a gateway for the rest of your office, and > the then that might explain why others are seeing the same thing. > Otherwise the problem is likely not FreeBSD-related, and you should > talk to your office networking folks to find out what's going on. > > Interesting, what is _really_ going on with the website? I was having connectivity issues to www.freebsd.org from linux, netbsd and freebsd machines. After adjusting the appropriate value for linux, netbsd and freebsd the issues seem to clear. Under linux adjust: net.ipv4.tcp_window_scaling Under FreeBSD/NetBSD adjust: net.inet.tcp.rfc1323 Sean From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 20:37:25 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB06416A421 for ; Thu, 25 Oct 2007 20:37:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id B018413C4B7 for ; Thu, 25 Oct 2007 20:37:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 25 Oct 2007 13:37:25 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D70B51267FC; Thu, 25 Oct 2007 13:37:24 -0700 (PDT) Message-ID: <4720FEA1.2040505@elischer.org> Date: Thu, 25 Oct 2007 13:37:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <47205B91.80408@FreeBSD.org> <867ilbtsrc.fsf@ds4.des.no> In-Reply-To: <867ilbtsrc.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Sergey Matveychuk Subject: Re: How to get a kthread ID? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 20:37:25 -0000 Dag-Erling Smørgrav wrote: > Sergey Matveychuk writes: >> Is there a possibility to get a kthread ID inside a kthread? >> Just like pthread_self(3). > > curthread? well that's a thread pointer, but you are I guess correct because from there you can get to curthread->td_tid which is the thread ID. > > DES From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 19:02:35 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93BFA16A418 for ; Thu, 25 Oct 2007 19:02:35 +0000 (UTC) (envelope-from lab@mailgate.gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 0558513C4B8 for ; Thu, 25 Oct 2007 19:02:34 +0000 (UTC) (envelope-from lab@mailgate.gta.com) Received: (qmail 89716 invoked by uid 1000); 25 Oct 2007 18:35:53 -0000 Date: 25 Oct 2007 18:35:53 -0000 Message-ID: <20071025183553.89715.qmail@mailgate.gta.com> From: Larry Baird To: freebsd-hackers@freebsd.org In-Reply-To: <107924.235636.88011@localhost> User-Agent: tin/1.5.9-20010723 ("Chord of Souls") (UNIX) (FreeBSD/4.10-RELEASE (i386)) X-Mailman-Approved-At: Thu, 25 Oct 2007 21:02:32 +0000 Cc: Jeremy Chadwick Subject: Re: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 19:02:35 -0000 In article <107924.235636.88011@localhost> you wrote: > On Wed, Oct 24, 2007 at 10:50:21AM -0700, Sean Bruno wrote: >> I have a drive that contains two seperate bootable partitions(ad0s1a and >> ad0s2a). The boot device selection menu(boot0?) appears to only be able to >> support 9600 8N1. I wanted to run the serial console at 115200, but I >> currently have to switch to 9600 if I need to change the boot device. Is >> there a way around this that I can't see? Could I get around this with a >> BIOS that can do console redirection? > > Which "boot device selection menu" are you referring to? "boot0?" > implies you don't know. Here's the difference: > > boot0 is this stage: > > F1 FreeBSD > F5 Drive 1 > Default: F1 > > boot2 is this stage: > >>> FreeBSD/i386 BOOT > Default: 0:ad(0,a)/boot/loader > boot: > > If you want serial capability in boot0, you should set > BOOT_COMCONSOLE_SPEED=115200 in your make.conf. After you do that, > you'll need to rebuild the boot blocks. The procedure for doing that is > step 4 of Section 24.6.5.2 in the Handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html The BIOS call that boot.S is using (int 0x14) only supports a maximum speed of 9600. To get speeds greater that 9600, it needs to do the I/O itself. There used to be a version floating around that did this. I have a extemely modified version that uses this method. If you can't find a version that does this, let mw know and I'll see if I can cleanup what I have. Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 21:14:43 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97EEC16A418 for ; Thu, 25 Oct 2007 21:14:43 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 62CBB13C48D for ; Thu, 25 Oct 2007 21:14:43 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 3BB941E002E; Thu, 25 Oct 2007 14:14:43 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02746-08; Thu, 25 Oct 2007 14:14:42 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 67DB71E002D; Thu, 25 Oct 2007 14:14:42 -0700 (PDT) Message-ID: <47210742.9000801@miralink.com> Date: Thu, 25 Oct 2007 14:14:42 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Larry Baird References: <20071025183553.89715.qmail@mailgate.gta.com> In-Reply-To: <20071025183553.89715.qmail@mailgate.gta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Oct 25 14:14:43 2007 X-DSPAM-Confidence: 0.7829 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 47210743246161214584237 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick Subject: Re: Serial speed for boot device selection prompt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 21:14:43 -0000 >> If you want serial capability in boot0, you should set >> BOOT_COMCONSOLE_SPEED=115200 in your make.conf. After you do that, >> you'll need to rebuild the boot blocks. The procedure for doing that is >> step 4 of Section 24.6.5.2 in the Handbook: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html >> > > The BIOS call that boot.S is using (int 0x14) only supports a maximum > speed of 9600. To get speeds greater that 9600, it needs to do the > I/O itself. There used to be a version floating around that did this. > I have a extemely modified version that uses this method. If you can't > find a version that does this, let mw know and I'll see if I can cleanup > what I have. > > Larry > > Thanks, that at least confirmed my theory while reviewing the assembly that boot.S was not capable of more than 9600. I'll look around first, but may request the code later. Sean From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 25 21:16:57 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F0816A420 for ; Thu, 25 Oct 2007 21:16:57 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id BEE4613C4B6 for ; Thu, 25 Oct 2007 21:16:56 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l9PLGtge028345; Thu, 25 Oct 2007 23:16:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l9PLGoH2075481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 23:16:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l9PLGnt5068450; Thu, 25 Oct 2007 23:16:49 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l9PLGn51068449; Thu, 25 Oct 2007 23:16:49 +0200 (CEST) (envelope-from ticso) Date: Thu, 25 Oct 2007 23:16:49 +0200 From: Bernd Walter To: Brooks Talley Message-ID: <20071025211649.GB46533@cicely12.cicely.de> References: <20071025010133.GV46533@cicely12.cicely.de> <31953061.121491193327568521.JavaMail.root@zmail.illuminati.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31953061.121491193327568521.JavaMail.root@zmail.illuminati.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: Getting nonstandard serial baud rates w/FTDI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 21:16:57 -0000 On Thu, Oct 25, 2007 at 08:52:48AM -0700, Brooks Talley wrote: > Thanks to everyone who applied. The OpenBSD approach to setting UFTDI baud rates is definitely superior. > > However, the root of my problem turned out to be Python. Even with the new baud rate hardcoded in the UFTDI kernel module and manually added to termios.h, Python was refusing to admit that it was a valid baud rate. > > The issue is that Python (2.5.1) compiles its own termios interface module, which builds a list of allowed baud rates from the defines in termios.h. Python's termios.c does something like this: > > include > termios_constants[] = { > {"B300",B300}, > {"B1200",B1200}, > {"B2400",B2400}, > . > . > . > #ifdef B115200 > {"B115200",B115200} > #endif > #ifdef B230400 > {"B230400",B230400} > #endif > > So of course my new buad rate never got added to the list. It's a fairly ugly problem, because the valud baud rates are set in #defines in termios.h and Python wants an array of them, and of course there's no way (that I know of) to enumerate defines and get a list of those that start with "B" followed by numbers (and, of course, for all I know there's some other BXXXXX define somewhere that is not intended to indicate an allowed baud rate). > > The real solution would be to use the OpenBSD UFTDI baud rate generator and update Python's termios.c to avoid the list of valid baud rates and have it just ask the serial port to set the requested rate and report back any error. But that requires far more than my meager skills. I just added another hardcoded #ifdef to Python's termios.c and it is all working now. I will take care about the ftdi driver within the next days, but will not MFC it until the releases are done. The python part is left for someone else. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 17:29:30 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF4B316A418 for ; Fri, 26 Oct 2007 17:29:30 +0000 (UTC) (envelope-from tching@arraynetworks.net) Received: from Exchange.arraynetworks.net (mail.arraynetworks.net [12.22.49.71]) by mx1.freebsd.org (Postfix) with ESMTP id B08C913C465 for ; Fri, 26 Oct 2007 17:29:30 +0000 (UTC) (envelope-from tching@arraynetworks.net) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Oct 2007 10:17:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: boot loader Thread-Index: AcgX9BYOwwIeZguiSZG6kId9lVRURw== From: "Thomas Ching" To: X-Mailman-Approved-At: Fri, 26 Oct 2007 17:33:29 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 17:29:31 -0000 Hi, I am trying to do the following with existing systems running 4.5. I'd really appreciate if anyone has any hints, pointers, opinions, or even just "you should talk to this other group" for me. =20 1. Existing system: FreeBSD 4.5 based with FreeBSD boot loader (boot0) in MBR 2. I am trying to install a new software based on either FreeBSD 6.2 or later, or LINUX with the following restrictions: a. No console access b. No media access other than serial port, Ethernet, existing HD with 4.5 installed (i.e. NO CD/DVD, floppy, USB....etc) 3. The hard drive (1) has enough empty space (currently not partitioned/used) so I can create a new slice to put the new OS/software in and boot from the new OS, but I am not sure how I can achieve that. =20 So I guess my questions are: =20 1. Is it possible for me to boot of FreeBSD 4.5 and "run an installation over Ethernet/ftp"? 2. Is it possible for me to "tar up a FreeBSD 6.2" partition, put onto the 4.5 disk (new partition) then "sysinstall" (or something like that) to make the system boot from the new partition? 3. How would I even start thinking about doing the same with LINUX as the new OS? :-) =20 Any information you can provide is highly appreciated. Thanks !!=20 =20 Thomas =20 From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 21:13:47 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D339116A418 for ; Fri, 26 Oct 2007 21:13:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 875C013C4A6 for ; Fri, 26 Oct 2007 21:13:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23442 invoked by uid 399); 26 Oct 2007 20:47:06 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 26 Oct 2007 20:47:06 -0000 X-Originating-IP: 127.0.0.1 Date: Fri, 26 Oct 2007 13:47:04 -0700 (PDT) From: Doug Barton To: Thomas Ching In-Reply-To: Message-ID: References: X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 21:13:47 -0000 FYI, for future reference this question is really more appropriate for freebsd-questions@freebsd.org. On Fri, 26 Oct 2007, Thomas Ching wrote: > Hi, I am trying to do the following with existing systems running 4.5. > I'd really appreciate if anyone has any hints, pointers, opinions, or > even just "you should talk to this other group" for me. > > 1. Existing system: FreeBSD 4.5 based with FreeBSD boot loader > (boot0) in MBR You're not planning to dual-boot anything, right? Just boot and run one operating system? > 2. I am trying to install a new software based on either FreeBSD > 6.2 or later, or LINUX with the following restrictions: > > a. No console access > b. No media access other than serial port, Ethernet, > existing HD with 4.5 installed (i.e. NO CD/DVD, floppy, USB....etc) > > 3. The hard drive (1) has enough empty space (currently not > partitioned/used) so I can create a new slice to put the new OS/software > in and boot from the new OS, but I am not sure how I can achieve that. You definitely can't use any of the standard installation methods without console access. You also can't dual boot without console access. > 1. Is it possible for me to boot of FreeBSD 4.5 and "run an > installation over Ethernet/ftp"? No. > 2. Is it possible for me to "tar up a FreeBSD 6.2" partition, put > onto the 4.5 disk (new partition) then "sysinstall" (or something like > that) to make the system boot from the new partition? You could theoretically install onto a local system, tar it up, then unpack it in the unused partition on your remote machine, yes. However in order to set the new slice bootable you'd have to then use the disk editor, and if you get even one thing the tiniest bit wrong, you've bricked it. If I were in your position I'd do this with make world, but that's going to take a looooooooong time because you'll first have to update to the latest RELENG_4, then 5-stable, then 6-stable (at least) and then if you don't want to have to do this again for a while I'd update to 7.0 when it is released. The other alternative is to bribe someone who is local to do the installation for you, which all things considered would probably be easier all around. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 21:17:09 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70D2816A417 for ; Fri, 26 Oct 2007 21:17:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id E83C613C4A7 for ; Fri, 26 Oct 2007 21:17:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so838044nfb for ; Fri, 26 Oct 2007 14:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=Nn75QlrVj9o0Cr/ljyn8Y7j2vH1Xk4iPgcoCdhDcwr0=; b=JWaRunSslmI6C0MgYS0yUWFB5ocqQZ14LiiV+pQs/WkRaJKdxGn5lfxNBQXzVjmWUjH5kVC7MyiONXdNN6iZISL6165fM7TGfKtNjkpSGq4hJxUHqGE6TVqm8qxS4EG/L3cX5WIHFiMo1vOwPT/lbyQidXCXWw3SSHkNoUUBi4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=VQYZpkEvdwcETtdnxx0B45VRVq7++e0eGIXhndeaqCCgTe3Iq7UnZFIuHhZGMT3p5NdYuopUjQuhJ89ArmR4OkZsDFESlRpNAombmOBZKDlzWUJpXWYuoo7c9ZZUABjwI2padyttJaS4cmGCeCjT7BHrEMGI0FdviOoHi3z1/4M= Received: by 10.86.36.11 with SMTP id j11mr2517749fgj.1193431936354; Fri, 26 Oct 2007 13:52:16 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.174.64]) by mx.google.com with ESMTPS id g8sm7739359muf.2007.10.26.13.52.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2007 13:52:15 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l9QKT47A008649; Fri, 26 Oct 2007 22:29:04 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l9QKT4vd008648; Fri, 26 Oct 2007 22:29:04 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Fri, 26 Oct 2007 22:29:04 +0200 From: Ulrich Spoerlein To: Clifton Royston Message-ID: <20071026202904.GC1482@roadrunner.spoerlein.net> Mail-Followup-To: Clifton Royston , FreeBSD hackers list References: <20071014193813.GA2677@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071014193813.GA2677@lava.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD hackers list Subject: Re: Creating install CD with custom ports - how to massage INDEX file? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 21:17:09 -0000 On Sun, 14.10.2007 at 09:38:14 -1000, Clifton Royston wrote: > I've been building my own install CDs for a planned multi-server > upgrade to 6.2Rp8 and ran into one last stumbling block this week. I > understand the process a lot better now than I did a few years back > when I was doing it for 4.8, but I'm still having trouble pieceing > together how I get my own package set onto the CD in a usable form. > > I built the release with NO_PORTS=yes, because I'm building the ports > from my own CVS tree, which is a tightly pared down subset of the > /usr/ports CVS, plus locally written software in ports format. I've > ensured that the tree is closed under the dependency operation (to use > some math jargon) - essentially that means that my ports subset includes > all the dependencies of every port I'm including and all of *its* > run/build dependencies in the tree, even if not being built. That > allows the dependency graph to be calculated and the INDEX-6 file to be > built properly. > > However, copying the INDEX-6 file and my private packages hierarchy > into the CD build area doesn't work; I can read them off the CD > post-install but sysinstall doesn't see them. It's not a disaster > because I can always put the CD back in after booting and install them > then, but it would would be nice to get them all zapped in with the > initial install. I'm doing something similar. I work with a complete ports tree and then build a subset of interesting packages (plus required packages). The problem with sysinstall is, that it requires the number of the CD, where the package resides. Since I make sure, that my ISO never exceeds one volume I decided to drop the volume number from the sysinstall INDEX altogether Here's the Makefile targets creating the packages and ISO packages: # prepare lots of stuff # ... .for pkg in ${PACKAGES} chroot ${TLR} /create_packages.sh ${pkg} .endfor ## Build a stripped down INDEX file, usually done by /usr/ports/Tools/scripts/release/scrubindex.pl, yet it would ## require manual handling. We assume all dependant packages are there (we just built them after all), so we simply ## take all lines where we have a package for it. ## First we grab the name of the indexfile (can be INDEX, INDEX-5, INDEX-6, etc.), then we loop over all entries of ## of the global index and test -f if the package was built, if so, we print the line. (INDEX=`sh -c "chroot ${TLR} /usr/bin/make -f /usr/ports/Makefile -V INDEXFILE"`; \ awk -F"|" '{if (system("test -f ${TLR}/usr/ports/packages/All/" $$1 ".tbz") == 0) print $$0}' \ ${TLR}/usr/ports/$$INDEX > ${TFR}/packages/INDEX) cd ${TFR} && find -d packages | cpio --quiet -dumpl ${TRR}/R/cdrom/disc1 iso: # Remove CD_VOLUME from the cdrom.inf, we only ship 'disc 0' echo "CD_VERSION = ${RELEASE}" > ${TRR}/R/cdrom/disc1/cdrom.inf mkisofs -r -J -V '${RELEASE}' -publisher 'Distribution made for 1822direkt' -o ${TFR}.iso \ -b boot/cdboot -no-emul-boot ${TRR}/R/cdrom/disc1 md5 ${TFR}.iso > ${TFR}.iso.md5 hth, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 21:21:07 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C85216A418 for ; Fri, 26 Oct 2007 21:21:07 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id A9D9A13C4AA for ; Fri, 26 Oct 2007 21:21:06 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so838716nfb for ; Fri, 26 Oct 2007 14:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=ZdEiFCLRXLCN5FIFE6Wk7KDUAG5IunaKXwTOMKsXGRI=; b=CRBZDace0JveS9203+yQRZXHi84/W+i8jp+v1ZtUKBb231qdAlI3F7Mi5Vy/+1hxkynDOlpIelZx+hh4x6iDyGS9PKIqqdZeyN80oSvb0jRFDsMwxnUf8pD786xJ0r4sY+40g41uD6d7SJChYaeHYmJt1x4z/5b8dV0D3dZseNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=fPmx9QFHKxpoFkfmBqu37hBEaCi2oUJb0j+TOgacLDXV+UUlYFhxEyYhr6UfzCVktwsVeOBn5m1jNLOsFudYsiDO5JUjp6egNSm+vTorxO5cWMYizm1mVIw+iDKh1u922Hc9twNc6L8C45924C3W+m2caJWPAV8hXmpujayTy5Y= Received: by 10.86.65.11 with SMTP id n11mr2531608fga.1193431937394; Fri, 26 Oct 2007 13:52:17 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.174.64]) by mx.google.com with ESMTPS id g8sm7739359muf.2007.10.26.13.52.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2007 13:52:16 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l9QKc7e6008833; Fri, 26 Oct 2007 22:38:07 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l9QKc6TO008832; Fri, 26 Oct 2007 22:38:06 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Fri, 26 Oct 2007 22:38:05 +0200 From: Ulrich Spoerlein To: Clifton Royston Message-ID: <20071026203805.GD1482@roadrunner.spoerlein.net> Mail-Followup-To: Clifton Royston , soralx@cydem.org, freebsd-hackers@freebsd.org References: <20071014203736.GB2677@lava.net> <20071014160520.07ad521d@soralx> <20071014231917.GB29405@lava.net> <20071024014737.GE19536@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071024014737.GE19536@lava.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: A more tenuously package-related question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 21:21:07 -0000 On Tue, 23.10.2007 at 15:47:40 -1000, Clifton Royston wrote: > I got a request to summarize my results to the list, so here's a > quick write-up. Based on my preliminary testing last week, pkg_replace > looks like the right tool for package-based server maintenance. Interesting, as I'm facing the same problem. > One invaluable feature which was not immediately obvious from the > description and man page is that if you give it a list of binary > packages on the command line, it orders the updates correctly based on > the dependencies between those packages. Does it take the dependency graph from the already installed packages? > Thus updating my test server with the recently security-fixed > versions of the packages for png and ImageMagick was just a matter of > executing: > sudo pkg_replace png-1.2.22.tbz ImageMagick-nox11-6.3.5.10_1.tbz > in my package repository directory. Where is your package repository? Does pkg_replace work by simply setting PKG_PATH=ftp://foo/bar ? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 20:56:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5ADD16A417 for ; Fri, 26 Oct 2007 20:56:44 +0000 (UTC) (envelope-from tching@arraynetworks.net) Received: from Exchange.arraynetworks.net (mail.arraynetworks.net [12.22.49.71]) by mx1.freebsd.org (Postfix) with ESMTP id A4E0D13C4B2 for ; Fri, 26 Oct 2007 20:56:44 +0000 (UTC) (envelope-from tching@arraynetworks.net) Content-class: urn:content-classes:message Date: Fri, 26 Oct 2007 13:56:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: boot loader Thread-Index: AcgYEWYohIfy8K8xQDOYPQY6jslLTQAAHGGw From: "Thomas Ching" To: "Doug Barton" X-Mailman-Approved-At: Fri, 26 Oct 2007 21:32:49 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: RE: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 20:56:44 -0000 Thanks Doug for your help. I am cc'ing freebsd-questions and I will drop freebsd-hackers from the next email on. A few things: 1. it's not a requirement, but I'd like to keep the current partitions (therefore dual boot) just in case anything goes wrong. 2. can you point me to more readings regarding how I might perform the following: " However in order to set the new slice bootable you'd have to then use the disk editor" 3. I guess what you are saying is that if I go with the upgrade path release 4->5->6, I can do "in place" upgrade over network. Again appreciate your help. Thomas=20 -----Original Message----- From: Doug Barton [mailto:dougb@FreeBSD.org]=20 Sent: Friday, October 26, 2007 1:47 PM To: Thomas Ching Cc: freebsd-hackers@freebsd.org Subject: Re: boot loader FYI, for future reference this question is really more appropriate for=20 freebsd-questions@freebsd.org. On Fri, 26 Oct 2007, Thomas Ching wrote: > Hi, I am trying to do the following with existing systems running 4.5. > I'd really appreciate if anyone has any hints, pointers, opinions, or > even just "you should talk to this other group" for me. > > 1. Existing system: FreeBSD 4.5 based with FreeBSD boot loader > (boot0) in MBR You're not planning to dual-boot anything, right? Just boot and run one=20 operating system? > 2. I am trying to install a new software based on either FreeBSD > 6.2 or later, or LINUX with the following restrictions: > > a. No console access > b. No media access other than serial port, Ethernet, > existing HD with 4.5 installed (i.e. NO CD/DVD, floppy, USB....etc) > > 3. The hard drive (1) has enough empty space (currently not > partitioned/used) so I can create a new slice to put the new OS/software > in and boot from the new OS, but I am not sure how I can achieve that. You definitely can't use any of the standard installation methods without=20 console access. You also can't dual boot without console access. > 1. Is it possible for me to boot of FreeBSD 4.5 and "run an > installation over Ethernet/ftp"? No. > 2. Is it possible for me to "tar up a FreeBSD 6.2" partition, put > onto the 4.5 disk (new partition) then "sysinstall" (or something like > that) to make the system boot from the new partition? You could theoretically install onto a local system, tar it up, then=20 unpack it in the unused partition on your remote machine, yes. However in=20 order to set the new slice bootable you'd have to then use the disk=20 editor, and if you get even one thing the tiniest bit wrong, you've=20 bricked it. If I were in your position I'd do this with make world, but that's going to take a looooooooong time because you'll first have to update to the=20 latest RELENG_4, then 5-stable, then 6-stable (at least) and then if you don't want to have to do this again for a while I'd update to 7.0 when it=20 is released. The other alternative is to bribe someone who is local to do the=20 installation for you, which all things considered would probably be easier=20 all around. hope this helps, Doug --=20 This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 23:15:41 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3C7A16A419; Fri, 26 Oct 2007 23:15:40 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id C78C613C48E; Fri, 26 Oct 2007 23:15:40 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id EAAD028BB2; Fri, 26 Oct 2007 17:48:10 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7AF2061C68; Fri, 26 Oct 2007 17:48:10 -0500 (CDT) Date: Fri, 26 Oct 2007 17:48:10 -0500 From: "Matthew D. Fuller" To: Doug Barton Message-ID: <20071026224810.GN50315@over-yonder.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.16-fullermd.4 (2007-06-09) Cc: freebsd-hackers@freebsd.org, Thomas Ching Subject: Re: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 23:15:41 -0000 On Fri, Oct 26, 2007 at 01:47:04PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: > > You could theoretically install onto a local system, tar it up, then > unpack it in the unused partition on your remote machine, yes. > However in order to set the new slice bootable you'd have to then > use the disk editor, and if you get even one thing the tiniest bit > wrong, you've bricked it. Actually, you may be able to talk the 4.x loader into loading and booting off the created 6.x partition. That would save disk editing. Still, you only get one shot at it without console access. But you said you have a serial port, so you could stuff a serial console on it, which gives you lots more safety. I moved a couple 4.x machines to 6.x remotely with just a serial console, and I think I only ended up needing to use the serial console on one machine where I didn't properly nudge the loader to look in the right place. Sure was glad to have it there, though. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 26 22:54:33 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DC6316A418; Fri, 26 Oct 2007 22:54:33 +0000 (UTC) (envelope-from tching@arraynetworks.net) Received: from Exchange.arraynetworks.net (mail.arraynetworks.net [12.22.49.71]) by mx1.freebsd.org (Postfix) with ESMTP id 4487613C4CB; Fri, 26 Oct 2007 22:54:33 +0000 (UTC) (envelope-from tching@arraynetworks.net) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2007 15:54:27 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20071026224810.GN50315@over-yonder.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: boot loader Thread-Index: AcgYIk/8lYe9+bFsTv+b87J0x1tzVQAAJhfg From: "Thomas Ching" To: "Matthew D. Fuller" , "Doug Barton" X-Mailman-Approved-At: Fri, 26 Oct 2007 23:35:23 +0000 Cc: freebsd-hackers@freebsd.org Subject: RE: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2007 22:54:33 -0000 Thanks for sharing your thoughts/opinions; I am glad that there are at least some things that I can try. Thomas -----Original Message----- From: Matthew D. Fuller [mailto:fullermd@over-yonder.net]=20 Sent: Friday, October 26, 2007 3:48 PM To: Doug Barton Cc: Thomas Ching; freebsd-hackers@freebsd.org Subject: Re: boot loader On Fri, Oct 26, 2007 at 01:47:04PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: >=20 > You could theoretically install onto a local system, tar it up, then > unpack it in the unused partition on your remote machine, yes. > However in order to set the new slice bootable you'd have to then > use the disk editor, and if you get even one thing the tiniest bit > wrong, you've bricked it. Actually, you may be able to talk the 4.x loader into loading and booting off the created 6.x partition. That would save disk editing. Still, you only get one shot at it without console access. But you said you have a serial port, so you could stuff a serial console on it, which gives you lots more safety. I moved a couple 4.x machines to 6.x remotely with just a serial console, and I think I only ended up needing to use the serial console on one machine where I didn't properly nudge the loader to look in the right place. Sure was glad to have it there, though. --=20 Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 27 14:42:25 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4243F16A418; Sat, 27 Oct 2007 14:42:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id EBCC213C480; Sat, 27 Oct 2007 14:42:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Ilmrn-0007Lq-EU; Sat, 27 Oct 2007 16:42:23 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: hackers@FreeBSD.org In-reply-to: References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> Comments: In-reply-to Danny Braniss message dated "Thu, 18 Oct 2007 13:35:11 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Oct 2007 16:42:23 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org Subject: Re: dump problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 14:42:25 -0000 to recap: dump will get stuck/deadlock. found the problem, but no solution in sight :-( dump creates 3 processess and syncs with them via kill(2) - don't want to go into the merrits of this - and sometimes: - the signal is received even if it's blocked. - the signal is not received. - it happens mainly on > 2way multicore hosts. all this seems to be a problem in the kernel. need some insight please! thanks, danny PS: sorry for the shortness of the message, anything else will get me to start %$#@! dump, specially tape.c. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 27 16:54:32 2007 Return-Path: Delivered-To: FreeBSD-Hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08EB16A57D for ; Sat, 27 Oct 2007 16:54:32 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from VM01.Vitsch.net (vm01.vitsch.net [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 651BB13C4AA for ; Sat, 27 Oct 2007 16:54:31 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([217.166.176.2]) by VM01.Vitsch.net (8.13.8/8.13.8) with ESMTP id l9RGqIMo014500; Sat, 27 Oct 2007 18:52:18 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) Received: from [192.168.46.217] (j29235.upc-j.chello.nl [24.132.29.235]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id l9RGrtdB031791; Sat, 27 Oct 2007 18:53:56 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: "M. Warner Losh" Date: Sat, 27 Oct 2007 18:53:44 +0200 User-Agent: KMail/1.9.7 References: <200710222211.51590.Danovitsch@vitsch.net> <20071024.151513.-713548131.imp@bsdimp.com> In-Reply-To: <20071024.151513.-713548131.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710271853.44167.Danovitsch@vitsch.net> Cc: FreeBSD-Hackers@freebsd.org Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 16:54:32 -0000 Hi Warner, On Wednesday 24 October 2007 23:15:13 you wrote: > In message: <200710222211.51590.Danovitsch@vitsch.net> > > "Daan Vreeken [PA4DAN]" writes: > : But what I haven't found is a description of exactly what the kernel is > : missing to allow floating point operations to be done there. > > FPU context is assumed to only change in user processes. You'd have > to fix the FPU state saving code to cope with it changing everywhere, > or you'd have to explicitly put the goo to save/restore it around the > FP you want to do in the kernel. Issei Suzuki pointed me into the right direction in his reply. (The following text is an exact copy of the reply I sent to Issei, but I'll just copy it here to show the code) If I understand the npx code correctly, there are 2 options when the kernel arrives at hardclock() : o The current process is using the FPU (fpcurthread != NULL) o The current process hasn't used the FPU (yet) since it has been switched to (fpcurthread == NULL) In the first case, FPU instructions can be used and will not result in a trap, but we should save/restore the FPU state before using them so userland doesn't get confused. In the last case FPU instructions result in a trap, so we need stop/start_emulating(), but as no one is using the FPU, there is no need to save/restore it's state. With this in mind I've come up with the following code : At the start of the function : // check FPU state on entry if (PCPU_GET(fpcurthread) != NULL) { // someone is using the FPU // save it's state and remember to put it back later restore = 1; fpusave(&fpu_state); } else { // no one is using the FPU // enable use of FPU instructions, no need to save it's state restore = 0; stop_emulating(); } // init FPU state every time we get here, as we don't know who has // been playing with it in between calls fninit(); control = __INITIAL_NPXCW__; fldcw(&control); Then we do some floating point arithmetic. And at the end of the function : // restore FPU state before we leave if (restore) { // restore FPU registers to what they were fpurstor(&fpu_state); } else { // no one was using the FPU, so re-enable the FPU trap start_emulating(); } With this code trap-22 has stopped to trigger within my function. The FPU instructions still seem to be executed correctly in my function and when adding a couple of printf()'s I can see it fpusave() and fpurstor() when interrupting a userland process that uses the FPU. Does this look reasonable to everyone? > You had also make sure that the > floating point exceptions never trap, since trapping inside the kernel > has very limited support. You'll have to fix the problems that this > would cause, or force the FPU into a state where it never traps. According to 'man feenableexcept'. All exceptions are masked by default. > Sure, maybe you can make it happen. However, you are in for much pain > and suffering. The kernel isn't a general purpose computing > environment, and trying to pretend it is will lead to suffering. > Especially inside of an interrupt handler. It is less bad if this is > an ithread, but could be quite painful if you want to do this inside > of a fast interrupt handler to reduce latency. > > I'd recommend strongly against trying this and revaluate your true > need for FP in the kernel. From your other mail, you don't seem open > to this answer. If you don't take it, you are setting yourself up for > a lot of pain and suffering. It is your choice, however. I'm building a system much like Matlab xPC : http://www.techsource.com.sg/pdts/pdt_details.asp?pcid=2&pscid=19 This system will be used by multiple people for various different control systems. All of them know how to write basic C code, but none of them has enough programming knowledge to write decent integer math. I'm not a big fan of using floating point operations inside of the kernel, but if I can't offer this, I'll have to write all of their control loop routines myself. (And I really don't have time for that.) The machines this will run on are dedicated to the control system. I can live with the machines spending 99% of their CPU time in kernel mode. Userland will only be used as a nice way to interface with the control loop and to transfer data and logs in/out. Userland will almost never use FP instructions. In the test I've done so far with the above code, FPU save/restore only has to be at most a couple of times a second. > If you do manage to pull it of, I'd be very interested in see what things I > didn't know to warn you about... Feel free to punch holes in the code I've written. I'm still rather new to the FPU internals, so it's highly possible that I've overseen something. So far testing shows that the code is working OK. Thanks, -- Daan From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 27 17:39:01 2007 Return-Path: Delivered-To: FreeBSD-Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 742CC16A418 for ; Sat, 27 Oct 2007 17:39:01 +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 249FC13C4A3 for ; Sat, 27 Oct 2007 17:39:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9RHaAX1093387; Sat, 27 Oct 2007 11:36:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 27 Oct 2007 11:36:58 -0600 (MDT) Message-Id: <20071027.113658.-2014464451.imp@bsdimp.com> To: Danovitsch@vitsch.net From: "M. Warner Losh" In-Reply-To: <200710271853.44167.Danovitsch@vitsch.net> References: <200710222211.51590.Danovitsch@vitsch.net> <20071024.151513.-713548131.imp@bsdimp.com> <200710271853.44167.Danovitsch@vitsch.net> 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: FreeBSD-Hackers@FreeBSD.org Subject: Re: Floating point in interrupt handler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 17:39:01 -0000 In message: <200710271853.44167.Danovitsch@vitsch.net> "Daan Vreeken [PA4DAN]" writes: : Hi Warner, : : On Wednesday 24 October 2007 23:15:13 you wrote: : > In message: <200710222211.51590.Danovitsch@vitsch.net> : > : > "Daan Vreeken [PA4DAN]" writes: : > : But what I haven't found is a description of exactly what the kernel is : > : missing to allow floating point operations to be done there. : > : > FPU context is assumed to only change in user processes. You'd have : > to fix the FPU state saving code to cope with it changing everywhere, : > or you'd have to explicitly put the goo to save/restore it around the : > FP you want to do in the kernel. : : Issei Suzuki pointed me into the right direction in his reply. (The following : text is an exact copy of the reply I sent to Issei, but I'll just copy it : here to show the code) : If I understand the npx code correctly, there are 2 options when the kernel : arrives at hardclock() : : o The current process is using the FPU (fpcurthread != NULL) : o The current process hasn't used the FPU (yet) since it has been switched to : (fpcurthread == NULL) : In the first case, FPU instructions can be used and will not result in a trap, : but we should save/restore the FPU state before using them so userland : doesn't get confused. In the last case FPU instructions result in a trap, so : we need stop/start_emulating(), but as no one is using the FPU, there is no : need to save/restore it's state. : : With this in mind I've come up with the following code : : : At the start of the function : : // check FPU state on entry : if (PCPU_GET(fpcurthread) != NULL) { : // someone is using the FPU : // save it's state and remember to put it back later : restore = 1; : fpusave(&fpu_state); : } else { : // no one is using the FPU : // enable use of FPU instructions, no need to save it's state : restore = 0; : stop_emulating(); : } : // init FPU state every time we get here, as we don't know who has : // been playing with it in between calls : fninit(); : control = __INITIAL_NPXCW__; : fldcw(&control); : : Then we do some floating point arithmetic. : : And at the end of the function : : // restore FPU state before we leave : if (restore) { : // restore FPU registers to what they were : fpurstor(&fpu_state); : } else { : // no one was using the FPU, so re-enable the FPU trap : start_emulating(); : } : : With this code trap-22 has stopped to trigger within my function. The FPU : instructions still seem to be executed correctly in my function and when : adding a couple of printf()'s I can see it fpusave() and fpurstor() when : interrupting a userland process that uses the FPU. : Does this look reasonable to everyone? My concern here would be to make sure that your code doesn't migrate from one CPU to another. Other than that, I think it is OK. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 27 22:45:25 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84A1616A421; Sat, 27 Oct 2007 22:45:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 8BEC813C4A7; Sat, 27 Oct 2007 22:45:24 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4723BF87.20302@FreeBSD.org> Date: Sun, 28 Oct 2007 00:45:27 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> In-Reply-To: <471EE4D9.5080307@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 22:45:25 -0000 Alexey Popov wrote: > Hi > > Kris Kennaway wrote: >>>>> So I can conclude that FreeBSD has a long standing bug in VM that >>>>> could be triggered when serving large amount of static data (much >>>>> bigger than memory size) on high rates. Possibly this only applies >>>>> to large files like mp3 or video. >>>> It is possible, we have further work to do to conclude this though. >>> I forgot to mention I have pmc and kgmon profiling for good and bad >>> times. But I have not enough knowledge to interpret it right and not >>> sure if it can help. >> pmc would be useful. > pmc profiling attached. Sorry for the delay, I was travelling last weekend and it took a few days to catch up. OK, the pmc traces do seem to show that it's not a lock contention issue. That being the case I don't think the fact that different servers perform better is directly related. In my tests multithreaded web servers don't seem to perform well anyway. There is also no evidence of a VM problem. What your vmstat and pmc traces show is that your system really isn't doing much work at all, relatively speaking. There is also still no evidence of a disk problem. In fact your disk seems to be almost idle in both cases you provided, only doing between 1 and 10 operations per second, which is trivial. In the "good" case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the "good" and "bad" times, since it only provides counters and an average rate over the uptime of the system. What there is evidence of is an interrupt aliasing problem between em and USB: irq16: uhci0 1464547796 1870 irq64: em0 1463513610 1869 This is a problem on some intel systems. Basically each em0 interrupt is also causing a bogus interrupt to the uhci0 device too. This will be causing some overhead and might be contributing to the UMA problems. I am not sure if it is the main issue, although it could be. It is mostly serious when both irqs run under Giant, because they will both fight for it every time one of them interrupts. That is not the case here but it could be other bad scenarios too. You could try disabling USB support in your kernel since you dont seem to be using it. Kris