From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 7 14:58:45 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055D016A468 for ; Sun, 7 Oct 2007 14:58:45 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id CE8BB13C467 for ; Sun, 7 Oct 2007 14:58:44 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 9CEC417391; Sun, 7 Oct 2007 09:38:06 -0500 (CDT) Date: Sun, 7 Oct 2007 09:38:06 -0500 From: "Christian S.J. Peron" To: dexterclarke@Safe-mail.net Message-ID: <20071007143806.GA65868@sub.vaned.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: audit doesn't seem to be working correctly. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2007 14:58:45 -0000 I think I have isolated the problem and I am working on a fix. For now if you want to experiement with audit you should be able to work around this bug by adding an entry into /etc/security/audit_user. Thanks for your report. On Thu, Oct 04, 2007 at 12:21:19AM -0400, dexterclarke@Safe-mail.net wrote: > After reading this article: > > http://www.regdeveloper.co.uk/2006/11/13/freebsd_security_event_auditing/ > > I decided to try audit. I edited /etc/security/audit_control > as the article (and the handbook example) shows: > > dir:/var/audit > flags:lo,+ex > minfree:20 > naflags:lo > policy:cnt > filesz:0 > > But having restarted auditd, I don't see audit events for > process execution being generated. However, if I do this: > > dir:/var/audit > flags:lo > minfree:20 > naflags:lo,+ex > policy:cnt > filesz:0 > > I get audit records for users executing programs. This seems > completely wrong to me. Why are these events being classed as > non-attributable when they're clearly being created by > authenticated users? > > I am running 6.2-RELEASE-p7 which is vanilla apart from the > addition of options MAC, AUDIT and VESA. > > -- > dc > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 8 14:13:16 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37FB816A468 for ; Mon, 8 Oct 2007 14:13:16 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id B84ED13C469 for ; Mon, 8 Oct 2007 14:13:15 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so975691nfb for ; Mon, 08 Oct 2007 07:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=4yrQ0PfrtiJPkENI6d+xKnJ1R2F/LYmy8/p6Qk+xpEQ=; b=BfcAOpgfPIzI10qefkZzunbBXkJF6S5X2ulyT2Z5gd8SQhbzmsemV/Q0M/3t5MNKMTn1AM1UlFvgdbIv5vhxvih7s+973TGshLAQJfjmgfD0HHjrpeojcoW+roLsckuq5BTkcgUZAYWv1g3NXe6LZyrEBwVdEEMX1nlOhItwyvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=TLN527J1mS3djHu0lzOMgDj8Fn3PlIBxfDA2MTRrjqlkSJoeTlq+ZhL5zU8OJuEDgUXDvfU4ED+ElRl8nkriYlKrz9SbZYfIuG5WVAeyDRoaUiS8RnpqR8dy+qErDpmlsCp9GVuII5Q/rhYUvbxA8rDGzrjeET2rusCgMgmVMV0= Received: by 10.86.49.13 with SMTP id w13mr5154658fgw.1191852794297; Mon, 08 Oct 2007 07:13:14 -0700 (PDT) Received: from ?192.168.1.185? ( [213.152.137.35]) by mx.google.com with ESMTPS id y18sm11630169fkd.2007.10.08.07.13.12 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Oct 2007 07:13:13 -0700 (PDT) Message-ID: <470A3AB2.4070604@gmail.com> Date: Mon, 08 Oct 2007 18:12:02 +0400 From: sam User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: linuxolator problem on i386 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, 08 Oct 2007 14:13:16 -0000 >>>/ On Monday 24 September 2007, sam wrote: />>/ /> >>>/ # mount|grep linux />>>/ linprocfs on /usr/compat/linux/proc (linprocfs, local) />>>/ linsysfs on /usr/compat/linux/sys (linsysfs, local) />>/ />>>/ # pkg_info | grep linux />>>/ linux_base-fc6-6_3 Base set of packages needed in Linux mode (for />>>/ i386/amd64) />>/ />>>/ [private links to debug.log & ktrace.out] />>>/ />>>/ please send me message after downloaded this files (for removing) ///>//>>/ cross-posting: />>>/ http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960. />>>/ html />>/> />/>> I haven't tried it on i386 yet, but I know that this works on amd64 with linux />/>> 2.4 compat and linux_base-fc4 on FreeBSD 7. />>/ />/ - Pieter />/ />/ /> yes, working > but, this trouble in kernel > new linux-software require linux 2.6 support Hello! http://www.freebsd.org/cgi/query-pr.cgi?pr=117010 please help, any solutions ... /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 8 18:21:13 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90FC616A476 for ; Mon, 8 Oct 2007 18:21:13 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id DF87113C494 for ; Mon, 8 Oct 2007 18:21:12 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id DCA6C1736A; Mon, 8 Oct 2007 13:18:28 -0500 (CDT) Date: Mon, 8 Oct 2007 13:18:28 -0500 From: "Christian S.J. Peron" To: dexterclarke@Safe-mail.net Message-ID: <20071008181828.GA75350@sub.vaned.net> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: audit doesn't seem to be working correctly. 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, 08 Oct 2007 18:21:13 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please try the attached patch: cp audit.diff /usr/src/sys patch < audit.diff Recompile your kernel. If please report success/failure to me. On Thu, Oct 04, 2007 at 12:21:19AM -0400, dexterclarke@Safe-mail.net wrote: > After reading this article: > > http://www.regdeveloper.co.uk/2006/11/13/freebsd_security_event_auditing/ > > I decided to try audit. I edited /etc/security/audit_control > as the article (and the handbook example) shows: > > dir:/var/audit > flags:lo,+ex > minfree:20 > naflags:lo > policy:cnt > filesz:0 > > But having restarted auditd, I don't see audit events for > process execution being generated. However, if I do this: > > dir:/var/audit > flags:lo > minfree:20 > naflags:lo,+ex > policy:cnt > filesz:0 > > I get audit records for users executing programs. This seems > completely wrong to me. Why are these events being classed as > non-attributable when they're clearly being created by > authenticated users? > > I am running 6.2-RELEASE-p7 which is vanilla apart from the > addition of options MAC, AUDIT and VESA. > > -- > dc > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer --4Ckj6UjgE2iN1+kY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="audit.diff" Index: kern/kern_prot.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v retrieving revision 1.211 diff -u -r1.211 kern_prot.c --- kern/kern_prot.c 12 Jun 2007 00:11:59 -0000 1.211 +++ kern/kern_prot.c 8 Oct 2007 17:59:34 -0000 @@ -1830,6 +1830,7 @@ #ifdef MAC mac_copy_cred(src, dest); #endif + dest->cr_flags = src->cr_flags; } /* Index: security/audit/audit.c =================================================================== RCS file: /home/ncvs/src/sys/security/audit/audit.c,v retrieving revision 1.33 diff -u -r1.33 audit.c --- security/audit/audit.c 1 Jul 2007 20:51:30 -0000 1.33 +++ security/audit/audit.c 8 Oct 2007 17:59:43 -0000 @@ -344,7 +344,7 @@ * Decide whether to commit the audit record by checking the error * value from the system call and using the appropriate audit mask. */ - if (ar->k_ar.ar_subj_auid == AU_DEFAUDITID) + if ((ar->k_ar_commit & AR_AMASK_GLOBAL) != 0) aumask = &audit_nae_mask; else aumask = &ar->k_ar.ar_subj_amask; @@ -461,7 +461,7 @@ * event mask or the process audit mask. */ auid = td->td_ucred->cr_audit.ai_auid; - if (auid == AU_DEFAUDITID) + if ((td->td_ucred->cr_flags & CRED_AMASK_GLOBAL) != 0) aumask = &audit_nae_mask; else aumask = &td->td_ucred->cr_audit.ai_mask; @@ -494,6 +494,13 @@ td->td_ar = audit_new(event, td); else td->td_ar = NULL; + /* + * If we have an audit record, and it's referencing the global + * preselection mask, set the AR_MASK_GLOBAL flag so we can make + * the distinction between the two. + */ + if (td->td_ar != NULL && aumask == &audit_nae_mask) + td->td_ar->k_ar_commit |= AR_AMASK_GLOBAL; } /* @@ -540,6 +547,7 @@ { bzero(&cred->cr_audit, sizeof(cred->cr_audit)); + cred->cr_flags |= CRED_AMASK_GLOBAL; } /* Index: security/audit/audit_private.h =================================================================== RCS file: /home/ncvs/src/sys/security/audit/audit_private.h,v retrieving revision 1.16 diff -u -r1.16 audit_private.h --- security/audit/audit_private.h 1 Jun 2007 21:58:58 -0000 1.16 +++ security/audit/audit_private.h 8 Oct 2007 17:59:43 -0000 @@ -86,6 +86,8 @@ #define AR_PRESELECT_USER_TRAIL 0x00004000U #define AR_PRESELECT_USER_PIPE 0x00008000U +#define AR_AMASK_GLOBAL 0x00010000U + /* * Audit data is generated as a stream of struct audit_record structures, * linked by struct kaudit_record, and contain storage for possible audit so Index: security/audit/audit_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/security/audit/audit_syscalls.c,v retrieving revision 1.21 diff -u -r1.21 audit_syscalls.c --- security/audit/audit_syscalls.c 27 Jun 2007 17:01:15 -0000 1.21 +++ security/audit/audit_syscalls.c 8 Oct 2007 17:59:43 -0000 @@ -547,6 +547,7 @@ newcred->cr_audit.ai_termid.at_addr[0] = ai.ai_termid.machine; newcred->cr_audit.ai_termid.at_port = ai.ai_termid.port; newcred->cr_audit.ai_termid.at_type = AU_IPv4; + newcred->cr_flags &= ~CRED_AMASK_GLOBAL; td->td_proc->p_ucred = newcred; PROC_UNLOCK(td->td_proc); crfree(oldcred); @@ -604,6 +605,7 @@ if (error) goto fail; newcred->cr_audit = aia; + newcred->cr_flags &= ~CRED_AMASK_GLOBAL; td->td_proc->p_ucred = newcred; PROC_UNLOCK(td->td_proc); crfree(oldcred); Index: sys/ucred.h =================================================================== RCS file: /home/ncvs/src/sys/sys/ucred.h,v retrieving revision 1.55 diff -u -r1.55 ucred.h --- sys/ucred.h 7 Jun 2007 22:27:15 -0000 1.55 +++ sys/ucred.h 8 Oct 2007 17:59:43 -0000 @@ -58,6 +58,8 @@ #define cr_endcopy cr_label struct label *cr_label; /* MAC label */ struct auditinfo_addr cr_audit; /* Audit properties. */ + u_int cr_flags; /* Flags for this credential */ +#define CRED_AMASK_GLOBAL 0x00000001 }; #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ --4Ckj6UjgE2iN1+kY-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 8 19:07:13 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D41416A41B; Mon, 8 Oct 2007 19:07:13 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4BD13C468; Mon, 8 Oct 2007 19:07:13 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id B89171736A; Mon, 8 Oct 2007 14:04:29 -0500 (CDT) Date: Mon, 8 Oct 2007 14:04:29 -0500 From: "Christian S.J. Peron" To: "Christian S.J. Peron" Message-ID: <20071008190429.GA75575@sub.vaned.net> References: <20071008181828.GA75350@sub.vaned.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071008181828.GA75350@sub.vaned.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: dexterclarke@Safe-mail.net, freebsd-hackers@freebsd.org Subject: Re: audit doesn't seem to be working correctly. 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, 08 Oct 2007 19:07:13 -0000 On Mon, Oct 08, 2007 at 01:18:28PM -0500, Christian S.J. Peron wrote: > Please try the attached patch: > > cp audit.diff /usr/src/sys > patch < audit.diff > > Recompile your kernel. > > If please report success/failure to me. > Actually.. ignore this patch. Sorry about that. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 9 04:13:07 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F06B16A419 for ; Tue, 9 Oct 2007 04:13:07 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id 39F9913C43E for ; Tue, 9 Oct 2007 04:13:07 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1If6Su-0005TB-Sj; Tue, 09 Oct 2007 00:13:04 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=VfaAPaK2mkSl97Ek1zptW+YFgFbp79sZ9YbpNSj8g897/C2Wpki6+3hXV/LiUtZD aI8T8D/9X2CPWLFfJo0XorudHCFWTSdMjwzOEChVQFrLPb9v4wgR7dqxIORrWxiM 8xVvBlMgRyjC67Z3YHqWgEkDvgb4dfM6E+yUIXCI1No=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Tue, 9 Oct 2007 00:13:04 -0400 From: dexterclarke@Safe-mail.net To: csjp@FreeBSD.org X-SMType: Regular X-SMRef: N1-tA4f-jLfU7 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: mOPGi47zMZR5ZQXUV5CDkQFJn576yQhSRC7iYQ6fDLHSp7ftZQ/X1iBLK5iDFrEZ 6TqmrNgs1d75XGrtW8shfj9ROTn0gDAqAu6sUqnz117ock30ZbKS+O/QZtH2QdhQ UOAAH4FB0cE/qINbC4zW1hSg8WHBbG4ZdrjBB/uLbE0= Cc: freebsd-hackers@freebsd.org Subject: Re: audit doesn't seem to be working correctly. 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, 09 Oct 2007 04:13:07 -0000 > Please try the attached patch: > > cp audit.diff /usr/src/sys > patch < audit.diff > > Recompile your kernel. > > If please report success/failure to me. > I completely missed the replies to this thread. At least I now know it's due to an actual problem rather than my inability to follow instructions! thanks! -- dc From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 9 05:18:30 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC5D16A418; Tue, 9 Oct 2007 05:18:30 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id B9C9E13C44B; Tue, 9 Oct 2007 05:18:30 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id D42AC17340; Tue, 9 Oct 2007 00:15:55 -0500 (CDT) Date: Tue, 9 Oct 2007 00:15:55 -0500 From: "Christian S.J. Peron" To: dexterclarke@Safe-mail.net Message-ID: <20071009051555.GA49311@sub.vaned.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org, csjp@FreeBSD.org Subject: Re: audit doesn't seem to be working correctly. 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, 09 Oct 2007 05:18:31 -0000 On Tue, Oct 09, 2007 at 12:13:04AM -0400, dexterclarke@Safe-mail.net wrote: [..] > > I completely missed the replies to this thread. At least > I now know it's due to an actual problem rather than my > inability to follow instructions! > Well, The problem that I thought was there, wasn't actually there, which is why I said to ignore the patch :) I've tried to reproduce the problems you are seeing but I have not been able to. So far I've tried on -CURRENT and RELENG_6. We are aware of some issues on RELENG_6_2 specifically with !i386 architectures (i.e. amd64, sparc64 etc). Is it possible you can send me: (1) The output to uname -a (2) Your /etc/security directory (3) How are you logging in to this machine, SSH? Telnet? (3) is important because the login program will be responsible for setting up the audit ID and preselection masks. Hopefully with this information, we can get to the bottom of this. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 10 19:00:54 2007 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387EA16A417; Wed, 10 Oct 2007 19:00:54 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0003D13C465; Wed, 10 Oct 2007 19:00:53 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 8A4808FD39; Wed, 10 Oct 2007 12:34:14 -0600 (MDT) Date: Wed, 10 Oct 2007 12:34:14 -0600 From: Brad Davis To: hackers@FreeBSD.org Message-ID: <20071010183414.GO26700@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Status Reports for the Third Quarter of 2007 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2007 19:00:54 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between July and October 2007. The sixth EuroBSDCon was held in Denmark in September. The Google Summer of Code project came to a close and lots of participants are working getting their code merged back into FreeBSD. The bugs in the FreeBSD HEAD branch are being shaked out and it is being prepared for the FreeBSD 7 branching. If your are curious about what's new in FreeBSD 7.0 we suggest reading Ivan Voras' excellent summary here . Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Google Summer of Code * Summer of Code * finstall * FreeBSD-update Front End * gvirstor * MTund - Magic Tunnel Daemon * Porting OpenBSD's sysctl Hardware Sensors Framework to FreeBSD * Ports Collection infrastructure improvements Projects * Apple's MacBook on FreeBSD * Multi-link PPP daemon (MPD) 5.x * Multicast DNS * Porting Linux KVM to FreeBSD * USB FreeBSD Team Reports * FreeBSD.org Admins Report * Ports Collection Network Infrastructure * Network Stack Virtualization Documentation * PC-BSD Handbook * The Hungarian Documentation Project * The Spanish Documentation Project Miscellaneous * EuroBSDcon 2007 * GNATS graphs __________________________________________________________________ Apple's MacBook on FreeBSD URL: http://wiki.freebsd.org/AppleMacbook Contact: Rui Paulo The Summer of Code project went well and we reached interesting results. At least the Mac Mini should be fully supported by now. Regarding the other Apple systems, we still need to polish some edges. Open tasks: 1. Integrate rpaulo-macbook p4 branch into CVS. 2. Continue the work on the remaining issues. __________________________________________________________________ EuroBSDcon 2007 URL: http://2007.EuroBSDCon.org/ Contact: EuroBSDCon 2007 Organizing Committee The sixth EuroBSDCon went well. 215 people attended the conference. Feedback has been very positive. At the conference we had a Best Talk contest. Steven Murdoch, Isaac Levy and Pawel Jakub "zfs-man" Dawidek each received a prize for their fantastic talks. Also over 300 pictures from the conference has been uploaded to Flickr with the tag EuroBSDCon2007 Videos and slides from the talks are now online at the conference website. We thank our speakers for graciously having permitted recording and publication of their talks EuroBSDCon 2008 will take place in Strassbourg. __________________________________________________________________ finstall URL: http://wiki.freebsd.org/finstall Contact: Ivan Voras The "finstall" project is about the new graphical installer for FreeBSD. The basic frameworks (both client-side and server-side) are done during the SoC 2007 and it's ready for major new features to be implemented. This project should yield an usable installer for 7.0-RELEASE. Open tasks: 1. - There are several patches needed for finstall's operation that are still waiting on re@'s approval (unionfs, pwd, kbdmap). Finstall will be late or unusuable until these patches are committed. 2. - After the patches are committed, there are several exciting features to be implemented, among others ZFS and GEOM RAID support. __________________________________________________________________ FreeBSD-update Front End URL: http://developer.berlios.de/projects/facund/ Contact: Andrew Turner The freebsd-update front end is able to wait for freebsd-update to download a new set of patches to apply. It can then install and rollback the patches on either the local computer or over a SSH tunnel. Since the end of the Summer of Code work has moved to BerliOS. The focus has been on writing tests for the front end, back end and communication library. The library has had tests written for most of it while the front and back ends have none. Open tasks: 1. Write more tests. __________________________________________________________________ FreeBSD.org Admins Report Contact: FreeBSD.org Admins Team admins@FreeBSD.org <> Over the last couple of months several FreeBSD.org systems have been experiencing hardware issues. This included the main web-server www.FreeBSD.org which had a bad fan. The bad fan has been replaced so it should hopefully be stable again. In general we are working on replacing older hardware with newer systems and consolidating machine functions in the process. Since August most FreeBSD.org services have been available via IPv6 with connectivity provided from ISC using a tunnel. To honor the "Eat your own dog-food" principle the first two FreeBSD.org infrastructure systems have been upgraded to FreeBSD 7 and more are being upgraded as time permit. Due to heavy load on the project's Perforce and CVS server the two services are being moved to seperate systems to improve performance of both CVS and Perforce. __________________________________________________________________ GNATS graphs URL: http://people.freebsd.org/~edwin/gnats/ Contact: Edwin Groothuis With the leaving of bsd@, we lost the GNATS statistics webpages. On this URL I generate a new set of graphs, right now a subset of what bsd@ had, hopefully a superset of that in the future. __________________________________________________________________ gvirstor URL: http://wiki.freebsd.org/gvirstor Contact: Ivan Voras GEOM_VIRSTOR (virtual disk space / over-commit GEOM class) has been committed to 7-CURRENT and will ship in 7.0-RELEASE. Thanks to Pawel Jakub Dawidek and others who have made this possible. Open tasks: 1. It needs wider exposure and testing. __________________________________________________________________ MTund - Magic Tunnel Daemon URL: http://wiki.freebsd.org/MTund URL: http://www.inf.ethz.ch/personal/mharvan/docs/eurobsdcon.pdf Contact: Matus Harvan IP can easily be tunneled over a plethora of network protocols at various layers, such as IP, ICMP, UDP, TCP, DNS, HTTP, SSH. While a direct connection may not always be possible due to a firewall, the IP packets could be encapsulated as payload in other protocols, which would get through. However, each such encapsulation requires the setup of a different program and the user has to manually probe different encapsulations to find out which of them works in a given environment. MTund is a tunneling daemon using run-time loadable plugins for the different encapsulations. It automagically selects the best encapsulation in each environment and can fail over to another encapsulation. Several plugins have been implemented and the daemon supports multiple concurrent clients. Note that the project originally started under the name of Super Tunnel Daemon, but was later renamed to Magic Tunnel Daemon (MTund). Open tasks: 1. Config file format and parser. 2. More plugins (http, ssh, ...). __________________________________________________________________ Multi-link PPP daemon (MPD) 5.x URL: http://sourceforge.net/projects/mpd/ URL: http://mpd.sourceforge.net/doc5/mpd5.html Contact: Alexander Motin New mpd-5.x branch has been started and first public release is planned soon. The main goal of the new branch is to implement new operation principles based on dynamic on-demand links/bundles creation. There are several benefits received from new design: * Significantly simplified server configuration - no more tons of predefined links/bundles, * New multilink implementation - no more predefined link-bundle relations, * Call forwarding (LAC, PAC, TSA) like in Cisco VPDN setups can now be enabled/configured depending on peer auth name/domain. Open tasks: 1. L2TP auth proxying support. __________________________________________________________________ Multicast DNS URL: http://wiki.freebsd.org/MulticastDNS Contact: Fredrik Lindberg The project (started out as a GSoC 2007 project) aims to provide a complete Multicast DNS and Service Discovery suite. Much progress have been made since the last status report and the project is slowly reaching a usable state. Most features are complete and the current focus is on fixing outstanding bugs, fine tuning and testing. However, there are still a few open tasks (see below). More information and snapshots can be found at the wiki page. Open tasks: 1. Avahi library wrapper. 2. dns_sd (Apple) library wrapper. 3. Testing (always welcome). __________________________________________________________________ Network Stack Virtualization URL: http://imunes.tel.fer.hr/virtnet/ Contact: Marko Zec The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail-like environmens, each maintaining its private network interface set, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more. The prototype, which is kept in sync with FreeBSD -CURRENT, should be sufficiently stable for testing and experimental use. The project's web page includes weekly code snapshots, as well as a virtualized FreeBSD system installed on a VMWare disk image available for download. The short-term goal is to deliver production-grade kernel support for virtualized networking for FreeBSD 7.0-RELEASE (as a snap-in kernel replacement), while continuing to keep the code in sync with -CURRENT for possible merging at a later date. __________________________________________________________________ PC-BSD Handbook URL: http://www.pcbsd.org URL: http://www.FreeBSD.org/handbook Contact: Murray Stokely Contact: Matt Olander Contact: Fukang Chen The PC-BSD derivative of FreeBSD is becoming increasingly popular for new users of BSD. Much of the content in the existing FreeBSD Handbook is directly applicable to PC-BSD. We are writing PC-BSD specific installation and port/packages chapters (PBI). These chapters will be checked into docs/en_US.ISO8859-1/books/pcbsd-handbook and will include some of the same chapters as the Handbook does, but with a different &os entity and possibly with some conditional changes in those chapter files. Open tasks: 1. More work is needed on a PC-BSD ports/packages chapter. Fukang may already have some work in this area so coordinate with him first. 2. More text is needed for the PC-BSD installation chapter to augment the screenshots that Fukang has collected. Contact him to coordinate. __________________________________________________________________ Porting Linux KVM to FreeBSD URL: http://feanor.sssup.it/~fabio/freebsd/lkvm/ Contact: Fabio Checconi Contact: Luigi Rizzo Linux KVM (Kernel-based Virtual Machine) is a software package that can be used to create virtual machines fully emulating x86 hardware on top of machines supporting Intel VT-x or AMD-V virtualization extensions, available on newer AMD and Intel processors, e.g., recent Athlon64, Core 2 Duo, Xeon and so on. Linux KVM has been ported to FreeBSD as a loadable kernel module, using the linux-kmod-compat port (in /usr/ports/devel/) to reuse as much as possible of the original source code, plus an userspace client consisting in a modified version of qemu, that uses KVM for the execution of its guests. The porting has been completed, many of the limitations present at the end of the Summer of Code have been removed and the known bugs have been fixed. Some configurations have been tested, FreeBSD-CURRENT i386 guests have been booted on Intel and AMD processors, both in i386 and amd64 (host) installations. Only one client at a time is supported by now and performance is not that exciting, but the project seems to be ready to receive wider testing. __________________________________________________________________ Porting OpenBSD's sysctl Hardware Sensors Framework to FreeBSD URL: http://wiki.freebsd.org/GSoC2007/cnst-sensors URL: http://cnst.livejournal.com/tag/GSoC2007 URL: http://cnst.livejournal.com/data/atom?tag=GSoC2007 URL: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-September/02172 2.html URL: http://p4web.freebsd.org//depot/projects/soc2007/cnst-sensors/?ac=83 Contact: Constantine A. Murenin Contact: Shteryana Shopova The GSoC2007/cnst-sensors project was about porting the sysctl hw.sensors framework from OpenBSD to FreeBSD. The project was successfully completed , committed into DragonFly BSD , and is now pending final review and integration into the FreeBSD's CVS tree (subject to the tree being unfrozen). The sensors framework provides a unified interface for storing, registering and accessing information about hardware monitoring sensors. Sensor types include, but are not limited to, temperature, voltage, fan RPM, time offset and logical drive status. In the OpenBSD base system, the framework spans sensor_attach(9) , sysctl(3) , sysctl(8) , systat(1) , sensorsd(8) , ntpd(8) and more than 50 drivers, ranging from I2C temperature sensors and Super I/O hardware monitors to IPMI and RAID controllers. Several third-party tools are also available, for example, a plug-in for Nagios and ports/sysutils/symon. As a part of this Google Summer of Code project, all core components of the framework were ported, including sysctl, systat and sensorsd. Some drivers for the most popular Super I/O Hardware Monitors were ported, too: it(4) , supporting most contemporary ITE Tech Super I/O, and lm(4) , supporting most contemporary Winbond Super I/O. Moreover, some existing FreeBSD drivers were converted to utilise the framework, for example, coretemp(4) . Open tasks: 1. Final Review and Commit __________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com URL: http://wiki.freebsd.org/gcc4 Contact: Mark Linimon The ports count is over 17,700. The PR count has decreased a bit to just over 700. There have been 6 experimental runs on the build cluster. The resulting commits include the fixup of last year's DESTDIR changes, the refactoring of perl bits into bsd.perl.mk, the update of xorg from 7.2 to 7.3, the upgrade of all of the autoconf dependencies to the latest version (wherever possible), and the upgrade of Python to 2.5. This effort has resulted in the fewest number of 'open' portmgr PRs in quite some time. portmgr appreciates all the people who worked with us on these patches, and people's patience as we catch up. As well, lofi@ committed the upgrade of QT to 4.3.1. We have added 3 new committers since the last report. Open tasks: 1. GCC4.2 has been imported to the base for 7.0. Unfortunately, this broke a large number of ports. The ones that have not yet been fixed have now been flagged as 'broken' for both i386 and amd64, as appropriate. Please see the GCC4 status page (above) if you are able to help. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have many unmaintained ports. The packages on amd64 are lagging behind a bit; those on sparc64 require even more work. __________________________________________________________________ Ports Collection infrastructure improvements URL: http://wiki.freebsd.org/G%C3%A1borSoC2007 Contact: Gábor Kövesdán The two most important parts of this Summer of Code projects have been accomplished. The DESTDIR support for the Ports Collection has been rewritten to use a chrooted install. Now it is much more lightweight and easier to understand, but it works well for the most common cases, where it is supposed to be useful. The Perl parts of the Ports Collection infrastructure have been extracted into an own module. At the same time, a new version handling has been invented. You can find more info on the Wiki. __________________________________________________________________ Summer of Code URL: http://www.FreeBSD.org/projects/summerofcode-2007.html URL: http://googlesummerofcode.blogspot.com/2007/09/updates-from-freebsd.htm l URL: http://wiki.freebsd.org/SummerOfCode2007 Contact: Murray Stokely Contact: Robert Watson We're happy to report the successful conclusion of our third consecutive Google Summer of Code. By all accounts, the FreeBSD participation in this program was an unqualified success. We narrowed down the many impressive applications to 25 that were selected for funding and 92% of these completed successfully and were awarded the full $4,500 stipend. The FreeBSD Foundation was also granted $500 per student from Google for a total of $12,500. These student projects included security research, improved installation tools, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program. Three students have already been granted full src/ commit access to CVS and more are expected. At least 2 of our FreeBSD mentors will be meeting with Google organizers in Mountain View this month to discuss the program at the Mentor Summit. Open tasks: 1. Integration of student projects into FreeBSD -CURRENT. Several are currently blocked on the FreeBSD 7.0 code freeze, but we hope to see these contributions included in a future release. 2. Updating the ideas list. Many of the items listed there have been completed and we could always use new projects for next year's students and for others to work on throughout the year. http://www.FreeBSD.org/projects/ideas __________________________________________________________________ The Hungarian Documentation Project URL: http://www.freebsd.org/hu/docproj/hungarian.html URL: http://www.freebsd.org/hu/ URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ docproj%5fhu&HIDEDEL=NO Contact: Gabor Kovesdan Contact: Gabor Pali We have a new volunteer, Gabor Pali, who provided us some high-quality contributions. As a result, we have been able to add 5 new articles since the last status report. There is also an ongoing effort in the Perforce repository to translate the FreeBSD Handbook to Hungarian. Any kind of support is highly welcome. Open tasks: 1. Translate the Handbook. __________________________________________________________________ The Spanish Documentation Project URL: http://www.freebsd.org/doc/es_ES.ISO8859-1/articles/fdp-es/ Contact: J. Vicente Carrasco Vayá Contact: Gabor Kovesdan After a long break in this project, we started reviewing and refreshing our translations. We have to update the content to reflect the current state of the English version. There are a few parts written in a poor style, another task is to improve these a bit. Any kind of help is highly welcome. Open tasks: 1. Sync the website with the English version. 2. Sync the documentation with the English version. 3. Review the quality of poorly translated parts. 4. Add more translations. __________________________________________________________________ USB URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ usb/src/sys/dev/usb&HIDEDEL=NO URL: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/usb/s rc/sys/dev/usb/README Contact: Hans Petter Sirevaag Selasky During the last three months there has been a flush of changes going into the FreeBSD USB P4 project. The changes mainly consern the ability to support the USB device side and multi frame USB transfers. Up to date the FreeBSD USB stack has only supported the USB Host Side. Before Christmas 2007 the P4 USB project will offer USB device support and some simple USB device side implementations. Technically an USB device side driver will look very similar to an USB host side driver. Infact there will be very few differences. Support for multi frame USB transfers opens up the possibility to transfer multiple short-packet terminated USB frames to/from different memory locations resulting in only one interrupt on the USB Host Controller. More specific: I have implemented support for the "alt_next" pointer in the EHCI Transfer Descriptor. This should give a noticable increase in the maximum number of short-packet terminated BULK frames that can be transferred per second. I regularly get questions from people asking about when the USB P4 project will be merged into FreeBSD-current. The answer is not simple, but probably something like another year. The reason is not that the current code in the USB P4 project is not usable, but rather that the quality needs to be raised in means of making already good solutions more technically excellent, writing more documentation and styling the code. Ideas and comments with regard to the new USB API are welcome at freebsd-usb@freebsd.org. __________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 03:20:06 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B4C16A419 for ; Thu, 11 Oct 2007 03:20:06 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id A1F3C13C45D for ; Thu, 11 Oct 2007 03:20:05 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [10.30.3.4] (HELO granpasso.retis) by sssup.it (CommuniGate Pro SMTP 4.1.8) with SMTP id 34883019 for hackers@freebsd.org; Thu, 11 Oct 2007 04:08:48 +0200 Received: (qmail 14861 invoked from network); 11 Oct 2007 02:20:01 -0000 Received: from unknown (HELO granpasso.retis) (127.0.0.1) by localhost.retis with SMTP; 11 Oct 2007 02:20:01 -0000 Received: (from fabio@localhost) by granpasso.retis (8.14.1/8.14.1/Submit) id l9B2K1uD014859; Thu, 11 Oct 2007 04:20:01 +0200 (CEST) (envelope-from fabio@freebsd.org) X-Authentication-Warning: granpasso.retis: fabio set sender to fabio@freebsd.org using -f Date: Thu, 11 Oct 2007 04:20:01 +0200 From: Fabio Checconi To: hackers@freebsd.org Message-ID: <20071011022001.GC13480@gandalf.sssup.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: s223560@studenti.ing.unipi.it, netchild@freebsd.org, joel@freebsd.org Subject: Pluggable Disk Scheduler Project 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, 11 Oct 2007 03:20:06 -0000 Hi, is anybody working on the `Pluggable Disk Scheduler Project' from the ideas page? To better understand how GEOM works, and how a (non work conserving) disk scheduler can fit into it, I've written a very simple, yet working, prototype: http://feanor.sssup.it/~fabio/freebsd/g_sched/geom-sched-class.patch I'd like to take a better look at the problem and work on it, and I'd like to know what you think about it. After reading [1], [2] and its follow-ups the main problems that need to be addressed seem to be: o is working on disk scheduling worth at all? o Where is the right place (in GEOM) for a disk scheduler? o How can anticipation be introduced into the GEOM framework? o What can be an interface for disk schedulers? o How to deal with devices that handle multiple request per time? o How to deal with metadata requests and other VFS issues? I think that some answers need a little bit of experimenting with real code and real hardware, so here it is this attempt. The interface used in this toy prototype for the scheduler is something like that: typedef void *gs_init_t (struct g_geom *geom); typedef void gs_fini_t (void *data); typedef void gs_start_t (void *data, struct bio *bio); typedef void gs_done_t (void *data, struct bio *bio); struct g_gsched { const char *gs_name; /* Scheduler name. */ int gs_refs; /* Refcount, internal use. */ gs_init_t *gs_init; /* Called on geom creation. */ gs_fini_t *gs_fini; /* Called on geom destruction. */ gs_start_t *gs_start; /* Called on geom start. */ gs_done_t *gs_done; /* Called on geom done. */ LIST_ENTRY(g_gsched) glist; /* List of schedulers, internal use. */ }; The main idea is to allow the scheduler to enqueue the requests having only one (other small fixed numbers can be better on some hardware) outstanding request and to pass new requests to its provider only after the service of the previous one ended. The example scheduler in the draft takes the following approach: o a scheduling GEOM class is introduced. It can be stacked on top of disk geoms, and schedules all the requests coming from its consumers. I'm not absolutely sure that a new class is really needed but I think that it can simplify testing and experimenting with various solutions on the scheduler placement. o Requests coming from consumers are passed down immediately if there is no other request under service, otherwise they are queued in a bioq. o When a request is served the scheduler is notified, then it can pass down a new request, or, as in this toy anticipatory[3] scheduler, wait for a new request from the same process, or for a timeout to expire, and only after one of those events make the next scheduling decision. So, as I've said, I'd like to know what you think about the subject, if I'm missing something, if there is some kind of interest on this and if/how can this work proceed. Thanks in advance, fabio [1] http://wiki.freebsd.org/Hybrid [2] http://lists.freebsd.org/pipermail/freebsd-geom/2007-January/001854.html [3] The details of the anticipation are really not interesting as it is extremely simplified by purpose. [4] http://feanor.sssup.it/~fabio/freebsd/g_sched/ contains also an userspace client to experiment with the GEOM class. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 09:31:50 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4A6016A41B; Thu, 11 Oct 2007 09:31:50 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8E713C49D; Thu, 11 Oct 2007 09:31:49 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 017D113DE4E; Thu, 11 Oct 2007 10:07:31 +0200 (CEST) Received: from caracal.stud.ntnu.no (caracal.stud.ntnu.no [129.241.56.185]) by merke.itea.ntnu.no (Postfix) with ESMTP; Thu, 11 Oct 2007 10:07:30 +0200 (CEST) Received: by caracal.stud.ntnu.no (Postfix, from userid 2312) id C0C306240F4; Thu, 11 Oct 2007 10:07:34 +0200 (CEST) Date: Thu, 11 Oct 2007 10:07:34 +0200 From: Ulf Lilleengen To: Fabio Checconi Message-ID: <20071011080734.GA20897@stud.ntnu.no> References: <20071011022001.GC13480@gandalf.sssup.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011022001.GC13480@gandalf.sssup.it> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: hackers@freebsd.org Subject: Re: Pluggable Disk Scheduler Project 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, 11 Oct 2007 09:31:51 -0000 On tor, okt 11, 2007 at 04:20:01 +0200, Fabio Checconi wrote: > Hi, > is anybody working on the `Pluggable Disk Scheduler Project' from > the ideas page? Hi, I did look into it :) But then other projects came. > > To better understand how GEOM works, and how a (non work conserving) > disk scheduler can fit into it, I've written a very simple, yet > working, prototype: > > http://feanor.sssup.it/~fabio/freebsd/g_sched/geom-sched-class.patch > > > I'd like to take a better look at the problem and work on it, and > I'd like to know what you think about it. > > After reading [1], [2] and its follow-ups the main problems that > need to be addressed seem to be: > > o is working on disk scheduling worth at all? It is hard to say, but I'd like to run some benchmarks with this to see. Also, noted in [2], newer hardware does more magic on their own, as well as solid state drives coming along. > o Where is the right place (in GEOM) for a disk scheduler? As discussed in [2], some suggested that disk scheduling should be done on a lower part of a kernel due to knowledge of hardware capabilities. As discussed in [1], ata for instance do it's own scheduling, so this might ruin performance (Even the hardware might do some magic of it's own). I think I tried disabling it though, so shouldn't be a big deal for testing. > o How can anticipation be introduced into the GEOM framework? This is actually perhaps one of the most interesting points, since the anticipation principle in itself fits here, but some other scheduling features might not be useful. > o What can be an interface for disk schedulers? I think the interface developed in [1] is a pretty good one actually. I think the disksort-routines looked as a good place to do this. Even there it might not know enough about the hardware. > o How to deal with devices that handle multiple request per time? This is an example of the problems you get doing this in GEOM. You don't have very good knowledge of the hardware. > o How to deal with metadata requests and other VFS issues? > > I think that some answers need a little bit of experimenting with > real code and real hardware, so here it is this attempt. The > interface used in this toy prototype for the scheduler is something > like that: > > typedef void *gs_init_t (struct g_geom *geom); > typedef void gs_fini_t (void *data); > typedef void gs_start_t (void *data, struct bio *bio); > typedef void gs_done_t (void *data, struct bio *bio); > > struct g_gsched { > const char *gs_name; /* Scheduler name. */ > int gs_refs; /* Refcount, internal use. */ > > gs_init_t *gs_init; /* Called on geom creation. */ > gs_fini_t *gs_fini; /* Called on geom destruction. */ > gs_start_t *gs_start; /* Called on geom start. */ > gs_done_t *gs_done; /* Called on geom done. */ > > LIST_ENTRY(g_gsched) glist; /* List of schedulers, internal use. */ > }; > > The main idea is to allow the scheduler to enqueue the requests having only > one (other small fixed numbers can be better on some hardware) outstanding > request and to pass new requests to its provider only after the service of > the previous one ended. > > The example scheduler in the draft takes the following approach: > > o a scheduling GEOM class is introduced. It can be stacked on > top of disk geoms, and schedules all the requests coming > from its consumers. I'm not absolutely sure that a new class > is really needed but I think that it can simplify testing and > experimenting with various solutions on the scheduler placement. > o Requests coming from consumers are passed down immediately > if there is no other request under service, otherwise they > are queued in a bioq. > o When a request is served the scheduler is notified, then it > can pass down a new request, or, as in this toy anticipatory[3] > scheduler, wait for a new request from the same process, or > for a timeout to expire, and only after one of those events > make the next scheduling decision. > > So, as I've said, I'd like to know what you think about the subject, > if I'm missing something, if there is some kind of interest on this > and if/how can this work proceed. Also, what would be interesting is implementing I/O priorities for processes to be able to give I/O time more fairly(or at least being able to set after preference) to processes. This was done in the Hybrid project, but this is something that definately could be done in GEOM. (I see you have some fairness in the g_as_dispatch routine though). However, I'll try testing the work you've got. I'll see if I can get some numbers with this when I get some disks up. Btw, I did run some benchmark when I tried chaning bioq_disksort into a FIFO queue which didn's seem to lower performance (on SCSI and UMASS, but need to test again with ATA). It was a long time ago, so it should be tried again though. > > [1] http://wiki.freebsd.org/Hybrid > > [2] http://lists.freebsd.org/pipermail/freebsd-geom/2007-January/001854.html > > [3] The details of the anticipation are really not interesting as it > is extremely simplified by purpose. > > [4] http://feanor.sssup.it/~fabio/freebsd/g_sched/ contains also an userspace > client to experiment with the GEOM class. > -- Ulf Lilleengen From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 11:19:43 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC5B916A479 for ; Thu, 11 Oct 2007 11:19:43 +0000 (UTC) (envelope-from m.jakeman@lancaster.ac.uk) Received: from hedwig.lancs.ac.uk (hedwig.lancs.ac.uk [148.88.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id CB68713C468 for ; Thu, 11 Oct 2007 11:19:43 +0000 (UTC) (envelope-from m.jakeman@lancaster.ac.uk) Received: from mail02.lancs.ac.uk ([148.88.1.54]) by hedwig.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1Ifvkp-0001Mm-9N for hackers@freebsd.org; Thu, 11 Oct 2007 11:58:59 +0100 Received: from ina044000004.lancs.ac.uk ([148.88.224.46]) by mail02.lancs.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1Ifvko-0000CR-4v for hackers@freebsd.org; Thu, 11 Oct 2007 11:58:58 +0100 From: Matthew Jakeman Organization: Lancaster University To: hackers@freebsd.org Date: Thu, 11 Oct 2007 11:56:38 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710111156.38525.m.jakeman@lancaster.ac.uk> Cc: Subject: Sysctl Naming X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.jakeman@lancaster.ac.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2007 11:19:43 -0000 Hi All, I am wanting to create a number of sysctl variables at kernel boot time, 1 for each network interface. I have the code set up to loop through the interfaces using ifnet_byindex() already for other purposes so wanted to create them in this loop. The problem I'm having is naming them, using the SYSCTL_INT() macro as specified : SYSCTL_INT(parent, nbr, name, access, ptr, val, descr); The 'name' parameter is what I wish to manipulate in the loop to append the interface name on to the sysctl variable created however I can't think of a way to do this. If there is another way to accomplish this I would be grateful to hear any suggestions. Cheers Matt From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 11:48:33 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7869016A41B for ; Thu, 11 Oct 2007 11:48:33 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id EDBC413C45D for ; Thu, 11 Oct 2007 11:48:32 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [10.30.3.4] (HELO granpasso.retis) by sssup.it (CommuniGate Pro SMTP 4.1.8) with SMTP id 34897922 for hackers@freebsd.org; Thu, 11 Oct 2007 13:37:17 +0200 Received: (qmail 19536 invoked from network); 11 Oct 2007 11:48:30 -0000 Received: from unknown (HELO granpasso.retis) (127.0.0.1) by localhost.retis with SMTP; 11 Oct 2007 11:48:30 -0000 Received: (from fabio@localhost) by granpasso.retis (8.14.1/8.14.1/Submit) id l9BBmSMw019534; Thu, 11 Oct 2007 13:48:28 +0200 (CEST) (envelope-from fabio@freebsd.org) X-Authentication-Warning: granpasso.retis: fabio set sender to fabio@freebsd.org using -f Date: Thu, 11 Oct 2007 13:48:28 +0200 From: Fabio Checconi To: Ulf Lilleengen Message-ID: <20071011114828.GE18725@gandalf.sssup.it> References: <20071011022001.GC13480@gandalf.sssup.it> <20071011080734.GA20897@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011080734.GA20897@stud.ntnu.no> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: Pluggable Disk Scheduler Project 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, 11 Oct 2007 11:48:33 -0000 Hi, > From: Ulf Lilleengen > Date: Thu, Oct 11, 2007 10:07:34AM +0200 > > On tor, okt 11, 2007 at 04:20:01 +0200, Fabio Checconi wrote: > > o is working on disk scheduling worth at all? > It is hard to say, but I'd like to run some benchmarks with this to see. > Also, noted in [2], newer hardware does more magic on their own, as well as > solid state drives coming along. > this is why I wanted to start with some kind of prototype, hoping that its simplicity does not limit too much the results we can obtain. > > o Where is the right place (in GEOM) for a disk scheduler? > As discussed in [2], some suggested that disk scheduling should be done on a > lower part of a kernel due to knowledge of hardware capabilities. > > As discussed in [1], ata for instance do it's own scheduling, so this might > ruin performance (Even the hardware might do some magic of it's own). I > think I tried disabling it though, so shouldn't be a big deal for testing. > I don't know if disabling the lower level queueing is needed, because if you have only one outstanding request (or just a few ones, for hardware that supports that, and that can be a parameter for the scheduler) the lower level queueing will not reorder the higher level schedule. > > o How can anticipation be introduced into the GEOM framework? > This is actually perhaps one of the most interesting points, since the > anticipation principle in itself fits here, but some other scheduling > features might not be useful. > Ok. Decoupling the anticipation from other scheduling details may not be easy, but this thing is all about trying :) > > o What can be an interface for disk schedulers? > I think the interface developed in [1] is a pretty good one actually. I think > the disksort-routines looked as a good place to do this. Even there it might > not know enough about the hardware. > > > o How to deal with devices that handle multiple request per time? > This is an example of the problems you get doing this in GEOM. You don't have > very good knowledge of the hardware. > > > So, as I've said, I'd like to know what you think about the subject, > > if I'm missing something, if there is some kind of interest on this > > and if/how can this work proceed. > > Also, what would be interesting is implementing I/O priorities for processes > to be able to give I/O time more fairly(or at least being able to set after > preference) to processes. This was done in the Hybrid project, but this is > something that definately could be done in GEOM. (I see you have some > fairness in the g_as_dispatch routine though). > I totally agree. My primary concern with this email was to know what others have done/think about the problem, and to try to identify some kind of interface and positioning for the scheduler. The actual scheduler has to be something _much_ more complex than this little thing. Hybrid ideas can be mapped to a CFQ-like scheduler (one C-LOOK queue per process, fair sharing among queues, anticipation on a per queue basis,) and I'm working on that with Paolo Valente (in CC,) but I think the infrastructure behind the scheduler is more important now, as it defines what the scheduler can do. > However, I'll try testing the work you've got. I'll see if I can get some > numbers with this when I get some disks up. > > Btw, I did run some benchmark when I tried chaning bioq_disksort into a FIFO > queue which didn's seem to lower performance (on SCSI and UMASS, but need to > test again with ATA). It was a long time ago, so it should be tried again > though. I think this can depend on the access patterns used for testing (on disks; of course on flash devices disk sorting is not needed at all.) If you have processes that do only synchronous requests there is almost no difference between a .*LOOK elevator and FIFO queueing, since in the queue there will always be only one request per process, and you switch between processes every time you serve a new request (of course the actual order will change, but the number of seeks is the factor that really limits the throughput in this situation. At least this is my understanding of the problem :) ) The test patterns we are using with Paolo try to pessimize the disk throughput reading in parallel (simply with a dd, that generates a typical example of greedy synchronous sequential read patterns,) from two or more files put on partitions at the opposite ends (at least considering their logical addresses) of the disk. This kind of access should generate something near to the worst case behavior for a work-conserving .*LOOK scheduler. Of course also the behavior for asyncronous requests has to be tested. Thank you very much for your feedback, I hope we can get some numbers to substantiate this topic, remembering also that a good interface is a requirement for a good scheduler. > > > > [1] http://wiki.freebsd.org/Hybrid > > > > [2] http://lists.freebsd.org/pipermail/freebsd-geom/2007-January/001854.html > > > > [3] The details of the anticipation are really not interesting as it > > is extremely simplified by purpose. > > > > [4] http://feanor.sssup.it/~fabio/freebsd/g_sched/ contains also an userspace > > client to experiment with the GEOM class. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 12:09:07 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3332C16A41B for ; Thu, 11 Oct 2007 12:09:07 +0000 (UTC) (envelope-from m.jakeman@lancaster.ac.uk) Received: from hedwig.lancs.ac.uk (hedwig.lancs.ac.uk [148.88.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 0265113C448 for ; Thu, 11 Oct 2007 12:09:06 +0000 (UTC) (envelope-from m.jakeman@lancaster.ac.uk) Received: from mail02.lancs.ac.uk ([148.88.1.54]) by hedwig.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1IfwU7-0007oQ-Il for freebsd-hackers@freebsd.org; Thu, 11 Oct 2007 12:45:47 +0100 Received: from ina044000004.lancs.ac.uk ([148.88.224.46]) by mail02.lancs.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1IfwU6-0000LV-Nf for freebsd-hackers@freebsd.org; Thu, 11 Oct 2007 12:45:46 +0100 From: Matthew Jakeman Organization: Lancaster University To: freebsd-hackers@freebsd.org Date: Thu, 11 Oct 2007 12:43:27 +0100 User-Agent: KMail/1.9.1 References: <200710111156.38525.m.jakeman@lancaster.ac.uk> In-Reply-To: <200710111156.38525.m.jakeman@lancaster.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710111243.27149.m.jakeman@lancaster.ac.uk> Subject: Re: Sysctl Naming X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.jakeman@lancaster.ac.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2007 12:09:07 -0000 Please ignore this, stupid question as I have now realised. Cheers Matt On Thursday 11 October 2007 11:56, Matthew Jakeman wrote: > Hi All, > > I am wanting to create a number of sysctl variables at kernel boot time, 1 > for each network interface. I have the code set up to loop through the > interfaces using ifnet_byindex() already for other purposes so wanted to > create them in this loop. > > The problem I'm having is naming them, using the SYSCTL_INT() macro as > specified : > > SYSCTL_INT(parent, nbr, name, access, ptr, val, descr); > > The 'name' parameter is what I wish to manipulate in the loop to append the > interface name on to the sysctl variable created however I can't think of a > way to do this. If there is another way to accomplish this I would be > grateful to hear any suggestions. > > Cheers > Matt > _______________________________________________ > 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 Oct 11 12:11:31 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 723BE16A468 for ; Thu, 11 Oct 2007 12:11:31 +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 3B91913C4CA for ; Thu, 11 Oct 2007 12:11:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 9C90A20BF; Thu, 11 Oct 2007 14:11:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8F4C920BB; Thu, 11 Oct 2007 14:11:21 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 760A08448F; Thu, 11 Oct 2007 14:11:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: m.jakeman@lancaster.ac.uk References: <200710111156.38525.m.jakeman@lancaster.ac.uk> Date: Thu, 11 Oct 2007 14:11:21 +0200 In-Reply-To: <200710111156.38525.m.jakeman@lancaster.ac.uk> (Matthew Jakeman's message of "Thu\, 11 Oct 2007 11\:56\:38 +0100") Message-ID: <86ejg14zrq.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Sysctl Naming 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, 11 Oct 2007 12:11:31 -0000 Matthew Jakeman writes: > I am wanting to create a number of sysctl variables at kernel boot > time, 1 for each network interface. I have the code set up to loop > through the interfaces using ifnet_byindex() already for other > purposes so wanted to create them in this loop. > > The problem I'm having is naming them, using the SYSCTL_INT() macro as > specified : > > SYSCTL_INT(parent, nbr, name, access, ptr, val, descr); > > The 'name' parameter is what I wish to manipulate in the loop to > append the interface name on to the sysctl variable created however I > can't think of a way to do this. If there is another way to accomplish > this I would be grateful to hear any suggestions. This is the wrong approach, simply create a node with a fixed name in each device's private sysctl tree. See for instance how the coretemp driver in CURRENT inserts a node into each CPU device's sysctl tree. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 14:23:34 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3C016A41A; Thu, 11 Oct 2007 14:23:34 +0000 (UTC) (envelope-from fb-hackers@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.freebsd.org (Postfix) with ESMTP id 02A9413C45B; Thu, 11 Oct 2007 14:23:33 +0000 (UTC) (envelope-from fb-hackers@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id l9BD7L5m003817; Thu, 11 Oct 2007 15:07:21 +0200 (CEST) (envelope-from fb-hackers@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id l9BD7LqS003816; Thu, 11 Oct 2007 15:07:21 +0200 (CEST) (envelope-from fb-hackers@psconsult.nl) Date: Thu, 11 Oct 2007 15:07:21 +0200 From: Paul Schenkeveld To: freebsd-hackers@freebsd.org Message-ID: <20071011130720.GA3541@psconsult.nl> Mail-Followup-To: freebsd-hackers@freebsd.org, rink@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: rink@freebsd.org Subject: Any progress on FreeBSD/xen port? 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, 11 Oct 2007 14:23:34 -0000 Hi, For a large project involving virtual servers under Xen I've been asked to advice on using BSD for some services instead of Linux. In the Q2/2007 FreeBSD Status Report work on the FreeBSD/xen port is mentioned but the last report which came in yesterday does not mention Xen at all. Is someone still working on FreeBSD/xen or has work on the project stalled? Is there anything usable, even beta, around which I can use to get a feeling of what's involved in running FreeBSD under Xen? Thanks. Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 19:45:35 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0427816A417 for ; Thu, 11 Oct 2007 19:45:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5C013C474 for ; Thu, 11 Oct 2007 19:45:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 214012639-1834499 for multiple; Thu, 11 Oct 2007 15:26:50 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l9BJSeAw028631; Thu, 11 Oct 2007 15:28:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 11 Oct 2007 14:41:48 -0400 User-Agent: KMail/1.9.6 References: <200710111156.38525.m.jakeman@lancaster.ac.uk> <86ejg14zrq.fsf@ds4.des.no> In-Reply-To: <86ejg14zrq.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710111441.48995.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 11 Oct 2007 15:28:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4529/Thu Oct 11 02:54:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , m.jakeman@lancaster.ac.uk Subject: Re: Sysctl Naming 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, 11 Oct 2007 19:45:35 -0000 On Thursday 11 October 2007 08:11:21 am Dag-Erling Sm=C3=B8rgrav wrote: > Matthew Jakeman writes: > > I am wanting to create a number of sysctl variables at kernel boot > > time, 1 for each network interface. I have the code set up to loop > > through the interfaces using ifnet_byindex() already for other > > purposes so wanted to create them in this loop. > > > > The problem I'm having is naming them, using the SYSCTL_INT() macro as > > specified : > > > > SYSCTL_INT(parent, nbr, name, access, ptr, val, descr); > > > > The 'name' parameter is what I wish to manipulate in the loop to > > append the interface name on to the sysctl variable created however I > > can't think of a way to do this. If there is another way to accomplish > > this I would be grateful to hear any suggestions. >=20 > This is the wrong approach, simply create a node with a fixed name in > each device's private sysctl tree. See for instance how the coretemp > driver in CURRENT inserts a node into each CPU device's sysctl tree. Yes, but not all 'struct ifnet's have an associated device_t (think vlans).= =20 More proper would be to create a net.if tree and give each ifnet its own=20 dynamic sysctl tree under the net.if tree similar to the per-device nodes=20 under dev. One wrinkle with this is that network interfaces can be renamed, and I don'= t=20 think the dynamic sysctl stuff lets you rename an existing node currently=20 (though you could fix that). =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 11 20:43:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D515016A417 for ; Thu, 11 Oct 2007 20:43:42 +0000 (UTC) (envelope-from kevin@your.org) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 50B5B13C481 for ; Thu, 11 Oct 2007 20:43:41 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id A781D2AD55C4 for ; Thu, 11 Oct 2007 20:20:54 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id F20DAA0A44E for ; Thu, 11 Oct 2007 20:20:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: "Kevin - Your.Org" Date: Thu, 11 Oct 2007 15:20:58 -0500 X-Mailer: Apple Mail (2.752.3) Subject: Debugging kernel assembly calls - no stack frame 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, 11 Oct 2007 20:43:42 -0000 I've got a kernel crash that I'm trying to debug. The below is on a test system running 6.1-RELEASE, but it's also happening under 6.2 nearly identically. The meat of it: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0850e64 stack pointer = 0x28:0xe901dba0 frame pointer = 0x28:0xe901dc08 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 22 (irq16: sdla0 twe0) trap number = 12 panic: page fault (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc064e3f5 in boot (howto=260) at ../../../kern/kern_shutdown.c:402 #2 0xc064e68c in panic (fmt=0xc089f053 "%s") at ../../../kern/ kern_shutdown.c:558 #3 0xc0852d54 in trap_fatal (frame=0xe901db60, eva=16) at ../../../ i386/i386/trap.c:836 #4 0xc0852536 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 16, tf_esi = -978130928, tf_ebp = -385754104, tf_isp = -385754228, tf_ebx = 59, tf_edx = 16, tf_ecx = 14, tf_eax = 16, tf_trapno = 12, tf_err = 2, tf_eip = -1065021852, tf_cs = 32, tf_eflags = 589843, tf_esp = -985082112, tf_ss = -985044480}) at ../../../i386/i386/trap.c:269 #5 0xc084257a in calltrap () at ../../../i386/i386/exception.s:139 #6 0xc0850e64 in memcpy () at ../../../i386/i386/support.s:681 Previous frame inner to this frame (corrupt stack?) It looks like memcpy is being called with bad pointers. Inside the memcpy frame I see that %edi is 0x10, which can't be right. However, I want to know who is calling memcpy this way. My understanding is that the *.s function calls don't set up a frame, so gdb is getting lost here. I'm trying to trace things back myself, but not having much luck. My thought processes so far: 673 ENTRY(memcpy) 674 pushl %edi 675 pushl %esi 676 movl 12(%esp),%edi 677 movl 16(%esp),%esi 678 movl 20(%esp),%ecx 679 movl %edi,%eax 680 shrl $2,%ecx /* copy by 32- bit words */ 681 cld /* nope, copy forwards */ 682 rep 683 movsl 684 movl 20(%esp),%ecx 685 andl $3,%ecx /* any bytes left? */ 686 rep 687 movsb 688 popl %esi 689 popl %edi 690 ret Memcpy pushes two registers onto the stack immediately. Following that should be the return pointer. Following that should be the destination address, the source address, and the count. (kgdb) up 6 #6 0xc0850e64 in memcpy () at ../../../i386/i386/support.s:681 681 cld /* nope, copy forwards */ (kgdb) info registers esp esp 0xc548d700 0xc548d700 0xc548d700 should be the stack pointer at the time of the crash. (kgdb) x/12xw 0xc548d700 0xc548d700: 0x00000000 0x00000000 0xc5b2e800 0x00000010 0xc548d710: 0x00000013 0x00000001 0x00000000 0x00000010 0xc548d720: 0x00000000 0x00000000 0x00000000 0x00000000 memcpy pushes twice on the stack when it starts up, which are the two 0x00000000s at the beginning. Following that is 0xc5b2e800, which is where the ret will go at the end. After that, it's obvious the destination and source aren't right. Even then though, if I look at the registers: (kgdb) info registers eax 0x10 16 ecx 0xe 14 edx 0x10 16 ebx 0x3b 59 esp 0xc548d700 0xc548d700 ebp 0xe901dc08 0xe901dc08 esi 0xc5b2e810 -978130928 edi 0x10 16 eip 0xc0850e64 0xc0850e64 eflags 0x90013 589843 cs 0x20 32 ss 0xc5496a00 -985044480 ds 0x28 40 es 0x28 40 fs 0x8 8 gs 0x0 0 edi looks like it got the destination address loaded correctly, but esi and ecx don't match what I'd expect from seeing the stack. Ignoring that and looking at the return address, I see this: (kgdb) x/20i 0xc5b2e800 0xc5b2e800: add %ah,0xffffffa8(%eax) 0xc5b2e803: sub %eax,%esi 0xc5b2e805: add %eax,(%eax) 0xc5b2e807: pusha 0xc5b2e808: add (%eax),%al 0xc5b2e80a: add %al,(%eax) 0xc5b2e80c: cmp (%eax),%eax 0xc5b2e80e: add %al,(%eax) 0xc5b2e810: strl (%eax) 0xc5b2e813: add %al,0x0(%ebp) 0xc5b2e816: add %dh,(%esp,%eax,2) 0xc5b2e819: ds 0xc5b2e81a: inc %eax 0xc5b2e81b: add %bh,(%esi,%eax,1) 0xc5b2e81e: mov $0xb7,%dh 0xc5b2e820: push %ebx 0xc5b2e821: xchg %eax,%ebp 0xc5b2e822: dec %eax 0xc5b2e823: adc 0x1f(%ebp),%al 0xc5b2e826: arpl %cx,(%eax) That... doesn't look like it makes any sense. Am I trashing the stack after memcpy is getting called, or is this dump corrupted somehow? If any of you were debugging this, how would you proceed? -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 07:32:44 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A478B16A418 for ; Fri, 12 Oct 2007 07:32:44 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2F68B13C448 for ; Fri, 12 Oct 2007 07:32:43 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [10.30.3.4] (HELO granpasso.retis) by sssup.it (CommuniGate Pro SMTP 4.1.8) with SMTP id 34924450 for hackers@freebsd.org; Fri, 12 Oct 2007 09:21:16 +0200 Received: (qmail 34532 invoked from network); 12 Oct 2007 07:32:32 -0000 Received: from unknown (HELO granpasso.retis) (127.0.0.1) by localhost.retis with SMTP; 12 Oct 2007 07:32:32 -0000 Received: (from fabio@localhost) by granpasso.retis (8.14.1/8.14.1/Submit) id l9C7WVZs034530; Fri, 12 Oct 2007 09:32:31 +0200 (CEST) (envelope-from fabio@freebsd.org) X-Authentication-Warning: granpasso.retis: fabio set sender to fabio@freebsd.org using -f Date: Fri, 12 Oct 2007 09:32:31 +0200 From: Fabio Checconi To: Alexander Leidinger Message-ID: <20071012073231.GA34322@gandalf.sssup.it> References: <20071011022001.GC13480@gandalf.sssup.it> <20071011080734.GA20897@stud.ntnu.no> <20071011114828.GE18725@gandalf.sssup.it> <20071012081835.dtrpaz2c0880oow4@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071012081835.dtrpaz2c0880oow4@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, Ulf Lilleengen Subject: Re: Pluggable Disk Scheduler Project 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, 12 Oct 2007 07:32:44 -0000 > From: Alexander Leidinger > Date: Fri, Oct 12, 2007 08:18:35AM +0200 > > Quoting Fabio Checconi (from Thu, 11 Oct 2007 > 13:48:28 +0200): > > >>From: Ulf Lilleengen > >>Date: Thu, Oct 11, 2007 10:07:34AM +0200 > >> > >>On tor, okt 11, 2007 at 04:20:01 +0200, Fabio Checconi wrote: > >>> o How to deal with devices that handle multiple request per time? > >>This is an example of the problems you get doing this in GEOM. You > >>don't have > >>very good knowledge of the hardware. > > One can't pass this info from the lower layers up into GEOM (maybe by > adding some attribute querying interface in GEOM if it doesn't exist)? > I think the g_getattr() call is there/can be used for things like that. The scheduler should need only to know how many outstanding requests it can allow, otherwise it should be rather independend from the lower layers. Anyway hardware queueing brings also a different kind of problems, that is it can't be mixed easily with anticipation, because if you have syncronous requests and you dispatch more than one of them you are serving more than one process by definition, thus you can break anticipation, unless this thing is done very carefully (e.g., when switching from a process to another, or mixing syncronous and asynchronous requests.) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 06:37:19 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375E616A418; Fri, 12 Oct 2007 06:37:19 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E02C113C455; Fri, 12 Oct 2007 06:37:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55A9A.dip.t-dialin.net [84.165.90.154]) by redbull.bpaserver.net (Postfix) with ESMTP id F32D42E06A; Fri, 12 Oct 2007 08:19:33 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 64BF55B4800; Fri, 12 Oct 2007 08:18:36 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9C6IZ3R055981; Fri, 12 Oct 2007 08:18:35 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 12 Oct 2007 08:18:35 +0200 Message-ID: <20071012081835.dtrpaz2c0880oow4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 12 Oct 2007 08:18:35 +0200 From: Alexander Leidinger To: Fabio Checconi References: <20071011022001.GC13480@gandalf.sssup.it> <20071011080734.GA20897@stud.ntnu.no> <20071011114828.GE18725@gandalf.sssup.it> In-Reply-To: <20071011114828.GE18725@gandalf.sssup.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.504, required 8, BAYES_00 -15.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Fri, 12 Oct 2007 11:57:01 +0000 Cc: hackers@freebsd.org, Ulf Lilleengen Subject: Re: Pluggable Disk Scheduler Project 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, 12 Oct 2007 06:37:19 -0000 Quoting Fabio Checconi (from Thu, 11 Oct 2007 =20 13:48:28 +0200): >> From: Ulf Lilleengen >> Date: Thu, Oct 11, 2007 10:07:34AM +0200 >> >> On tor, okt 11, 2007 at 04:20:01 +0200, Fabio Checconi wrote: >> > o What can be an interface for disk schedulers? >> I think the interface developed in [1] is a pretty good one =20 >> actually. I think >> the disksort-routines looked as a good place to do this. Even there it mi= ght >> not know enough about the hardware. >> >> > o How to deal with devices that handle multiple request per time? >> This is an example of the problems you get doing this in GEOM. You =20 >> don't have >> very good knowledge of the hardware. One can't pass this info from the lower layers up into GEOM (maybe by =20 adding some attribute querying interface in GEOM if it doesn't exist)? Bye, Alexander. --=20 The naked truth of it is, I have no shirt. =09=09-- William Shakespeare, "Love's Labour's Lost" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 14:24:57 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F49B16A419 for ; Fri, 12 Oct 2007 14:24:57 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (cat-btc.gbservices.biz [83.228.119.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0B72813C468 for ; Fri, 12 Oct 2007 14:24:56 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B0ABA1FA037 for ; Fri, 12 Oct 2007 16:03:42 +0200 (CEST) Received: from fs.gbs.gbdom.com (fs.gbs.gbdom.com [192.168.2.244]) by cat.gbs.gbdom.com (Postfix) with ESMTP id 966A91FA032 for ; Fri, 12 Oct 2007 16:03:42 +0200 (CEST) Received: from localhost (localhost.gbs.gbdom.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 1513A28505 for ; Fri, 12 Oct 2007 16:03:42 +0200 (CEST) Received: from daemon.gbs.gbdom.com (daemon.gbs.gbdom.com [192.168.2.104]) by fs.gbs.gbdom.com (Postfix) with SMTP id 9EA2528504 for ; Fri, 12 Oct 2007 16:03:41 +0200 (CEST) Date: Fri, 12 Oct 2007 17:03:41 +0300 From: Vladimir Terziev To: freebsd-hackers@freebsd.org Message-Id: <20071012170341.72b8b888.vlady@gbservices.biz> Organization: GB Services Ltd. X-Mailer: Sylpheed 2.4.7 (GTK+ 2.6.4; i386-unknown-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GBS-F X-Virus-Scanned: ClamAV GBS-C Subject: Video memory as swap under FreeBSD 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, 12 Oct 2007 14:24:57 -0000 Hi Hackers, i have found the following very interesting link: http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap It's a howto for Video memory utilization as a swap. Could someone point me whether the same is possible under FreeBSD ? Thanks in advance! Vladimir Terziev, CISSP Systems & Security Administrator GB Services Ltd. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 15:23:36 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E283F16A468 for ; Fri, 12 Oct 2007 15:23:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 253D113C44B; Fri, 12 Oct 2007 15:23:34 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <470F9175.3020002@FreeBSD.org> Date: Fri, 12 Oct 2007 17:23:33 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Vladimir Terziev References: <20071012170341.72b8b888.vlady@gbservices.biz> In-Reply-To: <20071012170341.72b8b888.vlady@gbservices.biz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 15:23:37 -0000 Vladimir Terziev wrote: > Hi Hackers, > > i have found the following very interesting link: > > http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap > > It's a howto for Video memory utilization as a swap. > > Could someone point me whether the same is possible under FreeBSD ? > > Thanks in advance! It is not. Apart from the geek factor I doubt this would be useful as swap anyway, typically you need much more memory than a video card contains. Maybe as a small ram disk. Kris From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 15:35:37 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7B516A41A for ; Fri, 12 Oct 2007 15:35:37 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (cat-btc.gbservices.biz [83.228.119.50]) by mx1.freebsd.org (Postfix) with ESMTP id F0E2113C47E for ; Fri, 12 Oct 2007 15:35:36 +0000 (UTC) (envelope-from vladimir.terziev@gbservices.biz) Received: from cat-btc.gbservices.biz (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 96AA31FA038; Fri, 12 Oct 2007 17:35:35 +0200 (CEST) Received: from fs.gbs.gbdom.com (fs.gbs.gbdom.com [192.168.2.244]) by cat.gbs.gbdom.com (Postfix) with ESMTP id 7C41D1FA037; Fri, 12 Oct 2007 17:35:35 +0200 (CEST) Received: from localhost (localhost.gbs.gbdom.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 208AB28505; Fri, 12 Oct 2007 17:35:35 +0200 (CEST) Received: from daemon.gbs.gbdom.com (daemon.gbs.gbdom.com [192.168.2.104]) by fs.gbs.gbdom.com (Postfix) with SMTP id DAD5728504; Fri, 12 Oct 2007 17:35:34 +0200 (CEST) Date: Fri, 12 Oct 2007 18:35:34 +0300 From: Vladimir Terziev To: Kris Kennaway Message-Id: <20071012183534.bacd989b.vlady@gbservices.biz> In-Reply-To: <470F9175.3020002@FreeBSD.org> References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> Organization: GB Services Ltd. X-Mailer: Sylpheed 2.4.7 (GTK+ 2.6.4; i386-unknown-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GBS-F X-Virus-Scanned: ClamAV GBS-C Cc: freebsd-hackers@freebsd.org Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 15:35:37 -0000 You're right, the swap, typically configured, is much more than the amount of the video memory, but in fact the swap is just a reserv, which ensures continuation of the normal operations on the machine, at times of peak loads. In our days the amount of RAM placed in the servers is so much, that the swap, in fact, is rarely used at all and a very small amount of it (several MB) is used. In that cases having a very fast swap space in the Video RAM, in addition to the disk swap, would be a good solution. Vladimir On Fri, 12 Oct 2007 17:23:33 +0200 Kris Kennaway wrote: > Vladimir Terziev wrote: > > Hi Hackers, > > > > i have found the following very interesting link: > > > > http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap > > > > It's a howto for Video memory utilization as a swap. > > > > Could someone point me whether the same is possible under FreeBSD ? > > > > Thanks in advance! > > It is not. Apart from the geek factor I doubt this would be useful as > swap anyway, typically you need much more memory than a video card > contains. Maybe as a small ram disk. > > Kris From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 16:36:21 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9482E16A418 for ; Fri, 12 Oct 2007 16:36:21 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from spacemail1-out.mgmt.space.net (spacemail1-out.mgmt.Space.Net [194.97.149.146]) by mx1.freebsd.org (Postfix) with ESMTP id 25FB313C47E for ; Fri, 12 Oct 2007 16:36:20 +0000 (UTC) (envelope-from se@FreeBSD.org) X-SpaceNet-SBRS: None X-IronPort-AV: E=Sophos;i="4.21,267,1188770400"; d="scan'208";a="70071656" Received: from mail.atsec.com ([195.30.252.105]) by spacemail1-out.mgmt.space.net with ESMTP; 12 Oct 2007 18:07:10 +0200 Received: from [10.2.2.88] (frueh.atsec.com [217.110.13.170]) (Authenticated sender: se@atsec.com) by mail.atsec.com (Postfix) with ESMTP id A563181C865; Fri, 12 Oct 2007 18:07:08 +0200 (CEST) Message-ID: <470F9BA9.5080606@FreeBSD.org> Date: Fri, 12 Oct 2007 18:07:05 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vladimir Terziev References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> <20071012183534.bacd989b.vlady@gbservices.biz> In-Reply-To: <20071012183534.bacd989b.vlady@gbservices.biz> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 16:36:21 -0000 Vladimir Terziev schrieb: > You're right, > > the swap, typically configured, is much more than the amount of the video memory, but in fact the swap is just a reserv, which ensures continuation of the normal operations on the machine, at times of peak loads. > In our days the amount of RAM placed in the servers is so much, that the swap, in fact, is rarely used at all and a very small amount of it (several MB) is used. In that cases having a very fast swap space in the Video RAM, in addition to the disk swap, would be a good solution. If you have a video card with so much excess memory, that you can use it for swap, then I wonder whether the video card has not been much too expensive ;-) How about spending $25 for another Gigabyte of RAM (real RAM, not SWAP) instead? Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 16:51:57 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C03816A418; Fri, 12 Oct 2007 16:51:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 802E513C47E; Fri, 12 Oct 2007 16:51:52 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <470FA625.3090108@FreeBSD.org> Date: Fri, 12 Oct 2007 18:51:49 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Stefan Esser References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> <20071012183534.bacd989b.vlady@gbservices.biz> <470F9BA9.5080606@FreeBSD.org> In-Reply-To: <470F9BA9.5080606@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vladimir Terziev , freebsd-hackers@freebsd.org Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 16:51:57 -0000 Stefan Esser wrote: > Vladimir Terziev schrieb: >> You're right, >> >> the swap, typically configured, is much more than the amount of the video memory, but in fact the swap is just a reserv, which ensures continuation of the normal operations on the machine, at times of peak loads. >> In our days the amount of RAM placed in the servers is so much, that the swap, in fact, is rarely used at all and a very small amount of it (several MB) is used. In that cases having a very fast swap space in the Video RAM, in addition to the disk swap, would be a good solution. > > If you have a video card with so much excess memory, that you can use it > for swap, then I wonder whether the video card has not been much too > expensive ;-) > > How about spending $25 for another Gigabyte of RAM (real RAM, not SWAP) > instead? > > Regards, STefan > > Yes indeed :) Kris From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 16:54:19 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D2EC16A41B; Fri, 12 Oct 2007 16:54:19 +0000 (UTC) (envelope-from kevin@your.org) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A45F13C465; Fri, 12 Oct 2007 16:54:19 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id D27192AD55C9; Fri, 12 Oct 2007 16:54:17 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 29B5BA0A44E; Fri, 12 Oct 2007 16:54:17 +0000 (UTC) In-Reply-To: <470F9BA9.5080606@FreeBSD.org> References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> <20071012183534.bacd989b.vlady@gbservices.biz> <470F9BA9.5080606@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C263E0F-1231-4F73-A820-1A3265B72078@your.org> Content-Transfer-Encoding: 7bit From: "Kevin - Your.Org" Date: Fri, 12 Oct 2007 11:54:23 -0500 To: Stefan Esser X-Mailer: Apple Mail (2.752.3) Cc: Vladimir Terziev , freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 16:54:19 -0000 On Oct 12, 2007, at 11:07 AM, Stefan Esser wrote: > Vladimir Terziev schrieb: >> You're right, >> >> the swap, typically configured, is much more than the amount of >> the video memory, but in fact the swap is just a reserv, which >> ensures continuation of the normal operations on the machine, at >> times of peak loads. >> In our days the amount of RAM placed in the servers is so much, >> that the swap, in fact, is rarely used at all and a very small >> amount of it (several MB) is used. In that cases having a very >> fast swap space in the Video RAM, in addition to the disk swap, >> would be a good solution. > > If you have a video card with so much excess memory, that you can > use it > for swap, then I wonder whether the video card has not been much too > expensive ;-) > > How about spending $25 for another Gigabyte of RAM (real RAM, not > SWAP) > instead? > I'm not commenting on if this is a good idea or not either way, but at least one vendor of servers that we've been buying from is now including 128 or 256MB of video ram(not UMA, real video ram) embedded on the motherboard now. I thought it was odd too, until I asked our sales rep. The 8MB ATI chipset they used to use would have disqualified them from being "Vista Capable". So, whether we want it or not, we're getting at least 128MB of video memory on our servers now. I'd thought about trying to use it for something, but decided it wasn't worth the effort. :) -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 21:40:16 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F9AE16A419; Fri, 12 Oct 2007 21:40:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0667813C468; Fri, 12 Oct 2007 21:40:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.13.4) with ESMTP id l9CLdWwY007175; Fri, 12 Oct 2007 15:39:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 12 Oct 2007 15:39:32 -0600 (MDT) Message-Id: <20071012.153932.74743180.imp@bsdimp.com> To: kevin@your.org From: Warner Losh In-Reply-To: <2C263E0F-1231-4F73-A820-1A3265B72078@your.org> References: <20071012183534.bacd989b.vlady@gbservices.biz> <470F9BA9.5080606@FreeBSD.org> <2C263E0F-1231-4F73-A820-1A3265B72078@your.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 12 Oct 2007 15:39:33 -0600 (MDT) Cc: vlady@gbservices.biz, freebsd-hackers@FreeBSD.org, kris@FreeBSD.org, se@FreeBSD.org Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 21:40:16 -0000 From: "Kevin - Your.Org" Subject: Re: Video memory as swap under FreeBSD Date: Fri, 12 Oct 2007 11:54:23 -0500 > > On Oct 12, 2007, at 11:07 AM, Stefan Esser wrote: > > > Vladimir Terziev schrieb: > >> You're right, > >> > >> the swap, typically configured, is much more than the amount of > >> the video memory, but in fact the swap is just a reserv, which > >> ensures continuation of the normal operations on the machine, at > >> times of peak loads. > >> In our days the amount of RAM placed in the servers is so much, > >> that the swap, in fact, is rarely used at all and a very small > >> amount of it (several MB) is used. In that cases having a very > >> fast swap space in the Video RAM, in addition to the disk swap, > >> would be a good solution. > > > > If you have a video card with so much excess memory, that you can > > use it > > for swap, then I wonder whether the video card has not been much too > > expensive ;-) > > > > How about spending $25 for another Gigabyte of RAM (real RAM, not > > SWAP) > > instead? > > > > I'm not commenting on if this is a good idea or not either way, but > at least one vendor of servers that we've been buying from is now > including 128 or 256MB of video ram(not UMA, real video ram) embedded > on the motherboard now. > > I thought it was odd too, until I asked our sales rep. The 8MB ATI > chipset they used to use would have disqualified them from being > "Vista Capable". > > So, whether we want it or not, we're getting at least 128MB of video > memory on our servers now. I'd thought about trying to use it for > something, but decided it wasn't worth the effort. :) It would be a cool hack. it would also be cool technology to have around because to 'swap' to the video ram, you need to have a way to map it to a device. And if you have that, then you have a short delta to many of the pci based battery backed ram disks. I'm sure that writing a small geom driver to cope wouldn't be very hard to do. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 18:01:54 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68ED116A41B; Fri, 12 Oct 2007 18:01:54 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFAA13C480; Fri, 12 Oct 2007 18:01:54 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-061-154-008.pools.arcor-ip.net ([84.61.154.8] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IgO8X-0003yw-Kb; Fri, 12 Oct 2007 19:17:21 +0200 Message-ID: <470FAC21.7000601@uni-paderborn.de> Date: Fri, 12 Oct 2007 19:17:21 +0200 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kris Kennaway References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> In-Reply-To: <470F9175.3020002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Oct 2007 23:23:40 +0000 Cc: Vladimir Terziev , freebsd-hackers@freebsd.org Subject: Re: Video memory as swap under FreeBSD 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, 12 Oct 2007 18:01:54 -0000 Kris Kennaway schrieb: > Vladimir Terziev wrote: >> Hi Hackers, >> >> i have found the following very interesting link: >> >> http://gentoo-wiki.com/TIP_Use_memory_on_video_card_as_swap >> >> It's a howto for Video memory utilization as a swap. >> >> Could someone point me whether the same is possible under FreeBSD ? >> >> Thanks in advance! > > It is not. Apart from the geek factor I doubt this would be useful as > swap anyway, typically you need much more memory than a video card > contains. Maybe as a small ram disk. VIdeo RAM may also not be as stable as your main RAM. I mean nobody if a bit flips in video ram. Arne From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 06:37:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01C7A16A41B; Sat, 13 Oct 2007 06:37:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 63E1F13C44B; Sat, 13 Oct 2007 06:37:58 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l9D61dTA015310; Sat, 13 Oct 2007 10:01:39 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l9D61dG0015309; Sat, 13 Oct 2007 10:01:39 +0400 (MSD) (envelope-from yar) Date: Sat, 13 Oct 2007 10:01:39 +0400 From: Yar Tikhiy To: obrien@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20071013060138.GA14388@comp.chem.msu.su> References: <20070901073440.GL85633@comp.chem.msu.su> <46DAFE5C.6070806@freebsd.org> <20070903120353.GH30502@comp.chem.msu.su> <200709261028.43378.jhb@freebsd.org> <20071004022344.GA60878@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071004022344.GA60878@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: Useful tools missing from /rescue 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, 13 Oct 2007 06:37:59 -0000 On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: > > > > Yar Tikhiy wrote: > > > > >I've had to use /rescue recently and felt lack of a few basic tools > > > > >in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, > > > > >e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), > > > > >tail(1), and even tee(1) can be emulated if one has sed(1), but the > > > > >tools are so tiny and convenient that it's a pity not to have them > > > > >all handy during hard times. > > I also don't see the need for pgrep - I think needing that says your > system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A skillful admin needs a rather limited number of tools, but some of them still are missing from /rescue. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) > Also head and tail - why not just add 'more' as that would give more > functionality if you're trying to read a file in /etc to fix something. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse through voluminous output for relevant parts. And it's hard to use pipelines w/o basic filters. Again, head(1) and tail(1) can be substituted by sed(1), but my fingers are just used to type "head" or "tail" in certain cases. I suspect that I'm not the only one of this kind out there. As for more(1), there is a reason not to include it in /rescue now, besides its rather large size. Namely it uses ncurses and thus depends on /etc/termcap to work well; but in a really tough case when you can mount only /, /etc/termcap is unavailable because it's a symlink to under /usr. This problem plagues /rescue/vi already (see PR bin/80256.) I think we should postpone adding more(1) to /rescue to after the problem has been fixed. And, of course, more(1) is no substitute for head(1) or tail(1) when it comes to pipelines. > > > > >In addition, there are chflags and chmod in /rescue, but there's > > > > >no chown in it, so the toolset is a bit incomplete. > > I don't see the purpose of chown - if you have to fall back to /rescue > you're user 'root' - and you're trying to fix enough so you can use > standard /*lib & /*bin > > chflags is needed so you can overwrite a file and chmod is needed so you > can "chmod +x" something - those needs are clear. > > Please don't pestimize the build - unless there is a clear benefit. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue are enough to run single-user and do basic things. (Note that there is /rescue/init.) Of course, what I've just told is my own view of /rescue's role, but it seems to be supported by some other folks. Thank you for your comments! I think this discussion can let us understand better what we need from /rescue. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 07:58:04 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E6E16A418 for ; Sat, 13 Oct 2007 07:58:04 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 22CE813C442 for ; Sat, 13 Oct 2007 07:58:03 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so121173uge for ; Sat, 13 Oct 2007 00:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=p70Xla84cpL3QYSqmIOxYRSPHI+Tq527uGOuuSOA6WA=; b=jvAylHci+TlAp3fz3SG8NDPNN6ggqKdmxh6C6T+CE2wMWdxdVaR3Wo5svSaif3wBF5I+CDEFDaKM2/RHtvKFJ7oikDrzLw1liea22qVwXNutke922pvMW81i7g7SutT90UaDuRAPVdo1+4fU500Ccg/AXrHyR4reqfMzfL6Y7DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=dzKkoDLmUIhJqFspV64EJHAJDR2J4mTGfYwMmcx2yy/TZhHuz3a9S3tL7/lAdlWuWyrytcppGqn82nN+BcDDG9ES0AN3mkr0fH7Wi8tdnFDIId6wyMXRdIEHJY2ERuaVsdi1d57XIh5FceHBd9uOCDr/KxW2es3A5aefHiHc2k4= Received: by 10.66.252.17 with SMTP id z17mr5278510ugh.1192262282998; Sat, 13 Oct 2007 00:58:02 -0700 (PDT) Received: from homegate ( [196.34.241.123]) by mx.google.com with ESMTPS id b36sm356678ika.2007.10.13.00.57.58 (version=SSLv3 cipher=OTHER); Sat, 13 Oct 2007 00:58:01 -0700 (PDT) From: David Naylor To: freebsd-hackers@freebsd.org Date: Sat, 13 Oct 2007 09:59:45 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710130959.45183.blackdragon@highveldmail.co.za> Sender: David Naylor Subject: Project Ideas and a question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 07:58:04 -0000 Hi, The question first: init does allow a chroot before booting the system however does it allow the first device to be unmounted and use the new chroot as the root device. If it does how can that be achieved. My motivation for this: Allow a USB device or CDROM to boot the system, then init running of the removable device to execute a script that will allow the system to be setup (such as configure devices, setup gdbe and geli, etc) then when init chroot's it unmounts the removable device and allows that device to be physically removed. I have some project ideas (due to lack of technical skills I can not pursue them at this time but that is no reason not to share :-). If someone thinks an idea is a good one could you please add it to the appropriate location (the volunteer projects page???). My ideas: 1) Automatic module loading. Create a discovery system that upon identifying hardware that a module supports, loads the module. This would probably be a user-land implementation? Motivation: Additional ease of use (especially with sound) 2) Automatic kernel customisation. A tool that builds a custom kernel with all the devices for the current system builtin and with everything not needed removed. Motivation: Take the hard work out of building a custom kernel] 3) If question above is not implemented than add to idea list... Feedback is welcome. Thank you for listening to me. David From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 08:45:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1540316A41A; Sat, 13 Oct 2007 08:45:44 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: from tapuz.safe-mail.net (tapuz.safe-mail.net [213.8.161.230]) by mx1.freebsd.org (Postfix) with ESMTP id C55EF13C45A; Sat, 13 Oct 2007 08:45:43 +0000 (UTC) (envelope-from dexterclarke@Safe-mail.net) Received: by tapuz.safe-mail.net with Safe-mail (Exim 4.52) id 1Igccu-0000xy-2a; Sat, 13 Oct 2007 04:45:40 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=e4/l6WMPQF7gxTRfd/d3RQJm0kA97QtJi9MlhXg9SVgPkfM5/KvLGRMYSpmIe6M0 FJUCpia87UbeWof4gk1lIpQzDbdxHNV6aXaExvi7t35Vynxv43m2bzgBGMTnfrII ksoNzIWI2WaL60ma0qBKoILefFSo+AtJeby+mlVhoRE=; Received: from pc ([81.86.41.187]) by Safe-mail.net with https Date: Sat, 13 Oct 2007 04:45:39 -0400 From: dexterclarke@Safe-mail.net To: csjp@FreeBSD.org X-SMType: Regular X-SMRef: N1-sOkB2VH_MQ Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMSignature: uTKuyEzO+6KrNokIp3pcVBwW8t9+mST46zL3kAUUmOCOHCqagWmpzaJEGaZ5Q7zI yxRpDd9791LVRAabZRNj0YdCq1fAFymc6q8Fv0y2bW5kVsWM/9X9Ti/0v5yc0whZ Zcxol+eF07jjc6jFGeaX1wjmT/26YGTRaZozlbxJhbI= Cc: freebsd-hackers@freebsd.org Subject: Re: audit doesn't seem to be working correctly. 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, 13 Oct 2007 08:45:44 -0000 > Well, > > The problem that I thought was there, wasn't actually there, > which is why I said to ignore the patch :) > > I've tried to reproduce the problems you are seeing but > I have not been able to. > > So far I've tried on -CURRENT and RELENG_6. We are aware > of some issues on RELENG_6_2 specifically with !i386 > architectures (i.e. amd64, sparc64 etc). > > Is it possible you can send me: > > (1) The output to uname -a > (2) Your /etc/security directory > (3) How are you logging in to this machine, SSH? Telnet? > > (3) is important because the login program will be responsible > for setting up the audit ID and preselection masks. > > Hopefully with this information, we can get to the bottom of this. > I've been without connectivity for a few days but am now back, with good news. I believe that the problem was actually down to the fact that the user being audited had not logged out and in again after the audit settings changed. I think this is just a documentation bug - the audit docs never mention explicitly that the login program handles preselection. It seems to be working properly now that the system has been rebooted (forcing new logins for all users). -- dc From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 09:13:26 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F3616A417 for ; Sat, 13 Oct 2007 09:13:26 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.freebsd.org (Postfix) with ESMTP id B61A413C448 for ; Sat, 13 Oct 2007 09:13:25 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from rionda.dyndns.org (87.8.188.88) by vsmtp4.tin.it (7.3.122) id 46F95D6C0278D183; Sat, 13 Oct 2007 11:01:40 +0200 Received: from rionda.dyndns.org (rionda@localhost [127.0.0.1]) by rionda.dyndns.org (8.14.1/8.14.1) with ESMTP id l9D91eI1011491; Sat, 13 Oct 2007 11:01:40 +0200 (CEST) (envelope-from matteo@freebsd.org) Received: (from rionda@localhost) by rionda.dyndns.org (8.14.1/8.14.1/Submit) id l9D91ceJ011490; Sat, 13 Oct 2007 11:01:38 +0200 (CEST) (envelope-from matteo@freebsd.org) X-Authentication-Warning: rionda.dyndns.org: rionda set sender to matteo@freebsd.org using -f Date: Sat, 13 Oct 2007 11:01:38 +0200 From: Matteo Riondato To: David Naylor Message-ID: <20071013090138.GF1739@kaiser.sig11.org> Mail-Followup-To: Matteo Riondato , David Naylor , freebsd-hackers@freebsd.org References: <200710130959.45183.blackdragon@highveldmail.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710130959.45183.blackdragon@highveldmail.co.za> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: Project Ideas and a question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 09:13:26 -0000 On Sat, Oct 13, 2007 at 09:59:45AM +0200, David Naylor wrote: > 1) Automatic module loading. Create a discovery system that upon identifying > hardware that a module supports, loads the module. This would probably be a > user-land implementation? > Motivation: Additional ease of use (especially with sound) FreeSBIE does this for sound and other things, like X configuration: http://cvsweb.freesbie.org/cgi-bin/cvsweb.cgi/freesbie2/extra/sound/ and other directories in the FreeSBIE CVS tree. It can be improved. -- Matteo Riondato FreeBSD Committer (http://www.FreeBSD.org) FreeSBIE Developer (http://www.FreeSBIE.org) GUFI Staff Member (http://www.GUFI.org) From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 10:09:33 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B8516A41B for ; Sat, 13 Oct 2007 10:09:33 +0000 (UTC) (envelope-from rizwanyz@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id E96A413C465 for ; Sat, 13 Oct 2007 10:09:32 +0000 (UTC) (envelope-from rizwanyz@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2167366pyb for ; Sat, 13 Oct 2007 03:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=s0vPxeDQj9Ffs4IqXrtT5FSqp6BH2e5FmjSDYj3Zrjg=; b=NfPVqWdSINCpS1b1Zsa7vcz6g26knb7nrRoPmVxWJFt8JE78ONV4rOxiKt/DvNLza1vS8lwXMfB4SgmJtfJB0D1LENkuK49JCwNRQYC/scb8rb5f6BA+itcqEkVQZe6WjhBgSQ2VhUyW/8uBdtg+EDsX5LlJcnJWRFY7zdxXbpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Lvqv3hc1thJGgH/vke6IDhMksBdKIH/wGCB/Z4r5C2OQHJ7odWMHZhXdsYlyU/oX2t9Qyz93xNZdhdxosL7iCecYHQl7qVUxl7Zp87FTtJOT6Asdk3lMDx1UawjjokBhYrkmH7/CLlo+1NY/+I/nq5l2ThPG76HXA4QqVnEJsJ4= Received: by 10.64.148.8 with SMTP id v8mr8362175qbd.1192268411167; Sat, 13 Oct 2007 02:40:11 -0700 (PDT) Received: by 10.65.54.16 with HTTP; Sat, 13 Oct 2007 02:40:11 -0700 (PDT) Message-ID: <45a619330710130240h57b5cadfyb2adb41c3db49210@mail.gmail.com> Date: Sat, 13 Oct 2007 15:40:11 +0600 From: "Rizwan Ahmad" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 13 Oct 2007 11:28:55 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CVSUP Connection Problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 10:09:33 -0000 Hi All, I am trying to run CVSUP from my system but I am not successful. I have tried many times by changing the CVSUP host too, but it did not work. All the time I am getting the below message and no other details. #cvsup -L 2 -g new-portsfile Connecting to cvsup7.freebsd.org Cannot connect to cvsup7.freebsd.org: Connection refused Will retry at 15:38:37 Can anyone help? Anything to do with the local firewall? Thanking you. Rizwan From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 12:00:29 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63B6116A46D for ; Sat, 13 Oct 2007 12:00:29 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 23B7A13C480 for ; Sat, 13 Oct 2007 12:00:28 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so967000wxd for ; Sat, 13 Oct 2007 05:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=IP4Y6F5h/GbAcxj3cMaqx/BkzP+rQzUcier9l84tm0c=; b=dCcG+d68qfsMP6Tf/YR/HxFcXuUj7JJK8DsxBlCCC7AE/iwnTk/1jpca7DlSAW8B5t3EQEdMtHT8iVVGATdrYUwdj90rREVPfA7+OUJe+mgMmSNiUwnbTG9x0QVx17NUZY5WpfMge8AInAo/269zcRwMLq+ZLXkcCKHXgV3e/Fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XGCLJpDy9w56ug2kpsGVIml608w8JpUAnQfAy51E4UqK8rfLR6i1uhedAueRFIGCnMrgeVvt27+457bd3hYejV2c1bfcgz/QJGabEdQHOzJabAzNmeIC5UjXfYKSNqhQEdZ/FoRqs7cZ4Tc+SsDVZUiTybowx21XJMKTQpv6va4= Received: by 10.70.37.12 with SMTP id k12mr7006314wxk.1192275370136; Sat, 13 Oct 2007 04:36:10 -0700 (PDT) Received: from ?192.168.2.2? ( [67.85.89.184]) by mx.google.com with ESMTPS id m33sm2631744ele.2007.10.13.04.36.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Oct 2007 04:36:08 -0700 (PDT) Message-ID: <471074DE.1040607@gmail.com> Date: Sat, 13 Oct 2007 07:33:50 +0000 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.6 (X11/20071005) MIME-Version: 1.0 To: Rizwan Ahmad References: <45a619330710130240h57b5cadfyb2adb41c3db49210@mail.gmail.com> In-Reply-To: <45a619330710130240h57b5cadfyb2adb41c3db49210@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: CVSUP Connection Problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 12:00:29 -0000 Rizwan Ahmad wrote: > Hi All, > I am trying to run CVSUP from my system but I am not successful. I have > tried many times by changing the CVSUP host too, but it did not work. All > the time I am getting the below message and no other details. > > #cvsup -L 2 -g new-portsfile > > Connecting to cvsup7.freebsd.org > Cannot connect to cvsup7.freebsd.org: Connection refused > Will retry at 15:38:37 Sorry for the stupid question but does this happen for all cvsup servers? From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 12:10:40 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00F616A420; Sat, 13 Oct 2007 12:10:40 +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 7C94F13C447; Sat, 13 Oct 2007 12:10:40 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id CF27420C7; Sat, 13 Oct 2007 14:10:31 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B3EA520C6; Sat, 13 Oct 2007 14:10:31 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 95DA384485; Sat, 13 Oct 2007 14:10:31 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Arne Schwabe References: <20071012170341.72b8b888.vlady@gbservices.biz> <470F9175.3020002@FreeBSD.org> <470FAC21.7000601@uni-paderborn.de> Date: Sat, 13 Oct 2007 14:10:31 +0200 In-Reply-To: <470FAC21.7000601@uni-paderborn.de> (Arne Schwabe's message of "Fri\, 12 Oct 2007 19\:17\:21 +0200") Message-ID: <864pgvjjuw.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Vladimir Terziev , freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: Video memory as swap under FreeBSD 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, 13 Oct 2007 12:10:40 -0000 Arne Schwabe writes: > VIdeo RAM may also not be as stable as your main RAM. I mean nobody if a > bit flips in video ram. That may have been true fifteen years ago, but not today. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 13 12:13:17 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DBE816A469 for ; Sat, 13 Oct 2007 12:13:17 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id C641813C458 for ; Sat, 13 Oct 2007 12:13:16 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9DBr4jW010884; Sat, 13 Oct 2007 21:53:04 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9DBr4Aw010883; Sat, 13 Oct 2007 21:53:04 +1000 (EST) (envelope-from peter) Date: Sat, 13 Oct 2007 21:53:04 +1000 From: Peter Jeremy To: Rizwan Ahmad Message-ID: <20071013115304.GR93545@turion.vk2pj.dyndns.org> References: <45a619330710130240h57b5cadfyb2adb41c3db49210@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qftxBdZWiueWNAVY" Content-Disposition: inline In-Reply-To: <45a619330710130240h57b5cadfyb2adb41c3db49210@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: CVSUP Connection Problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2007 12:13:17 -0000 --qftxBdZWiueWNAVY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-13 15:40:11 +0600, Rizwan Ahmad wrote: >Connecting to cvsup7.freebsd.org >Cannot connect to cvsup7.freebsd.org: Connection refused =2E.. >Can anyone help? Anything to do with the local firewall? Most likely. CVSup needs outbound access to TCP port 5999 on the CVSup server. --=20 Peter Jeremy --qftxBdZWiueWNAVY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHELGg/opHv/APuIcRAjr1AJoDpoG4IhOKoaQHfUQEib2btSl+xgCgvq5l 1Nw5ekXI3pbNxWNj4s6v5wU= =bW/D -----END PGP SIGNATURE----- --qftxBdZWiueWNAVY--