From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 7 15:20:07 2009 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 17EFE1065670 for ; Mon, 7 Dec 2009 15:20:07 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id CF61D8FC19 for ; Mon, 7 Dec 2009 15:20:06 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 5F1467E853; Mon, 7 Dec 2009 06:20:05 -0900 (AKST) From: Mel Flynn To: freebsd-hackers@freebsd.org Date: Mon, 7 Dec 2009 16:20:03 +0100 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; i386; ; ) References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <867htduvwh.fsf@ds4.des.no> <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> In-Reply-To: <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200912071620.03371.mel.flynn+fbsd.hackers@mailing.thruhere.net> Cc: Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 07 Dec 2009 15:20:07 -0000 On Thursday 26 November 2009 18:11:10 Linda Messerschmidt wrote: > I did not mean to suggest that we were asking for help solving a > problem with squid rotation. I provided that information as > background to discuss what we observed as a potential misbehavior in > the new VM superpages feature, in the hope that if there is a problem > with the new feature, we can help find/resolve it or, if this is > working as intended, hopefully gain some insight as to what's going > on. I tend to agree with this, though I don't know the nitty gritty of the implementation, it seems that: a) superpages aren't copied efficiently (at all?) on fork and probably other workloads b) vfork is encouraged for memory intensive applications, yet: BUGS This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork() as it will, in that case, be made synonymous to fork(2). So is this entire problem eliminated when system sharing mechanisms are in place and vfork considered the temporary work around or is copying of superpages a problem that remains? -- Mel From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 7 17:15:03 2009 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 B1144106566C for ; Mon, 7 Dec 2009 17:15:03 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 80D5E8FC16 for ; Mon, 7 Dec 2009 17:15:03 +0000 (UTC) Received: (qmail 86904 invoked by uid 1000); 7 Dec 2009 16:48:22 -0000 Date: Mon, 7 Dec 2009 08:48:22 -0800 From: "Mahlon E. Smith" To: freebsd-hackers@freebsd.org Message-ID: <20091207164821.GA22924@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Fwd: ZFS and jailed environments -- best practice? 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, 07 Dec 2009 17:15:03 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ repost from -questions in the hopes of generating some discussion! ] ----- Forwarded message from "Mahlon E. Smith" ----- Date: Wed, 25 Nov 2009 15:43:10 -0800 =46rom: "Mahlon E. Smith" To: questions@freebsd.org Subject: ZFS and jailed environments -- best practice? I've been playing with mixing up ZFS and jailed environments under 8.0RC, and I've hit a point where I'm just kind of wondering how everyone else is doing it. I wanted to do this to take advantage of delegated administration -- I want users inside a jail to be able to control snapshot/rollback in their own homedir. I'll break this up into what I did to get it working (I can't seem to find a good step by step out there yet), and where I think I'm running into what could be potential trouble. First off, sysctl variables. security.jail.enforce_statfs=3D0 security.jail.mount_allowed=3D1 vfs.usermount=3D1 I've always run jails with with enforce_statfs=3D1 or enforce_statfs=3D2. I honestly don't see why that wouldn't work for ZFS stuff too, but in the interests of following instructions (the zfs man page), I set it to 0. Next, the 'zfs' dev node needs to be accessible from inside the jail. So I created an /etc/devfs.rules file with the following: host# cat /etc/devfs.rules=20 [zfsenable=3D10] add path 'zfs' unhide=20 =2E..and added the ruleset to the jail config in rc.conf: jail_zfstest_devfs_ruleset=3D"zfsenable" So far so good, the jail gets a /dev/zfs, and I can issue zfs commands. I get 'no datasets available' from within the jail, which is exactly what I'd expect. So, tank/jails/jail1 is a ZFS volume, and I want tank/jails/jail1/home to be under the control of the jail, and mounted at /home inside of it. I stop the jail and unmount the home volume. host# zfs umount tank/jails/jail1/home Then enabled 'jailed mode' on the volume, and start the jail back up. host# zfs set jailed=3Don tank/jails/jail1/home In the host, lets just say the JID is 8. host# /sbin/zfs jail 8 tank/jails/jail1/home =46rom that point, it appears that the host thinks that volume is not under its own control. (good!) host# zfs mount tank/jails/jail1/home cannot mount 'tank/jails/jail1/home': dataset is exported to a local zo= ne Whew, okay. Back into the jail. jail# zfs set mountpoint=3D/home tank/jails/jail1/home jail# zfs mount -a jail# zfs allow -s @homedir create,clone,mount,rollback,snapshot,send,r= eceive,compression,checksum,quota,readonly,destroy tank/jails/jail1/home jail# zfs allow -u user1 @homedir tank/jails/jail1/home/user1 =2E.. and by god, it works. Yay! Here are the weird parts, or parts that make me feel like I'm not doing something correctly. 1) From the host now -- I've got two /home partitions mounted when displaying a 'df'. They -appear- to do the right thing... /home on the host is correct when getting a listing, and /home in the jail is also correct. But I can't help but feel like this is asking for trouble, or will eat the delicious data at some point. 2) What the heck is the procedure for automating this on boot? Roll your own? The JID shuffles, of course. I could easily whip up some zfs jail `jls | awk '/jail1/ { print $2 }' ... junk, but where would I put something like that? jail_afterstart0=3D"" seems to load things in the context of the jail, not the host. And then I'd have to set canmount=3Dnoauto on that home volume, and mount it manually from within the jail via some startup script? Seems... like a pain in the ass for what is otherwise a pretty blissful setup. Really, I'm not sure what's right, what's stable, and what won't make me totally regret doing this later. :) Advice, discussion, or pointers elsewhere are all appreciated! -Mahlon -- Mahlon E. Smith =20 http://www.martini.nu/contact.html ----- End forwarded message ----- --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFLHTHV1bsjBDapbeMRAmQwAKCMXZIIX9uDOq1O6rigQTNEGAMq9gCgpW5S y5yUISqOFm1mHzVcSDzF+sI= =nj8S -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 8 14:08:42 2009 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 B7D231065695 for ; Tue, 8 Dec 2009 14:08:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 044AF8FC16 for ; Tue, 8 Dec 2009 14:08:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA28873; Tue, 08 Dec 2009 16:08:36 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B1E5DE4.1010702@icyb.net.ua> Date: Tue, 08 Dec 2009 16:08:36 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Mel Flynn References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <867htduvwh.fsf@ds4.des.no> <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> <200912071620.03371.mel.flynn+fbsd.hackers@mailing.thruhere.net> In-Reply-To: <200912071620.03371.mel.flynn+fbsd.hackers@mailing.thruhere.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 08 Dec 2009 14:08:42 -0000 on 07/12/2009 17:20 Mel Flynn said the following: > b) vfork is encouraged for memory intensive applications, yet: > BUGS > This system call will be eliminated when proper system sharing mechanisms > are implemented. Users should not depend on the memory sharing semantics > of vfork() as it will, in that case, be made synonymous to fork(2). > > So is this entire problem eliminated when system sharing mechanisms are in > place and vfork considered the temporary work around or is copying of > superpages a problem that remains? I think no :) This section is either already removed or is going to be. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 8 18:35:38 2009 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 19833106566B for ; Tue, 8 Dec 2009 18:35:38 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB7F8FC16 for ; Tue, 8 Dec 2009 18:35:37 +0000 (UTC) Received: by bwz5 with SMTP id 5so4654449bwz.3 for ; Tue, 08 Dec 2009 10:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=J51LmRd/8doTzfT6664twWPhaFdIVT8ly6q9hSQwYnQ=; b=cZq28GL7RIy7GQ0S/Jjqyo7OwKNzGfWeZXXAqM0cepVXraiyFcoayMpvPd6dfBUN2b b7om0nv/f/lArSOIMsgoLZ9cB1/zxieCfQvKbpPcoR2kFJiI7+7B18ukTSyw4ESW0EN6 9YAdExNTo9s2E/c+JaWndyfxBkQyUW9FCMU10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=xEWgcn5mKRlbk7puI93v97juHBVEEzIEw96eV4m2BKMW85ht1YQpBV8sERsU42TBEz aMgw45BZXZF7E+LKEgdC+vg+R2n+JYajWUkZdmrlMzfg5Y8uyvjEWhACGm/xei4p/GGg 78EOrQ6IG9/LOptAzdHT2pXu71wO1W45yAVd4= Received: by 10.204.150.77 with SMTP id x13mr1222063bkv.100.1260295805601; Tue, 08 Dec 2009 10:10:05 -0800 (PST) Received: from mbp-gige.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id 19sm2585687fkr.18.2009.12.08.10.10.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 10:10:04 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Dec 2009 20:10:02 +0200 Message-Id: <47D1BC12-848C-4C5B-9B4B-EFD6057B8B7B@gmail.com> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Tue, 08 Dec 2009 18:45:25 +0000 Subject: accessing geom stats from the kernel 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, 08 Dec 2009 18:35:38 -0000 Hello, I have a small four SATA bay machine (HP ex470) which I'm using as a NAS = with FreeBSD+ZFS. It has four dual color leds for each SATA bay (red and blue + purple if = lit together) Which I'm controlling either from userspace by writing data to the = enclosure management ioport, or recently I've made a kernel module which uses the led(4) framework = and exports the leds as device nodes in /dev. What I'm wondering now is, if there is an easy way to access geom/disk = stats from in kernel and make the leds flash only during disk activity, without having to do it in userspace? =20 -- Regards, Nikolay Denev From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 8 23:43:23 2009 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 48F33106568D for ; Tue, 8 Dec 2009 23:43:23 +0000 (UTC) (envelope-from ltsampros@upnet.gr) Received: from kane.otenet.gr (kane.otenet.gr [83.235.67.31]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA8C8FC1A for ; Tue, 8 Dec 2009 23:43:21 +0000 (UTC) Received: from bifteki.lan (ppp-94-66-125-153.home.otenet.gr [94.66.125.153]) by kane.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id nB8NFWun016202 for ; Wed, 9 Dec 2009 01:15:32 +0200 Received: from bifteki.lan (localhost [127.0.0.1]) by bifteki.lan (8.14.3/8.14.3) with ESMTP id nB8NC4UY001133 for ; Wed, 9 Dec 2009 01:12:04 +0200 (EET) (envelope-from ltsampros@bifteki.lan) Received: (from ltsampros@localhost) by bifteki.lan (8.14.3/8.14.3/Submit) id nB8NC4JB001132; Wed, 9 Dec 2009 01:12:04 +0200 (EET) (envelope-from ltsampros@bifteki.lan) From: Leonidas Tsampros To: freebsd-hackers@freebsd.org Mail-Followup-To: freebsd-hackers@freebsd.org Date: Wed, 09 Dec 2009 01:12:04 +0200 Message-ID: <86d42pjc1n.fsf@bifteki.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: old/unupdated xterm entries in termcap db 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, 08 Dec 2009 23:43:23 -0000 --=-=-= Hello, Recently, I tried to enable/configure 256 color support under xterm (and/or other terminal emulators). The application for which I wanted 256 color support is emacs (although this does not matter). Normally, all I'd have to do to get this done is: export TERM=xterm-256color Of course, this didn't work because the termcap file installed had the following entry: xterm-256color|xterm alias 3:tc=xterm-xfree86: which points to xterm-xfree86, which in turn points to xterm-basic. This last entry (if you look at the termcap file) has 8 colors defined. (I think the parameter in question is 'Co' but I guess other parameters are needed as well). The above stands true about xterm-16color and xterm-88color too. After searching a bit, I noticed that xterm entries in FreeBSD's termcap file were copied directly from the termcap file that ships with xterm (but most probably from a very old xterm version). So, I removed all the related entries (lines 2932 to 3090) and I inserted at their place an exact copy of the contents of the termcap that ships with xterm-251. This seems to work correctly for me, and I managed to get 256 color support. However, I have not done any extensive testing for the other changed/updated entries that this change brought. Attached you can find a patch for share/termcap/termcap.src. Why aren't these entries updated in order to match the ones that ship with xterm? Am I missing something? Regards Leonidas --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=updated-termcap.diff Content-Description: sync termcap with xterm-251 --- termcap.src.~1.156.2.1.~ 2009-08-03 08:13:06.000000000 +0000 +++ termcap.src 2009-12-08 22:20:14.000000000 +0000 @@ -2803,29 +2803,29 @@ # # $XFree86: xc/programs/xterm/termcap,v 3.28 2001/01/17 23:46:39 dawes Exp $ # -xterm-xfree86|XFree86 xterm:\ - :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\ - :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:\ - :k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\ - :@7=\EOF:@8=\EOM:kI=\E[2~:\ - :kh=\EOH:kP=\E[5~:kN=\E[6~:\ - :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:tc=xterm-basic: +xf|xterm-new|modern xterm:\ + :*6=\EOF:@7=\EOF:F1=\E[23~:F2=\E[24~:K2=\EOE:Km=\E[M:\ + :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\ + :k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kH=\EOF:kI=\E[2~:\ + :kN=\E[6~:kP=\E[5~:kd=\EOB:kh=\EOH:kl=\EOD:kr=\EOC:ku=\EOA:\ + :tc=xterm-basic: # # This chunk is used for building the VT220/Sun/PC keyboard variants. -xterm-basic|xterm common (XFree86):\ - :li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:\ - :is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:\ - :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:\ - :UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:\ - :ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:\ - :im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:kb=^H:\ - :sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:\ - :eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:\ - :md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:\ - :ti=\E[?1049h:te=\E[?1049l:vi=\E[?25l:ve=\E[?25h:\ - :ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm: +xb|xterm-basic|modern xterm common:\ + :am:bs:km:mi:ms:ut:xn:AX:\ + :Co#8:co#80:kn#12:li#24:pa#64:\ + :AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\ + :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=\E(B:al=\E[L:\ + :as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ + :cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:\ + :ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\ + :kD=\E[3~:kb=^H:ke=\E[?1l\E>:ks=\E[?1h\E=:le=^H:md=\E[1m:\ + :me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:\ + :rc=\E8:rs=\E[!p\E[?3;4l\E[4l\E>:sc=\E7:se=\E[27m:sf=^J:\ + :so=\E[7m:sr=\EM:st=\EH:te=\E[?1049l:ti=\E[?1049h:\ + :ue=\E[24m:up=\E[A:us=\E[4m:ve=\E[?12l\E[?25h:vi=\E[?25l:vs=\E[?12;25h: -# The xterm-xfree86 description has all of the features, but is not completely +# The xterm-new description has all of the features, but is not completely # compatible with vt220. If you are using a Sun or PC keyboard, set the # sunKeyboard resource to true: # + maps the editing keypad @@ -2834,136 +2834,164 @@ # + maps numeric keypad "+" to ",". # + uses DEC-style control sequences for the application keypad. # -xterm-vt220|xterm emulating vt220:\ - :kH=\E[4~::@7=\E[4~:*6=\E[4~:kh=\E[1~:Km=\E[M:tc=xterm-basic: +vt|xterm-vt220|xterm emulating vt220:\ + :*6=\E[4~:@7=\E[4~:K2=\EOu:Km=\E[M:kH=\E[4~:kh=\E[1~:\ + :tc=xterm-basic: -xterm-24|xterms|vs100|24x80 xterm:\ - :li#24:\ - :tc=xterm: -xterm-65|65x80 xterm:\ - :li#65:tc=xterm: -xterm-bold|xterm with bold for underline:\ - :so=\E[7m:us=\E[1m:tc=xterm: -xterm-boldso|xterm with bold for standout:\ - :se=\E[m:so=\E[1m:tc=xterm: -xterm-mono|monochrome xterm:\ - :kn#20:\ - :st@:ut@:Co@:NC@:op@:AB@:AF@:pa@:Sf@:Sb@:tc=xterm: +v1|xterm-24|xterms|vs100|24x80 xterm:\ + :li#24:tc=xterm-old: +v2|xterm-65|65x80 xterm:\ + :li#65:tc=xterm-old: +vb|xterm-bold|xterm with bold for underline:\ + :so=\E[7m:us=\E[1m:tc=xterm-old: +vB|xterm-boldso|xterm with bold for standout:\ + :se=\E[m:so=\E[1m:tc=xterm-old: +vm|xterm-mono|monochrome xterm:\ + :ut@:\ + :Co@:NC@:kn#20:pa@:\ + :AB@:AF@:Sb@:Sf@:op@:st@:tc=xterm-old: # # Alternate terminal description that "works" for interactive shells such as # tcsh and bash. -xterm-noapp|xterm with cursor keys in normal mode:\ - :kl=\E[D:kd=\E[B:kr=\E[C:ku=\E[A:ks=\E=:ke=\E>:ti@:te@:tc=xterm: +xn|xterm-noapp|xterm with cursor keys in normal mode:\ + :kd=\E[B:ke=\E>:kl=\E[D:kr=\E[C:ks=\E=:ku=\E[A:te@:ti@:\ + :tc=xterm: +# +# This should work for the commonly used "color xterm" variations (XFree86 +# xterm, color_xterm, nxterm, rxvt). Note that it does not set 'bce', so for +# XFree86 and rxvt, some applications that use colors will be less efficient, +# and in a few special cases (with "smart" optimization) the wrong color will +# be painted in spots. +vc|xterm-color|generic "ANSI" color xterm:\ + :Co#8:NC@:pa#64:\ + :AB=\E[4%dm:AF=\E[3%dm:ac=:op=\E[m:tc=xterm-r6: # # These aliases are for compatibility with the terminfo; termcap cannot provide -# the extra features, but termcap applications still want the names. -xterm-16color|xterm alias 1:tc=xterm-xfree86: -xterm-88color|xterm alias 2:tc=xterm-256color: -xterm-256color|xterm alias 3:tc=xterm-xfree86: -xterm-nrc|xterm alias 4:tc=xterm: -xterm-rep|xterm alias 5:tc=xterm: -xterm-xmc|xterm alias 6:sg#1:tc=xterm: +# the extra features such as color initialization, but termcap applications +# still want the names. +x1|xterm-16color|xterm alias:\ + :tc=xterm-new: + +x2|xterm-88color|xterm alias:\ + :Co#88:pa#7744:tc=xterm-256color: + +x3|xterm-256color|xterm alias:\ + :Co#256:pa#32767:\ + :AB=\E[48;5;%dm:AF=\E[38;5;%dm:tc=xterm-new: + +xi|xterm-nrc|xterm alias:\ + :tc=xterm: +xr|xterm-rep|xterm alias:\ + :tc=xterm: +xx|xterm-xmc|xterm alias:\ + :sg#1:tc=xterm: # # An 8-bit description is doable with termcap, but there are probably no # termcap (or BSD curses) applications that are able to use it. -xterm-8bit|xterm terminal emulator 8-bit controls (X Window System):\ - :co#80:li#24:\ - :it#8:am:km:mi:ms:xn:\ - :AL=\233%dL:DC=\233%dP:DL=\233%dM:DO=\233%dB:IC=\233%d@:LE=\233%dD:\ - :RI=\233%dC:UP=\233%dA:ae=^O:al=\233L:as=^N:bl=^G:bt=\233Z:\ - :cd=\233J:ce=\233K:cl=\233H\2332J:cm=\233%i%d;%dH:cr=^M:\ - :cs=\233%i%d;%dr:ct=\2333g:dc=\233P:dl=\233M:do=^J:up=\233A:nd=\233C:\ - :ei=\2334l:ho=\233H:im=\2334h:\ +x8|xterm-8bit|xterm terminal emulator 8-bit controls (X Window System):\ + :am:km:mi:ms:xn:\ + :co#80:it#8:li#24:\ + :AL=\233%dL:DC=\233%dP:DL=\233%dM:DO=\233%dB:IC=\233%d@:\ + :K2=\217y:Km=\233M:LE=\233%dD:RI=\233%dC:UP=\233%dA:\ + :ae=\E(B:al=\233L:as=\E(0:bl=^G:bt=\233Z:cd=\233J:ce=\233K:\ + :cl=\233H\2332J:cm=\233%i%d;%dH:cr=^M:cs=\233%i%d;%dr:\ + :ct=\2333g:dc=\233P:dl=\233M:do=^J:ei=\2334l:ho=\233H:\ + :im=\2334h:\ :is=\E[62"p\E G\233m\233?7h\E>\E7\233?1;3;4;6l\2334l\233r\E8:\ :k1=\23311~:k2=\23312~:k3=\23313~:k4=\23314~:k5=\23315~:\ :k6=\23317~:k7=\23318~:k8=\23319~:k9=\23320~:kD=\2333~:\ :kI=\2332~:kN=\2336~:kP=\2335~:kb=^H:kd=\217B:\ :ke=\233?1l\E>:kh=\2331~:kl=\217D:kr=\217C:ks=\233?1h\E=:\ - :ku=\217A:le=^H:mb=\2335m:md=\2331m:me=\233m^O:mr=\2337m:\ - :rc=\E8:sc=\E7:se=\23327m:sf=^J:so=\2337m:sr=\215:\ - :st=\210:ta=^I:te=\233?1049l:ti=\233?1049h:ue=\23324m:us=\2334m:\ - :vb=\233?5h\233?5l:ve=\233?25h:vi=\233?25l:Km=\233M: -# -xterm-hp|XFree86 xterm with hpterm function keys:\ - :k1=\Ep:k2=\Eq:k3=\Er:k4=\Es:k5=\Et:k6=\Eu:k7=\Ev:k8=\Ew:\ - :kC=\EJ:kD=\EP:@7=\EF:kI=\EQ:kN=\ES:kP=\ET:kh=\Eh:\ - :kd=\EB:kl=\ED:kr=\EC:ku=\EA:tc=xterm-basic: -# -xterm-sco|XFree86 xterm with SCO function keys:\ - :kl=\E[D:kd=\E[B:kr=\E[C:ku=\E[A:@7=\E[F:\ - :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:\ - :k6=\E[R:k7=\E[S:k8=\E[T:k9=\E[U:k;=\E[V:\ - :F1=\E[W:F2=\E[X:F3=\E[Y:F5=\E[a:F6=\E[b:\ - :F7=\E[c:F8=\E[d:F9=\E[e:FA=\E[f:FB=\E[g:\ - :FC=\E[h:FD=\E[i:FE=\E[j:FF=\E[k:\ - :kh=\E[H:kI=\E[L:kN=\E[G:kP=\E[I:ac@:tc=xterm-basic: + :ku=\217A:le=^H:mb=\2335m:md=\2331m:me=\233m:mr=\2337m:\ + :nd=\233C:rc=\E8:sc=\E7:se=\23327m:sf=^J:so=\2337m:sr=\215:\ + :st=\210:ta=^I:te=\233?1049l:ti=\233?1049h:ue=\23324m:\ + :up=\233A:us=\2334m:vb=\233?5h\233?5l:ve=\233?25l\233?25h:\ + :vs=\233?12;25h:vi=\233?25l: +# +hp|xterm-hp|xterm with hpterm function keys:\ + :@7=\EF:k1=\Ep:k2=\Eq:k3=\Er:k4=\Es:k5=\Et:k6=\Eu:k7=\Ev:\ + :k8=\Ew:kC=\EJ:kD=\EP:kI=\EQ:kN=\ES:kP=\ET:kd=\EB:kh=\Eh:\ + :kl=\ED:kr=\EC:ku=\EA:tc=xterm-basic: +# +xS|xterm-sco|xterm with SCO function keys:\ + :@7=\E[F:F1=\E[W:F2=\E[X:F3=\E[Y:F5=\E[a:F6=\E[b:F7=\E[c:\ + :F8=\E[d:F9=\E[e:FA=\E[f:FB=\E[g:FC=\E[h:FD=\E[i:FE=\E[j:\ + :FF=\E[k:ac=:k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:\ + :k6=\E[R:k7=\E[S:k8=\E[T:k9=\E[U:k;=\E[V:kD=\177:kI=\E[L:\ + :kN=\E[G:kP=\E[I:kd=\E[B:kh=\E[H:kl=\E[D:kr=\E[C:ku=\E[A:\ + :tc=xterm-basic: # -xterm-vt52|xterm emulating vt52:\ +v5|xterm-vt52|xterm emulating vt52:\ :bs:\ :co#80:it#8:li#24:\ :ae=\EG:as=\EF:bl=^G:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :\ :cr=^M:do=\EB:ho=\EH:kb=^H:kd=\EB:kl=\ED:kr=\EC:ku=\EA:\ :le=\ED:nd=\EC:nw=^M^J:sf=^J:sr=\EI:ta=^I:up=\EA: # -xterm-sun|xterm with Sun functionkeys:\ - :k1=\E[224z:k2=\E[225z:k3=\E[226z:k4=\E[227z:\ - :k5=\E[228z:k6=\E[229z:k7=\E[230z:k8=\E[231z:\ - :k9=\E[232z:k;=\E[233z:F1=\E[192z:F2=\E[193z:\ - :%1=\E[196z:&8=\E[195z:@0=\E[200z:kI=\E[2z:\ - :kN=\E[222z:kP=\E[216z:kh=\E[214z:kD=^?:\ - :Km=\E[M:@5=\E[197z::@7=\E[220z:\ +xs|xterm-sun|xterm with Sun functionkeys:\ + :%1=\E[196z:&8=\E[195z:@0=\E[200z:@5=\E[197z:@7=\E[220z:\ + :F1=\E[192z:F2=\E[193z:K2=\E[218z:Km=\E[M:k1=\E[224z:\ + :k2=\E[225z:k3=\E[226z:k4=\E[227z:k5=\E[228z:k6=\E[229z:\ + :k7=\E[230z:k8=\E[231z:k9=\E[232z:k;=\E[233z:kD=\E[3z:\ + :kI=\E[2z:kN=\E[222z:kP=\E[216z:kh=\E[214z:\ :tc=xterm-basic: # # vi may work better with this entry, because vi doesn't use insert mode much. -# |xterm-ic|xterm-vi|xterm with insert character instead of insert mode: -xterm-ic|xterm-vi|xterm with insert char:\ - :im@:ei@:mi@:ic=\E[@:IC=\E[%d@:tc=xterm: +# |xterm-ic|xterm-vi|xterm with insert character instead of insert mode:\ +vi|xterm-ic|xterm-vi|xterm with insert char:\ + :mi@:\ + :IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm: # # Compatible with the X11R6.3 xterm -xterm-r6|xterm-old|X11R6 xterm:\ +r6|xterm-r6|xterm-old|X11R6 xterm:\ + :am:bs:km:mi:ms:pt:xn:\ + :co#80:kn#20:li#24:\ + :*6=\E[4~:@0=\E[1~:@7=\E[4~:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\ + :DO=\E[%dB:F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:\ + :F5=\E[28~:F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:\ + :FA=\E[34~:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:\ + :as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\ + :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:eA=\E)0:ei=\E[4l:\ + :ho=\E[H:im=\E[4h:\ :is=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ - :rs=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ - :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:DO=\E[%dB:UP=\E[%dA:\ - :LE=\E[%dD:RI=\E[%dC:al=\E[L:am:bl=^G:\ - :bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:co#80:\ - :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:ho=\E[H:\ - :im=\E[4h:ei=\E[4l:mi:ks=\E[?1h\E=:ke=\E[?1l\E>:@7=\E[4~:kh=\E[1~:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\ - :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\ - :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\ - :kn#20:km:@0=\E[1~:kI=\E[2~:kD=^?:*6=\E[4~:kP=\E[5~:kN=\E[6~:\ - :kb=^H:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:\ - :li#24:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt:\ - :eA=\E)0:as=^N:ae=^O:ml=\El:mu=\Em:\ - :sc=\E7:rc=\E8:sf=\n:so=\E[7m:se=\E[m:sr=\EM:\ - :ti=\E7\E[?47h:te=\E[2J\E[?47l\E8:up=\E[A:us=\E[4m:ue=\E[m:xn: + :kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=^H:kd=\EOB:\ + :ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:\ + :ku=\EOA:md=\E[1m:me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:\ + :rc=\E8:rs=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ + :sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:te=\E[2J\E[?47l\E8:\ + :ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m: # # Compatible with the R5 xterm -xterm-r5|X11R5 xterm X11R5:\ - :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:UP=\E[%dA:\ - :al=\E[L:am:\ - :bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:co#80:\ - :cs=\E[%i%d;%dr:ct=\E[3g:\ - :dc=\E[P:dl=\E[M:\ - :im=\E[4h:ei=\E[4l:mi:\ - :ho=\E[H:\ +r5|xterm-r5|X11R5 xterm X11R5:\ + :am:bs:km:mi:ms:pt:xn:\ + :co#80:kn#4:li#24:\ + :@7=\E[4~:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:\ + :IC=\E[%d@:UP=\E[%dA:al=\E[L:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ + :cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:\ + :ei=\E[4l:ho=\E[H:im=\E[4h:\ :is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ + :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:kb=^H:kd=\EOB:\ + :ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:\ + :ku=\EOA:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:\ :rs=\E>\E[?1;3;4;5;6l\E[4l\E[?7h\E[m\E[r\E[2J\E[H:\ - :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:kb=^H:kd=\EOB:ke=\E[?1l\E>:\ - :kl=\EOD:km:kn#4:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:\ - :@7=\E[4~:kh=\E[1~:\ - :li#24:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt:\ - :sc=\E7:rc=\E8:sf=\n:so=\E[7m:se=\E[m:sr=\EM:\ - :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:\ - :up=\E[A:us=\E[4m:ue=\E[m:xn: + :sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:te=\E[2J\E[?47l\E8:\ + :ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m: +# +# Customization begins here. +x0|xterm-xfree86|xterm terminal emulator (XFree86):\ + :tc=xterm-new: # # This is the only entry which you should have to customize, since "xterm" # is widely used for a variety of incompatible terminal emulations including # color_xterm and rxvt. -xterm|xterm-color|X11 terminal emulator:\ - :ti@:te@:tc=xterm-xfree86: +v0|xterm|X11 terminal emulator:\ + :tc=xterm-new: # :tc=xterm-r6: + + + # dtterm termcap entry - Obtained from Xinside's CDE with permission # from Thomas Roell dtterm|dtterm-cde10:\ --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 01:59:39 2009 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 B8CCB106566C; Wed, 9 Dec 2009 01:59:39 +0000 (UTC) (envelope-from prvs=159455d173=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 29E088FC08; Wed, 9 Dec 2009 01:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260323325; x=1260928125; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=L0h3TmbHaxUDpePu+5ouURxiOimnipnPMn GpSL2rg+4=; b=S/IFR+BtCXykmGr9jDo+E79eQgygMfj3BUu9BONokSeqyUITFr leJdGZrWkPXeqKrtJ8e5CRqwmFPBQ1z264UKzERKQikkWFcUSZeDXFceYrbKvthI nWyt1vEcrG80GuboWGf4xXBWpCnS9IRc5JhnlHte+Rk4soezrNMsh6lY0= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 09 Dec 2009 01:48:45 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008820207.msg; Wed, 09 Dec 2009 01:48:44 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 09 Dec 2009 01:48:44 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=159455d173=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> From: "Steven Hartland" To: , Date: Wed, 9 Dec 2009 01:48:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0? 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, 09 Dec 2009 01:59:40 -0000 I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a strange segv which seems to indicate a core library error in _rtld_error. Could this be the case or is the stack just badly corrupted? (gdb) bt #0 0x00000008005577dc in _rtld_error () from /libexec/ld-elf.so.1 #1 0x0000000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 #2 0x0000000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 #3 0x000000080055851b in dladdr () from /libexec/ld-elf.so.1 #4 0x00000008005585f3 in dladdr () from /libexec/ld-elf.so.1 #5 0x000000080055576d in ?? () from /libexec/ld-elf.so.1 #6 0x0000000000000001 in ?? () #7 0x00000000004117f8 in boost::detail::sp_counted_impl_p::dispose (this=0x800768980) at sp_counted_impl.hpp:78 Previous frame inner to this frame (corrupt stack?) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 10:21:37 2009 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 271FD106568D; Wed, 9 Dec 2009 10:21:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 892598FC16; Wed, 9 Dec 2009 10:21:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nB9ALMD1060066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 12:21:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nB9ALM59018491; Wed, 9 Dec 2009 12:21:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nB9ALMuq018490; Wed, 9 Dec 2009 12:21:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Dec 2009 12:21:22 +0200 From: Kostik Belousov To: Steven Hartland Message-ID: <20091209102122.GC43143@deviant.kiev.zoral.com.ua> References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3+nIULlytNYGw3fk" Content-Disposition: inline In-Reply-To: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0? 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, 09 Dec 2009 10:21:37 -0000 --3+nIULlytNYGw3fk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 09, 2009 at 01:48:38AM -0000, Steven Hartland wrote: > I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a= =20 > strange > segv which seems to indicate a core library error in _rtld_error. Could t= his > be the case or is the stack just badly corrupted? >=20 > (gdb) bt > #0 0x00000008005577dc in _rtld_error () from /libexec/ld-elf.so.1 > #1 0x0000000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 > #2 0x0000000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 > #3 0x000000080055851b in dladdr () from /libexec/ld-elf.so.1 > #4 0x00000008005585f3 in dladdr () from /libexec/ld-elf.so.1 > #5 0x000000080055576d in ?? () from /libexec/ld-elf.so.1 > #6 0x0000000000000001 in ?? () > #7 0x00000000004117f8 in=20 > boost::detail::sp_counted_impl_p= ::dispose (this=3D0x800768980) at=20 > sp_counted_impl.hpp:78 > Previous frame inner to this frame (corrupt stack?) You need to rebuild rtld with debugging information. Ideally, all shared objects should have valid debug info. At least, enter src/libexec/rtld-elf and do make obj make depend make all install DEBUG_FLAGS=3D-g --3+nIULlytNYGw3fk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksfeiEACgkQC3+MBN1Mb4h0EwCcD0sCJpM8ZBNnI9/JbwUeCq4S IpsAoPc8iPYbC2CvuKy32Iiq5+8kje6W =0ANi -----END PGP SIGNATURE----- --3+nIULlytNYGw3fk-- From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 11:20:59 2009 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 1F576106568B; Wed, 9 Dec 2009 11:20:59 +0000 (UTC) (envelope-from prvs=159455d173=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8DE8FC17; Wed, 9 Dec 2009 11:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1260357659; x=1260962459; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=oLrsXK3YBUpUKhGoXErAg 7zPMKaRXkWWioHNvzLMJFI=; b=GT1HplvF9iryXWA5q31MIBSKmRSdaxNQwbx30 diYH8cSaTHsunpc/eb1VKhdmiXPqn6xB1hsNwDEgM4TdSn9tgVtyxyq8HZgHiVLd bLLc1Stxnh+d7BcRl7Xvc8xSq5AhJfh2TYvlmz+IeA9kDN7TkzZKtkWJ/GKGyW9A 6soIx0= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 09 Dec 2009 11:20:59 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008832456.msg; Wed, 09 Dec 2009 11:20:58 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 09 Dec 2009 11:20:58 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=159455d173=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <3898B34F179B4BB7917631C532CDF95F@multiplay.co.uk> From: "Steven Hartland" To: "Kostik Belousov" References: <6B44BF0945694D98BC060164D404B5A9@multiplay.co.uk> <20091209102122.GC43143@deviant.kiev.zoral.com.ua> Date: Wed, 9 Dec 2009 11:20:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0? 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, 09 Dec 2009 11:20:59 -0000 ----- Original Message ----- From: "Kostik Belousov" To: "Steven Hartland" Cc: ; Sent: Wednesday, December 09, 2009 10:21 AM Subject: Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0? This is the trace once world had been recompiled with:- CFLAGS=-pipe WITH_CTF=1 DEBUG_FLAGS=-g #0 0x0000000800c95eec in thr_kill () at thr_kill.S:3 #1 0x0000000800b22e9e in _thr_send_sig (thread=0x800f06600, sig=6) at /usr/src/lib/libthr/thread/thr_kern.c:92 #2 0x0000000800b1f878 in _raise (sig=6) at /usr/src/lib/libthr/thread/thr_sig.c:187 #3 0x0000000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #4 0x000000000043b8a7 in Client::threadMain (this=0x800f9cf40) at ext/nginx/HelperServer.cpp:516 #5 0x0000000000411302 in boost::_mfi::mf0::operator() (this=0x7fffffa45ea8, p=0x800f9cf40) at mem_fn_template.hpp:49 #6 0x0000000000411651 in boost::_bi::list1 >::operator(), boost::_bi::list0> (this=0x7fffffa45eb8, f=@0x7fffffa45ea8, a=@0x7fffffa45d7f) at bind.hpp:232 #7 0x0000000000411696 in boost::_bi::bind_t, boost::_bi::list1 > >::operator() (this=0x7fffffa45ea8) at bind_template.hpp:20 #8 0x00000000004116bd in boost::detail::function::void_function_obj_invoker0, boost::_bi::list1 > >, void>::invoke ( function_obj_ptr=@0x7fffffa45ea8) at function_template.hpp:158 #9 0x000000000042e73a in boost::function0 >::operator() (this=0x7fffffa45ea0) at function_template.hpp:825 #10 0x0000000000435760 in oxt::thread::thread_main (func=@0x7fffffa45ea0, data=@0x7fffffa45e90) at thread.hpp:107 #11 0x000000000041310e in boost::_bi::list2 > >, boost::_bi::value > >::operator() >, boost::shared_ptr), boost::_bi::list0> (this=0x800f3ee80, f=@0x800f3ee78, a=@0x7fffffa45f0f) at bind.hpp:289 #12 0x0000000000413196 in boost::_bi::bind_t >, boost::shared_ptr), boost::_bi::list2 > >, boost::_bi::value > > >::operator() (this=0x800f3ee78) at bind_template.hpp:20 #13 0x00000000004131b9 in boost::thread::thread_data >, boost::shared_ptr), boost::_bi::list2 > >, boost::_bi::value > > > >::run (this=0x800f3ee00) at thread.hpp:130 #14 0x0000000000443259 in thread_proxy (param=0x800f3ee00) at ext/boost/src/pthread/thread.cpp:127 #15 0x0000000800b1badd in thread_start (curthread=0x800f06600) at /usr/src/lib/libthr/thread/thr_create.c:288 #16 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffffa46000 Current language: auto; currently asm It seems that in the passenger client threads it calls closeStream which errors when the socket close errors with ENOTCONN virtual void closeStream() { TRACE_POINT(); if (fd != -1) { int ret = syscalls::close(fd); fd = -1; if (ret == -1) { if (errno == EIO) { throw SystemException("A write operation on the session stream failed", errno); } else { throw SystemException("Cannot close the session stream", errno); } } } } This causes it to call abort on the the thread which then crashes the app with the above stack trace, which seems really weird. Anyone got any ideas? Regards steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 11:25:34 2009 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 C68C6106566B for ; Wed, 9 Dec 2009 11:25:34 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBF78FC15 for ; Wed, 9 Dec 2009 11:25:34 +0000 (UTC) Received: from [195.4.92.12] (helo=2.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NIKfk-0001mj-VU; Wed, 09 Dec 2009 12:25:32 +0100 Received: from p57ae1d0a.dip0.t-ipconnect.de ([87.174.29.10]:20289 helo=ernst.jennejohn.org) by 2.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NIKfk-0005XU-L6; Wed, 09 Dec 2009 12:25:32 +0100 Date: Wed, 9 Dec 2009 12:25:32 +0100 From: Gary Jennejohn To: Leonidas Tsampros Message-ID: <20091209122532.2c55aa22@ernst.jennejohn.org> In-Reply-To: <86d42pjc1n.fsf@bifteki.lan> References: <86d42pjc1n.fsf@bifteki.lan> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: old/unupdated xterm entries in termcap db X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 11:25:34 -0000 On Wed, 09 Dec 2009 01:12:04 +0200 Leonidas Tsampros wrote: > Why aren't these entries updated in order to match the > ones that ship with xterm? Am I missing something? > Probably because xterm is under ports and termcap under src and it would not be easy to track changes in ports under src. The only practical way to keep termcap up to date would be for the committer updating the port to also check and update termcap under src. The problem with this is that most ports committers aren't authorized to make commits under src. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 11:29:23 2009 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 05D35106566C for ; Wed, 9 Dec 2009 11:29:23 +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 BD0138FC1C for ; Wed, 9 Dec 2009 11:29:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E8F806D41B; Wed, 9 Dec 2009 11:29:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C7AEF844E9; Wed, 9 Dec 2009 12:29:21 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: gary.jennejohn@freenet.de References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> Date: Wed, 09 Dec 2009 12:29:21 +0100 In-Reply-To: <20091209122532.2c55aa22@ernst.jennejohn.org> (Gary Jennejohn's message of "Wed, 9 Dec 2009 12:25:32 +0100") Message-ID: <86ws0w4c8e.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Leonidas Tsampros , freebsd-hackers@freebsd.org Subject: Re: old/unupdated xterm entries in termcap db 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, 09 Dec 2009 11:29:23 -0000 Gary Jennejohn writes: > Leonidas Tsampros writes: > > Why aren't these entries updated in order to match the ones that > > ship with xterm? Am I missing something? > Probably because xterm is under ports and termcap under src and it > would not be easy to track changes in ports under src. > > The only practical way to keep termcap up to date would be for the > committer updating the port to also check and update termcap under src. > The problem with this is that most ports committers aren't authorized > to make commits under src. That's not an issue - termcaps don't change all that often. We should just import the new definitions. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 11:32:49 2009 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 90507106566B for ; Wed, 9 Dec 2009 11:32:49 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA8B8FC15 for ; Wed, 9 Dec 2009 11:32:49 +0000 (UTC) Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NIKml-0007Rl-VW; Wed, 09 Dec 2009 12:32:47 +0100 Received: from p57ae1d0a.dip0.t-ipconnect.de ([87.174.29.10]:28283 helo=ernst.jennejohn.org) by 7.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NIKml-0003UF-NW; Wed, 09 Dec 2009 12:32:47 +0100 Date: Wed, 9 Dec 2009 12:32:46 +0100 From: Gary Jennejohn To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-ID: <20091209123246.22b9ecc3@ernst.jennejohn.org> In-Reply-To: <86ws0w4c8e.fsf@ds4.des.no> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Leonidas Tsampros , freebsd-hackers@freebsd.org Subject: Re: old/unupdated xterm entries in termcap db X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 11:32:49 -0000 On Wed, 09 Dec 2009 12:29:21 +0100 Dag-Erling Sm__rgrav wrote: > Gary Jennejohn writes: > > Leonidas Tsampros writes: > > > Why aren't these entries updated in order to match the ones that > > > ship with xterm? Am I missing something? > > Probably because xterm is under ports and termcap under src and it > > would not be easy to track changes in ports under src. > > > > The only practical way to keep termcap up to date would be for the > > committer updating the port to also check and update termcap under src. > > The problem with this is that most ports committers aren't authorized > > to make commits under src. > > That's not an issue - termcaps don't change all that often. We should > just import the new definitions. > That's a practical attitude, but it begs the question why it hasn't happened in the past. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 11:42:20 2009 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 3BFCF106566C for ; Wed, 9 Dec 2009 11:42:20 +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 F20538FC08 for ; Wed, 9 Dec 2009 11:42:19 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 2502D6D41B; Wed, 9 Dec 2009 11:42:19 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id ED24B844E9; Wed, 9 Dec 2009 12:42:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: gary.jennejohn@freenet.de References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> Date: Wed, 09 Dec 2009 12:42:18 +0100 In-Reply-To: <20091209123246.22b9ecc3@ernst.jennejohn.org> (Gary Jennejohn's message of "Wed, 9 Dec 2009 12:32:46 +0100") Message-ID: <86skbk4bmt.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Leonidas Tsampros , freebsd-hackers@freebsd.org Subject: Re: old/unupdated xterm entries in termcap db 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, 09 Dec 2009 11:42:20 -0000 Gary Jennejohn writes: > Dag-Erling Sm=C3=B8rgrav writes: > > That's not an issue - termcaps don't change all that often. We should > > just import the new definitions. > That's a practical attitude, but it begs the question why it hasn't > happened in the past. Because what was there worked well enough for most people... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 9 15:16:56 2009 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 E693F1065670 for ; Wed, 9 Dec 2009 15:16:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B83268FC14 for ; Wed, 9 Dec 2009 15:16:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 655CE46B03; Wed, 9 Dec 2009 10:16:56 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 589FC8A020; Wed, 9 Dec 2009 10:16:55 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 9 Dec 2009 09:07:33 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> In-Reply-To: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912090907.33433.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Dec 2009 10:16:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 09 Dec 2009 15:16:57 -0000 On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: > It's not clear to me if this might be a problem with the superpages > implementation, or if squid does something particularly horrible to > its memory when it forks to cause this, but I wanted to ask about it > on the list in case somebody who understands it better might know > whats going on. :-) I talked with Alan Cox some about this off-list and there is a case that can cause this behavior if the parent squid process takes write faults on a superpage before the child process has called exec() then it can result in superpages being fragmented and never reassembled. Using vfork() should prevent this from happening. It is a known issue, but it will probably be some time before it is addressed. There is lower hanging fruit in other areas in the VM that will probably be worked on first. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 00:06:14 2009 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 E51421065672 for ; Thu, 10 Dec 2009 00:06:14 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id CE4038FC08 for ; Thu, 10 Dec 2009 00:06:14 +0000 (UTC) Received: from vesper.usenix.org (vesper.usenix.org [131.106.3.142]) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id nBA03407011510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Dec 2009 16:06:14 -0800 (PST) Message-Id: <8D3813BF-B72D-433A-B947-F7C589DC82CF@usenix.org> From: Lionel Garth Jones To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 9 Dec 2009 16:06:14 -0800 X-Mailer: Apple Mail (2.930.3) X-DCC-Usenix-Metrics: lonestar; whitelist X-Spam-Status: No, score=-1.4 required=6.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on lonestar X-Mailman-Approved-At: Thu, 10 Dec 2009 00:21:42 +0000 Subject: USENIX WebApps '10 Submissions Deadline Approaching 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, 10 Dec 2009 00:06:15 -0000 I'm writing to remind you that the submission deadline for the USENIX Conference on Web Application Development (WebApps '10) is approaching. Please submit your paper titles and abstracts by January 4, 2010, and your complete papers by January 11, 2010. The Call for Papers, with submission guidelines, can be found at http://www.usenix.org/webapps10/cfpb/ WebApps '10 is a new technical conference designed to bring together experts in all aspects of developing and deploying Web applications. Suggested topics related to Web application development include but are not limited to: * Computing substrates and deployment technologies ("cloud computing") * Frameworks for developing Web applications * Client-side toolkits, libraries, and plug-ins * Storage systems * Security issues for Web applications * Management techniques for large-scale Web applications * Languages for Web applications * Scalability issues and techniques * Techniques for creating highly interactive Web applications * Software as a service * Applications that illustrate interesting new features or implementation techniques * Performance measurements of Web applications * Real-time data delivery over the Web * Web services WebApps '10 will take place June 23=9625, 2010, in Boston, MA. I look forward to receiving your submissions! Sincerely, John Ousterhout, Stanford University WebApps '10 Program Chair webapps10chair@usenix.org ------------------------------------------------------------------------ Call for Papers: USENIX Conference on Web Application Development (WebApps '10) June 20=9625, 2010 Boston, MA http://www.usenix.org/webapps10/cfpb Paper abstracts and titles deadline: January 4, 2010 Complete papers submission deadline: January 11, 2010 ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:32:09 2009 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 643601065672 for ; Thu, 10 Dec 2009 09:32:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 411808FC1D for ; Thu, 10 Dec 2009 09:32:09 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id DAA1646B0C; Thu, 10 Dec 2009 04:32:08 -0500 (EST) Date: Thu, 10 Dec 2009 09:32:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: xorquewasp@googlemail.com In-Reply-To: <20091130142950.GA86528@logik.internal.network> Message-ID: References: <20091130142950.GA86528@logik.internal.network> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 09:32:09 -0000 On Mon, 30 Nov 2009, xorquewasp@googlemail.com wrote: > jackd (audio/jack) creates a directory in /tmp with a UNIX domain socket in > it. Clients connect to this socket to communicate with the server. We currently support the sharing of UNIX domain sockets between file system layers on either nullfs or unionfs. In the former case, this is a bug, and in the latter case, it is a feature. The specific nature of the bug is that you can't just copy the socket pointer between layers in the vnode stack without additional reference counting (and other similar state propagation), so if we allowed inter-layer access it would lead to use-after-free panics and similar sorts of problems. This occurs, BTW, because the socket pointer is directly in struct vnode, and not queried by a VOP, which could be forwarded by nullfs down a layer. The fixes here aren't easy, so I would anticipate UNIX domain sockets not working across nullfs layers for some time to come. It's not immediately clear to me which approach is the best way to fix it, since it likely requires UNIX domain sockets to learn about stacked file systems in some form, which will significantly complicate an already complicated relationship. Robert N M Watson Computer Laboratory University of Cambridge > > $ jackd -d oss -r 44100 -p 128 > $ ls -alF /tmp/jack-11001/default > total 4 > drwx------ 2 xw wheel 512 30 Nov 14:19 ./ > drwx------ 3 xw wheel 512 30 Nov 14:19 ../ > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0| > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1| > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2| > srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0= > srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0= > > $ sudo mount_nullfs /tmp/ /jail/k4m/tmp > > In the jail: > > k4m$ ls -alF /tmp/jack-11001/default > drwx------ 2 xw wheel 512 30 Nov 14:19 ./ > drwx------ 3 xw wheel 512 30 Nov 14:19 ../ > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0| > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1| > prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2| > srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0= > srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0= > > k4m$ ktrace jack_showtime > jack server not running? > > k4m$ kdump | grep '/tmp/jack-11001' > 76030 initial thread STRU struct sockaddr { AF_LOCAL, /tmp/jack-11001/default/jack_0 } > 76030 initial thread NAMI "/tmp/jack-11001/default/jack_0" > 76030 initial thread RET connect -1 errno 61 Connection refused > > $ uname -a > FreeBSD viper.internal.network 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > xw > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:43:07 2009 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 BA5FC106566B; Thu, 10 Dec 2009 09:43:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 952B08FC1F; Thu, 10 Dec 2009 09:43:07 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 31BF046B0C; Thu, 10 Dec 2009 04:43:07 -0500 (EST) Date: Thu, 10 Dec 2009 09:43:07 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: <20091130142950.GA86528@logik.internal.network> <20091130150127.GA82188@logik.internal.network> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 09:43:07 -0000 On Mon, 30 Nov 2009, Ivan Voras wrote: >> What's the sane solution, then, when the only method of communication is >> unix domain sockets? > > It is a security problem. I think the long-term solution would be to add a > sysctl analogous to security.jail.param.securelevel to handle this. > > I don't think there is a workaround right now. I'm not sure I agree on the above, hence my comments about nullfs and unionfs. I see nullfs as intended to provide references (possibly masked to read-only) to the same fundamental object, and unionfs to provide independence between different consumers that see objects via different file system mounts. As such, I'd expect UNIX domain sockets to "work" for inter-jail communication when using nullfs, and "not work" when using unionfs. It's simply a property of the implementation of the linkage between VFS and UNIX domain sockets that they are currently both broken (in fact, someone tried to "fix" it with union mounts recenty, running into the use-after-free bugs I mentioned, but also breaking the semantics in my view). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:44:38 2009 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 534FE106566B; Thu, 10 Dec 2009 09:44:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA018FC27; Thu, 10 Dec 2009 09:44:38 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D5F5846B06; Thu, 10 Dec 2009 04:44:37 -0500 (EST) Date: Thu, 10 Dec 2009 09:44:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Linda Messerschmidt In-Reply-To: <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> Message-ID: References: <20091130142950.GA86528@logik.internal.network> <20091130150127.GA82188@logik.internal.network> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 09:44:38 -0000 On Tue, 1 Dec 2009, Linda Messerschmidt wrote: > On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras wrote: >>> What's the sane solution, then, when the only method of communication >>> is unix domain sockets? >> >> It is a security problem. I think the long-term solution would be to add a >> sysctl analogous to security.jail.param.securelevel to handle this. > > Out of curiosity, why is allowing accessing to a Unix domain socket in a > filesystem to which a jail has explicitly been allowed access more or less > secure than allowing access to a file or a devfs node in a filesystem to > which a jail has explicitly been allowed access? (I seem to have caught this thread rather late in the game due to being on travel) -- Ivan is wrong about nullfs, it's broken due to a bug, not a feature, and that bug is not present when using a single file system. He's thinking of unionfs semantics, where if it worked it would be a bug. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:47:55 2009 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 A8FB6106568D for ; Thu, 10 Dec 2009 09:47:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1D58FC1B for ; Thu, 10 Dec 2009 09:47:55 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1DF9E46B0C; Thu, 10 Dec 2009 04:47:55 -0500 (EST) Date: Thu, 10 Dec 2009 09:47:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: xorquewasp@googlemail.com In-Reply-To: Message-ID: References: <20091130142950.GA86528@logik.internal.network> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 09:47:55 -0000 On Thu, 10 Dec 2009, Robert Watson wrote: > On Mon, 30 Nov 2009, xorquewasp@googlemail.com wrote: > >> jackd (audio/jack) creates a directory in /tmp with a UNIX domain socket in >> it. Clients connect to this socket to communicate with the server. > > We currently support the sharing of UNIX domain sockets between file system > layers on either nullfs or unionfs. In the former case, this is a bug, and Should read "neither ... nor". Robert N M Watson Computer Laboratory University of Cambridge > in the latter case, it is a feature. > > The specific nature of the bug is that you can't just copy the socket pointer > between layers in the vnode stack without additional reference counting (and > other similar state propagation), so if we allowed inter-layer access it > would lead to use-after-free panics and similar sorts of problems. > > This occurs, BTW, because the socket pointer is directly in struct vnode, and > not queried by a VOP, which could be forwarded by nullfs down a layer. The > fixes here aren't easy, so I would anticipate UNIX domain sockets not working > across nullfs layers for some time to come. It's not immediately clear to me > which approach is the best way to fix it, since it likely requires UNIX > domain sockets to learn about stacked file systems in some form, which will > significantly complicate an already complicated relationship. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> $ jackd -d oss -r 44100 -p 128 >> $ ls -alF /tmp/jack-11001/default >> total 4 >> drwx------ 2 xw wheel 512 30 Nov 14:19 ./ >> drwx------ 3 xw wheel 512 30 Nov 14:19 ../ >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0| >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1| >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2| >> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0= >> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0= >> >> $ sudo mount_nullfs /tmp/ /jail/k4m/tmp >> >> In the jail: >> >> k4m$ ls -alF /tmp/jack-11001/default >> drwx------ 2 xw wheel 512 30 Nov 14:19 ./ >> drwx------ 3 xw wheel 512 30 Nov 14:19 ../ >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-0| >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-1| >> prw-r--r-- 1 xw wheel 0 30 Nov 14:19 jack-ack-fifo-54211-2| >> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_0= >> srwxr-xr-x 1 xw wheel 0 30 Nov 14:19 jack_ack_0= >> >> k4m$ ktrace jack_showtime >> jack server not running? >> >> k4m$ kdump | grep '/tmp/jack-11001' >> 76030 initial thread STRU struct sockaddr { AF_LOCAL, >> /tmp/jack-11001/default/jack_0 } >> 76030 initial thread NAMI "/tmp/jack-11001/default/jack_0" >> 76030 initial thread RET connect -1 errno 61 Connection refused >> >> $ uname -a >> FreeBSD viper.internal.network 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov >> 21 15:02:08 UTC 2009 >> root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> >> xw >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:59:42 2009 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 19A941065670; Thu, 10 Dec 2009 09:59:42 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 734738FC0A; Thu, 10 Dec 2009 09:59:41 +0000 (UTC) Received: by ewy26 with SMTP id 26so3548575ewy.3 for ; Thu, 10 Dec 2009 01:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=2B+NfKU4ECm3O4eoAj75+r3c3Y9R22t3AWZhyr1fCpg=; b=UJAxrAcGz1lvPglKJK/y5eZXCsXSeFW7kDXRTe83z11oTWnKLwR6u5k7Fyd/n7Qemn 9bEBvK8AShprZliZH/cWax2tNH1zx7Ci/6K/J/Qeu8mncujCJP3ekJUA4OZ1K+OYoyab mxR3q7537MPSHU7Xgx6DtTBipBrBVlOz4W0yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=HTF5aaxiHSIHi1Y+aPiJ8PVYnl5em0Dvma18P8awA3NBpKJTHY3iLl+W9mLZNo5H2o IE3A9dRjtLUkvo732RtXRmVFsFYaDNbQcl7+yNEXq88VfA5+5UTyPkeJB+YEqhK4t0ov +zr6m1NNiF7y8e2LVnwK7dIun/vgjUQsJGujM= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.86.131 with SMTP id w3mr178698wee.156.1260439180122; Thu, 10 Dec 2009 01:59:40 -0800 (PST) In-Reply-To: References: <20091130142950.GA86528@logik.internal.network> <20091130150127.GA82188@logik.internal.network> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> From: Ivan Voras Date: Thu, 10 Dec 2009 10:59:20 +0100 X-Google-Sender-Auth: e1d29ef32b14371b Message-ID: <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 09:59:42 -0000 2009/12/10 Robert Watson : > > On Tue, 1 Dec 2009, Linda Messerschmidt wrote: > >> On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras wrote: >>>> >>>> What's the sane solution, then, when the only method of communication >>>> is unix domain sockets? >>> >>> It is a security problem. I think the long-term solution would be to ad= d >>> a >>> sysctl analogous to security.jail.param.securelevel to handle this. >> >> Out of curiosity, why is allowing accessing to a Unix domain socket in a >> filesystem to which a jail has explicitly been allowed access more or le= ss >> secure than allowing access to a file or a devfs node in a filesystem to >> which a jail has explicitly been allowed access? > > (I seem to have caught this thread rather late in the game due to being o= n > travel) -- Ivan is wrong about nullfs, it's broken due to a bug, not a > feature, and that bug is not present when using a single file system. =C2= =A0He's > thinking of unionfs semantics, where if it worked it would be a bug. =C2= =A0:-) You have a point there. I was actually thinking more of sysvshm - which doesn't have anything to do with any of the issues here - but has some of the same properties (and is also used by databases - e.g. postgresql, which I'm using daily so it sort of cross-linked). The reason I'd like the nullfs barrier kept is that it (like shm) is used for IPC, and in this case, IPC across different jails (though a file system itself also be used so...). It's not a big issue - I'll also accept that it's the operator's fault if he doesn't know sharing file systems will also share sockets and fifos on it... From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 11:59:12 2009 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 9A561106566C; Thu, 10 Dec 2009 11:59:12 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 711748FC08; Thu, 10 Dec 2009 11:59:12 +0000 (UTC) Received: from [192.168.2.102] (host86-146-40-97.range86-146.btcentralplus.com [86.146.40.97]) by cyrus.watson.org (Postfix) with ESMTPSA id 8F1E146B2D; Thu, 10 Dec 2009 06:59:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> Date: Thu, 10 Dec 2009 11:59:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <42E1ACF8-08AA-46D6-9BF9-65B543059C8F@freebsd.org> References: <20091130142950.GA86528@logik.internal.network> <20091130150127.GA82188@logik.internal.network> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> <9bbcef730912100159s49704c18o1225d060c422b273@mail.gmail.com> To: Ivan Voras X-Mailer: Apple Mail (2.1077) Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: UNIX domain sockets on nullfs still broken? 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, 10 Dec 2009 11:59:12 -0000 On 10 Dec 2009, at 09:59, Ivan Voras wrote: > You have a point there. I was actually thinking more of sysvshm - > which doesn't have anything to do with any of the issues here - but > has some of the same properties (and is also used by databases - e.g. > postgresql, which I'm using daily so it sort of cross-linked). The > reason I'd like the nullfs barrier kept is that it (like shm) is used > for IPC, and in this case, IPC across different jails (though a file > system itself also be used so...). It's not a big issue - I'll also > accept that it's the operator's fault if he doesn't know sharing file > systems will also share sockets and fifos on it... Yeah, what this really comes down to is IPC namespaces. We have a lot, = and they have different properties, unfortunately, leading to different = interactions with Jail, which is largely about namespace subsetting. = Very little is about IPC "between" jails, but rather, whether the IPC = namespace supported easy subsetting/virtualization. In the new vimage = world order, it should now be "easy" to virtualize all of the remaining = IPC namespaces (small matter of code). Robert= From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 12:42:24 2009 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 724E1106566C for ; Thu, 10 Dec 2009 12:42:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 13B918FC1A for ; Thu, 10 Dec 2009 12:42:23 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D76E41CC5D; Thu, 10 Dec 2009 13:42:22 +0100 (CET) Date: Thu, 10 Dec 2009 13:42:22 +0100 From: Ed Schouten To: Alexander Leidinger Message-ID: <20091210124222.GA64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fGuzmz4QlMaBM5pF" Content-Disposition: inline In-Reply-To: <20091210104430.1381356nnmx30okk@webmail.leidinger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.org Subject: Re: old/unupdated xterm entries in termcap db 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, 10 Dec 2009 12:42:24 -0000 --fGuzmz4QlMaBM5pF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Alexander, others, * Alexander Leidinger wrote: > The practical attitude should be coordinated with ed@ (CCed), as he > switched the console in 9-current to be an xterm, and AFAIR it does > not support as much colors as the real xterm. Maybe there is a > reason to not update it. So the idea is to make TERM=3Dxterm use 256 colors? Even though I think having more colors would be awesome, I think many things would break. For example: - As Alexander mentioned, our console driver doesn't support more than 16 (well, 8 on the background) colors. Fortunately our implementation in HEAD smashes down the 256 colors back to 8, so it shouldn't cause any serious artifacts. Just a slight inconvenience. - I know Apple's Terminal.app for example doesn't support 256 colors and badly misinterprets the escape sequences, causing portions of the screen to blink (because the sequence to switch to one of the extended colors contains a 5, which is blink). But if someone is interested in updating the entries in the termcap file to something newer (but no 256 colors), please do! Patches welcome! I will even MFC it! Our current entry for xterm isn't entirely compatible with Apple's Terminal.app either. I've noticed that an Erase Line (EL, ^[[K) with xterm uses the terminal's selected attributes to blank the terminal, while Apple's implementation uses the default terminal attributes (i.e. black background). --=20 Ed Schouten WWW: http://80386.nl/ --fGuzmz4QlMaBM5pF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksg7K4ACgkQ52SDGA2eCwX7SACcCf+8dQCXVUFpY/YIeka8O2cx 8XgAn1kiiuc5HeT/Aha0EZuriUCsRTBB =kBA0 -----END PGP SIGNATURE----- --fGuzmz4QlMaBM5pF-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 12:51:08 2009 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 4BC34106568F for ; Thu, 10 Dec 2009 12:51:08 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by mx1.freebsd.org (Postfix) with ESMTP id D004B8FC13 for ; Thu, 10 Dec 2009 12:51:07 +0000 (UTC) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout4.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NIiU3-0007dZ-AP; Thu, 10 Dec 2009 13:51:03 +0100 Received: from p57ae296f.dip0.t-ipconnect.de ([87.174.41.111]:11915 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NIiU3-0004NS-3z; Thu, 10 Dec 2009 13:51:03 +0100 Date: Thu, 10 Dec 2009 13:51:02 +0100 From: Gary Jennejohn To: Ed Schouten Message-ID: <20091210135102.3434e5cf@ernst.jennejohn.org> In-Reply-To: <20091210124222.GA64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-hackers@FreeBSD.org Subject: Re: old/unupdated xterm entries in termcap db X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 12:51:08 -0000 On Thu, 10 Dec 2009 13:42:22 +0100 Ed Schouten wrote: > But if someone is interested in updating the entries in the termcap file > to something newer (but no 256 colors), please do! Patches welcome! I > will even MFC it! Our current entry for xterm isn't entirely compatible > with Apple's Terminal.app either. I've noticed that an Erase Line (EL, > ^[[K) with xterm uses the terminal's selected attributes to blank the > terminal, while Apple's implementation uses the default terminal > attributes (i.e. black background). > IIRC there was a patch in the original post which may be a good starting point. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 12:59:28 2009 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 34E31106568F for ; Thu, 10 Dec 2009 12:59:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id EE1DE8FC14 for ; Thu, 10 Dec 2009 12:59:27 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 431C51CC5D; Thu, 10 Dec 2009 13:59:27 +0100 (CET) Date: Thu, 10 Dec 2009 13:59:27 +0100 From: Ed Schouten To: Gary Jennejohn Message-ID: <20091210125927.GB64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> <20091210135102.3434e5cf@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rftSBn8ujW1dGbW1" Content-Disposition: inline In-Reply-To: <20091210135102.3434e5cf@ernst.jennejohn.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Leidinger , freebsd-hackers@FreeBSD.org Subject: Re: old/unupdated xterm entries in termcap db 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, 10 Dec 2009 12:59:28 -0000 --rftSBn8ujW1dGbW1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Gary Jennejohn wrote: > IIRC there was a patch in the original post which may be a good starting = point. I just tried the patch, but when I run `make' in share/termcap, I get the following: | gzip -cn termcap.5 > termcap.5.gz | TERM=3Ddumb TERMCAP=3Ddumb: ex - /store/home/ed/projects/freebsd-head/sha= re/termcap/termcap.src < /store/home/ed/projects/freebsd-head/share/termcap= /reorder | script, 36: Pattern not found | script, 36: Ex command failed: pending commands discarded | *** Error code 1 |=20 | Stop in /store/home/ed/projects/freebsd-head/share/termcap. --=20 Ed Schouten WWW: http://80386.nl/ --rftSBn8ujW1dGbW1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksg8K8ACgkQ52SDGA2eCwVlUACeKdFSNg2oEKZxaGYzrvUwK6Z9 82oAn3yqwJMVHZkRRaZVfEZzgGTt0b6V =DCop -----END PGP SIGNATURE----- --rftSBn8ujW1dGbW1-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 13:25:55 2009 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 3E1951065672 for ; Thu, 10 Dec 2009 13:25:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6208FC13 for ; Thu, 10 Dec 2009 13:25:54 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 103271CC5D; Thu, 10 Dec 2009 14:25:54 +0100 (CET) Date: Thu, 10 Dec 2009 14:25:54 +0100 From: Ed Schouten To: Gary Jennejohn Message-ID: <20091210132554.GC64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> <20091210135102.3434e5cf@ernst.jennejohn.org> <20091210125927.GB64905@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="flD90yxhZo4KvcOf" Content-Disposition: inline In-Reply-To: <20091210125927.GB64905@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Leidinger , freebsd-hackers@FreeBSD.org Subject: [Patch] Updated termcap entries for xterm 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, 10 Dec 2009 13:25:55 -0000 --flD90yxhZo4KvcOf Content-Type: multipart/mixed; boundary="po7Nh40UCuB+nesY" Content-Disposition: inline --po7Nh40UCuB+nesY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > I just tried the patch, but when I run `make' in share/termcap, I get > the following: >=20 > | gzip -cn termcap.5 > termcap.5.gz > | TERM=3Ddumb TERMCAP=3Ddumb: ex - /store/home/ed/projects/freebsd-head/s= hare/termcap/termcap.src < /store/home/ed/projects/freebsd-head/share/termc= ap/reorder > | script, 36: Pattern not found > | script, 36: Ex command failed: pending commands discarded > | *** Error code 1 > |=20 > | Stop in /store/home/ed/projects/freebsd-head/share/termcap. The attached patch should bring the entries up-to-date. Unfortunately it still seems the issue with Apple's Terminal.app is present, but that's just Apple's fault. Because of that, I don't see a reason (yet) to MFC this. Any testers, before I commit this patch to HEAD? --=20 Ed Schouten WWW: http://80386.nl/ --po7Nh40UCuB+nesY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="termcap.diff" Content-Transfer-Encoding: quoted-printable Index: share/termcap/termcap.src =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/termcap/termcap.src (revision 200186) +++ share/termcap/termcap.src (working copy) @@ -2784,48 +2784,46 @@ :ts=3D\E_:fs=3D\E\\:ds=3D\E_\E\\:tc=3Dscreen: SW|screen-w|VT 100/ANSI X3.64 virtual terminal with 132 cols:\ :co#132:tc=3Dscreen: -# $Xorg: termcap,v 1.3 2000/08/17 19:55:10 cpqbld Exp $ +# $XTermId: termcap,v 1.78 2009/11/09 00:24:26 tom Exp $ # # Note: # termcap format is limited to 1023 characters. This set of descriptions # is a subset of the terminfo, since not all features can be fit into # that limit. The 'xterm' description supports color. The monochrome -# 'xtermm' drops color in favor of additional function keys. If you need -# both, use terminfo. +# 'xterm-mono' drops color in favor of additional function keys. If you +# need both, use terminfo. # # The 1023-character limit applies to each entry after resolving the # "tc=3D" strings. Some implementations may discount all or part of the # formatting characters in the entry (i.e., the backslash newline tab # colon). GNU termcap does not have this limit. # -# I checked the limits using ncurses "captoinfo -CrTv", which prints +# I checked the limits using ncurses "captoinfo -CrTUvx", which prints # the resolved length of each entry in a comment at the end - T.Dickey # -# $XFree86: xc/programs/xterm/termcap,v 3.28 2001/01/17 23:46:39 dawes Exp= $ +xterm-new|modern xterm:\ + :*6=3D\EOF:@7=3D\EOF:F1=3D\E[23~:F2=3D\E[24~:K2=3D\EOE:Km=3D\E[M:\ + :k1=3D\EOP:k2=3D\EOQ:k3=3D\EOR:k4=3D\EOS:k5=3D\E[15~:k6=3D\E[17~:\ + :k7=3D\E[18~:k8=3D\E[19~:k9=3D\E[20~:k;=3D\E[21~:kH=3D\EOF:kI=3D\E[2~:\ + :kN=3D\E[6~:kP=3D\E[5~:kd=3D\EOB:kh=3D\EOH:kl=3D\EOD:kr=3D\EOC:ku=3D\EOA:\ + :tc=3Dxterm-basic: # -xterm-xfree86|XFree86 xterm:\ - :k1=3D\EOP:k2=3D\EOQ:k3=3D\EOR:k4=3D\EOS:\ - :k5=3D\E[15~:k6=3D\E[17~:k7=3D\E[18~:k8=3D\E[19~:\ - :k9=3D\E[20~:k;=3D\E[21~:F1=3D\E[23~:F2=3D\E[24~:\ - :@7=3D\EOF:@8=3D\EOM:kI=3D\E[2~:\ - :kh=3D\EOH:kP=3D\E[5~:kN=3D\E[6~:\ - :ku=3D\EOA:kd=3D\EOB:kr=3D\EOC:kl=3D\EOD:Km=3D\E[M:tc=3Dxterm-basic: -# # This chunk is used for building the VT220/Sun/PC keyboard variants. -xterm-basic|xterm common (XFree86):\ - :li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=3D^G:\ - :is=3D\E[!p\E[?3;4l\E[4l\E>:rs=3D\E[!p\E[?3;4l\E[4l\E>:le=3D^H:\ - :AL=3D\E[%dL:DL=3D\E[%dM:DC=3D\E[%dP:al=3D\E[L:dc=3D\E[P:dl=3D\E[M:\ - :UP=3D\E[%dA:DO=3D\E[%dB:LE=3D\E[%dD:RI=3D\E[%dC:\ - :ho=3D\E[H:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:cm=3D\E[%i%d;%dH:cs=3D\E[%i= %d;%dr:\ - :im=3D\E[4h:ei=3D\E[4l:ks=3D\E[?1h\E=3D:ke=3D\E[?1l\E>:kD=3D\E[3~:kb=3D^H= :\ - :sf=3D\n:sr=3D\EM:st=3D\EH:ct=3D\E[3g:sc=3D\E7:rc=3D\E8:\ - :eA=3D\E(B\E)0:as=3D\E(0:ae=3D\E(B:ml=3D\El:mu=3D\Em:up=3D\E[A:nd=3D\E[C:\ - :md=3D\E[1m:me=3D\E[m:mr=3D\E[7m:so=3D\E[7m:se=3D\E[27m:us=3D\E[4m:ue=3D\= E[24m:\ - :ti=3D\E[?1049h:te=3D\E[?1049l:vi=3D\E[?25l:ve=3D\E[?25h:\ - :ut:Co#8:pa#64:op=3D\E[39;49m:AB=3D\E[4%dm:AF=3D\E[3%dm: +xterm-basic|modern xterm common:\ + :am:bs:km:mi:ms:ut:xn:AX:\ + :Co#8:co#80:kn#12:li#24:pa#64:\ + :AB=3D\E[4%dm:AF=3D\E[3%dm:AL=3D\E[%dL:DC=3D\E[%dP:DL=3D\E[%dM:\ + :DO=3D\E[%dB:LE=3D\E[%dD:RI=3D\E[%dC:UP=3D\E[%dA:ae=3D\E(B:al=3D\E[L:\ + :as=3D\E(0:bl=3D^G:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:\ + :cm=3D\E[%i%d;%dH:cs=3D\E[%i%d;%dr:ct=3D\E[3g:dc=3D\E[P:dl=3D\E[M:\ + :ei=3D\E[4l:ho=3D\E[H:im=3D\E[4h:is=3D\E[!p\E[?3;4l\E[4l\E>:\ + :kD=3D\E[3~:kb=3D^H:ke=3D\E[?1l\E>:ks=3D\E[?1h\E=3D:le=3D^H:md=3D\E[1m:\ + :me=3D\E[m:ml=3D\El:mr=3D\E[7m:mu=3D\Em:nd=3D\E[C:op=3D\E[39;49m:\ + :rc=3D\E8:rs=3D\E[!p\E[?3;4l\E[4l\E>:sc=3D\E7:se=3D\E[27m:sf=3D^J:\ + :so=3D\E[7m:sr=3D\EM:st=3D\EH:te=3D\E[?1049l:ti=3D\E[?1049h:\ + :ue=3D\E[24m:up=3D\E[A:us=3D\E[4m:ve=3D\E[?12l\E[?25h:vi=3D\E[?25l:vs=3D\= E[?12;25h: =20 -# The xterm-xfree86 description has all of the features, but is not comple= tely +# The xterm-new description has all of the features, but is not completely # compatible with vt220. If you are using a Sun or PC keyboard, set the # sunKeyboard resource to true: # + maps the editing keypad @@ -2835,68 +2833,91 @@ # + uses DEC-style control sequences for the application keypad. # xterm-vt220|xterm emulating vt220:\ - :kH=3D\E[4~::@7=3D\E[4~:*6=3D\E[4~:kh=3D\E[1~:Km=3D\E[M:tc=3Dxterm-basic: + :*6=3D\E[4~:@7=3D\E[4~:K2=3D\EOu:Km=3D\E[M:kH=3D\E[4~:kh=3D\E[1~:\ + :tc=3Dxterm-basic: =20 xterm-24|xterms|vs100|24x80 xterm:\ - :li#24:\ - :tc=3Dxterm: + :li#24:tc=3Dxterm-old: xterm-65|65x80 xterm:\ - :li#65:tc=3Dxterm: + :li#65:tc=3Dxterm-old: xterm-bold|xterm with bold for underline:\ - :so=3D\E[7m:us=3D\E[1m:tc=3Dxterm: + :so=3D\E[7m:us=3D\E[1m:tc=3Dxterm-old: xterm-boldso|xterm with bold for standout:\ - :se=3D\E[m:so=3D\E[1m:tc=3Dxterm: + :se=3D\E[m:so=3D\E[1m:tc=3Dxterm-old: xterm-mono|monochrome xterm:\ - :kn#20:\ - :st@:ut@:Co@:NC@:op@:AB@:AF@:pa@:Sf@:Sb@:tc=3Dxterm: + :ut@:\ + :Co@:NC@:kn#20:pa@:\ + :AB@:AF@:Sb@:Sf@:op@:st@:tc=3Dxterm-old: # # Alternate terminal description that "works" for interactive shells such = as # tcsh and bash. xterm-noapp|xterm with cursor keys in normal mode:\ - :kl=3D\E[D:kd=3D\E[B:kr=3D\E[C:ku=3D\E[A:ks=3D\E=3D:ke=3D\E>:ti@:te@:tc= =3Dxterm: + :kd=3D\E[B:ke=3D\E>:kl=3D\E[D:kr=3D\E[C:ks=3D\E=3D:ku=3D\E[A:te@:ti@:\ + :tc=3Dxterm: # +# This should work for the commonly used "color xterm" variations (XFree86 +# xterm, color_xterm, nxterm, rxvt). Note that it does not set 'bce', so = for +# XFree86 and rxvt, some applications that use colors will be less efficie= nt, +# and in a few special cases (with "smart" optimization) the wrong color w= ill +# be painted in spots. +xterm-color|generic "ANSI" color xterm:\ + :Co#8:NC@:pa#64:\ + :AB=3D\E[4%dm:AF=3D\E[3%dm:ac=3D:op=3D\E[m:tc=3Dxterm-r6: +# # These aliases are for compatibility with the terminfo; termcap cannot pr= ovide -# the extra features, but termcap applications still want the names. -xterm-16color|xterm alias 1:tc=3Dxterm-xfree86: -xterm-88color|xterm alias 2:tc=3Dxterm-256color: -xterm-256color|xterm alias 3:tc=3Dxterm-xfree86: -xterm-nrc|xterm alias 4:tc=3Dxterm: -xterm-rep|xterm alias 5:tc=3Dxterm: -xterm-xmc|xterm alias 6:sg#1:tc=3Dxterm: +# the extra features such as color initialization, but termcap applications +# still want the names. +xterm-16color|xterm alias:\ + :tc=3Dxterm-new: + +xterm-88color|xterm alias:\ + :Co#88:pa#7744:tc=3Dxterm-256color: + +xterm-256color|xterm alias:\ + :Co#256:pa#32767:\ + :AB=3D\E[48;5;%dm:AF=3D\E[38;5;%dm:tc=3Dxterm-new: + +xterm-nrc|xterm alias:\ + :tc=3Dxterm: +xterm-rep|xterm alias:\ + :tc=3Dxterm: +xterm-xmc|xterm alias:\ + :sg#1:tc=3Dxterm: # # An 8-bit description is doable with termcap, but there are probably no # termcap (or BSD curses) applications that are able to use it. xterm-8bit|xterm terminal emulator 8-bit controls (X Window System):\ - :co#80:li#24:\ - :it#8:am:km:mi:ms:xn:\ - :AL=3D\233%dL:DC=3D\233%dP:DL=3D\233%dM:DO=3D\233%dB:IC=3D\233%d@:LE=3D\2= 33%dD:\ - :RI=3D\233%dC:UP=3D\233%dA:ae=3D^O:al=3D\233L:as=3D^N:bl=3D^G:bt=3D\233Z:\ - :cd=3D\233J:ce=3D\233K:cl=3D\233H\2332J:cm=3D\233%i%d;%dH:cr=3D^M:\ - :cs=3D\233%i%d;%dr:ct=3D\2333g:dc=3D\233P:dl=3D\233M:do=3D^J:up=3D\233A:n= d=3D\233C:\ - :ei=3D\2334l:ho=3D\233H:im=3D\2334h:\ + :am:km:mi:ms:xn:\ + :co#80:it#8:li#24:\ + :AL=3D\233%dL:DC=3D\233%dP:DL=3D\233%dM:DO=3D\233%dB:IC=3D\233%d@:\ + :K2=3D\217y:Km=3D\233M:LE=3D\233%dD:RI=3D\233%dC:UP=3D\233%dA:\ + :ae=3D\E(B:al=3D\233L:as=3D\E(0:bl=3D^G:bt=3D\233Z:cd=3D\233J:ce=3D\233K:\ + :cl=3D\233H\2332J:cm=3D\233%i%d;%dH:cr=3D^M:cs=3D\233%i%d;%dr:\ + :ct=3D\2333g:dc=3D\233P:dl=3D\233M:do=3D^J:ei=3D\2334l:ho=3D\233H:\ + :im=3D\2334h:\ :is=3D\E[62"p\E G\233m\233?7h\E>\E7\233?1;3;4;6l\2334l\233r\E8:\ :k1=3D\23311~:k2=3D\23312~:k3=3D\23313~:k4=3D\23314~:k5=3D\23315~:\ :k6=3D\23317~:k7=3D\23318~:k8=3D\23319~:k9=3D\23320~:kD=3D\2333~:\ :kI=3D\2332~:kN=3D\2336~:kP=3D\2335~:kb=3D^H:kd=3D\217B:\ :ke=3D\233?1l\E>:kh=3D\2331~:kl=3D\217D:kr=3D\217C:ks=3D\233?1h\E=3D:\ - :ku=3D\217A:le=3D^H:mb=3D\2335m:md=3D\2331m:me=3D\233m^O:mr=3D\2337m:\ - :rc=3D\E8:sc=3D\E7:se=3D\23327m:sf=3D^J:so=3D\2337m:sr=3D\215:\ - :st=3D\210:ta=3D^I:te=3D\233?1049l:ti=3D\233?1049h:ue=3D\23324m:us=3D\233= 4m:\ - :vb=3D\233?5h\233?5l:ve=3D\233?25h:vi=3D\233?25l:Km=3D\233M: + :ku=3D\217A:le=3D^H:mb=3D\2335m:md=3D\2331m:me=3D\233m:mr=3D\2337m:\ + :nd=3D\233C:rc=3D\E8:sc=3D\E7:se=3D\23327m:sf=3D^J:so=3D\2337m:sr=3D\215:\ + :st=3D\210:ta=3D^I:te=3D\233?1049l:ti=3D\233?1049h:ue=3D\23324m:\ + :up=3D\233A:us=3D\2334m:vb=3D\233?5h\233?5l:ve=3D\233?25l\233?25h:\ + :vs=3D\233?12;25h:vi=3D\233?25l: # -xterm-hp|XFree86 xterm with hpterm function keys:\ - :k1=3D\Ep:k2=3D\Eq:k3=3D\Er:k4=3D\Es:k5=3D\Et:k6=3D\Eu:k7=3D\Ev:k8=3D\Ew:\ - :kC=3D\EJ:kD=3D\EP:@7=3D\EF:kI=3D\EQ:kN=3D\ES:kP=3D\ET:kh=3D\Eh:\ - :kd=3D\EB:kl=3D\ED:kr=3D\EC:ku=3D\EA:tc=3Dxterm-basic: +xterm-hp|xterm with hpterm function keys:\ + :@7=3D\EF:k1=3D\Ep:k2=3D\Eq:k3=3D\Er:k4=3D\Es:k5=3D\Et:k6=3D\Eu:k7=3D\Ev:\ + :k8=3D\Ew:kC=3D\EJ:kD=3D\EP:kI=3D\EQ:kN=3D\ES:kP=3D\ET:kd=3D\EB:kh=3D\Eh:\ + :kl=3D\ED:kr=3D\EC:ku=3D\EA:tc=3Dxterm-basic: # -xterm-sco|XFree86 xterm with SCO function keys:\ - :kl=3D\E[D:kd=3D\E[B:kr=3D\E[C:ku=3D\E[A:@7=3D\E[F:\ - :k1=3D\E[M:k2=3D\E[N:k3=3D\E[O:k4=3D\E[P:k5=3D\E[Q:\ - :k6=3D\E[R:k7=3D\E[S:k8=3D\E[T:k9=3D\E[U:k;=3D\E[V:\ - :F1=3D\E[W:F2=3D\E[X:F3=3D\E[Y:F5=3D\E[a:F6=3D\E[b:\ - :F7=3D\E[c:F8=3D\E[d:F9=3D\E[e:FA=3D\E[f:FB=3D\E[g:\ - :FC=3D\E[h:FD=3D\E[i:FE=3D\E[j:FF=3D\E[k:\ - :kh=3D\E[H:kI=3D\E[L:kN=3D\E[G:kP=3D\E[I:ac@:tc=3Dxterm-basic: +xterm-sco|xterm with SCO function keys:\ + :@7=3D\E[F:F1=3D\E[W:F2=3D\E[X:F3=3D\E[Y:F5=3D\E[a:F6=3D\E[b:F7=3D\E[c:\ + :F8=3D\E[d:F9=3D\E[e:FA=3D\E[f:FB=3D\E[g:FC=3D\E[h:FD=3D\E[i:FE=3D\E[j:\ + :FF=3D\E[k:ac=3D:k1=3D\E[M:k2=3D\E[N:k3=3D\E[O:k4=3D\E[P:k5=3D\E[Q:\ + :k6=3D\E[R:k7=3D\E[S:k8=3D\E[T:k9=3D\E[U:k;=3D\E[V:kD=3D\177:kI=3D\E[L:\ + :kN=3D\E[G:kP=3D\E[I:kd=3D\E[B:kh=3D\E[H:kl=3D\E[D:kr=3D\E[C:ku=3D\E[A:\ + :tc=3Dxterm-basic: # xterm-vt52|xterm emulating vt52:\ :bs:\ @@ -2906,63 +2927,65 @@ :le=3D\ED:nd=3D\EC:nw=3D^M^J:sf=3D^J:sr=3D\EI:ta=3D^I:up=3D\EA: # xterm-sun|xterm with Sun functionkeys:\ - :k1=3D\E[224z:k2=3D\E[225z:k3=3D\E[226z:k4=3D\E[227z:\ - :k5=3D\E[228z:k6=3D\E[229z:k7=3D\E[230z:k8=3D\E[231z:\ - :k9=3D\E[232z:k;=3D\E[233z:F1=3D\E[192z:F2=3D\E[193z:\ - :%1=3D\E[196z:&8=3D\E[195z:@0=3D\E[200z:kI=3D\E[2z:\ - :kN=3D\E[222z:kP=3D\E[216z:kh=3D\E[214z:kD=3D^?:\ - :Km=3D\E[M:@5=3D\E[197z::@7=3D\E[220z:\ + :%1=3D\E[196z:&8=3D\E[195z:@0=3D\E[200z:@5=3D\E[197z:@7=3D\E[220z:\ + :F1=3D\E[192z:F2=3D\E[193z:K2=3D\E[218z:Km=3D\E[M:k1=3D\E[224z:\ + :k2=3D\E[225z:k3=3D\E[226z:k4=3D\E[227z:k5=3D\E[228z:k6=3D\E[229z:\ + :k7=3D\E[230z:k8=3D\E[231z:k9=3D\E[232z:k;=3D\E[233z:kD=3D\E[3z:\ + :kI=3D\E[2z:kN=3D\E[222z:kP=3D\E[216z:kh=3D\E[214z:\ :tc=3Dxterm-basic: # # vi may work better with this entry, because vi doesn't use insert mode m= uch. -# |xterm-ic|xterm-vi|xterm with insert character instead of insert mode: +# |xterm-ic|xterm-vi|xterm with insert character instead of insert mode:\ xterm-ic|xterm-vi|xterm with insert char:\ - :im@:ei@:mi@:ic=3D\E[@:IC=3D\E[%d@:tc=3Dxterm: + :mi@:\ + :IC=3D\E[%d@:ei@:ic=3D\E[@:im@:tc=3Dxterm: # # Compatible with the X11R6.3 xterm xterm-r6|xterm-old|X11R6 xterm:\ + :am:bs:km:mi:ms:pt:xn:\ + :co#80:kn#20:li#24:\ + :*6=3D\E[4~:@0=3D\E[1~:@7=3D\E[4~:AL=3D\E[%dL:DC=3D\E[%dP:DL=3D\E[%dM:\ + :DO=3D\E[%dB:F1=3D\E[23~:F2=3D\E[24~:F3=3D\E[25~:F4=3D\E[26~:\ + :F5=3D\E[28~:F6=3D\E[29~:F7=3D\E[31~:F8=3D\E[32~:F9=3D\E[33~:\ + :FA=3D\E[34~:LE=3D\E[%dD:RI=3D\E[%dC:UP=3D\E[%dA:ae=3D^O:al=3D\E[L:\ + :as=3D^N:bl=3D^G:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:cm=3D\E[%i%d;%dH:\ + :cs=3D\E[%i%d;%dr:ct=3D\E[3g:dc=3D\E[P:dl=3D\E[M:eA=3D\E)0:ei=3D\E[4l:\ + :ho=3D\E[H:im=3D\E[4h:\ :is=3D\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ - :rs=3D\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ - :AL=3D\E[%dL:DL=3D\E[%dM:DC=3D\E[%dP:DO=3D\E[%dB:UP=3D\E[%dA:\ - :LE=3D\E[%dD:RI=3D\E[%dC:al=3D\E[L:am:bl=3D^G:\ - :bs:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:cm=3D\E[%i%d;%dH:co#80:\ - :cs=3D\E[%i%d;%dr:ct=3D\E[3g:dc=3D\E[P:dl=3D\E[M:ho=3D\E[H:\ - :im=3D\E[4h:ei=3D\E[4l:mi:ks=3D\E[?1h\E=3D:ke=3D\E[?1l\E>:@7=3D\E[4~:kh= =3D\E[1~:\ :k1=3D\E[11~:k2=3D\E[12~:k3=3D\E[13~:k4=3D\E[14~:k5=3D\E[15~:\ :k6=3D\E[17~:k7=3D\E[18~:k8=3D\E[19~:k9=3D\E[20~:k;=3D\E[21~:\ - :F1=3D\E[23~:F2=3D\E[24~:F3=3D\E[25~:F4=3D\E[26~:F5=3D\E[28~:\ - :F6=3D\E[29~:F7=3D\E[31~:F8=3D\E[32~:F9=3D\E[33~:FA=3D\E[34~:\ - :kn#20:km:@0=3D\E[1~:kI=3D\E[2~:kD=3D^?:*6=3D\E[4~:kP=3D\E[5~:kN=3D\E[6~:\ - :kb=3D^H:ku=3D\EOA:kd=3D\EOB:kr=3D\EOC:kl=3D\EOD:\ - :li#24:md=3D\E[1m:me=3D\E[m:mr=3D\E[7m:ms:nd=3D\E[C:pt:\ - :eA=3D\E)0:as=3D^N:ae=3D^O:ml=3D\El:mu=3D\Em:\ - :sc=3D\E7:rc=3D\E8:sf=3D\n:so=3D\E[7m:se=3D\E[m:sr=3D\EM:\ - :ti=3D\E7\E[?47h:te=3D\E[2J\E[?47l\E8:up=3D\E[A:us=3D\E[4m:ue=3D\E[m:xn: + :kD=3D\E[3~:kI=3D\E[2~:kN=3D\E[6~:kP=3D\E[5~:kb=3D^H:kd=3D\EOB:\ + :ke=3D\E[?1l\E>:kh=3D\E[1~:kl=3D\EOD:kr=3D\EOC:ks=3D\E[?1h\E=3D:\ + :ku=3D\EOA:md=3D\E[1m:me=3D\E[m:ml=3D\El:mr=3D\E[7m:mu=3D\Em:nd=3D\E[C:\ + :rc=3D\E8:rs=3D\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8:\ + :sc=3D\E7:se=3D\E[m:sf=3D^J:so=3D\E[7m:sr=3D\EM:te=3D\E[2J\E[?47l\E8:\ + :ti=3D\E7\E[?47h:ue=3D\E[m:up=3D\E[A:us=3D\E[4m: # # Compatible with the R5 xterm xterm-r5|X11R5 xterm X11R5:\ - :AL=3D\E[%dL:DC=3D\E[%dP:DL=3D\E[%dM:DO=3D\E[%dB:IC=3D\E[%d@:UP=3D\E[%dA:\ - :al=3D\E[L:am:\ - :bs:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:cm=3D\E[%i%d;%dH:co#80:\ - :cs=3D\E[%i%d;%dr:ct=3D\E[3g:\ - :dc=3D\E[P:dl=3D\E[M:\ - :im=3D\E[4h:ei=3D\E[4l:mi:\ - :ho=3D\E[H:\ + :am:bs:km:mi:ms:pt:xn:\ + :co#80:kn#4:li#24:\ + :@7=3D\E[4~:AL=3D\E[%dL:DC=3D\E[%dP:DL=3D\E[%dM:DO=3D\E[%dB:\ + :IC=3D\E[%d@:UP=3D\E[%dA:al=3D\E[L:cd=3D\E[J:ce=3D\E[K:cl=3D\E[H\E[2J:\ + :cm=3D\E[%i%d;%dH:cs=3D\E[%i%d;%dr:ct=3D\E[3g:dc=3D\E[P:dl=3D\E[M:\ + :ei=3D\E[4l:ho=3D\E[H:im=3D\E[4h:\ :is=3D\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ + :k1=3D\E[11~:k2=3D\E[12~:k3=3D\E[13~:k4=3D\E[14~:kb=3D^H:kd=3D\EOB:\ + :ke=3D\E[?1l\E>:kh=3D\E[1~:kl=3D\EOD:kr=3D\EOC:ks=3D\E[?1h\E=3D:\ + :ku=3D\EOA:md=3D\E[1m:me=3D\E[m:mr=3D\E[7m:nd=3D\E[C:rc=3D\E8:\ :rs=3D\E>\E[?1;3;4;5;6l\E[4l\E[?7h\E[m\E[r\E[2J\E[H:\ - :k1=3D\E[11~:k2=3D\E[12~:k3=3D\E[13~:k4=3D\E[14~:kb=3D^H:kd=3D\EOB:ke=3D\= E[?1l\E>:\ - :kl=3D\EOD:km:kn#4:kr=3D\EOC:ks=3D\E[?1h\E=3D:ku=3D\EOA:\ - :@7=3D\E[4~:kh=3D\E[1~:\ - :li#24:md=3D\E[1m:me=3D\E[m:mr=3D\E[7m:ms:nd=3D\E[C:pt:\ - :sc=3D\E7:rc=3D\E8:sf=3D\n:so=3D\E[7m:se=3D\E[m:sr=3D\EM:\ - :te=3D\E[2J\E[?47l\E8:ti=3D\E7\E[?47h:\ - :up=3D\E[A:us=3D\E[4m:ue=3D\E[m:xn: + :sc=3D\E7:se=3D\E[m:sf=3D^J:so=3D\E[7m:sr=3D\EM:te=3D\E[2J\E[?47l\E8:\ + :ti=3D\E7\E[?47h:ue=3D\E[m:up=3D\E[A:us=3D\E[4m: # +# Customization begins here. +xterm-xfree86|xterm terminal emulator (XFree86):\ + :tc=3Dxterm-new: +# # This is the only entry which you should have to customize, since "xterm" # is widely used for a variety of incompatible terminal emulations includi= ng # color_xterm and rxvt. -xterm|xterm-color|X11 terminal emulator:\ - :ti@:te@:tc=3Dxterm-xfree86: +xterm|X11 terminal emulator:\ + :tc=3Dxterm-new: # :tc=3Dxterm-r6: # dtterm termcap entry - Obtained from Xinside's CDE with permission # from Thomas Roell --po7Nh40UCuB+nesY-- --flD90yxhZo4KvcOf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksg9uEACgkQ52SDGA2eCwUnbACeIdzxYII2lFL4dmyzWcfAwigf 6x0AnAnzPoCiW3eG3avdVEPZHahO0rCD =I8xf -----END PGP SIGNATURE----- --flD90yxhZo4KvcOf-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 09:44:41 2009 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 606F0106568B for ; Thu, 10 Dec 2009 09:44:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id CF5628FC2E for ; Thu, 10 Dec 2009 09:44:40 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FCF1.dip.t-dialin.net [217.84.252.241]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id EBD16844914; Thu, 10 Dec 2009 10:44:34 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 6CA732990EB; Thu, 10 Dec 2009 10:44:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1260438271; bh=7PJX9Mf91s28x1YeNG5c81D+JUJZw4byZbJ2kjCm2QQ=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hHBAFkJyvTuIf/UnHInu3znFL2pso8gOnfo7xGOQo/AC1cxHP8R6NLQCaTjvYFsdg 33SO8/7oZaV1Al3OsB4BfstFgSWMwCWvFoVfQM9MaqGzM6xgO+obBDKfn+dydRTEl3 tNlcvJUgwhVMlHlrlgPDrTJHOJrIh5yvrMjDsRkk4l8RlOlODJwWyU9juVIPtsOB9P 8l96NASXr1hYozBSXmv/JIaOZKnBcWn0xOnuQFSA7w4A924h6LZFM3kNzlhCLDXxNt UPuGJm+SDmDRVTm8oFLDJsPfoAj4wcKg9XiCHk9G6rGHWx7Yb3jY2L4Tt2QL0PSoUg KWWoW+kyJ4znA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id nBA9iUmn032462; Thu, 10 Dec 2009 10:44:30 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 10 Dec 2009 10:44:30 +0100 Message-ID: <20091210104430.1381356nnmx30okk@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 10 Dec 2009 10:44:30 +0100 From: Alexander Leidinger To: gary.jennejohn@freenet.de, ed@FreeBSD.org References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> In-Reply-To: <20091209123246.22b9ecc3@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.5) / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: EBD16844914.26F5F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1261043076.02508@b5dHQRpdh6V5lLWI+HYBFQ X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 10 Dec 2009 13:38:22 +0000 Cc: freebsd-hackers@FreeBSD.org Subject: Re: old/unupdated xterm entries in termcap db 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, 10 Dec 2009 09:44:41 -0000 Quoting Gary Jennejohn (from Wed, 9 Dec 2009 12:32:46 +0100): > On Wed, 09 Dec 2009 12:29:21 +0100 > Dag-Erling Sm__rgrav wrote: > >> Gary Jennejohn writes: >> > Leonidas Tsampros writes: >> > > Why aren't these entries updated in order to match the ones that >> > > ship with xterm? Am I missing something? >> > Probably because xterm is under ports and termcap under src and it >> > would not be easy to track changes in ports under src. >> > >> > The only practical way to keep termcap up to date would be for the >> > committer updating the port to also check and update termcap under src. >> > The problem with this is that most ports committers aren't authorized >> > to make commits under src. >> >> That's not an issue - termcaps don't change all that often. We should >> just import the new definitions. >> > > That's a practical attitude, but it begs the question why it hasn't > happened in the past. The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. Bye, Alexander. -- You can't depend on the man who made the mess to clean it up. -- Richard Nixon, 1952 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 14:02:25 2009 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 8F0AC1065693; Thu, 10 Dec 2009 14:02:25 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id F21A48FC2A; Thu, 10 Dec 2009 14:02:24 +0000 (UTC) Received: by ewy26 with SMTP id 26so3783480ewy.3 for ; Thu, 10 Dec 2009 06:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=y9RFP5JPyvp15pX3FrKlH032fTOLtdCkATBp558RUjo=; b=STuPO8xgXyNvgHxmgAkTLt8q6YoJtnshpUbdKEbnIuG0O7FwqOfUUgqQcUGBbIhp3o q6hrdtnICoos1GUA34BMsydhYPc27jGLY46iGdj98IfxKHMoXx6zvB5IvRpFTgTv+ifw v7YwPD4btKl/o14fe5Dz2TiMwdDhZpBIhP3+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l1LSa0B33843u7dz+5GYvd082f/YQejnJDzmneibEetbVLt85uXHRkMxPw2PpYRKbK z3vNi08oBJwLAM7RahW+Q1qKeWnByEBJG+9dq90dqzPaR4lM0HPiGNL0NAxRFohEQWDc rRL6D1qUk6vlpK6DdWHq/9wllz1MbTPrUebcA= MIME-Version: 1.0 Received: by 10.216.85.17 with SMTP id t17mr1381052wee.178.1260453743775; Thu, 10 Dec 2009 06:02:23 -0800 (PST) In-Reply-To: <200912090907.33433.jhb@freebsd.org> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> Date: Thu, 10 Dec 2009 09:02:23 -0500 Message-ID: <237c27100912100602v3aa4ba7eg1a366ceeed836848@mail.gmail.com> From: Linda Messerschmidt To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 14:02:25 -0000 On Wed, Dec 9, 2009 at 9:07 AM, John Baldwin wrote: > There is lower hanging fruit in other areas > in the VM that will probably be worked on first. OK, as long as somebody who knows more than me knows whats going on, that's good enough for me. :) Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 14:50:58 2009 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 532971065696 for ; Thu, 10 Dec 2009 14:50:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id D444A8FC14 for ; Thu, 10 Dec 2009 14:50:57 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id nBAEothU031301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Dec 2009 15:50:55 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id nBAEoqCt000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id nBAEoqJI028612; Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id nBAEoq4N028611; Thu, 10 Dec 2009 15:50:52 +0100 (CET) (envelope-from ticso) Date: Thu, 10 Dec 2009 15:50:52 +0100 From: Bernd Walter To: John Baldwin Message-ID: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912090907.33433.jhb@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.029, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 14:50:58 -0000 On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote: > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: > > It's not clear to me if this might be a problem with the superpages > > implementation, or if squid does something particularly horrible to > > its memory when it forks to cause this, but I wanted to ask about it > > on the list in case somebody who understands it better might know > > whats going on. :-) > > I talked with Alan Cox some about this off-list and there is a case that can > cause this behavior if the parent squid process takes write faults on a > superpage before the child process has called exec() then it can result in > superpages being fragmented and never reassembled. Using vfork() should > prevent this from happening. It is a known issue, but it will probably be > some time before it is addressed. There is lower hanging fruit in other areas > in the VM that will probably be worked on first. For me the whole threads puzzles me. Especially because vfork is often called a solution. Scenario A Parent with super page fork/exec This problem can happen because there is a race. The parent now has it's super pages fragmented permanently!? the child throws away his pages because of the exec!? Scenario B Parent with super page vfork/exec This problem won't happen because the child has no pseudo copy of the parents memory and then starts with a completely new map. Scenario C Parent with super page fork/ no exec The problem can happen because the child shares the same memory over it's complete lifetime. The parent can get it's super pages fragmented over time. I don't see a use case for scenario A, because vfork is there since over 16 years. I use fork myself, because it is easier sometimes, but people writing big programms such as squid should know better. If squid doesn't use vfork they likely have a reason. With scenario C I don't see how vfork can help, since this is not a legal case for vfork. I use quid myself, but don't know how it handles it's childs. But isn't the whole story about such slave childs that they share memory with the master? - How can vfork be solution for this case? How can fragmentation of super pages be avoided at all? I obviously don't have enough clue about this to understand those details. Hope that someone can enlighten me. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 15:18:00 2009 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 2F2E5106568F for ; Thu, 10 Dec 2009 15:18:00 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id B7D4B8FC22 for ; Thu, 10 Dec 2009 15:17:59 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so54173eye.9 for ; Thu, 10 Dec 2009 07:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=knGZp0+3LC2cXu4xAFUUVX3VKwxOM4vpjSALhkkTx3Q=; b=l8xqPK/6PBOMrvzhREa9IEHj7IpxmXjJCCHuoWCYUrhe5+r0Hzw8rSA+8+WvvS/k1e HFgNc5uguCaOcjkF8j77rfab6OrMTmV0xL6KMcVghS0V3mKiJ44bc5lOXh8yL35X5RyW MSNNspF+LPA5lbEp4uf/v79xvPhpk/NwFlIC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sBoXxNEyljwPNrfmVL0cmFV8Sk6SQ+iS9qt8E8FEy73tieYtkdpZ0T+dOmaI5QXfTD 97Wdv+dRCg5zxW8Yj1IOoZfDyBxxdMaY0R8AWtWoQCwxbG+LZsq2zzv6o7eFSksJqUS2 i4gGl+CR3xS2Jo6Lg0waCyhdUlHO34nXiF/6w= MIME-Version: 1.0 Received: by 10.216.90.67 with SMTP id d45mr25292wef.42.1260458278211; Thu, 10 Dec 2009 07:17:58 -0800 (PST) In-Reply-To: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> Date: Thu, 10 Dec 2009 10:17:58 -0500 Message-ID: <237c27100912100717x3f1cda23n2865457e43e226f@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 15:18:00 -0000 On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote: > I obviously don't have enough clue about this to understand those details. > Hope that someone can enlighten me. I think what he is saying is that they are aware that the current situation is not ideal. vfork() is suggested as a workaround, definitely not a fix. The problem is that there is limited effort available to be put into the VM subsystem and since mostly-working superpages is still *way* better than no superpages, that limited effort is best spent elsewhere at present, presumably dealing with other, bigger VM subsystem issues. Hope I got that right. :) From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 15:23:09 2009 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 6C3ED106566B for ; Thu, 10 Dec 2009 15:23:09 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 02D4A8FC1A for ; Thu, 10 Dec 2009 15:23:08 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so557335fgg.13 for ; Thu, 10 Dec 2009 07:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4icy5XwuEfXvyzrRCUFKrq7hNHOxuyVT64WT9hh0TQU=; b=NKiCVVc7T+hlhrmy3yBtNzNK63VqJ3A7tcEZxqX2+bNae2MC2okJMmKLtGs0q+C+Qj CzKL1jsFtIGgbroP7o+BkxiZ48/G0wH+ojhvndamg9WqKpHM8+3yKiFI3GRe8ndHGPrX HmUbD0xFYViWlt+G6pcqRe/F/ohNZCqPPA6GU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Lca39TeF0dGVIVwdY687A8aNLjMkKrIkcklgxOXM6tFlovUQN9efuqvrtEA9YjIpE/ jYYqJroBGAOYnn2jyHCUhQVbBHlNvDGX6HUcFPvd/46XePaEttMqLx7WXek73xtRAuw4 lNLwm8HsIBuEmQqwpDqWtBOMVosZolJtBhu7E= MIME-Version: 1.0 Received: by 10.216.90.11 with SMTP id d11mr8435wef.187.1260458587498; Thu, 10 Dec 2009 07:23:07 -0800 (PST) In-Reply-To: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> Date: Thu, 10 Dec 2009 10:23:07 -0500 Message-ID: <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 15:23:09 -0000 Also... On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote: > I use fork myself, because it is easier sometimes, but people writing > big programms such as squid should know better. > If squid doesn't use vfork they likely have a reason. Actually they are probably going to switch to vfork(). They were previously not using it because they thought there was some ambiguity about whether it was going to be around long term. I actually am not a huge fan of vfork() since it stalls the parent process until the child exec()'s. To me, this case actually highlights why that's an issue. If the explanation is that stuff is happening in the parent process between fork() and the child's exec() causes the fragmentation, that's stuff that would be deferred in a vfork() regime, with unknown potential consequences. (At a minimum, decreased performance.) But that's personal and largely uninformed opinion. :) From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 15:24:27 2009 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 83D1E1065672 for ; Thu, 10 Dec 2009 15:24:27 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 124188FC22 for ; Thu, 10 Dec 2009 15:24:27 +0000 (UTC) Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NIksT-0006a5-Nh; Thu, 10 Dec 2009 16:24:25 +0100 Received: from p57ae296f.dip0.t-ipconnect.de ([87.174.41.111]:29227 helo=ernst.jennejohn.org) by 12.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NIksT-00029v-HI; Thu, 10 Dec 2009 16:24:25 +0100 Date: Thu, 10 Dec 2009 16:24:24 +0100 From: Gary Jennejohn To: Ed Schouten Message-ID: <20091210162424.674e2db3@ernst.jennejohn.org> In-Reply-To: <20091210132554.GC64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> <20091210135102.3434e5cf@ernst.jennejohn.org> <20091210125927.GB64905@hoeg.nl> <20091210132554.GC64905@hoeg.nl> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [Patch] Updated termcap entries for xterm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:24:27 -0000 On Thu, 10 Dec 2009 14:25:54 +0100 Ed Schouten wrote: > * Ed Schouten wrote: > > I just tried the patch, but when I run `make' in share/termcap, I get > > the following: > > > > | gzip -cn termcap.5 > termcap.5.gz > > | TERM=dumb TERMCAP=dumb: ex - /store/home/ed/projects/freebsd-head/share/termcap/termcap.src < /store/home/ed/projects/freebsd-head/share/termcap/reorder > > | script, 36: Pattern not found > > | script, 36: Ex command failed: pending commands discarded > > | *** Error code 1 > > | > > | Stop in /store/home/ed/projects/freebsd-head/share/termcap. > > The attached patch should bring the entries up-to-date. Unfortunately it > still seems the issue with Apple's Terminal.app is present, but that's > just Apple's fault. Because of that, I don't see a reason (yet) to MFC > this. > > Any testers, before I commit this patch to HEAD? > I tried it with a "real" xterm and mrxvt and see no regressions. However, I didn't try it with a VT as xterm. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 15:42:54 2009 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 D79D1106566C for ; Thu, 10 Dec 2009 15:42:54 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 82C4B8FC12 for ; Thu, 10 Dec 2009 15:42:54 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nBAFgso07631; Thu, 10 Dec 2009 07:42:54 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nBAFgrH05735; Thu, 10 Dec 2009 07:42:53 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 10 Dec 2009 07:42:53 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Linda Messerschmidt In-Reply-To: <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> Message-ID: References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 15:42:54 -0000 On Thu, 10 Dec 2009, Linda Messerschmidt wrote: > Also... > > On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote: >> I use fork myself, because it is easier sometimes, but people writing >> big programms such as squid should know better. >> If squid doesn't use vfork they likely have a reason. > > Actually they are probably going to switch to vfork(). They were > previously not using it because they thought there was some ambiguity > about whether it was going to be around long term. Well, the worst that would likely happen to vfork() is it would become an alias of fork(), and you'd be back to where you are now (or better if fork() were fixed in the meantime). I'd be more worried about the mysterious bugs which it's so easy to introduce with vfork() if you do anything at all nontrivial before exec() and accidentally touch the parent's memory. What about using posix_spawn(3)? This is implemented in terms of vfork(), so you'll gain the same performance advantages, but it avoids many of vfork's pitfalls. Also, since it's a POSIX standard function, you needn't worry that it will go away or change its semantics someday. > I actually am not a huge fan of vfork() since it stalls the parent > process until the child exec()'s. If you're doing so much work between vfork() and exec() that this delay is significant, then I would think you're really abusing vfork(). > To me, this case actually highlights why that's an issue. If the > explanation is that stuff is happening in the parent process between > fork() and the child's exec() causes the fragmentation, that's stuff > that would be deferred in a vfork() regime, with unknown potential > consequences. (At a minimum, decreased performance.) Not necessarily. In the fork() case, presumably copy-on-write is to blame for the fragmentation. In the vfork() case, there's no copy at all. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 16:05:26 2009 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 5BAA2106566C for ; Thu, 10 Dec 2009 16:05:26 +0000 (UTC) (envelope-from chris@brueffer.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id C3BE98FC17 for ; Thu, 10 Dec 2009 16:05:25 +0000 (UTC) Received: from brueffer.de (host1.allnav.ch [212.55.212.50]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MbJMy-1NbX9i24cG-00JGsn; Thu, 10 Dec 2009 16:52:35 +0100 Received: by brueffer.de (Postfix, from userid 1001) id 512CC17040; Thu, 10 Dec 2009 16:52:27 +0100 (CET) Date: Thu, 10 Dec 2009 16:52:27 +0100 From: Christian Brueffer To: Mel Flynn Message-ID: <20091210155226.GA59257@serenity> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <867htduvwh.fsf@ds4.des.no> <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> <200912071620.03371.mel.flynn+fbsd.hackers@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <200912071620.03371.mel.flynn+fbsd.hackers@mailing.thruhere.net> X-Operating-System: FreeBSD 9.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.19 (2009-01-05) X-Provags-ID: V01U2FsdGVkX1/cqM0WtsiP9G58YILp5pNbQumwHLi0U+EK2QP HeA1sflu+cA3zDw0HSSpmqtwSjMv4Qv/QGWtpl4aNlcJ8wwjSi PkWf4uW8SVFn4QgZCba8wAQ9Pu6kqeO Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 16:05:26 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2009 at 04:20:03PM +0100, Mel Flynn wrote: > On Thursday 26 November 2009 18:11:10 Linda Messerschmidt wrote: >=20 > > I did not mean to suggest that we were asking for help solving a > > problem with squid rotation. I provided that information as > > background to discuss what we observed as a potential misbehavior in > > the new VM superpages feature, in the hope that if there is a problem > > with the new feature, we can help find/resolve it or, if this is > > working as intended, hopefully gain some insight as to what's going > > on. >=20 > I tend to agree with this, though I don't know the nitty gritty of the=20 > implementation, it seems that: > a) superpages aren't copied efficiently (at all?) on fork and probably ot= her=20 > workloads > b) vfork is encouraged for memory intensive applications, yet: > BUGS > This system call will be eliminated when proper system sharing mecha= nisms > are implemented. Users should not depend on the memory sharing sema= ntics > of vfork() as it will, in that case, be made synonymous to fork(2). >=20 FYI, this comment has been removed a couple of weeks ago in HEAD and the STABLE branches. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkshGToACgkQbHYXjKDtmC1oEgCdF6W6Xt2lfK+HBdiIv+Vc/5XG jgYAn2OULbuj8pPu9AMNlJRGBCdbx4Gr =YPjW -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 16:19:10 2009 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 ECB431065670 for ; Thu, 10 Dec 2009 16:19:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2738FC19 for ; Thu, 10 Dec 2009 16:19:10 +0000 (UTC) Received: by iwn36 with SMTP id 36so5480840iwn.3 for ; Thu, 10 Dec 2009 08:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ICxv3M22DUOz9WFmFMGiXsEafp+RcGk1Jv1diBeQWKw=; b=F6AayjJ1tpfa5QvoqrdjDgUXat9aSu7tLQ7XeV3ax5viJNL/5XHRMUoZ835GIGHocI 5l3xAvoyhtFE+N3e25XQ441BufV3Y0KtbWRWlt86jVAbC5pacFQghNKrAXNghzRH4Hrz Jo/gtbo2T/Pz/bsc/YEG39dpqmjVawrVGh4K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UQLfU6+X2Iqt/SbC5mpaP04OYIfJCSdEgdeCpp8S88zn0sVfcPIlQjYsEQ7B/dov9b HE9honhLWXr0k8ai6XQbOsoBXWhOUTQMFvuNvTd2UMgWGhw1ns0o4RkkKEU65yw4X3Qw J2avr/3RMIod9BKgy7mzuBGTODdPLnGqj2jSg= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.231.167.204 with SMTP id r12mr51088iby.31.1260461949963; Thu, 10 Dec 2009 08:19:09 -0800 (PST) In-Reply-To: <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> Date: Fri, 11 Dec 2009 00:19:09 +0800 X-Google-Sender-Auth: 0d602fdaf62e4d60 Message-ID: From: Adrian Chadd To: Linda Messerschmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 16:19:11 -0000 Depending upon the IPC method being used, the fork() may be followed with calls to socket() and connect(), which may take a while. The main process will stall if you have a busy proxy and there's some temporary shortage of something which makes connect() take longer than usual, the main process will stall, potentially causing the shortage to become worse. 2c, Adrian (With his (ex-, kinda) Squid hacker hat on.) 2009/12/10 Linda Messerschmidt : > Also... > > On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter w= rote: >> I use fork myself, because it is easier sometimes, but people writing >> big programms such as squid should know better. >> If squid doesn't use vfork they likely have a reason. > > Actually they are probably going to switch to vfork(). =A0They were > previously not using it because they thought there was some ambiguity > about whether it was going to be around long term. > > I actually am not a huge fan of vfork() since it stalls the parent > process until the child exec()'s. > > To me, this case actually highlights why that's an issue. =A0If the > explanation is that stuff is happening in the parent process between > fork() and the child's exec() causes the fragmentation, that's stuff > that would be deferred in a vfork() regime, with unknown potential > consequences. =A0(At a minimum, decreased performance.) > > But that's personal and largely uninformed opinion. :) > _______________________________________________ > 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= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 18:34:16 2009 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 8FDD7106576B for ; Thu, 10 Dec 2009 18:34:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 814058FC1B for ; Thu, 10 Dec 2009 18:34:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1462A46B38; Thu, 10 Dec 2009 13:34:15 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E11508A01B; Thu, 10 Dec 2009 13:34:13 -0500 (EST) From: John Baldwin To: ticso@cicely.de Date: Thu, 10 Dec 2009 11:13:56 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> In-Reply-To: <20091210145052.GX20668@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912101113.56570.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 10 Dec 2009 13:34:13 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 10 Dec 2009 18:34:16 -0000 On Thursday 10 December 2009 9:50:52 am Bernd Walter wrote: > On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote: > > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: > > > It's not clear to me if this might be a problem with the superpages > > > implementation, or if squid does something particularly horrible to > > > its memory when it forks to cause this, but I wanted to ask about it > > > on the list in case somebody who understands it better might know > > > whats going on. :-) > > > > I talked with Alan Cox some about this off-list and there is a case that can > > cause this behavior if the parent squid process takes write faults on a > > superpage before the child process has called exec() then it can result in > > superpages being fragmented and never reassembled. Using vfork() should > > prevent this from happening. It is a known issue, but it will probably be > > some time before it is addressed. There is lower hanging fruit in other areas > > in the VM that will probably be worked on first. > > For me the whole threads puzzles me. > Especially because vfork is often called a solution. > > Scenario A > Parent with super page > fork/exec > This problem can happen because there is a race. > The parent now has it's super pages fragmented permanently!? > the child throws away his pages because of the exec!? > > Scenario B > Parent with super page > vfork/exec > This problem won't happen because the child has no pseudo copy of the > parents memory and then starts with a completely new map. Actually, the fact that vfork() doesn't let the parent execute until the child has called exec() also closes the race, as it were, and that was the primary reason in my mind for saying that vfork() would prevent it. > Scenario C > Parent with super page > fork/ no exec > The problem can happen because the child shares the same memory over > it's complete lifetime. > The parent can get it's super pages fragmented over time. > > I don't see a use case for scenario A, because vfork is there since > over 16 years. > I use fork myself, because it is easier sometimes, but people writing > big programms such as squid should know better. > If squid doesn't use vfork they likely have a reason. > With scenario C I don't see how vfork can help, since this is not a legal > case for vfork. > I use quid myself, but don't know how it handles it's childs. > But isn't the whole story about such slave childs that they share memory > with the master? - How can vfork be solution for this case? > How can fragmentation of super pages be avoided at all? In Linda's case it was a fork to run a log rotation binary, so it was A). For C) I think you would want to map the pages MAP_SHARED (or use minherit(2) with INHERIT_SHARE) in which case they would not be COW'd on fork() and you would keep the superpages. Assuming that you explicitly want to share the memory with your child processes you already have to do this to really do sharing anyway. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 22:29:54 2009 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 C51AE1065676 for ; Thu, 10 Dec 2009 22:29:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 6522E8FC15 for ; Thu, 10 Dec 2009 22:29:54 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A5CA21CEBB; Thu, 10 Dec 2009 23:29:53 +0100 (CET) Date: Thu, 10 Dec 2009 23:29:53 +0100 From: Ed Schouten To: Gary Jennejohn Message-ID: <20091210222953.GH64905@hoeg.nl> References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> <20091210135102.3434e5cf@ernst.jennejohn.org> <20091210125927.GB64905@hoeg.nl> <20091210132554.GC64905@hoeg.nl> <20091210162424.674e2db3@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d0pUq+GjfRcwe6V7" Content-Disposition: inline In-Reply-To: <20091210162424.674e2db3@ernst.jennejohn.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.org Subject: Re: [Patch] Updated termcap entries for xterm 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, 10 Dec 2009 22:29:54 -0000 --d0pUq+GjfRcwe6V7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Gary Jennejohn wrote: > On Thu, 10 Dec 2009 14:25:54 +0100 > Ed Schouten wrote: > > Any testers, before I commit this patch to HEAD? > >=20 >=20 > I tried it with a "real" xterm and mrxvt and see no regressions. However, > I didn't try it with a VT as xterm. I couldn't find any regressions either, so I just committed it to HEAD. It turns out it did improve the situation for Terminal.app a little, so I am going to MFC it after all. Thanks for {testing,reporting,etc}! --=20 Ed Schouten WWW: http://80386.nl/ --d0pUq+GjfRcwe6V7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkshdmEACgkQ52SDGA2eCwWLswCfWYgEMg0bWELGqc5L79xCso28 wmUAn2yVeJzvCoQfcMeCnHRq0RD5d4Yl =Y6ZN -----END PGP SIGNATURE----- --d0pUq+GjfRcwe6V7-- From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 11 05:56:29 2009 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 E7A381065670 for ; Fri, 11 Dec 2009 05:56:29 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2D08FC12 for ; Fri, 11 Dec 2009 05:56:29 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 51A20EB4741; Fri, 11 Dec 2009 07:56:28 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 30AD245303; Fri, 11 Dec 2009 07:56:28 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CWm4uNhbN7k; Fri, 11 Dec 2009 07:56:28 +0200 (EET) Received: from kobe.laptop (ppp-94-64-229-194.home.otenet.gr [94.64.229.194]) by mail.ceid.upatras.gr (Postfix) with ESMTP id DE26B452FB; Fri, 11 Dec 2009 07:56:27 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nBB5uQYC099703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 07:56:27 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nBB5uOFF099698; Fri, 11 Dec 2009 07:56:24 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Ed Schouten In-Reply-To: <20091210124222.GA64905@hoeg.nl> (Ed Schouten's message of "Thu, 10 Dec 2009 13:42:22 +0100") References: <86d42pjc1n.fsf@bifteki.lan> <20091209122532.2c55aa22@ernst.jennejohn.org> <86ws0w4c8e.fsf@ds4.des.no> <20091209123246.22b9ecc3@ernst.jennejohn.org> <20091210104430.1381356nnmx30okk@webmail.leidinger.net> <20091210124222.GA64905@hoeg.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (berkeley-unix) Date: Fri, 11 Dec 2009 07:56:17 +0200 Message-ID: <87fx7if3zy.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: Alexander Leidinger , freebsd-hackers@freebsd.org Subject: Re: old/unupdated xterm entries in termcap db 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, 11 Dec 2009 05:56:30 -0000 --=-=-= On Thu, 10 Dec 2009 13:42:22 +0100, Ed Schouten wrote: > Hello Alexander, others, > > * Alexander Leidinger wrote: >> The practical attitude should be coordinated with ed@ (CCed), as he >> switched the console in 9-current to be an xterm, and AFAIR it does >> not support as much colors as the real xterm. Maybe there is a >> reason to not update it. > > So the idea is to make TERM=xterm use 256 colors? Even though I think > having more colors would be awesome, I think many things would break. How about an "xterm" entry with 8 fg and 8 bg colors and a separate "xterm-256color" entry with 256 colors? I know, from our personal chat sessions, that the original drive behind Leonidas' patch to termcap was to make it possible for Emacs and vim to highlight/format code with more than 8 colors. This *is* useful for X11-based xterm windows but it may be less useful for vty terminals. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAksh3wcACgkQ1g+UGjGGA7ZROgCfc2YONQGOf/7kpfrHfnwqpenZ QrgAoL8zL5OkR7BuF179bMIgWzjUnjeI =vXnQ -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 12 09:44:05 2009 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 9DCAB106566C for ; Sat, 12 Dec 2009 09:44:05 +0000 (UTC) (envelope-from gatinhodosseussonhos@hotmail.com) Received: from snt0-omc3-s35.snt0.hotmail.com (snt0-omc3-s35.snt0.hotmail.com [65.55.90.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6818FC15 for ; Sat, 12 Dec 2009 09:44:05 +0000 (UTC) Received: from SNT102-W31 ([65.55.90.136]) by snt0-omc3-s35.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Dec 2009 01:44:04 -0800 Message-ID: X-Originating-IP: [187.52.21.29] From: Phillip Spring To: , Date: Sat, 12 Dec 2009 10:44:04 +0100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 12 Dec 2009 09:44:04.0887 (UTC) FILETIME=[A48C6270:01CA7B0F] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Request for information - timers, hz, interrupts 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, 12 Dec 2009 09:44:05 -0000 fact: =20 I had to clean up a motherboard to boot Suse 10.2 kernel. I think that dust and dead insects are for Windows 2003 only. =20 dog -- now with the right sender name :) =20 =20 > To: freebsd-hackers@freebsd.org > From: ivoras@freebsd.org > Date: Fri=2C 4 Dec 2009 15:52:39 +0100 > Subject: Request for information - timers=2C hz=2C interrupts >=20 > For a long time=2C at least in the 6-stable timeframe=2C I was used to=20 > seeing timer interrupts going at the frequency of 2*HZ=2C e.g. this is=20 > from 6.4-RELEASE: >=20 > kern.clockrate: { hz =3D 250=2C tick =3D 4000=2C profhz =3D 166=2C stathz= =3D 33 } > debug.psm.hz: 20 >=20 > cpu0: timer 6789885563 499 > cpu2: timer 6789885538 499 > cpu1: timer 6789885538 499 > cpu3: timer 6789885537 499 >=20 > Then sometime in 7.x this changed to 4*HZ=2C which continues in 8.x=2C e.= g.=20 > from 7.2-RELEASE: >=20 > kern.clockrate: { hz =3D 250=2C tick =3D 4000=2C profhz =3D 1000=2C stath= z =3D 142 } > kern.hz: 250 >=20 > cpu0: timer 1368329715 988 > cpu1: timer 1368324640 988 > cpu2: timer 1367642854 988 > cpu3: timer 1367642874 988 >=20 > I'm not very worried about it (though maybe laptop users might be=20 > because of potential power drainage) but would like to know the=20 > explanation behind it. >=20 > Presumably it has something to do with profhz but what and why? There=20 > isn't an obvious correlation between profhz frequency in 6.x and HZ and=20 > in 7.x. and HZ. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe=2C send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" =20 _________________________________________________________________ Windows 7: agora com conex=F5es autom=E1ticas de rede. Conhe=E7a. http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=3D1539= From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 12 13:38:48 2009 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 F2C04106568F for ; Sat, 12 Dec 2009 13:38:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCAEE8FC19 for ; Sat, 12 Dec 2009 13:38:48 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5D8E146B0D; Sat, 12 Dec 2009 08:38:48 -0500 (EST) Date: Sat, 12 Dec 2009 13:38:48 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nate Eldredge In-Reply-To: Message-ID: References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE 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, 12 Dec 2009 13:38:49 -0000 On Thu, 10 Dec 2009, Nate Eldredge wrote: > What about using posix_spawn(3)? This is implemented in terms of vfork(), > so you'll gain the same performance advantages, but it avoids many of > vfork's pitfalls. Also, since it's a POSIX standard function, you needn't > worry that it will go away or change its semantics someday. Just as a note here: while we do posix_spawn(3) as a library function, Mac OS X does it as a system call. As a result, they can implement certain spawn flags that we can't, among others, the ability to have the newly created process/image be suspended before its first instruction executes. This would be very useful when debugging the runtime linker, among other things. On the other hand, it's quite a complex kernel code path... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 12 19:50:53 2009 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 AF5E91065697 for ; Sat, 12 Dec 2009 19:50:53 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7895C8FC15 for ; Sat, 12 Dec 2009 19:50:53 +0000 (UTC) Received: by pxi12 with SMTP id 12so517831pxi.3 for ; Sat, 12 Dec 2009 11:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1cV78V0iUzvhTikSn/70vjruAB+hySEepUSP0WjjERw=; b=Gco3PaCK5H0anUgXXLMfeOzuZzZTbK6Ja+bIeMnBZEXjNQ5P5VKKvSGZXlUbVJ+6NB 5FEQbIGkQ90lWXXllBaIqX3XGHh2NGBLwaZe+f9qXWZwMKUFJdc9CwFYzYlFOgPnyJji B6nvdeYGc+0Vnn/2b2kVmpZjxJAZFTtJk9DIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=B78RmGb52JZKl0pEJDJOJF/jlXFuCUWFJs/A+SEpLdeO9rFqDqmf4w1vdxmFXqe/Hy BizdBuCWdiPNZTass/wD5EWF6wDkfG5YfOnD2EcRFqWm1BQPxJn39orR/xvgRM0BiCLt 4YFbYxdlcuuSZqD48xC1MoyuSNNY681cjVayM= MIME-Version: 1.0 Received: by 10.143.128.2 with SMTP id f2mr1807701wfn.295.1260647452798; Sat, 12 Dec 2009 11:50:52 -0800 (PST) In-Reply-To: <20091210145052.GX20668@cicely7.cicely.de> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> Date: Sat, 12 Dec 2009 13:50:52 -0600 Message-ID: From: Alan Cox To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt , alc@cs.rice.edu Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 19:50:53 -0000 On Thu, Dec 10, 2009 at 8:50 AM, Bernd Walter wrote: > On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote: > > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: > > > It's not clear to me if this might be a problem with the superpages > > > implementation, or if squid does something particularly horrible to > > > its memory when it forks to cause this, but I wanted to ask about it > > > on the list in case somebody who understands it better might know > > > whats going on. :-) > > > > I talked with Alan Cox some about this off-list and there is a case that > can > > cause this behavior if the parent squid process takes write faults on a > > superpage before the child process has called exec() then it can result > in > > superpages being fragmented and never reassembled. Using vfork() should > > prevent this from happening. It is a known issue, but it will probably > be > > some time before it is addressed. There is lower hanging fruit in other > areas > > in the VM that will probably be worked on first. > > For me the whole threads puzzles me. > Especially because vfork is often called a solution. > > Scenario A > Parent with super page > fork/exec > This problem can happen because there is a race. > The parent now has it's super pages fragmented permanently!? > the child throws away his pages because of the exec!? > > Scenario B > Parent with super page > vfork/exec > This problem won't happen because the child has no pseudo copy of the > parents memory and then starts with a completely new map. > > Scenario C > Parent with super page > fork/ no exec > The problem can happen because the child shares the same memory over > it's complete lifetime. > The parent can get it's super pages fragmented over time. > > I'm not sure how you are defining "problem". If we define "problem" as I would, i.e., that "re-promotion can never occur", then Scenario C is not a problem scenario, only Scenario A is. The source of the problem in Scenario A is basically that we have two ways of handling copy-on-write faults. Before the exec() occurs, copy-on-write faults are handled as you might intuit from the name, a new physical copy is made. If the entirety of the 2MB region is written to before the exec(), then this region will be promoted to a superpage. However, once the exec() occurs, copy-on-write faults are "optimized". Specifically, the kernel recognizes that the underlying physical page is no longer shared with the child and simply restores write access to it. It is the combination of these two methods that effectively blocks re-promotion because the underlying 4KB physical pages within a 2MB region are no longer contiguous. In other words, once the first page within a region has been copied, you have a choice to make: Do you perform avoidable copies or do you abandon the possibility of ever creating a superpage. The former has a significant one-time cost and the latter has a small recurring cost. Not knowing how much the latter will add up to, I chose the former. However, that choice may change in time, particularly, if I find an effective heuristic for choosing between the two options. Anyway, please keep trying superpages with large memory applications like this. Reports like this help me to prioritize my efforts. Regards, Alan