From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 08:02:01 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F72C16A40F for ; Sun, 17 Sep 2006 08:02:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A79CC43D9F for ; Sun, 17 Sep 2006 08:01:59 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GOrbC-000Olz-52 for freebsd-hackers@FreeBSD.org; Sun, 17 Sep 2006 11:01:58 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Sep 2006 11:01:58 +0300 From: Danny Braniss Message-ID: Cc: Subject: pxe boot size limit? 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, 17 Sep 2006 08:02:01 -0000 it seems that pxeboot has a limit with respect to the kernel size, which prevents the kernel to get loaded, the error printed is slightly misleading. the solution is to make a kernel with loadable modules, instead of compiled in. danny From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 19:29:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D1E16A412 for ; Sun, 17 Sep 2006 19:29:33 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DE343D53 for ; Sun, 17 Sep 2006 19:29:30 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so330052uge for ; Sun, 17 Sep 2006 12:29:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=sUMpsHOBtc4BUNlu/dJfKxV4AwPHMITdoOhRZsN80Ckio1qM29JnxTPCJ5OACpQCcsEQ7D/XkPSvji7ywX40euH1nvRc06frKZ3iZYme1DxeQC6lo1/DYYZo8iV67GQwIUSI6fQEzDDSEQlZtpncou4C8xYvabhO1tCNb4G4D/w= Received: by 10.67.97.7 with SMTP id z7mr6777206ugl; Sun, 17 Sep 2006 12:29:29 -0700 (PDT) Received: from ?192.168.123.146? ( [195.241.221.201]) by mx.gmail.com with ESMTP id k1sm2530149ugf.2006.09.17.12.29.28; Sun, 17 Sep 2006 12:29:28 -0700 (PDT) Message-ID: <450DA217.9080602@gmail.com> Date: Sun, 17 Sep 2006 21:29:27 +0200 From: Rene Ladan User-Agent: Thunderbird 1.5.0.7 (X11/20060914) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-usb@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: anyone working on setting output items with usbhidctl(1) ? 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, 17 Sep 2006 19:29:33 -0000 Hi, is anyone working on setting output items with usbhidctl(1) ? I'm trying to add LED/rumbler support for the Xbox 360 Gamepad to uhid(4), but there doesn't seem to be a userland tool to test output items and the output report descriptor doesn't seem to be publicly available (i.e. I must reverse-engineer it). This device has 4 LEDs which can be controlled with the command 01 03 xx, where xx ranges from 0 to 255. It also has two rumble motors which can be controlled with 00 08 00 bb ll 00 00 00, where bb and ll both range from 0 to 255. I thought that something like -s "feature1=value1,feature2=value2,..." would be nice to have. I'm not subscribed to the usb@ list, so please cc me. Kind regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 21:20:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2270816A40F for ; Sun, 17 Sep 2006 21:20:04 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A20CB43D69 for ; Sun, 17 Sep 2006 21:19:06 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 93A251A3C1C; Sun, 17 Sep 2006 14:19:06 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B27B651B1F; Sun, 17 Sep 2006 17:19:05 -0400 (EDT) Date: Sun, 17 Sep 2006 17:19:05 -0400 From: Kris Kennaway To: Alex Lyashkov Message-ID: <20060917211905.GA64182@xor.obsecurity.org> References: <1158407656.3215.33.camel@berloga.shadowland> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <1158407656.3215.33.camel@berloga.shadowland> User-Agent: Mutt/1.4.2.2i Cc: freebsd-hackers@freebsd.org Subject: Re: jail2 patchset 12 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, 17 Sep 2006 21:20:04 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 16, 2006 at 02:54:16PM +0300, Alex Lyashkov wrote: > Hello All, >=20 > Some time ago I finished the next public jail2 patchset. > As of now, jail2 supports per-jail SYSV IPC namespaces. > It is possible to configure which jails can and which cannot use > SYSV IPC. The UID hash is also perl-jail now. > he patchset also implements per-jail resource limits, such as: > - number of SYSV IPC objects; > - number of processes; > - number of filedescriptors. > In addition, all jail-related code was moved under 'options JAIL'. >=20 > The project's homepage: > http://docs.freevps.com/doku.php?id=3Dfreebsd:index I get the following panic when creating a jail: panic: mutex allprison not owned at ../../../kern/kern_jail.c:374 cpuid =3D 1 KDB: enter: panic [thread pid 930 tid 106142 ] Stopped at kdb_enter+0x32: leave db> wh Tracing pid 930 tid 106142 td 0xd30841b0 kdb_enter(c0756d95,1,c0755e9c,f17c9b80,d30841b0,...) at kdb_enter+0x32 panic(c0755e9c,c075431c,c0754331,176,1,...) at panic+0x1b1 _mtx_unlock_spin_flags(c07c6214,1,c0754331,176,0,...) at _mtx_unlock_spin_f= lags prison_find(1,0,0,d30841b0,c5bb9800,...) at prison_find+0x2e jail_attach(d30841b0,f17c9bf0,c0754331,9f,c5bb992c,...) at jail_attach+0x38 jail(d30841b0,f17c9d04,4,f17c9d38,1,...) at jail+0x3b5 syscall(3b,3b,3b,bfbfe8c0,bfbfe904,...) at syscall+0x152 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (338, FreeBSD ELF32, jail), eip =3D 0x280d1ee7, esp =3D 0xbfbfe= 3ac, ebp =3D 0xbfbfe888 --- 930 545 544 0 R CPU 1 jail Kris --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFDbvJWry0BWjoQKURAr8TAJwKXPoh7gmgm+RZDW5tV3szIZdoQgCg2nef 8ssPSb+bb9cQkC2pwaPHaeE= =rRJO -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 22:09:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A602816A4AB for ; Sun, 17 Sep 2006 22:09:22 +0000 (UTC) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED28443DA5 for ; Sun, 17 Sep 2006 22:08:25 +0000 (GMT) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 156D417001A; Mon, 18 Sep 2006 01:08:50 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id F236F170004; Mon, 18 Sep 2006 01:08:49 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k8HM8O3W004959; Mon, 18 Sep 2006 01:08:24 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k8HM8Ott004957; Mon, 18 Sep 2006 01:08:24 +0300 From: Alex Lyashkov To: Kris Kennaway In-Reply-To: <20060917211905.GA64182@xor.obsecurity.org> References: <1158407656.3215.33.camel@berloga.shadowland> <20060917211905.GA64182@xor.obsecurity.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: SevcityNet Message-Id: <1158530904.3213.1.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Mon, 18 Sep 2006 01:08:24 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org Subject: Re: jail2 patchset 12 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, 17 Sep 2006 22:09:22 -0000 Thanks for you report. I really more test new jail2 API then old :( Please apply this patch. # p4 diff -du kern_jail.c =3D=3D=3D=3D //depot/projects/jail2/sys/kern/kern_jail.c#4 - /root/jail2/sys/kern/kern_jail.c =3D=3D=3D=3D @@ -316,6 +316,7 @@ if (error) return (error); + mtx_lock(&allprison_mtx); pr =3D prison_find(uap->jid); if (pr =3D=3D NULL) { return (ESRCH); =F7 =F0=CE=C4, 18.09.2006, =D7 00:19, Kris Kennaway =D0=C9=DB=C5=D4: > On Sat, Sep 16, 2006 at 02:54:16PM +0300, Alex Lyashkov wrote: > > Hello All, > >=20 > > Some time ago I finished the next public jail2 patchset. > > As of now, jail2 supports per-jail SYSV IPC namespaces. > > It is possible to configure which jails can and which cannot use > > SYSV IPC. The UID hash is also perl-jail now. > > he patchset also implements per-jail resource limits, such as: > > - number of SYSV IPC objects; > > - number of processes; > > - number of filedescriptors. > > In addition, all jail-related code was moved under 'options JAIL'. > >=20 > > The project's homepage: > > http://docs.freevps.com/doku.php?id=3Dfreebsd:index >=20 > I get the following panic when creating a jail: >=20 > panic: mutex allprison not owned at ../../../kern/kern_jail.c:374 > cpuid =3D 1 > KDB: enter: panic > [thread pid 930 tid 106142 ] > Stopped at kdb_enter+0x32: leave > db> wh > Tracing pid 930 tid 106142 td 0xd30841b0 > kdb_enter(c0756d95,1,c0755e9c,f17c9b80,d30841b0,...) at kdb_enter+0x32 > panic(c0755e9c,c075431c,c0754331,176,1,...) at panic+0x1b1 > _mtx_unlock_spin_flags(c07c6214,1,c0754331,176,0,...) at _mtx_unlock_spin= _flags > prison_find(1,0,0,d30841b0,c5bb9800,...) at prison_find+0x2e > jail_attach(d30841b0,f17c9bf0,c0754331,9f,c5bb992c,...) at jail_attach+0x= 38 > jail(d30841b0,f17c9d04,4,f17c9d38,1,...) at jail+0x3b5 > syscall(3b,3b,3b,bfbfe8c0,bfbfe904,...) at syscall+0x152 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (338, FreeBSD ELF32, jail), eip =3D 0x280d1ee7, esp =3D 0xbfb= fe3ac, ebp =3D 0xbfbfe888 --- >=20 > 930 545 544 0 R CPU 1 jail >=20 > Kris From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 22:15:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15D7816A416 for ; Sun, 17 Sep 2006 22:15:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B53F43D4C for ; Sun, 17 Sep 2006 22:15:51 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id ECF6A1A3C19; Sun, 17 Sep 2006 15:15:50 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3886B5159A; Sun, 17 Sep 2006 18:15:46 -0400 (EDT) Date: Sun, 17 Sep 2006 18:15:46 -0400 From: Kris Kennaway To: Alex Lyashkov Message-ID: <20060917221546.GA65438@xor.obsecurity.org> References: <1158407656.3215.33.camel@berloga.shadowland> <20060917211905.GA64182@xor.obsecurity.org> <1158530904.3213.1.camel@berloga.shadowland> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <1158530904.3213.1.camel@berloga.shadowland> User-Agent: Mutt/1.4.2.2i Cc: freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: jail2 patchset 12 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, 17 Sep 2006 22:15:52 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 18, 2006 at 01:08:24AM +0300, Alex Lyashkov wrote: > Thanks for you report. I really more test new jail2 API then old :( > Please apply this patch. >=20 > # p4 diff -du kern_jail.c > =3D=3D=3D=3D //depot/projects/jail2/sys/kern/kern_jail.c#4 - > /root/jail2/sys/kern/kern_jail.c =3D=3D=3D=3D > @@ -316,6 +316,7 @@ > if (error) > return (error); >=20 > + mtx_lock(&allprison_mtx); > pr =3D prison_find(uap->jid); > if (pr =3D=3D NULL) { > return (ESRCH); Thanks. The jail2 patch doesn't apply cleanly to HEAD now, BTW. Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFDckSWry0BWjoQKURAke3AJ9NbXde4oFeLUQ5r7GHm+R7fqPlYgCgiBxJ NgxtK85KTrMwM7pfcwnLzEk= =Qs57 -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 22:19:05 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFA2D16A407; Sun, 17 Sep 2006 22:19:05 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AFA543D45; Sun, 17 Sep 2006 22:19:04 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A7EF9.dip.t-dialin.net [84.154.126.249]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k8HMJ2Bk075516; Mon, 18 Sep 2006 00:19:03 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id k8HMJ06b001466; Mon, 18 Sep 2006 00:19:01 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id k8HMJ0Ub094762; Mon, 18 Sep 2006 00:19:00 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200609172219.k8HMJ0Ub094762@fire.jhs.private> To: hackers@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix C Net Consultancy, Munich/Muenchen User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com X-Fallback: jhs@mail.brierdr.com, jhs@freebsd.org, jhs@berklix.net In-reply-to: Your message of "Mon, 11 Sep 2006 20:30:38 +0200." <200609111830.k8BIUcNJ047171@thin.berklix.org> Date: Mon, 18 Sep 2006 00:19:00 +0200 Sender: jhs@flat.berklix.net Cc: Hajimu UMEMOTO Subject: Re: ppp cmmand port listens on ipv6 only if kernel has 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, 17 Sep 2006 22:19:06 -0000 > With a 6.1 Release custom kernel compiled with > options INET6 > & /etc/ppp/ppp.conf with > set server +12345 mypasswd > sockstat -l showed only: > sockstat -l showed only: > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > root ppp 1020 9 tcp6 *:12345 *:* > (& no 2nd line for ipv4), & so from my internal host, this failed: > pppctl -p mypasswd dsl:12345 Moved to: To: net@freebsd.org Subject: ppp command port does not listens on ipv4 unless no INET6 in kernel Message-id: <200609141344.k8EDiI42092840@flat.berklix.org> Patch posted,: Message-id: Date: Sun, 17 Sep 2006 20:10:47 +0900 From: Hajimu UMEMOTO Works fine, thanks :-) Nice if a 2nd tester confirm it, making it easier to commit I guess, (you dont need a DSL modem to test, after normal testing I unplugged modem & rebooted to check that) http://docs.freebsd.org/cgi/getmsg.cgi?fetch=50020+0+current/freebsd-net http://docs.FreeBSD.org/cgi/mid.cgi?200609172135.k8HLZvN5094226 If you try patch & confirm it, please cc Hajimu UMEMOTO Thanks -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 17 22:21:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FAFE16A40F for ; Sun, 17 Sep 2006 22:21:16 +0000 (UTC) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CBAB43D70 for ; Sun, 17 Sep 2006 22:21:02 +0000 (GMT) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 1C75D17001A; Mon, 18 Sep 2006 01:21:28 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 3D698170004; Mon, 18 Sep 2006 01:21:22 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k8HMKvlx005533; Mon, 18 Sep 2006 01:20:57 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k8HMKuxO005531; Mon, 18 Sep 2006 01:20:56 +0300 From: Alex Lyashkov To: Kris Kennaway In-Reply-To: <20060917221546.GA65438@xor.obsecurity.org> References: <1158407656.3215.33.camel@berloga.shadowland> <20060917211905.GA64182@xor.obsecurity.org> <1158530904.3213.1.camel@berloga.shadowland> <20060917221546.GA65438@xor.obsecurity.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SevcityNet Message-Id: <1158531656.3213.6.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Mon, 18 Sep 2006 01:20:56 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org Subject: Re: jail2 patchset 12 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, 17 Sep 2006 22:21:16 -0000 patchset 12 created 2 week ago (or so). Today i integrate last changes and upload patchset 13. =F7 =F0=CE=C4, 18.09.2006, =D7 01:15, Kris Kennaway =D0=C9=DB=C5=D4: > On Mon, Sep 18, 2006 at 01:08:24AM +0300, Alex Lyashkov wrote: > > Thanks for you report. I really more test new jail2 API then old :( > > Please apply this patch. > >=20 > > # p4 diff -du kern_jail.c > > =3D=3D=3D=3D //depot/projects/jail2/sys/kern/kern_jail.c#4 - > > /root/jail2/sys/kern/kern_jail.c =3D=3D=3D=3D > > @@ -316,6 +316,7 @@ > > if (error) > > return (error); > >=20 > > + mtx_lock(&allprison_mtx); > > pr =3D prison_find(uap->jid); > > if (pr =3D=3D NULL) { > > return (ESRCH); >=20 > Thanks. The jail2 patch doesn't apply cleanly to HEAD now, BTW. >=20 > Kris From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 10:55:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 168E816A416 for ; Mon, 18 Sep 2006 10:55:07 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B90A43D76 for ; Mon, 18 Sep 2006 10:54:58 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so3911164wxd for ; Mon, 18 Sep 2006 03:54:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CPowbSn1E2umsjfJMLbNIztjovN3V8AGgNvh7DimkN9bjlCa6C8/AfkYU4rqr3icwP2KCpi84ifdT68c06mR2debmGc5jFfQDQMzZq1lhDxh4g6PrtpIGeABqlC7FmxxCBSpBNApdewkJu3W1DxPY9sv+n+6HXDvW0EcbB/5bk8= Received: by 10.70.29.7 with SMTP id c7mr19948143wxc; Mon, 18 Sep 2006 03:54:58 -0700 (PDT) Received: by 10.70.124.6 with HTTP; Mon, 18 Sep 2006 03:54:57 -0700 (PDT) Message-ID: Date: Mon, 18 Sep 2006 12:54:57 +0200 From: "Rene Ladan" To: "Ed Schouten" In-Reply-To: <20060918095813.GM22564@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <450DA217.9080602@gmail.com> <20060918095813.GM22564@hoeg.nl> Cc: FreeBSD Hackers , freebsd-usb@freebsd.org Subject: Re: anyone working on setting output items with usbhidctl(1) ? 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, 18 Sep 2006 10:55:08 -0000 2006/9/18, Ed Schouten : > Hello Rene, > > * Rene Ladan wrote: > > is anyone working on setting output items with usbhidctl(1) ? > > > > I'm trying to add LED/rumbler support for the Xbox 360 Gamepad to > > uhid(4), but there doesn't seem to be a userland tool to test output > > items and the output report descriptor doesn't seem to be publicly > > available (i.e. I must reverse-engineer it). > > > > This device has 4 LEDs which can be controlled with the command 01 03 > > xx, where xx ranges from 0 to 255. > > It also has two rumble motors which can be controlled with 00 08 00 bb > > ll 00 00 00, where bb and ll both range from 0 to 255. > > Try the following C code: > > | #include > | #include > | > | int > | main(int argc, char *argv[]) > | { > | char buffer[3] = { 1, 3, 0 }; > | int fd; > | > | fd = open("/dev/ugen0.2", O_WRONLY); > | if (fd < 0) { > | fprintf(stderr, "Cannot open device\n"); > | return (-1); > | } > | > | write(fd, buffer, sizeof buffer); > | close(fd); > | > | return (0); > | } > > I'm currently toying around with the headset, so I've disabled the > uhid(4) driver, so the LED on the gamepad keeps blinking. Running the > application above turns off the LED. I guess it should also work when > you write it to /dev/uhidX. > I tried that too, it does not work on /dev/uhidX (my code opened the device read/write instead of write-only). I'll try to extend the HID descriptor to support the LED and rumblers. > -- > Ed Schouten > WWW: http://g-rave.nl/ > > > Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 09:58:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDC716A415; Mon, 18 Sep 2006 09:58:16 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 512D043D6E; Mon, 18 Sep 2006 09:58:15 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 86A231CC0E; Mon, 18 Sep 2006 11:58:13 +0200 (CEST) Date: Mon, 18 Sep 2006 11:58:13 +0200 From: Ed Schouten To: Rene Ladan Message-ID: <20060918095813.GM22564@hoeg.nl> References: <450DA217.9080602@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBMNUjqROSlRgKnE" Content-Disposition: inline In-Reply-To: <450DA217.9080602@gmail.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Mailman-Approved-At: Mon, 18 Sep 2006 11:27:41 +0000 Cc: FreeBSD Hackers , freebsd-usb@freebsd.org Subject: Re: anyone working on setting output items with usbhidctl(1) ? 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, 18 Sep 2006 09:58:16 -0000 --gBMNUjqROSlRgKnE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Rene, * Rene Ladan wrote: > is anyone working on setting output items with usbhidctl(1) ? >=20 > I'm trying to add LED/rumbler support for the Xbox 360 Gamepad to > uhid(4), but there doesn't seem to be a userland tool to test output > items and the output report descriptor doesn't seem to be publicly > available (i.e. I must reverse-engineer it). >=20 > This device has 4 LEDs which can be controlled with the command 01 03 > xx, where xx ranges from 0 to 255. > It also has two rumble motors which can be controlled with 00 08 00 bb > ll 00 00 00, where bb and ll both range from 0 to 255. Try the following C code: | #include | #include |=20 | int | main(int argc, char *argv[]) | { | char buffer[3] =3D { 1, 3, 0 }; | int fd; |=20 | fd =3D open("/dev/ugen0.2", O_WRONLY); | if (fd < 0) { | fprintf(stderr, "Cannot open device\n"); | return (-1); | } |=20 | write(fd, buffer, sizeof buffer); | close(fd); |=20 | return (0); | } I'm currently toying around with the headset, so I've disabled the uhid(4) driver, so the LED on the gamepad keeps blinking. Running the application above turns off the LED. I guess it should also work when you write it to /dev/uhidX. --=20 Ed Schouten WWW: http://g-rave.nl/ --gBMNUjqROSlRgKnE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFDm2152SDGA2eCwURAkhXAJ9VJXQi9U49PcVy+aL4EcEQP0sO4wCfUj2g UL36uJcKFGDEJsKdAYghmG8= =WbYv -----END PGP SIGNATURE----- --gBMNUjqROSlRgKnE-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 11:39:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8875816A492 for ; Mon, 18 Sep 2006 11:39:37 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id A83D043D6B for ; Mon, 18 Sep 2006 11:39:04 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so3922781wxd for ; Mon, 18 Sep 2006 04:39:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kJtcryJzyeWraLCgOIDUlpuw/MTsccVVbceLr+rkzuxCxVojO0pKqmorO3Y+2e/FkqgYtohoXCaUinpO20+prfOarZiOxdt/2srIjRqqX24GW77jCLEwdNelvIi1/7muRhJU0M7r5gRB5HcITgs4KYr6zM/9HB/5rabxqLuJLKw= Received: by 10.70.19.16 with SMTP id 16mr18269337wxs; Mon, 18 Sep 2006 04:39:03 -0700 (PDT) Received: by 10.70.124.6 with HTTP; Mon, 18 Sep 2006 04:39:03 -0700 (PDT) Message-ID: Date: Mon, 18 Sep 2006 13:39:03 +0200 From: "Rene Ladan" To: freebsd-hackers@freebsd.org, freebsd-usb@freebsd.org In-Reply-To: <450DA217.9080602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <450DA217.9080602@gmail.com> Cc: Subject: Re: anyone working on setting output items with usbhidctl(1) ? 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, 18 Sep 2006 11:39:37 -0000 2006/9/17, Rene Ladan : > Hi, > > is anyone working on setting output items with usbhidctl(1) ? > > I thought that something like -s "feature1=value1,feature2=value2,..." > would be nice to have. > I noticed that the usbhidctl(1) tool in OpenBSD has a -w option to set output and feature items, so I'll try to port it to the FreeBSD tool. > I'm not subscribed to the usb@ list, so please cc me. > Kind regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 15:02:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8CAE16A417 for ; Mon, 18 Sep 2006 15:02:12 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67C3643D73 for ; Mon, 18 Sep 2006 15:02:12 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k8IF2BVH037772 for ; Mon, 18 Sep 2006 10:02:11 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <450EB4FE.2090203@centtech.com> Date: Mon, 18 Sep 2006 10:02:22 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.87.1/1892/Mon Sep 18 06:53:36 2006 on mh2.centtech.com X-Virus-Status: Clean Subject: 6-STABLE filesystem related panics/locks (kgdb output) 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, 18 Sep 2006 15:02:13 -0000 Hi all, On one of our NFS servers, we've seen repeated filesystem issues with two of the filesystems (it has 4 exported via NFS). It usually manifests itself by a hung 'df -lk' (wedged in 'ufs'), and mountd becomes wedged also, not allowing new mounts, and unable to be killed. From an NFS client, one can continue using the filesystem just fine, without an issue. From the server itself, you can cd to the filesystem's root directory, but an ls will hang. Running a background fsck on that filesystem while in this state also blocks on ufs. My nfsd processes with also get stuck in the 'D' state (in 'ufs'), but they still appear to be serving data. About a month ago, I brought the system down, did a full fsck on all the filesystems, and brought it back up. It survived for several weeks (2-3), but is now doing the same thing, so I'm uncertain if the issue was affected by the fsck at all (doubtful). This morning, prior to rebooting the system to get it out of this state, I began unmounting filesystems in case of a panic, and after unmounting (successfully) two of the filesystems (the ones I've never seen an issue on), I tried unmounting the third (/scr02), and a panic ensued. /scr01 is the other filesystem that is giving me issues. Some information about the system/setup: FreeBSD smd2.centtech.com 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Aug 12 13:24:02 CDT 2006 # df -ilk Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/amrd0s1a 20308398 3098864 15584864 17% 259261 2378561 10% / devfs 1 1 0 100% 0 0 100% /dev /dev/amrd0s1d 13065232 3960250 8059764 33% 870 1694872 0% /var /dev/ufs/rss 213268540 93886480 102320578 48% 399297 27180093 1% /rss /dev/ufs/scr02 213268540 116904962 79302096 60% 426573 27152817 2% /scr02 /dev/ufs/scr04 167568544 93374026 60789036 61% 13008 21654830 0% /scr04 /dev/ufs/scr01 232100360 161547746 51984586 76% 531834 29473412 2% /scr01 (rss and scr04 never give me any issues) All four of the ufs/* partitions are on the same RAID array, and I don't believe there is any underlying disk issue. Here's some kgdb output from when the system was wedged on /scr01, but the unmount of /scr02 caused a panic: # kgdb -q -n 3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] Unread portion of the kernel message buffer: Mount point /scr02 had 1 dangling refs panic: unmount: dangling vnode cpuid = 0 KDB: enter: panic Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261824 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 5 59 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0473b9b in db_fncall (dummy1=-1063129632, dummy2=0, dummy3=-1064859081, dummy4=0xe8de3ab8 "ä:Þè\234l\207ÀÐ:ÞèÔ:Þè\220\a") at /usr/src/sys/ddb/db_command.c:492 #2 0xc04739a0 in db_command (last_cmdp=0xc09d0144, cmd_table=0x0, aux_cmd_tablep=0xc092fe4c, aux_cmd_tablep_end=0xc092fe68) at /usr/src/sys/ddb/db_command.c:350 #3 0xc0473a68 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #4 0xc0475679 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0697c0c in kdb_trap (type=3, code=0, tf=0xe8de3bfc) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc0896338 in trap (frame= {tf_fs = -388104184, tf_es = -1066860504, tf_ds = -1064304600, tf_edi = -1064235220, tf_esi = 1, tf_ebp = -388088772, tf_isp = -388088792, tf _ebx = -388088728, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066829453, tf_cs = 32, tf_eflags = 646, tf_ esp = -388088740, tf_ss = -1066934521}) at /usr/src/sys/i386/i386/trap.c:593 #7 0xc0881e5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xc0697973 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc067df07 in panic (fmt=0xc0910f2c "unmount: dangling vnode") at /usr/src/sys/kern/kern_shutdown.c:549 #10 0xc06d153e in vfs_mount_destroy (mp=0xc5964000, td=0xc620c600) at /usr/src/sys/kern/vfs_mount.c:514 #11 0xc06d2d26 in dounmount (mp=0xc5964000, flags=134217728, td=0xc620c600) at /usr/src/sys/kern/vfs_mount.c:1162 #12 0xc06d27de in unmount (td=0xc620c600, uap=0xe8de3d04) at /usr/src/sys/kern/vfs_mount.c:1052 #13 0xc0896c0b in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134521957, tf_esi = 134535289, tf_ebp = -1077942776, tf_isp = -388088476, tf_ebx = -1077942864, tf_edx = 26, tf_ecx = 0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 671864503, tf_cs = 51, tf_eflags = 518, tf_esp = -1077942948, tf_ss = 5 9}) at /usr/src/sys/i386/i386/trap.c:981 #14 0xc0881eaf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xc06d153e in vfs_mount_destroy (mp=0xc5964000, td=0xc620c600) at /usr/src/sys/kern/vfs_mount.c:514 514 panic("unmount: dangling vnode"); (kgdb) l 509 printf("mount point secondary write ops completed\n"); 510 } 511 MNT_IUNLOCK(mp); 512 mp->mnt_vfc->vfc_refcount--; 513 if (!TAILQ_EMPTY(&mp->mnt_nvnodelist)) 514 panic("unmount: dangling vnode"); 515 lockdestroy(&mp->mnt_lock); 516 MNT_ILOCK(mp); 517 if (mp->mnt_kern_flag & MNTK_MWAIT) 518 wakeup(mp); (kgdb) p *mp $2 = {mnt_list = {tqe_next = 0xc5964400, tqe_prev = 0xc59bbc00}, mnt_op = 0xc09b96e0, mnt_vfc = 0xc09b9720, mnt_vnodecovered = 0xc5ae0cc0, mnt_syncer = 0x0, mnt_nvnodelist = {tqh_first = 0xc6d59440, tqh_last = 0xc6d59454}, mnt_lock = {lk_interlock = 0xc09eac84, lk_flags = 1048576, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc0910dff "vfslock", lk_timo = 0, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, mnt_mtx = {mtx_object = {lo_class = 0xc0980124, lo_name = 0xc0910dee "struct mount mtx", lo_type = 0xc0910dee "struct mount mtx", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, mnt_writeopcount = 0, mnt_flag = 2097920, mnt_opt = 0xc5926a00, mnt_optnew = 0x0, mnt_kern_flag = 553648128, mnt_maxsymlinklen = 120, mnt_stat = {f_version = 537068824, f_type = 5, f_flags = 2102016, f_bsize = 2048, f_iosize = 16384, f_blocks = 106634270, f_bfree = 48180134, f_bavail = 39649393, f_files = 27579390, f_ffree = 27152822, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {1111508928, -571478071}}, f_charspare = '\0' , f_fstypename = "ufs", '\0' , f_mntfromname = "/dev/ufs/scr02", '\0' , f_mntonname = "/scr02", '\0' }, mnt_cred = 0xc59f2080, mnt_data = 0x0, mnt_time = 0, mnt_iosize_max = 131072, mnt_export = 0xc5d25c00, mnt_mntlabel = 0x0, mnt_fslabel = 0x0, mnt_nvnodelistsize = 1, mnt_hashseed = 3369618744, mnt_markercnt = 0, mnt_holdcnt = 0, mnt_holdcntwaiters = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 2126786, mnt_ref = 1} (kgdb) p mp->mnt_vfc->vfc_refcount $3 = 4 Anything else I can provide to help find the issue? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 15:17:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E577416A494 for ; Mon, 18 Sep 2006 15:17:15 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A3543D4C for ; Mon, 18 Sep 2006 15:17:14 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k8IFHEhi040200 for ; Mon, 18 Sep 2006 10:17:14 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <450EB884.9090301@centtech.com> Date: Mon, 18 Sep 2006 10:17:24 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: FreeBSD Hackers References: <450EB4FE.2090203@centtech.com> In-Reply-To: <450EB4FE.2090203@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.87.1/1892/Mon Sep 18 06:53:36 2006 on mh2.centtech.com X-Virus-Status: Clean Subject: Re: 6-STABLE filesystem related panics/locks (kgdb output) 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, 18 Sep 2006 15:17:16 -0000 On 09/18/06 10:02, Eric Anderson wrote: > Hi all, > > On one of our NFS servers, we've seen repeated filesystem issues with > two of the filesystems (it has 4 exported via NFS). It usually > manifests itself by a hung 'df -lk' (wedged in 'ufs'), and mountd > becomes wedged also, not allowing new mounts, and unable to be killed. > From an NFS client, one can continue using the filesystem just fine, > without an issue. From the server itself, you can cd to the > filesystem's root directory, but an ls will hang. Running a background > fsck on that filesystem while in this state also blocks on ufs. My nfsd > processes with also get stuck in the 'D' state (in 'ufs'), but they > still appear to be serving data. About a month ago, I brought the system > down, did a full fsck on all the filesystems, and brought it back up. > It survived for several weeks (2-3), but is now doing the same thing, so > I'm uncertain if the issue was affected by the fsck at all (doubtful). > > This morning, prior to rebooting the system to get it out of this state, > I began unmounting filesystems in case of a panic, and after unmounting > (successfully) two of the filesystems (the ones I've never seen an issue > on), I tried unmounting the third (/scr02), and a panic ensued. /scr01 > is the other filesystem that is giving me issues. > > Some information about the system/setup: > > FreeBSD smd2.centtech.com 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Aug 12 > 13:24:02 CDT 2006 > > # df -ilk > Filesystem 1K-blocks Used Avail Capacity iused ifree > %iused Mounted on > /dev/amrd0s1a 20308398 3098864 15584864 17% 259261 2378561 > 10% / > devfs 1 1 0 100% 0 0 > 100% /dev > /dev/amrd0s1d 13065232 3960250 8059764 33% 870 1694872 > 0% /var > /dev/ufs/rss 213268540 93886480 102320578 48% 399297 27180093 > 1% /rss > /dev/ufs/scr02 213268540 116904962 79302096 60% 426573 27152817 > 2% /scr02 > /dev/ufs/scr04 167568544 93374026 60789036 61% 13008 21654830 > 0% /scr04 > /dev/ufs/scr01 232100360 161547746 51984586 76% 531834 29473412 > 2% /scr01 > > (rss and scr04 never give me any issues) > > All four of the ufs/* partitions are on the same RAID array, and I don't > believe there is any underlying disk issue. > > Here's some kgdb output from when the system was wedged on /scr01, but > the unmount of /scr02 caused a panic: > > # kgdb -q -n 3 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > Unread portion of the kernel message buffer: > Mount point /scr02 had 1 dangling refs > panic: unmount: dangling vnode > cpuid = 0 > KDB: enter: panic > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1023MB (261824 pages) 1007 991 975 959 943 927 911 895 879 > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 > 575 5 > 59 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 > 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0473b9b in db_fncall (dummy1=-1063129632, dummy2=0, > dummy3=-1064859081, dummy4=0xe8de3ab8 "ä:Þè\234l\207ÀÐ:ÞèÔ:Þè\220\a") > at /usr/src/sys/ddb/db_command.c:492 > #2 0xc04739a0 in db_command (last_cmdp=0xc09d0144, cmd_table=0x0, > aux_cmd_tablep=0xc092fe4c, aux_cmd_tablep_end=0xc092fe68) > at /usr/src/sys/ddb/db_command.c:350 > #3 0xc0473a68 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 > #4 0xc0475679 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 > #5 0xc0697c0c in kdb_trap (type=3, code=0, tf=0xe8de3bfc) at > /usr/src/sys/kern/subr_kdb.c:473 > #6 0xc0896338 in trap (frame= > {tf_fs = -388104184, tf_es = -1066860504, tf_ds = -1064304600, > tf_edi = -1064235220, tf_esi = 1, tf_ebp = -388088772, tf_isp = > -388088792, tf > _ebx = -388088728, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, > tf_trapno = 3, tf_err = 0, tf_eip = -1066829453, tf_cs = 32, tf_eflags = > 646, tf_ > esp = -388088740, tf_ss = -1066934521}) at /usr/src/sys/i386/i386/trap.c:593 > #7 0xc0881e5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #8 0xc0697973 in kdb_enter (msg=0x12
) at > cpufunc.h:60 > #9 0xc067df07 in panic (fmt=0xc0910f2c "unmount: dangling vnode") at > /usr/src/sys/kern/kern_shutdown.c:549 > #10 0xc06d153e in vfs_mount_destroy (mp=0xc5964000, td=0xc620c600) at > /usr/src/sys/kern/vfs_mount.c:514 > #11 0xc06d2d26 in dounmount (mp=0xc5964000, flags=134217728, > td=0xc620c600) at /usr/src/sys/kern/vfs_mount.c:1162 > #12 0xc06d27de in unmount (td=0xc620c600, uap=0xe8de3d04) at > /usr/src/sys/kern/vfs_mount.c:1052 > #13 0xc0896c0b in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134521957, tf_esi = > 134535289, tf_ebp = -1077942776, tf_isp = -388088476, tf_ebx = -1077942864, > tf_edx = 26, tf_ecx = 0, tf_eax = 22, tf_trapno = 12, tf_err = 2, > tf_eip = 671864503, tf_cs = 51, tf_eflags = 518, tf_esp = -1077942948, > tf_ss = 5 > 9}) at /usr/src/sys/i386/i386/trap.c:981 > #14 0xc0881eaf in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > #15 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) frame 10 > #10 0xc06d153e in vfs_mount_destroy (mp=0xc5964000, td=0xc620c600) at > /usr/src/sys/kern/vfs_mount.c:514 > 514 panic("unmount: dangling vnode"); > (kgdb) l > 509 printf("mount point secondary write ops > completed\n"); > 510 } > 511 MNT_IUNLOCK(mp); > 512 mp->mnt_vfc->vfc_refcount--; > 513 if (!TAILQ_EMPTY(&mp->mnt_nvnodelist)) > 514 panic("unmount: dangling vnode"); > 515 lockdestroy(&mp->mnt_lock); > 516 MNT_ILOCK(mp); > 517 if (mp->mnt_kern_flag & MNTK_MWAIT) > 518 wakeup(mp); > > (kgdb) p *mp > $2 = {mnt_list = {tqe_next = 0xc5964400, tqe_prev = 0xc59bbc00}, mnt_op > = 0xc09b96e0, mnt_vfc = 0xc09b9720, mnt_vnodecovered = 0xc5ae0cc0, > mnt_syncer = 0x0, mnt_nvnodelist = {tqh_first = 0xc6d59440, tqh_last > = 0xc6d59454}, mnt_lock = {lk_interlock = 0xc09eac84, lk_flags = 1048576, > lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio > = 80, lk_wmesg = 0xc0910dff "vfslock", lk_timo = 0, > lk_lockholder = 0xffffffff, lk_newlock = 0x0}, mnt_mtx = > {mtx_object = {lo_class = 0xc0980124, lo_name = 0xc0910dee "struct mount > mtx", > lo_type = 0xc0910dee "struct mount mtx", lo_flags = 196608, > lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock > = 4, > mtx_recurse = 0}, mnt_writeopcount = 0, mnt_flag = 2097920, mnt_opt > = 0xc5926a00, mnt_optnew = 0x0, mnt_kern_flag = 553648128, > mnt_maxsymlinklen = 120, mnt_stat = {f_version = 537068824, f_type = > 5, f_flags = 2102016, f_bsize = 2048, f_iosize = 16384, > f_blocks = 106634270, f_bfree = 48180134, f_bavail = 39649393, > f_files = 27579390, f_ffree = 27152822, f_syncwrites = 0, f_asyncwrites > = 0, > f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, > 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {1111508928, > -571478071}}, f_charspare = '\0' , > f_fstypename = "ufs", '\0' , > f_mntfromname = "/dev/ufs/scr02", '\0' , > f_mntonname = "/scr02", '\0' }, mnt_cred = 0xc59f2080, > mnt_data = 0x0, mnt_time = 0, mnt_iosize_max = 131072, mnt_export = > 0xc5d25c00, mnt_mntlabel = 0x0, mnt_fslabel = 0x0, mnt_nvnodelistsize = 1, > mnt_hashseed = 3369618744, mnt_markercnt = 0, mnt_holdcnt = 0, > mnt_holdcntwaiters = 0, mnt_secondary_writes = 0, > mnt_secondary_accwrites = 2126786, mnt_ref = 1} > (kgdb) p mp->mnt_vfc->vfc_refcount > $3 = 4 > > > Anything else I can provide to help find the issue? > > > Eric > > > Another batch of kgdb output from this same system, with the same issue: # kgdb -q -n 1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] Unread portion of the kernel message buffer: Mount point /rss had 1 dangling refs panic: unmount: dangling vnode cpuid = 0 KDB: enter: panic Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261824 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc0473b9b in db_fncall (dummy1=-1063129632, dummy2=0, dummy3=-1064859081, dummy4=0xe8e65ab8 "äZæè\234l\207ÀÐZæèÔZæè\220\a") at /usr/src/sys/ddb/db_command.c:492 #2 0xc04739a0 in db_command (last_cmdp=0xc09d0144, cmd_table=0x0, aux_cmd_tablep=0xc092fe4c, aux_cmd_tablep_end=0xc092fe68) at /usr/src/sys/ddb/db_command.c:350 #3 0xc0473a68 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #4 0xc0475679 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0697c0c in kdb_trap (type=3, code=0, tf=0xe8e65bfc) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc0896338 in trap (frame= {tf_fs = -387579896, tf_es = -1066860504, tf_ds = -1064304600, tf_edi = -1064235220, tf_esi = 1, tf_ebp = -387556292, tf_isp = -387556312, tf_ebx = -387556248, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066829453, tf_cs = 32, tf_eflags = 646, tf_esp = -387556260, tf_ss = -1066934521}) at /usr/src/sys/i386/i386/trap.c:593 #7 0xc0881e5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xc0697973 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc067df07 in panic (fmt=0xc0910f2c "unmount: dangling vnode") at /usr/src/sys/kern/kern_shutdown.c:549 #10 0xc06d153e in vfs_mount_destroy (mp=0xc59bbc00, td=0xc5c16000) at /usr/src/sys/kern/vfs_mount.c:514 #11 0xc06d2d26 in dounmount (mp=0xc59bbc00, flags=134217728, td=0xc5c16000) at /usr/src/sys/kern/vfs_mount.c:1162 #12 0xc06d27de in unmount (td=0xc5c16000, uap=0xe8e65d04) at /usr/src/sys/kern/vfs_mount.c:1052 #13 0xc0896c0b in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134521957, tf_esi = 134534817, tf_ebp = -1077942776, tf_isp = -387555996, tf_ebx = -1077942864, tf_edx = 25, tf_ecx = 0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 671864503, tf_cs = 51, tf_eflags = 518, tf_esp = -1077942948, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 #14 0xc0881eaf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xc06d153e in vfs_mount_destroy (mp=0xc59bbc00, td=0xc5c16000) at /usr/src/sys/kern/vfs_mount.c:514 514 panic("unmount: dangling vnode"); (kgdb) l 509 printf("mount point secondary write ops completed\n"); 510 } 511 MNT_IUNLOCK(mp); 512 mp->mnt_vfc->vfc_refcount--; 513 if (!TAILQ_EMPTY(&mp->mnt_nvnodelist)) 514 panic("unmount: dangling vnode"); 515 lockdestroy(&mp->mnt_lock); 516 MNT_ILOCK(mp); 517 if (mp->mnt_kern_flag & MNTK_MWAIT) 518 wakeup(mp); (kgdb) p mp->mnt_vfc->vfc_refcount $1 = 4 (kgdb) p *mp $2 = {mnt_list = {tqe_next = 0xc595d000, tqe_prev = 0xc59bc000}, mnt_op = 0xc09b96e0, mnt_vfc = 0xc09b9720, mnt_vnodecovered = 0xc5a81cc0, mnt_syncer = 0x0, mnt_nvnodelist = {tqh_first = 0xc8af4000, tqh_last = 0xc8af4014}, mnt_lock = {lk_interlock = 0xc09eac18, lk_flags = 1048576, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc0910dff "vfslock", lk_timo = 0, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, mnt_mtx = {mtx_object = {lo_class = 0xc0980124, lo_name = 0xc0910dee "struct mount mtx", lo_type = 0xc0910dee "struct mount mtx", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, mnt_writeopcount = 0, mnt_flag = 2097920, mnt_opt = 0xc5728a40, mnt_optnew = 0x0, mnt_kern_flag = 553648128, mnt_maxsymlinklen = 120, mnt_stat = {f_version = 537068824, f_type = 5, f_flags = 2102016, f_bsize = 2048, f_iosize = 16384, f_blocks = 106634270, f_bfree = 65410962, f_bavail = 56880221, f_files = 27579390, f_ffree = 27203064, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = {val = {1111508926, 499625180}}, f_charspare = '\0' , f_fstypename = "ufs", '\0' , f_mntfromname = "/dev/ufs/rss", '\0' , f_mntonname = "/rss", '\0' }, mnt_cred = 0xc5a56c80, mnt_data = 0x0, mnt_time = 0, mnt_iosize_max = 131072, mnt_export = 0xc59e8000, mnt_mntlabel = 0x0, mnt_fslabel = 0x0, mnt_nvnodelistsize = 1, mnt_hashseed = 2115021039, mnt_markercnt = 0, mnt_holdcnt = 0, mnt_holdcntwaiters = 0, mnt_secondary_writes = 0, mnt_secondary_accwrites = 12553194, mnt_ref = 1} (kgdb) p &mp->mnt_nvnodelist $3 = (struct vnodelst *) 0xc59bbc18 (kgdb) p mp->mnt_nvnodelist $4 = {tqh_first = 0xc8af4000, tqh_last = 0xc8af4014} Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 18:55:19 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2186A16A403 for ; Mon, 18 Sep 2006 18:55:18 +0000 (UTC) (envelope-from jchoque@tlmat.unican.es) Received: from luna.tlmat.unican.es (luna.tlmat.unican.es [193.144.186.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4BE43D5F for ; Mon, 18 Sep 2006 18:54:37 +0000 (GMT) (envelope-from jchoque@tlmat.unican.es) Received: from Altair (altair.tlmat.unican.es [193.144.186.43]) by luna.tlmat.unican.es (8.12.11/8.12.11) with ESMTP id k8IIPp9r000973 for ; Mon, 18 Sep 2006 20:25:51 +0200 From: "Johnny Choque" To: Date: Mon, 18 Sep 2006 20:54:34 +0200 Message-ID: <004d01c6db53$e1dbe150$2bba90c1@Altair> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcbbU+HLG/ezzWvqRhmV+wpnFYhV4Q== Subject: ath driver debug 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, 18 Sep 2006 18:55:19 -0000 Hi, I would like to know how can I set the ath driver in debug mode. The scanning functionality of ath0 interface only detect the associated AP but do not the other ones. I'm trying to use the debug mode in order to detect what the problem is. My wireless card is D-link DWL-AG660. Johnny From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 20:05:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA60516A40F for ; Mon, 18 Sep 2006 20:05:00 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E78643D64 for ; Mon, 18 Sep 2006 20:05:00 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 79477217DE; Mon, 18 Sep 2006 16:04:59 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id E1D234AC56; Mon, 18 Sep 2006 16:04:55 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17678.64487.843332.915988@canoe.dclg.ca> Date: Mon, 18 Sep 2006 16:04:55 -0400 To: freebsd-hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Subject: isc-dhclient declining offers. 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, 18 Sep 2006 20:05:00 -0000 I'm having trouble with the isc-dhclient port declining offers. On the cosole, it says: dhclient.c(2174): null pointer each time. Now... the code in dhclient seems to be heavily macro'd to look like lisp, so I'm a little lost as to the nature of this problem. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 20:08:51 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D66DA16A568 for ; Mon, 18 Sep 2006 20:08:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 434C443D64 for ; Mon, 18 Sep 2006 20:08:50 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060918200849m9100sn0sae>; Mon, 18 Sep 2006 20:08:49 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k8IK8dMf041759; Mon, 18 Sep 2006 15:08:40 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k8IK8ZF4041758; Mon, 18 Sep 2006 15:08:35 -0500 (CDT) (envelope-from brooks) Date: Mon, 18 Sep 2006 15:08:35 -0500 From: Brooks Davis To: David Gilbert Message-ID: <20060918200834.GA41744@lor.one-eyed-alien.net> References: <17678.64487.843332.915988@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <17678.64487.843332.915988@canoe.dclg.ca> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: isc-dhclient declining offers. 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, 18 Sep 2006 20:08:51 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 18, 2006 at 04:04:55PM -0400, David Gilbert wrote: > I'm having trouble with the isc-dhclient port declining offers. On > the cosole, it says: >=20 > dhclient.c(2174): null pointer >=20 > each time. >=20 > Now... the code in dhclient seems to be heavily macro'd to look like > lisp, so I'm a little lost as to the nature of this problem. You should bring this up on the ISC mailing lists. We no longer ship the ISC client in any activly developed version of FreeBSD. -- Brooks --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFDvzCXY6L6fI4GtQRAoaVAKDftehhKh1hva+/b3/9C6VztF/pgQCfXwut UQJoPWIgxaHJFN/SkZzy9BE= =MctR -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 20:46:27 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D315B16A4F4 for ; Mon, 18 Sep 2006 20:46:27 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A6443D64 for ; Mon, 18 Sep 2006 20:46:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k8IKkOI2006625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Sep 2006 13:46:26 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <450F05A0.5070404@errno.com> Date: Mon, 18 Sep 2006 13:46:24 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: Johnny Choque References: <004d01c6db53$e1dbe150$2bba90c1@Altair> In-Reply-To: <004d01c6db53$e1dbe150$2bba90c1@Altair> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ath driver debug 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, 18 Sep 2006 20:46:28 -0000 Johnny Choque wrote: > Hi, > > I would like to know how can I set the ath driver in debug mode. The > scanning functionality of ath0 interface only detect the associated AP but > do not the other ones. I'm trying to use the debug mode in order to detect > what the problem is. My wireless card is D-link DWL-AG660. First, if you've got a problem with scanning turning on debug msgs in the driver is unlikely to help you. Instead turn on debug msgs in the net80211 layer with wlandebug (src/tools/tools/net80211). As to ath debug msgs you need to build the driver with the ATH_DEBUG option. Then you can use athdebug a la wlandebug (src/tools/tools/ath). Sam From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 18 22:05:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7238E16A403 for ; Mon, 18 Sep 2006 22:05:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8908A43D67 for ; Mon, 18 Sep 2006 22:05:21 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8IM5Gdk079022; Mon, 18 Sep 2006 18:05:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 18 Sep 2006 17:50:57 -0400 User-Agent: KMail/1.9.1 References: <1158407656.3215.33.camel@berloga.shadowland> <20060917211905.GA64182@xor.obsecurity.org> <1158530904.3213.1.camel@berloga.shadowland> In-Reply-To: <1158530904.3213.1.camel@berloga.shadowland> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609181750.58145.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]); Mon, 18 Sep 2006 18:05:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1893/Mon Sep 18 14:37:26 2006 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: Alex Lyashkov , Kris Kennaway Subject: Re: jail2 patchset 12 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, 18 Sep 2006 22:05:26 -0000 On Sunday 17 September 2006 18:08, Alex Lyashkov wrote: > Thanks for you report. I really more test new jail2 API then old :( > Please apply this patch. > > # p4 diff -du kern_jail.c > ==== //depot/projects/jail2/sys/kern/kern_jail.c#4 - > /root/jail2/sys/kern/kern_jail.c ==== > @@ -316,6 +316,7 @@ > if (error) > return (error); > > + mtx_lock(&allprison_mtx); > pr = prison_find(uap->jid); > if (pr == NULL) { > return (ESRCH); Does this leak the lock in the ESRCH case now? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 07:55:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABC0816A403 for ; Tue, 19 Sep 2006 07:55:52 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 086BA43D46 for ; Tue, 19 Sep 2006 07:55:51 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail24.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k8J7toOK032706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 19 Sep 2006 17:55:50 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k8J7tocT001043 for ; Tue, 19 Sep 2006 17:55:50 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k8J7tonP001042 for freebsd-hackers@freebsd.org; Tue, 19 Sep 2006 17:55:50 +1000 (EST) (envelope-from peter) Date: Tue, 19 Sep 2006 17:55:50 +1000 From: Peter Jeremy To: freebsd-hackers@freebsd.org Message-ID: <20060919075550.GB720@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.12-2006-07-14 Subject: Delivering SIGKILL to init 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, 19 Sep 2006 07:55:52 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Prompted by some discussion elsewhere, I've been trying to send SIGKILL to init. If I ktrace kill(1), I can see "kill(1,9)" which returns 0 but the signal is never delivered. If I sent (eg) SIGXCPU then init dies and the kernel panics (as expected). I've looked through sys/kern/kern_* and can't see anywhere that special cases the delivery of SIGKILL to init. Can anyone please explain why SIGKILL doesn't kill init (at least on -stable). --=20 Peter Jeremy --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFD6KG/opHv/APuIcRAvBCAJ40ObuxklNZn5sFdzfxnjY3SkUmjgCeNZiJ szexJpQszDVVHhtCQ+TC2jg= =37qi -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 08:12:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AEB216A403; Tue, 19 Sep 2006 08:12:25 +0000 (UTC) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id D38C143D5D; Tue, 19 Sep 2006 08:12:22 +0000 (GMT) (envelope-from umka@sevcity.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 84DD617000A; Tue, 19 Sep 2006 11:12:49 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id C079F170004; Tue, 19 Sep 2006 11:12:46 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k8J8CHeL004146; Tue, 19 Sep 2006 11:12:17 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k8J8CG6e004143; Tue, 19 Sep 2006 11:12:16 +0300 From: Alex Lyashkov To: John Baldwin In-Reply-To: <200609181750.58145.jhb@freebsd.org> References: <1158407656.3215.33.camel@berloga.shadowland> <20060917211905.GA64182@xor.obsecurity.org> <1158530904.3213.1.camel@berloga.shadowland> <200609181750.58145.jhb@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: SevcityNet Message-Id: <1158653536.3213.5.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Tue, 19 Sep 2006 11:12:16 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org, Kris Kennaway Subject: Re: jail2 patchset 12 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, 19 Sep 2006 08:12:25 -0000 thanks for point this :( i will rewrite old jail api as wrapper to new API for avoid similar errors... =F7 =F7=D4=D2, 19.09.2006, =D7 00:50, John Baldwin =D0=C9=DB=C5=D4: > On Sunday 17 September 2006 18:08, Alex Lyashkov wrote: > > Thanks for you report. I really more test new jail2 API then old :( > > Please apply this patch. > >=20 > > # p4 diff -du kern_jail.c > > =3D=3D=3D=3D //depot/projects/jail2/sys/kern/kern_jail.c#4 - > > /root/jail2/sys/kern/kern_jail.c =3D=3D=3D=3D > > @@ -316,6 +316,7 @@ > > if (error) > > return (error); > >=20 > > + mtx_lock(&allprison_mtx); > > pr =3D prison_find(uap->jid); > > if (pr =3D=3D NULL) { > > return (ESRCH); >=20 > Does this leak the lock in the ESRCH case now? > =20 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 12:11:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE39D16A4AB for ; Tue, 19 Sep 2006 12:11:47 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8E443DA2 for ; Tue, 19 Sep 2006 12:11:27 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.8/8.13.6) with ESMTP id k8JCBCG3033896; Tue, 19 Sep 2006 16:11:13 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 19 Sep 2006 16:11:12 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-hackers@freebsd.org, danny@cs.huji.ac.il In-Reply-To: <200609141232.k8ECWTXj045191@lurza.secnetix.de> Message-ID: <20060919160511.T33371@woozle.rinet.ru> References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Tue, 19 Sep 2006 16:11:13 +0400 (MSD) Cc: Subject: Re: numbers don't lie ... 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, 19 Sep 2006 12:11:47 -0000 On Thu, 14 Sep 2006, Oliver Fromme wrote: OF> Because buildworld is I/O-bound on systems with sufficiently OF> fast processors. OF> OF> Try putting the contents of /usr/src into a RAM disk and OF> repeat the benchmark. The numbers might look a little OF> different then. Of course, you should have sufficient RAM OF> in the machines -- If they're going to swap to the disks, OF> your benchmark won't be happy. OF> OF> I think putting /usr/obj onto a RAM disk is _not_ necessary OF> because of soft-updates, so the processes shouldn't block OF> on writes. My experiments show that if you have enough memory to host radmdrive for /usr/src you'd better leave it for caching - there were no statistically meaningful performance difference, at least on machines with 1G+ RAM. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 12:15:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A252116A403; Tue, 19 Sep 2006 12:15:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4145843D4C; Tue, 19 Sep 2006 12:15:33 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GPeVg-000HUx-46; Tue, 19 Sep 2006 15:15:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org In-reply-to: Your message of Sun, 17 Sep 2006 11:01:58 +0300 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Sep 2006 15:15:32 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: 6.2/pxe blues, was Re: pxe boot size limit? 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, 19 Sep 2006 12:15:33 -0000 > it seems that pxeboot has a limit with respect to the kernel size, > which prevents the kernel to get loaded, the error printed is > slightly misleading. > > the solution is to make a kernel with loadable modules, instead of > compiled in. not entirely true :-( but changing kernel size has different results. kernel is 6.2-PRERELEASE. hosts are 64bits: 1 - amd Athlon dual core - nic is em 2 - intel Xeon dual core - nic is bc 3 - intel Pentium 4 K8 - nic is bge 1 & 3 are now booting, but 2 is panics with: /boot/kernel/kernel text=0x430118 data=0x79450+0x3ccf0 syms=[0x8+0x73278+0x8+0x62861] panic: free: guard1 fail @ 0x7c6fe from /r+d/6.2/src/lib/libstand/ufs.c:699 a slightly older kernel, and bigger, boots just fine. booting from local disk is also ok. so, what is causing pxeboot to fail? From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 17:34:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DCF516A415 for ; Tue, 19 Sep 2006 17:34:22 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D57843D70 for ; Tue, 19 Sep 2006 17:34:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0223F1A3C1F; Tue, 19 Sep 2006 10:34:22 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 57F27515F7; Tue, 19 Sep 2006 13:34:21 -0400 (EDT) Date: Tue, 19 Sep 2006 13:34:21 -0400 From: Kris Kennaway To: Dmitry Morozovsky Message-ID: <20060919173421.GA45928@xor.obsecurity.org> References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919160511.T33371@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20060919160511.T33371@woozle.rinet.ru> User-Agent: Mutt/1.4.2.2i Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... 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, 19 Sep 2006 17:34:22 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 19, 2006 at 04:11:12PM +0400, Dmitry Morozovsky wrote: > On Thu, 14 Sep 2006, Oliver Fromme wrote: >=20 > OF> Because buildworld is I/O-bound on systems with sufficiently > OF> fast processors. > OF>=20 > OF> Try putting the contents of /usr/src into a RAM disk and > OF> repeat the benchmark. The numbers might look a little > OF> different then. Of course, you should have sufficient RAM > OF> in the machines -- If they're going to swap to the disks, > OF> your benchmark won't be happy. > OF>=20 > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary > OF> because of soft-updates, so the processes shouldn't block > OF> on writes. >=20 > My experiments show that if you have enough memory to host radmdrive for= =20 > /usr/src you'd better leave it for caching - there were no statistically > meaningful performance difference, at least on machines with 1G+ RAM. Really? My measurements show the opposite (on a system with 16GB of RAM). Kris --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFECodWry0BWjoQKURAo5wAJ9oj/GoMfRtJa+zZngfoj+LvSrIzACffWzK TEXdE2mAQZ1G/aETqD3io/8= =LO+5 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 19 19:16:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4919A16A403 for ; Tue, 19 Sep 2006 19:16:06 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A3F43D49 for ; Tue, 19 Sep 2006 19:16:05 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail17.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k8JJG3we002368 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 20 Sep 2006 05:16:04 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k8JJG3R9003356 for ; Wed, 20 Sep 2006 05:16:03 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k8JJG3LT003355 for freebsd-hackers@freebsd.org; Wed, 20 Sep 2006 05:16:03 +1000 (EST) (envelope-from peter) Date: Wed, 20 Sep 2006 05:16:03 +1000 From: Peter Jeremy To: freebsd-hackers@freebsd.org Message-ID: <20060919191603.GA3318@turion.vk2pj.dyndns.org> References: <20060919075550.GB720@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20060919075550.GB720@turion.vk2pj.dyndns.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: Delivering SIGKILL to init 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, 19 Sep 2006 19:16:06 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Sep-19 17:55:50 +1000, Peter Jeremy wrote: >Prompted by some discussion elsewhere, I've been trying to send >SIGKILL to init. If I ktrace kill(1), I can see "kill(1,9)" which >returns 0 but the signal is never delivered. If I sent (eg) SIGXCPU >then init dies and the kernel panics (as expected). I've looked >through sys/kern/kern_* and can't see anywhere that special cases >the delivery of SIGKILL to init. For anyone else interested: I was pointed to code in kern_sig.c:issignal() by a friend. The signal action handling switch (about line 2172 in -stable) ignores any signals marked SIG_DFL for "system" processes (those with a PID of 1 or less). Since SIGKILL is marked SIG_DFL (because it can't be changed), this means SIGKILL isn't delivered. SIGXCPU (and a variety of other signals) have a handler defined by init so they aren't SIG_DFL and therefore are delivered. --=20 Peter Jeremy --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFEEHz/opHv/APuIcRAuQFAKCLG3VswKgMGDiHhwvszsnV8viIpQCgsCfg a4+oW1rN4zernsNkZSKwnTg= =IskI -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 01:02:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 227EE16A412 for ; Wed, 20 Sep 2006 01:02:16 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7793E43D68 for ; Wed, 20 Sep 2006 01:02:15 +0000 (GMT) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id k8K11WDS086609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Sep 2006 18:01:32 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id k8K11WXB086607 for freebsd-hackers@freebsd.org; Tue, 19 Sep 2006 18:01:32 -0700 (PDT) Received: by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21405; Tue, 19 Sep 06 18:01:15 PDT Date: Tue, 19 Sep 06 18:01:15 PDT From: perryh@pluto.rain.com (Perry Hutchison) Message-Id: <10609200101.AA21405@pluto.rain.com> To: freebsd-hackers@freebsd.org Subject: Symlinks on read-only FS 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, 20 Sep 2006 01:02:16 -0000 I've just noticed this, in ufs/ufs/ufs_vnops.c:ufs_access() /* * Disallow write attempts on read-only filesystems; * unless the file is a socket, fifo, or a block or * character device resident on the filesystem. */ if (mode & VWRITE) { switch (vp->v_type) { case VDIR: case VLNK: case VREG: if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); Is the inclusion of VLNK here correct? I would think that only the target of the symlink should matter: if it happens to point onto a writable FS, the fact that the symlink itself is on a ROFS should not matter. From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 03:04:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7318D16A403 for ; Wed, 20 Sep 2006 03:04:03 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (wooster.rojer.pp.ru [80.68.246.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id C703C43D46 for ; Wed, 20 Sep 2006 03:04:02 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP id 17379114E9; Wed, 20 Sep 2006 07:03:59 +0400 (MSD) X-Spam-Checker-Version: SpamAssassin 3.1.5-rojer (2006-08-29) on wooster.rojer.pp.ru X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.5-rojer Received: from [IPv6:::1] (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP; Wed, 20 Sep 2006 07:03:54 +0400 (MSD) Message-ID: <4510AF6D.2060809@rojer.pp.ru> Date: Tue, 19 Sep 2006 20:03:09 -0700 From: Deomid Ryabkov User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: Perry Hutchison References: <10609200101.AA21405@pluto.rain.com> In-Reply-To: <10609200101.AA21405@pluto.rain.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010307090802070606090306" Cc: freebsd-hackers@freebsd.org Subject: Re: Symlinks on read-only FS 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, 20 Sep 2006 03:04:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010307090802070606090306 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Perry Hutchison wrote: > Is the inclusion of VLNK here correct? I would think that > only the target of the symlink should matter: if it happens > to point onto a writable FS, the fact that the symlink itself > is on a ROFS should not matter. yes, it is correct. short symbolic links are stored in the inode itself, so if you modify a short link, you'll be modifying metadata, which is not allowed. it could be argued, that as long as the change is restricted to one inode, it could be tolerable, but moreover, if your short symbolic link is modified to be longer than fits in inode, a disk block will need to be allocated, which would involve a change to block map, which is certainly not desirable for read-only mounts. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 --------------ms010307090802070606090306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPTCC AvkwggJioAMCAQICEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDQwMTE4MjY1NFoX DTA3MDQwMTE4MjY1NFowXzEQMA4GA1UEBBMHUnlhYmtvdjEPMA0GA1UEKhMGRGVvbWlkMRcw FQYDVQQDEw5EZW9taWQgUnlhYmtvdjEhMB8GCSqGSIb3DQEJARYSbXlzZWxmQHJvamVyLnBw LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmnOKvalRf0lrl/4S2fAVovyt 2FxjDn8hDhSOeYNY97Ddi8Y2t+eELg7cpxAUq9GnymPBQanGlvUN2VTuSA4YUVg+VE1yhGgE TDKm0CNVh0v5LOVVAs52IFvdQ0wREYRH0nPBa/ovPWVvlsJ/cIR5GhvRfAW3FbvuP+bEYU54 ESo7OTu7EeGVOLBTF5ow1zaU9PStIied3ffaK5xl8lB6TnQ7DBnIir0ugCqdAuaVxsjD4SfG hqzv42uOuvNjFCQhtFn9dUSnx1cF1TI39cumqVV4UNrqDlQZ4bgrBu/ClqSI4oJnfxgafNkq oSVx7mXNuD1U7V8tJRbOiNdZFpS6mwIDAQABoy8wLTAdBgNVHREEFjAUgRJteXNlbGZAcm9q ZXIucHAucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAmvjeaZmSMwreI1RIl M1frBBOatokRhsStY6nyswNwxpCCcMGiK6sS8a0rtE4Iowvm48oCfXG062anUAFUMJ+e6Fse uOE1lJKrFQRJWGUzp61BOZJH8HZfKnrb7ll2GXY7YvvBicmif/wdjEBgp0WwNucm6jJS/57f mY3M9LQbwzCCAvkwggJioAMCAQICEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcNAQEEBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDQw MTE4MjY1NFoXDTA3MDQwMTE4MjY1NFowXzEQMA4GA1UEBBMHUnlhYmtvdjEPMA0GA1UEKhMG RGVvbWlkMRcwFQYDVQQDEw5EZW9taWQgUnlhYmtvdjEhMB8GCSqGSIb3DQEJARYSbXlzZWxm QHJvamVyLnBwLnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmnOKvalRf0lr l/4S2fAVovyt2FxjDn8hDhSOeYNY97Ddi8Y2t+eELg7cpxAUq9GnymPBQanGlvUN2VTuSA4Y UVg+VE1yhGgETDKm0CNVh0v5LOVVAs52IFvdQ0wREYRH0nPBa/ovPWVvlsJ/cIR5GhvRfAW3 FbvuP+bEYU54ESo7OTu7EeGVOLBTF5ow1zaU9PStIied3ffaK5xl8lB6TnQ7DBnIir0ugCqd AuaVxsjD4SfGhqzv42uOuvNjFCQhtFn9dUSnx1cF1TI39cumqVV4UNrqDlQZ4bgrBu/ClqSI 4oJnfxgafNkqoSVx7mXNuD1U7V8tJRbOiNdZFpS6mwIDAQABoy8wLTAdBgNVHREEFjAUgRJt eXNlbGZAcm9qZXIucHAucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAmvjea ZmSMwreI1RIlM1frBBOatokRhsStY6nyswNwxpCCcMGiK6sS8a0rtE4Iowvm48oCfXG062an UAFUMJ+e6FseuOE1lJKrFQRJWGUzp61BOZJH8HZfKnrb7ll2GXY7YvvBicmif/wdjEBgp0Ww Nucm6jJS/57fmY3M9LQbwzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDp3dO8bl 5F6fYEAzW4CSbTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA5MjAwMzAzMDlaMCMGCSqGSIb3DQEJBDEWBBRwV8Qw6XqSck24 8w3zA6uj2B3cIzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA6d 3TvG5eRen2BAM1uAkm0wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcN AQEBBQAEggEAZ8MWuh2H+ebGGBCGZav5HfQa6mqpmfp6Hj1x9W7JEn2eWQtceLr/bip7Xpgs qomE3Q9yGVsBfZawYB7PdHz5CytTI9IS0+NfzKHWcsB/GO3FaTTvhp2pt260drMGpfJ8k3ki 1LDBu07OwNdUhg0zgLs9fR4rMHGjxkjoAFfCWk4mlXk7/0tSCVAIIQomxPkhfQYmtOyH0C+g EVUki/hpcnArq17I/tDBuwrZncHp5na3FDOjTMKWEMVzsX0Ozm1SwGDJfpJnkg8s40bNG/Jj C8sUU1B8cZdGkU/aU17RV8sL+gkTf4liYzJsPhfooPpiWBSPT8iBVCEyLss26EajEwAAAAAA AA== --------------ms010307090802070606090306-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 04:01:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE2C916A40F for ; Wed, 20 Sep 2006 04:01:47 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9AF43D45 for ; Wed, 20 Sep 2006 04:01:47 +0000 (GMT) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id k8K415cc039591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Sep 2006 21:01:06 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id k8K4153L039590; Tue, 19 Sep 2006 21:01:05 -0700 (PDT) Received: by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21953; Tue, 19 Sep 06 20:56:49 PDT Date: Tue, 19 Sep 06 20:56:49 PDT From: perryh@pluto.rain.com (Perry Hutchison) Message-Id: <10609200356.AA21953@pluto.rain.com> To: myself@rojer.pp.ru In-Reply-To: <4510AF6D.2060809@rojer.pp.ru> References: <10609200101.AA21405@pluto.rain.com> <4510AF6D.2060809@rojer.pp.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: Symlinks on read-only FS 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, 20 Sep 2006 04:01:47 -0000 > > Is the inclusion of VLNK here correct? I would think that > > only the target of the symlink should matter: if it happens > > to point onto a writable FS, the fact that the symlink itself > > is on a ROFS should not matter. > > yes, it is correct. > short symbolic links are stored in the inode itself, so if you > modify a short link, you'll be modifying metadata, which is > not allowed. it could be argued, that as long as the change is > restricted to one inode, it could be tolerable, but moreover, > if your short symbolic link is modified to be longer than fits > in inode, a disk block will need to be allocated, which would > involve a change to block map, which is certainly not desirable > for read-only mounts. So the sort of write access being validated here would be writing to the symlink itself (i.e. the definition)? I did not know that could be done. I had expected that the caller would eventually dereference the link, and write to its target. Certainly we wouldn't want to allow changing what the link itself contains if it is on a ROFS -- indeed this might not even be possible (e.g. if the FS is recorded on a CDROM). From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 05:00:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08F3316A407 for ; Wed, 20 Sep 2006 05:00:59 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (wooster.rojer.pp.ru [80.68.246.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6481143D53 for ; Wed, 20 Sep 2006 05:00:58 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP id DE784114E9 for ; Wed, 20 Sep 2006 09:00:56 +0400 (MSD) X-Spam-Checker-Version: SpamAssassin 3.1.5-rojer (2006-08-29) on wooster.rojer.pp.ru X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.5-rojer Received: from [IPv6:::1] (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP for ; Wed, 20 Sep 2006 09:00:52 +0400 (MSD) Message-ID: <4510CAD7.5080001@rojer.pp.ru> Date: Tue, 19 Sep 2006 22:00:07 -0700 From: Deomid Ryabkov User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <10609200101.AA21405@pluto.rain.com> <4510AF6D.2060809@rojer.pp.ru> <10609200356.AA21953@pluto.rain.com> In-Reply-To: <10609200356.AA21953@pluto.rain.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080601030103080802060906" Subject: Re: Symlinks on read-only FS 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, 20 Sep 2006 05:00:59 -0000 This is a cryptographically signed message in MIME format. --------------ms080601030103080802060906 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Perry Hutchison wrote: > So the sort of write access being validated here would be writing to > the symlink itself (i.e. the definition)? symlinks are dereferenced during name lookup and are not affected by the write mount options of the filesystems they reside on. you can open a file for write by accessing a symlink pointing to it, even though the symlink itself may reside on a read-only filesystem. and you can disregard what i said in my previous post: there's no interface to change the symlink after it was created. actually, i'm not sure there is a real-world case in which this code would be invoked with VLNK. checking write permissions on a symlink? access(2)/eaccess(2) dereference symlinks. but if, for whatever reason, someone calls VOP_ACCESS on read-only UFS filesystem, checking if writing to symlink itself is ok, it will be denied. which makes sense. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 --------------ms080601030103080802060906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPTCC AvkwggJioAMCAQICEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDQwMTE4MjY1NFoX DTA3MDQwMTE4MjY1NFowXzEQMA4GA1UEBBMHUnlhYmtvdjEPMA0GA1UEKhMGRGVvbWlkMRcw FQYDVQQDEw5EZW9taWQgUnlhYmtvdjEhMB8GCSqGSIb3DQEJARYSbXlzZWxmQHJvamVyLnBw LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmnOKvalRf0lrl/4S2fAVovyt 2FxjDn8hDhSOeYNY97Ddi8Y2t+eELg7cpxAUq9GnymPBQanGlvUN2VTuSA4YUVg+VE1yhGgE TDKm0CNVh0v5LOVVAs52IFvdQ0wREYRH0nPBa/ovPWVvlsJ/cIR5GhvRfAW3FbvuP+bEYU54 ESo7OTu7EeGVOLBTF5ow1zaU9PStIied3ffaK5xl8lB6TnQ7DBnIir0ugCqdAuaVxsjD4SfG hqzv42uOuvNjFCQhtFn9dUSnx1cF1TI39cumqVV4UNrqDlQZ4bgrBu/ClqSI4oJnfxgafNkq oSVx7mXNuD1U7V8tJRbOiNdZFpS6mwIDAQABoy8wLTAdBgNVHREEFjAUgRJteXNlbGZAcm9q ZXIucHAucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAmvjeaZmSMwreI1RIl M1frBBOatokRhsStY6nyswNwxpCCcMGiK6sS8a0rtE4Iowvm48oCfXG062anUAFUMJ+e6Fse uOE1lJKrFQRJWGUzp61BOZJH8HZfKnrb7ll2GXY7YvvBicmif/wdjEBgp0WwNucm6jJS/57f mY3M9LQbwzCCAvkwggJioAMCAQICEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcNAQEEBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDQw MTE4MjY1NFoXDTA3MDQwMTE4MjY1NFowXzEQMA4GA1UEBBMHUnlhYmtvdjEPMA0GA1UEKhMG RGVvbWlkMRcwFQYDVQQDEw5EZW9taWQgUnlhYmtvdjEhMB8GCSqGSIb3DQEJARYSbXlzZWxm QHJvamVyLnBwLnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmnOKvalRf0lr l/4S2fAVovyt2FxjDn8hDhSOeYNY97Ddi8Y2t+eELg7cpxAUq9GnymPBQanGlvUN2VTuSA4Y UVg+VE1yhGgETDKm0CNVh0v5LOVVAs52IFvdQ0wREYRH0nPBa/ovPWVvlsJ/cIR5GhvRfAW3 FbvuP+bEYU54ESo7OTu7EeGVOLBTF5ow1zaU9PStIied3ffaK5xl8lB6TnQ7DBnIir0ugCqd AuaVxsjD4SfGhqzv42uOuvNjFCQhtFn9dUSnx1cF1TI39cumqVV4UNrqDlQZ4bgrBu/ClqSI 4oJnfxgafNkqoSVx7mXNuD1U7V8tJRbOiNdZFpS6mwIDAQABoy8wLTAdBgNVHREEFjAUgRJt eXNlbGZAcm9qZXIucHAucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAmvjea ZmSMwreI1RIlM1frBBOatokRhsStY6nyswNwxpCCcMGiK6sS8a0rtE4Iowvm48oCfXG062an UAFUMJ+e6FseuOE1lJKrFQRJWGUzp61BOZJH8HZfKnrb7ll2GXY7YvvBicmif/wdjEBgp0Ww Nucm6jJS/57fmY3M9LQbwzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDp3dO8bl 5F6fYEAzW4CSbTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA5MjAwNTAwMDdaMCMGCSqGSIb3DQEJBDEWBBRhCA00XDdcWwAb SxDtK4FEJYZeGjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA6d 3TvG5eRen2BAM1uAkm0wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA6d3TvG5eRen2BAM1uAkm0wDQYJKoZIhvcN AQEBBQAEggEAXUgP3tHrjhnqSnMIeWuFPWDkyETZS/7CPbcUsZOMo1nF4GctEA4nVMEv9AHa hyVGZ3J9r2WzP9icgqkifx2rvg0NXG5Yn67+whj/+p0Pg/1w3fDPKOYC80ISKMt+kgovnFoL qIlHh9GMajmK3LhSPKzJa3StdWgKvuMaOKf9dVln4scElvbgEbbIUHXPGCPkVDrVI6GK30E8 79EOA4kEaU3SwTjwRX9V6/AWprq16O1KfKW8snDzaOlHdT2EW1VKFmP2ZFrGoi8LT2c4kqD9 hBmkTvrZ3vSpkoSEgrPa9yxmH6vcxZ/zo89LcRaPNlOHQWGrR89/lnV3+Om55o5tjwAAAAAA AA== --------------ms080601030103080802060906-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 05:08:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6418616A417 for ; Wed, 20 Sep 2006 05:08:40 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0359B43D46 for ; Wed, 20 Sep 2006 05:08:37 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id D7D0B4CD94 for ; Wed, 20 Sep 2006 05:10:07 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 699594CD9D for ; Wed, 20 Sep 2006 05:10:07 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id AD5E38A065; Wed, 20 Sep 2006 15:08:35 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id A96368A029; Wed, 20 Sep 2006 15:08:35 +1000 (EST) Message-ID: <4510CCD3.5060000@thebeastie.org> Date: Wed, 20 Sep 2006 15:08:35 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... 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, 20 Sep 2006 05:08:40 -0000 Danny Braniss wrote: >Im testing these 2 boxes, Sun X4100 and Dell-2950, and: > > SUN X4100: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU) > one 70g sata disk > DELL 2950: Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU) > 4 sata disks + raid0 > >they both run identical 6.1-STABLE. > >my 'cpu benchmark' shows the amd being much better than the intel. >but, doing a make buildworld give interesting results: > >dell-2950 : make -j16 TARGET_ARCH=amd64 buildworld : 24m17.41s real 1h3m3.26s >user 17m15.07s sys >dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld : 24m8.28s real 1h2m59.38s >user 16m16.20s sys > >sunfire : make -j16 TARGET_ARCH=amd64 buildworld : 24m21.38s real 49m6.68s >user 14m22.64s sys >sunfire : make -j8 TARGET_ARCH=amd64 buildworld : 23m47.69s real 48m53.58s >user 13m44.81s sys > >which probably says something about my 'cpu benchmark' :-( >but why is the user time so much different between the boxes? > > > Even though your asking about user time I would like to point out I have long prefered to see build world as by far a hard disk io benchmark over a CPU benchmark. After doing such benchmarks my self I have noticed my raid 1 SAS Dells with upto 40% less CPU power crush my Dell dual socket 3.6ghz raid 5 SAS servers in buildworld speed, this is purely because simple fact raid 5 is much slower on writes, CPU has far less to do with buildworld performance. Also a Dell 2950 on SATA seems to be a bit of a odd combination as I would believe most people get the SAS drives for a Dell 2950 and use the PERC5 / mfi SAS device crontroller. Mike From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 08:45:39 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 448DD16A407 for ; Wed, 20 Sep 2006 08:45:39 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9003D43D53 for ; Wed, 20 Sep 2006 08:45:38 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.8/8.13.6) with ESMTP id k8K8jbHw066525; Wed, 20 Sep 2006 12:45:37 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 20 Sep 2006 12:45:37 +0400 (MSD) From: Dmitry Morozovsky To: Kris Kennaway In-Reply-To: <20060919173421.GA45928@xor.obsecurity.org> Message-ID: <20060920123940.W63482@woozle.rinet.ru> References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919160511.T33371@woozle.rinet.ru> <20060919173421.GA45928@xor.obsecurity.org> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Wed, 20 Sep 2006 12:45:37 +0400 (MSD) Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... 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, 20 Sep 2006 08:45:39 -0000 On Tue, 19 Sep 2006, Kris Kennaway wrote: KK> > OF> Because buildworld is I/O-bound on systems with sufficiently KK> > OF> fast processors. KK> > OF> KK> > OF> Try putting the contents of /usr/src into a RAM disk and KK> > OF> repeat the benchmark. The numbers might look a little KK> > OF> different then. Of course, you should have sufficient RAM KK> > OF> in the machines -- If they're going to swap to the disks, KK> > OF> your benchmark won't be happy. KK> > OF> KK> > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary KK> > OF> because of soft-updates, so the processes shouldn't block KK> > OF> on writes. KK> > KK> > My experiments show that if you have enough memory to host radmdrive for KK> > /usr/src you'd better leave it for caching - there were no statistically KK> > meaningful performance difference, at least on machines with 1G+ RAM. KK> KK> Really? My measurements show the opposite (on a system with 16GB of KK> RAM). My last test on amd64/dualcore with 4G of RAM and -j4 shows (buildworld+buildkernel): ==> /tmp/buildlog <== 1996.45 real 3032.94 user 624.83 sys Script done on Tue Sep 19 14:44:54 2006 ==> /tmp/buildlog.md <== 1957.45 real 3033.93 user 585.78 sys Script done on Tue Sep 19 15:20:42 2006 Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the gmirror'ed pair of SATAs. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 11:04:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E818B16A40F for ; Wed, 20 Sep 2006 11:04:25 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from cydem.org (S0106000103ce4c9c.vc.shawcable.net [24.87.27.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5EDC43D4C for ; Wed, 20 Sep 2006 11:04:25 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from soralx.cydem.org (unknown [192.168.0.249]) by cydem.org (Postfix/FreeBSD) with ESMTP id 9E11890D55 for ; Wed, 20 Sep 2006 04:04:24 -0700 (PDT) From: soralx@cydem.org To: freebsd-hackers@freebsd.org Date: Wed, 20 Sep 2006 04:04:23 -0700 User-Agent: KMail/1.9.1 References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919173421.GA45928@xor.obsecurity.org> <20060920123940.W63482@woozle.rinet.ru> In-Reply-To: <20060920123940.W63482@woozle.rinet.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200609200404.23618.soralx@cydem.org> Subject: Re: numbers don't lie ... 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, 20 Sep 2006 11:04:26 -0000 > KK> > My experiments show that if you have enough memory to host radmdrive for > KK> > /usr/src you'd better leave it for caching - there were no statistically > KK> > meaningful performance difference, at least on machines with 1G+ RAM. > KK> > KK> Really? My measurements show the opposite (on a system with 16GB of > KK> RAM). > > My last test on amd64/dualcore with 4G of RAM and -j4 shows > (buildworld+buildkernel): > > ==> /tmp/buildlog <== > 1996.45 real 3032.94 user 624.83 sys > Script done on Tue Sep 19 14:44:54 2006 > > ==> /tmp/buildlog.md <== > 1957.45 real 3033.93 user 585.78 sys > Script done on Tue Sep 19 15:20:42 2006 > > Second one was with 512M/4k/512 swap-backed md, the former with /usr/src on the > gmirror'ed pair of SATAs. In both cases, the amount of processing was the same ('user' times are remarkably close to each other: ~3033.5 CPU-seconds), because the source code didn't change. However, in the first case additional 39 seconds were spent in kernel ('sys'), which made the whole compile process be 39 seconds slower in real time. Notice how {(3033.93/2)+585.78=2102.745} > {1957.45}. Where had those 'extra' 145.3 seconds gone? 2 possibilities: 0a. The number of cores is not 2, but 2.21 rather, meaning that each core is loaded 110.6% (i.e., each CPU-second of computations takes noticeably less than 1 second of real time to complete, assuming 100% load). This is impossible. Changes in user time should always track changes in real time. 0b. 'Sys' time calculation might not be totally independent of 'user' time. So, I say if 0a is somehow true, then the setup is likely CPU-bound, but if 0b is true, then it's probbly IO-ound. Well, I suppose it's hitting both limits at times, as swapping seems to be present too. My logic could be broken here, though, 'cause it's 04:00 in the morning... > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [SorAlx] ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 12:50:25 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83A0816A4D4 for ; Wed, 20 Sep 2006 12:50:25 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A24D43D9E for ; Wed, 20 Sep 2006 12:50:21 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mdazwt@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k8KCo82N048911 for ; Wed, 20 Sep 2006 14:50:17 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k8KCo8sm048910; Wed, 20 Sep 2006 14:50:08 +0200 (CEST) (envelope-from olli) Date: Wed, 20 Sep 2006 14:50:08 +0200 (CEST) Message-Id: <200609201250.k8KCo8sm048910@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20060919160511.T33371@woozle.rinet.ru> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Sep 2006 14:50:17 +0200 (CEST) X-Mailman-Approved-At: Wed, 20 Sep 2006 12:53:03 +0000 Cc: Subject: Re: numbers don't lie ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 12:50:25 -0000 Dmitry Morozovsky wrote: > Oliver Fromme wrote: > > Because buildworld is I/O-bound on systems with sufficiently > > fast processors. > > > > Try putting the contents of /usr/src into a RAM disk and > > repeat the benchmark. The numbers might look a little > > different then. Of course, you should have sufficient RAM > > in the machines -- If they're going to swap to the disks, > > your benchmark won't be happy. > > > > I think putting /usr/obj onto a RAM disk is _not_ necessary > > because of soft-updates, so the processes shouldn't block > > on writes. > > My experiments show that if you have enough memory to host radmdrive for > /usr/src you'd better leave it for caching - there were no statistically > meaningful performance difference, at least on machines with 1G+ RAM. That might only be true if you have enough RAM to keep _all_ buildworld files (src, obj, toolchain) in the cache _and_ you pre-read all of /usr/src before actually starting the buildworld, so it is in the cache. If you don't have that much RAM, but enough to store /usr/src, then using a RAM disk for it is a win. Reading /usr/src from a physical disk certainly requires quite some I/O that takes more than zero time. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 13:23:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD2116A636 for ; Wed, 20 Sep 2006 13:23:58 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D13543D76 for ; Wed, 20 Sep 2006 13:23:57 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k8KDNv4P054078 for ; Wed, 20 Sep 2006 08:23:57 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <451140F8.9030500@centtech.com> Date: Wed, 20 Sep 2006 08:24:08 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200609201250.k8KCo8sm048910@lurza.secnetix.de> In-Reply-To: <200609201250.k8KCo8sm048910@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1909/Tue Sep 19 21:58:44 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: numbers don't lie ... 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, 20 Sep 2006 13:23:58 -0000 On 09/20/06 07:50, Oliver Fromme wrote: > Dmitry Morozovsky wrote: > > Oliver Fromme wrote: > > > Because buildworld is I/O-bound on systems with sufficiently > > > fast processors. > > > > > > Try putting the contents of /usr/src into a RAM disk and > > > repeat the benchmark. The numbers might look a little > > > different then. Of course, you should have sufficient RAM > > > in the machines -- If they're going to swap to the disks, > > > your benchmark won't be happy. > > > > > > I think putting /usr/obj onto a RAM disk is _not_ necessary > > > because of soft-updates, so the processes shouldn't block > > > on writes. > > > > My experiments show that if you have enough memory to host radmdrive for > > /usr/src you'd better leave it for caching - there were no statistically > > meaningful performance difference, at least on machines with 1G+ RAM. > > That might only be true if you have enough RAM to keep > _all_ buildworld files (src, obj, toolchain) in the cache > _and_ you pre-read all of /usr/src before actually starting > the buildworld, so it is in the cache. If you don't have > that much RAM, but enough to store /usr/src, then using > a RAM disk for it is a win. > > Reading /usr/src from a physical disk certainly requires > quite some I/O that takes more than zero time. But, in order to populate the ram disk, you must read /usr/src also from something, and that also takes time, which you should include in the full scope. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 13:56:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5121B16A47B for ; Wed, 20 Sep 2006 13:56:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F6EF43D81 for ; Wed, 20 Sep 2006 13:56:07 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.8/8.13.6) with ESMTP id k8KDu45o073068; Wed, 20 Sep 2006 17:56:04 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 20 Sep 2006 17:56:04 +0400 (MSD) From: Dmitry Morozovsky To: Eric Anderson In-Reply-To: <451140F8.9030500@centtech.com> Message-ID: <20060920175539.Q63482@woozle.rinet.ru> References: <200609201250.k8KCo8sm048910@lurza.secnetix.de> <451140F8.9030500@centtech.com> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Wed, 20 Sep 2006 17:56:04 +0400 (MSD) Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... 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, 20 Sep 2006 13:56:14 -0000 On Wed, 20 Sep 2006, Eric Anderson wrote: EA> > > > My experiments show that if you have enough memory to host radmdrive EA> > for > /usr/src you'd better leave it for caching - there were no EA> > statistically EA> > > meaningful performance difference, at least on machines with 1G+ RAM. EA> > EA> > That might only be true if you have enough RAM to keep EA> > _all_ buildworld files (src, obj, toolchain) in the cache EA> > _and_ you pre-read all of /usr/src before actually starting EA> > the buildworld, so it is in the cache. If you don't have EA> > that much RAM, but enough to store /usr/src, then using EA> > a RAM disk for it is a win. EA> > EA> > Reading /usr/src from a physical disk certainly requires EA> > quite some I/O that takes more than zero time. EA> EA> But, in order to populate the ram disk, you must read /usr/src also from EA> something, and that also takes time, which you should include in the full EA> scope. ... and that populates cache with src files as well ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 15:04:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CE6716A407 for ; Wed, 20 Sep 2006 15:04:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A72843D8C for ; Wed, 20 Sep 2006 15:04:33 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GQ3cl-000O7T-90; Wed, 20 Sep 2006 18:04:31 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Kris Kennaway In-reply-to: <20060919173421.GA45928@xor.obsecurity.org> References: <200609141232.k8ECWTXj045191@lurza.secnetix.de> <20060919160511.T33371@woozle.rinet.ru> <20060919173421.GA45928@xor.obsecurity.org> Comments: In-reply-to Kris Kennaway message dated "Tue, 19 Sep 2006 13:34:21 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Sep 2006 18:04:31 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Dmitry Morozovsky Subject: Re: numbers don't lie ... 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, 20 Sep 2006 15:04:36 -0000 > > --FCuugMFkClbJLl1L > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Sep 19, 2006 at 04:11:12PM +0400, Dmitry Morozovsky wrote: > > On Thu, 14 Sep 2006, Oliver Fromme wrote: > >=20 > > OF> Because buildworld is I/O-bound on systems with sufficiently > > OF> fast processors. > > OF>=20 > > OF> Try putting the contents of /usr/src into a RAM disk and > > OF> repeat the benchmark. The numbers might look a little > > OF> different then. Of course, you should have sufficient RAM > > OF> in the machines -- If they're going to swap to the disks, > > OF> your benchmark won't be happy. > > OF>=20 > > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary > > OF> because of soft-updates, so the processes shouldn't block > > OF> on writes. > >=20 > > My experiments show that if you have enough memory to host radmdrive for= > =20 > > /usr/src you'd better leave it for caching - there were no statistically > > meaningful performance difference, at least on machines with 1G+ RAM. > > Really? My measurements show the opposite (on a system with 16GB of > RAM). > > Kris here are a bunch of new numbers: make: dell 2950 OS: Freebsd 6.2-PRERELEASE cpu: XEON 3.20GHz dualcore * 2 memory: 4GB no swap configured/used. make buildworld -j 8: src & obj real user system hyper -------------------- --------- ---------- --------- ----- Dell PERC 5/i RAID 0 24m17.73s 1h4m31.49s 15m47.44s no Dell PERC 5/i RAID 0 22m3.39s 1h38m46.84s 28m54.18s yes iSCSI/netapp 26m49.98s 1h4m26.77s 16m12.89s no src obj -------------------- md Dell PERC 5/i 24m7.22s 1h4m44.94s 16m24.45 no so, if numbers are to be believed: 1- hypert helps in the real time, but user and system are bigger. allot of sweat for a very small gain. 2- src in memory made no change. 3- slow disc (iscsi) vs. very fast disk (PERC 5/i RAID 0) - about 1:3 speed, produced less than 10% gain in time. danny From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 15:29:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73A716A403 for ; Wed, 20 Sep 2006 15:29:32 +0000 (UTC) (envelope-from gortaur@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 602EF43D6E for ; Wed, 20 Sep 2006 15:29:30 +0000 (GMT) (envelope-from gortaur@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so139948nzn for ; Wed, 20 Sep 2006 08:29:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BFCHfXvRC2aZBEUu0IO6kpYR2cxzG+ogD5VZOYYG3RIxeyxAtznv8HcwbmNBqHRdGlYAAJiystZW8C7Uld6RnpOqKSUTf2R6ej/SkbjDbXiBYxDvHgkiFgX0OecGlm2mThI/JnMOjYPACi6YFwHY4QB0lqkDf+VoUVhmMnJLuoQ= Received: by 10.65.121.9 with SMTP id y9mr16678160qbm; Wed, 20 Sep 2006 08:29:29 -0700 (PDT) Received: by 10.65.231.16 with HTTP; Wed, 20 Sep 2006 08:29:29 -0700 (PDT) Message-ID: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> Date: Wed, 20 Sep 2006 18:29:29 +0300 From: "Taras Danko" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: How to find a certain socket? 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, 20 Sep 2006 15:29:33 -0000 Hi. I need to find and close a certain socket from kernel module. My current implementation iterates over the "allproc" list and checks every process' file descriptors list to find needed socket. But maybe there is an easier way to do this? Some nixes have "inpcbtable" which holds all the open sockets on the system. Is there anything similar in FreeBSD? And the second question: whats the correct way to close the socket which was found? My implementation: ..... mysocket = myproc->p_fd->fd_ofiles[i]->f_data; myproc->p_fd->fd_ofiles[i]->f_data = NULL; myproc->p_fd->fd_ofiles[i]->f_ops = &badfileops; soclose(mysocket); ..... The socket closes but it causes a kernel panic in 90% of cases and file descriptor doesnt actualy released (as fstat shows), but is marked as "error" (because of "badfileops" I suppose). Maybe I should acqure some mutex lock or something before starting manipulations with socket? Any exampe code will be very much appreciated. Its my first steps in fbsd kernel programming so please xcuse me for newbie questions. Taras Danko. - - - - - - - - - - - - - - - - - - - - - - contact me: email: gortaur@gmail.com icq: 166956956 From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 08:32:10 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2362416A417 for ; Thu, 21 Sep 2006 08:32:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DFBA43D5E for ; Thu, 21 Sep 2006 08:32:06 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (hcxina@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k8L8Vx6T007259 for ; Thu, 21 Sep 2006 10:32:05 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k8L8VxvK007258; Thu, 21 Sep 2006 10:31:59 +0200 (CEST) (envelope-from olli) Date: Thu, 21 Sep 2006 10:31:59 +0200 (CEST) Message-Id: <200609210831.k8L8VxvK007258@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <451140F8.9030500@centtech.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 21 Sep 2006 10:32:05 +0200 (CEST) X-Mailman-Approved-At: Thu, 21 Sep 2006 11:23:02 +0000 Cc: Subject: Re: numbers don't lie ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2006 08:32:10 -0000 Eric Anderson wrote: > Oliver Fromme wrote: > > Dmitry Morozovsky wrote: > > > > Because buildworld is I/O-bound on systems with sufficiently > > > > fast processors. > > > > > > > > Try putting the contents of /usr/src into a RAM disk and > > > > repeat the benchmark. The numbers might look a little > > > > different then. Of course, you should have sufficient RAM > > > > in the machines -- If they're going to swap to the disks, > > > > your benchmark won't be happy. > > > > > > > > I think putting /usr/obj onto a RAM disk is _not_ necessary > > > > because of soft-updates, so the processes shouldn't block > > > > on writes. > > > > > > My experiments show that if you have enough memory to host radmdrive for > > > /usr/src you'd better leave it for caching - there were no statistically > > > meaningful performance difference, at least on machines with 1G+ RAM. > > > > That might only be true if you have enough RAM to keep > > _all_ buildworld files (src, obj, toolchain) in the cache > > _and_ you pre-read all of /usr/src before actually starting > > the buildworld, so it is in the cache. If you don't have > > that much RAM, but enough to store /usr/src, then using > > a RAM disk for it is a win. > > > > Reading /usr/src from a physical disk certainly requires > > quite some I/O that takes more than zero time. > > But, in order to populate the ram disk, you must read /usr/src also from > something, and that also takes time, which you should include in the > full scope. But when you perform the buildworld several times (as you should do when you're benchmarking properly), everything is already in the RAM disk. If you instead rely on caching but you don't have enough RAM to hold all of src + obj + toolchain in RAM, then src (or at least parts of it) will have to be read from the physical disk again upon each buildworld. By the way, the contents of the RAM disk are _not_ cached in RAM, so they don't waste RAM twice. That was only a problem with the old vn(4)/vnconfig(8) in FreeBSD 4. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 14:47:04 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7050116A47B for ; Thu, 21 Sep 2006 14:47:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 341A743D5D for ; Thu, 21 Sep 2006 14:47:00 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GQPpL-000IWx-R9 for freebsd-hackers@FreeBSD.ORG; Thu, 21 Sep 2006 17:46:59 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@FreeBSD.ORG In-reply-to: <200609210831.k8L8VxvK007258@lurza.secnetix.de> References: <200609210831.k8L8VxvK007258@lurza.secnetix.de> Comments: In-reply-to Oliver Fromme message dated "Thu, 21 Sep 2006 10:31:59 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2006 17:46:59 +0300 From: Danny Braniss Message-ID: Cc: Subject: Re: numbers don't lie ... 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, 21 Sep 2006 14:47:04 -0000 [...] > But when you perform the buildworld several times (as you > should do when you're benchmarking properly), everything > is already in the RAM disk. If you instead rely on caching > but you don't have enough RAM to hold all of src + obj + > toolchain in RAM, then src (or at least parts of it) will > have to be read from the physical disk again upon each > buildworld. > > By the way, the contents of the RAM disk are _not_ cached > in RAM, so they don't waste RAM twice. That was only a > problem with the old vn(4)/vnconfig(8) in FreeBSD 4. > > Best regards > Oliver you might have a point, but this started when I asked why, two boxes, under similar test gave idential real times, but very different user times. dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld: 24m8.28s real 1h2m59.38s user 16m16.20s sys sunfire : make -j8 TARGET_ARCH=amd64 buildworld: 23m47.69s real 48m53.58s user 13m44.81s sys and SUN X4100: Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU) one 70g sas disk (via mpt) -- x 2 DELL 2950: Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU) 4 sata disks + raid0 (via mfi) -- dual core x 2 cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 17:06:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2C416A40F for ; Thu, 21 Sep 2006 17:06:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB0A43D5A for ; Thu, 21 Sep 2006 17:06:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4665746C8D; Thu, 21 Sep 2006 13:06:13 -0400 (EDT) Date: Thu, 21 Sep 2006 18:06:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Taras Danko In-Reply-To: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> Message-ID: <20060921180348.S56349@fledge.watson.org> References: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: How to find a certain socket? 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, 21 Sep 2006 17:06:16 -0000 On Wed, 20 Sep 2006, Taras Danko wrote: > I need to find and close a certain socket from kernel module. My current > implementation iterates over the "allproc" list and checks every process' > file descriptors list to find needed socket. But maybe there is an easier > way to do this? Some nixes have "inpcbtable" which holds all the open > sockets on the system. Is there anything similar in FreeBSD? What are you trying to do, exactly? The semantics of closing sockets open in processes are a bit tricky -- first off, you really don't want to actually close the file descriptor, as the application may misbehave in rather unfortunate ways, such as writing data to the wrong files, etc. So in that sense, what you're doing is better than actually closing the file descriptor, which would cause that to happen. If you're interested only in closing TCP sockets, then the existing tcpkill command may well do what you want. > And the second question: whats the correct way to close the socket which was > found? I'm not sure there's really a "correct" way to go about ripping a socket out from under an application. tcpkill does the next closest thing, which is to simulate a RST on the TCP connection and force it to close, which is propagated up the stack in a way the application will understand. Robert N M Watson Computer Laboratory University of Cambridge > > My implementation: > > ..... > mysocket = myproc->p_fd->fd_ofiles[i]->f_data; > myproc->p_fd->fd_ofiles[i]->f_data = NULL; > myproc->p_fd->fd_ofiles[i]->f_ops = &badfileops; > soclose(mysocket); > ..... > > The socket closes but it causes a kernel panic in 90% of cases and > file descriptor doesnt actualy released (as fstat shows), but is > marked as "error" (because of "badfileops" I suppose). Maybe I should > acqure some mutex lock or something before starting manipulations with > socket? Any exampe code will be very much appreciated. > > Its my first steps in fbsd kernel programming so please xcuse me for > newbie questions. > > Taras Danko. > - - - - - - - - - - - - - - - - - - - - - - > contact me: > email: gortaur@gmail.com > icq: 166956956 > _______________________________________________ > 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 Sep 21 17:17:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63ABB16A40F; Thu, 21 Sep 2006 17:17:46 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B293043D49; Thu, 21 Sep 2006 17:17:45 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.3) with ESMTP id k8LHHhmE034793; Thu, 21 Sep 2006 21:17:43 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 21 Sep 2006 21:17:42 +0400 (MSD) From: Maxim Konovalov To: Robert Watson In-Reply-To: <20060921180348.S56349@fledge.watson.org> Message-ID: <20060921211707.G34389@mp2.macomnet.net> References: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> <20060921180348.S56349@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, Taras Danko Subject: Re: How to find a certain socket? 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, 21 Sep 2006 17:17:46 -0000 [...] > you're interested only in closing TCP sockets, then the existing tcpkill > command may well do what you want. It's tcpdrop(8). -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 17:43:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64FE116A412 for ; Thu, 21 Sep 2006 17:43:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0221B43D49 for ; Thu, 21 Sep 2006 17:42:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ADAC246C56; Thu, 21 Sep 2006 13:42:59 -0400 (EDT) Date: Thu, 21 Sep 2006 18:42:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Konovalov In-Reply-To: <20060921211707.G34389@mp2.macomnet.net> Message-ID: <20060921184244.W56349@fledge.watson.org> References: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> <20060921180348.S56349@fledge.watson.org> <20060921211707.G34389@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Taras Danko Subject: Re: How to find a certain socket? 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, 21 Sep 2006 17:43:00 -0000 On Thu, 21 Sep 2006, Maxim Konovalov wrote: > [...] >> you're interested only in closing TCP sockets, then the existing tcpkill >> command may well do what you want. > > It's tcpdrop(8). Er, yes, so it is. Thanks :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 18:14:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8FE216A417; Thu, 21 Sep 2006 18:14:18 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D73643E6B; Thu, 21 Sep 2006 18:13:09 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Fri, 22 Sep 2006 02:12:51 +0800 id 0010E409.4512D623.00003440 From: "Intron is my alias on the Internet" To: freebsd-hackers@freebsd.org Date: Fri, 22 Sep 2006 02:12:51 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: A Bug in linker_reference_module() ? 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, 21 Sep 2006 18:14:18 -0000 Please have a look at the function linker_reference_module() in /sys/kern/kern_linker.c of 7.0-CURRENT. If the module is loaded on demand, why not increase its reference counter after loading? In my opinion, linker_reference_module() behaves differently from linker_load_file(). ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 18:29:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D65F16A416 for ; Thu, 21 Sep 2006 18:29:47 +0000 (UTC) (envelope-from gortaur@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAC5543D8E for ; Thu, 21 Sep 2006 18:29:41 +0000 (GMT) (envelope-from gortaur@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so414637nzn for ; Thu, 21 Sep 2006 11:29:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nAhrZMrlfqe2bJGl8aZRMUtbnv+Xt3Ii4F0B2V/aUDeiw6rAd+wLhbnkDjFRR1ayPTJFG+NjQlPJdugwnCUznn0mmB3Dlc4PKMoVFfCBj094i15b9TdpjQi1i4C+6SCgveLjBFbwaTIkGHl91y/3i+je1zQsTgSwuoZclpcbO8o= Received: by 10.65.38.7 with SMTP id q7mr18954345qbj; Thu, 21 Sep 2006 11:29:41 -0700 (PDT) Received: by 10.65.231.16 with HTTP; Thu, 21 Sep 2006 11:29:41 -0700 (PDT) Message-ID: <89b086450609211129n4c74c4feycdbbe53faccf9568@mail.gmail.com> Date: Thu, 21 Sep 2006 21:29:41 +0300 From: "Taras Danko" To: "Robert Watson" In-Reply-To: <20060921180348.S56349@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89b086450609200829t2ef4dd9ft13c2051644101ba8@mail.gmail.com> <20060921180348.S56349@fledge.watson.org> Cc: freebsd-hackers@freebsd.org Subject: Re: How to find a certain socket? 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, 21 Sep 2006 18:29:47 -0000 2006/9/21, Robert Watson : > > > What are you trying to do, exactly? > The idea is the following: I have a module which replaces the "socket" system call with my own "extended" socket syscall which adds some restrictions for "socket" callers. After my module is kldloaded - some processes/users/domains become restricted in creation of some type of TCP/UDP sockets. This part is quite obvious. But I also want to handle the situation when a restricted process has created a sockets _before_ my module was loaded. So I want to close its sockets so the process will have to recreate them passing through my restriction policy this time. > > And the second question: whats the correct way to close the socket which was > > found? > > I'm not sure there's really a "correct" way to go about ripping a socket out > from under an application. tcpkill does the next closest thing, which is to > simulate a RST on the TCP connection and force it to close, which is > propagated up the stack in a way the application will understand. As I understand, RST will take effect only for the client side sockets but the server side "listening" socket still will be alive awaiting for another connections. And I want to be able to close sockets of both server and client types (sure if they were created by my restricted process mentioned above). Taras Danko -- contact me: email: gortaur@gmail.com icq: 166956956 From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 21 18:31:15 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50F1F16A403 for ; Thu, 21 Sep 2006 18:31:15 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B48043D7B for ; Thu, 21 Sep 2006 18:31:12 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (pyjsba@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k8LIV5NG040533 for ; Thu, 21 Sep 2006 20:31:11 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k8LIV57C040532; Thu, 21 Sep 2006 20:31:05 +0200 (CEST) (envelope-from olli) Date: Thu, 21 Sep 2006 20:31:05 +0200 (CEST) Message-Id: <200609211831.k8LIV57C040532@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 21 Sep 2006 20:31:11 +0200 (CEST) X-Mailman-Approved-At: Thu, 21 Sep 2006 18:33:59 +0000 Cc: Subject: Re: numbers don't lie ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2006 18:31:15 -0000 Danny Braniss wrote: > you might have a point, but this started when I asked why, two > boxes, under similar test gave idential real times, but very different > user times. Right, and the answer was: One box has a much faster CPU, so it's user time is smaller, but buildworld isn't purely CPU-bound, and because of I/O delays the real times end up to be about the same. In other words: The faster box had to wait more often for the disk than the slower box. If both of your machines have enough RAM, it would be interesting to repeat the test with /usr/src being in a RAM disk, so read I/O doesn't play that much of a role. Best regards Oliver PS: Numbers don't lie ... but are often misinterpreted. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 22 01:41:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74E5F16A47C for ; Fri, 22 Sep 2006 01:41:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3061D43D55 for ; Fri, 22 Sep 2006 01:41:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8M1f7U0009019; Thu, 21 Sep 2006 21:41:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Intron is my alias on the Internet" Date: Thu, 21 Sep 2006 21:36:18 -0400 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609212136.18850.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Thu, 21 Sep 2006 21:41:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1922/Thu Sep 21 19:05:55 2006 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: freebsd-hackers@freebsd.org Subject: Re: A Bug in linker_reference_module() ? 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, 22 Sep 2006 01:41:26 -0000 On Thursday 21 September 2006 14:12, Intron is my alias on the Internet wrote: > Please have a look at the function linker_reference_module() in > /sys/kern/kern_linker.c of 7.0-CURRENT. If the module is loaded on demand, > why not increase its reference counter after loading? In my opinion, > linker_reference_module() behaves differently from linker_load_file(). This is because a new kld loaded via linker_load_module() starts off with a refcount of 1. Thus, if you do: linker_reference_module(...); ... linker_release_module(...); Then with the current code the release_module() call drops the reference count to 0 and the module is unloaded. This is the desired operation for reference_module/release_module. This model is commonly used in the kernel. For example, when creating a credential, one just does 'crget()' and later a 'crfree()' to free it instead of doing 'crget(); crhold()' to create one. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 22 01:58:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA86F16A49E; Fri, 22 Sep 2006 01:58:01 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48B1743D7C; Fri, 22 Sep 2006 01:57:56 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Fri, 22 Sep 2006 09:57:55 +0800 id 0010E408.45134323.00004A36 References: <200609212136.18850.jhb@freebsd.org> In-Reply-To: <200609212136.18850.jhb@freebsd.org> From: "Intron is my alias on the Internet" To: John Baldwin Date: Fri, 22 Sep 2006 09:57:55 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: A Bug in linker_reference_module() ? 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, 22 Sep 2006 01:58:01 -0000 John Baldwin wrote: > On Thursday 21 September 2006 14:12, Intron is my alias on the Internet wrote: >> Please have a look at the function linker_reference_module() in >> /sys/kern/kern_linker.c of 7.0-CURRENT. If the module is loaded on demand, >> why not increase its reference counter after loading? In my opinion, >> linker_reference_module() behaves differently from linker_load_file(). > > This is because a new kld loaded via linker_load_module() starts off > with a refcount of 1. Thus, if you do: > > linker_reference_module(...); > ... > linker_release_module(...); > > Then with the current code the release_module() call drops the reference > count to 0 and the module is unloaded. This is the desired operation for > reference_module/release_module. This model is commonly used in the kernel. > For example, when creating a credential, one just does 'crget()' and later > a 'crfree()' to free it instead of doing 'crget(); crhold()' to create one. This model is a little confusing. If a module is loaded on demand as dependency, its reference counter is set to 1. And if the module is loaded by kldload(2), its reference counter is also set to 1, though in fact no other loaded module depends on it. Although this "shift" model can work correctly, I want to know whether there's a more reasonable way, such as setting up an auto-unloadable flag. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 22 05:59:53 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CFC716A40F for ; Fri, 22 Sep 2006 05:59:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A528043D7B for ; Fri, 22 Sep 2006 05:59:52 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GQe4l-000OA9-Dq for freebsd-hackers@FreeBSD.ORG; Fri, 22 Sep 2006 08:59:51 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@FreeBSD.ORG In-reply-to: <200609211831.k8LIV57C040532@lurza.secnetix.de> References: <200609211831.k8LIV57C040532@lurza.secnetix.de> Comments: In-reply-to Oliver Fromme message dated "Thu, 21 Sep 2006 20:31:05 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Sep 2006 08:59:51 +0300 From: Danny Braniss Message-ID: Cc: Subject: Re: numbers don't lie ... 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, 22 Sep 2006 05:59:53 -0000 > Danny Braniss wrote: > > you might have a point, but this started when I asked why, two > > boxes, under similar test gave idential real times, but very different > > user times. > > Right, and the answer was: One box has a much faster CPU, > so it's user time is smaller, but buildworld isn't purely > CPU-bound, and because of I/O delays the real times end > up to be about the same. In other words: The faster box > had to wait more often for the disk than the slower box. > > If both of your machines have enough RAM, it would be > interesting to repeat the test with /usr/src being in a > RAM disk, so read I/O doesn't play that much of a role. > > Best regards > Oliver > > PS: Numbers don't lie ... but are often misinterpreted. or missused by salesmen/politician/etc :-) i have run many tests, even having /usr/src in memory, the results where posted some days ago, but here they are again: make: dell 2950 OS: Freebsd 6.2-PRERELEASE cpu: XEON 3.20GHz dualcore * 2 memory: 4GB src & obj real user system hyper -------------------- --------- ---------- --------- ----- Dell PERC 5/i RAID 0 24m17.73s 1h4m31.49s 15m47.44s no Dell PERC 5/i RAID 0 22m3.39s 1h38m46.84s 28m54.18s yes iSCSI/netapp 26m49.98s 1h4m26.77s 16m12.89s no src obj -------------------- md Dell PERC 5/i 24m7.22s 1h4m44.94s 16m24.45 no so something is still fishy in the state of Denmark. or, in the case of this box, the cpu is so slow, that no matter how fast the I/O is is does not change the equation. I will try to run similar tests on the amd/sun, but have to wait till some real work finishes. danny From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 22 18:58:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBBA316A403 for ; Fri, 22 Sep 2006 18:58:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C9743D45 for ; Fri, 22 Sep 2006 18:58:44 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8MIwfgg015364; Fri, 22 Sep 2006 14:58:41 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Intron is my alias on the Internet" Date: Fri, 22 Sep 2006 14:44:23 -0400 User-Agent: KMail/1.9.1 References: <200609212136.18850.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200609221444.23702.jhb@freebsd.org> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 22 Sep 2006 14:58:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1927/Fri Sep 22 06:06:31 2006 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: freebsd-hackers@freebsd.org Subject: Re: A Bug in linker_reference_module() ? 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, 22 Sep 2006 18:58:45 -0000 On Thursday 21 September 2006 21:57, Intron is my alias on the Internet wrote: > John Baldwin wrote: > > > On Thursday 21 September 2006 14:12, Intron is my alias on the Internet wrote: > >> Please have a look at the function linker_reference_module() in > >> /sys/kern/kern_linker.c of 7.0-CURRENT. If the module is loaded on demand, > >> why not increase its reference counter after loading? In my opinion, > >> linker_reference_module() behaves differently from linker_load_file(). > > > > This is because a new kld loaded via linker_load_module() starts off > > with a refcount of 1. Thus, if you do: > > > > linker_reference_module(...); > > ... > > linker_release_module(...); > > > > Then with the current code the release_module() call drops the reference > > count to 0 and the module is unloaded. This is the desired operation for > > reference_module/release_module. This model is commonly used in the kernel. > > For example, when creating a credential, one just does 'crget()' and later > > a 'crfree()' to free it instead of doing 'crget(); crhold()' to create one. > > This model is a little confusing. If a module is loaded on demand as > dependency, its reference counter is set to 1. And if the module is loaded > by kldload(2), its reference counter is also set to 1, though in fact > no other loaded module depends on it. kldload(2) is a way for to specify a user reference on the module, and kldunload(2) is how you drop that user reference. > Although this "shift" model can work correctly, I want to know whether > there's a more reasonable way, such as setting up an auto-unloadable flag. There is this effectively done with the userref flag. When you kldload a module, it sets userref to 1, and you can only kldunload a module when userref == 1. This lets the following work: thread 1 thread 2 kldload(foo) ... ... linker_reference_module(foo) (now foo has userref == 1 and refs == 2) kldunload(foo) ... (now foo has userref == 0 and refs == 1, kldunload reports success, but module isn't unloaded due to in-kernel reference) ... linker_release_module(foo) (now refs drops to 0 and module is actually unloaded) The simpler cases also work fine if you try them out. -- John Baldwin