From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 02:57:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE93016A4DD; Sun, 20 Aug 2006 02:57:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492BA43D53; Sun, 20 Aug 2006 02:57:44 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-48.lns1.adl2.internode.on.net [203.122.219.48]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7K2vbKp068876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2006 12:27:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 20 Aug 2006 12:27:26 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> In-Reply-To: <44E77EF7.6070004@ngo.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1407416.P8Yqx4vqRb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608201227.34510.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 02:57:46 -0000 --nextPart1407416.P8Yqx4vqRb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 06:43, Nik Clayton wrote: > I realise that I need to replace the disk. However, while I'm waiting > until I can schedule the downtime, is there a short term solution I can > use to stop FreeBSD (I'm running current from a couple of months ago) > from trying to use this block? Reboot into single user mode so swap is not being used and then try dd if=3D/dev/zero of=3D/dev/XXX bs=3D64k (where XXX is your swapdev) The disk should remap the sector, if it refuses to write to the sector beca= use=20 it's out of remappable sectors then you could try splitting your swap into = 2=20 partitions around the dead sector and then using them both (should be no=20 appreciable speed decrease) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1407416.P8Yqx4vqRb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE58+e5ZPcIHs/zowRAqgRAJ9rMWJTUOvI8G/riphDLbS1jOin7wCfYdJb YTWZsZ0E5OJcEaeD4NwA8Pk= =zWu9 -----END PGP SIGNATURE----- --nextPart1407416.P8Yqx4vqRb-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 02:57:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE93016A4DD; Sun, 20 Aug 2006 02:57:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492BA43D53; Sun, 20 Aug 2006 02:57:44 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-48.lns1.adl2.internode.on.net [203.122.219.48]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7K2vbKp068876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2006 12:27:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 20 Aug 2006 12:27:26 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> In-Reply-To: <44E77EF7.6070004@ngo.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1407416.P8Yqx4vqRb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608201227.34510.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 02:57:46 -0000 --nextPart1407416.P8Yqx4vqRb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 06:43, Nik Clayton wrote: > I realise that I need to replace the disk. However, while I'm waiting > until I can schedule the downtime, is there a short term solution I can > use to stop FreeBSD (I'm running current from a couple of months ago) > from trying to use this block? Reboot into single user mode so swap is not being used and then try dd if=3D/dev/zero of=3D/dev/XXX bs=3D64k (where XXX is your swapdev) The disk should remap the sector, if it refuses to write to the sector beca= use=20 it's out of remappable sectors then you could try splitting your swap into = 2=20 partitions around the dead sector and then using them both (should be no=20 appreciable speed decrease) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1407416.P8Yqx4vqRb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE58+e5ZPcIHs/zowRAqgRAJ9rMWJTUOvI8G/riphDLbS1jOin7wCfYdJb YTWZsZ0E5OJcEaeD4NwA8Pk= =zWu9 -----END PGP SIGNATURE----- --nextPart1407416.P8Yqx4vqRb-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 04:42:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B71016A4DE for ; Sun, 20 Aug 2006 04:42:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A49B343D46 for ; Sun, 20 Aug 2006 04:42:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k7K4gATc046235; Sat, 19 Aug 2006 22:42:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 19 Aug 2006 22:42:15 -0600 (MDT) Message-Id: <20060819.224215.-233672510.imp@bsdimp.com> To: nik@ngo.org.uk From: "M. Warner Losh" In-Reply-To: <44E77EF7.6070004@ngo.org.uk> References: <44E77EF7.6070004@ngo.org.uk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 19 Aug 2006 22:42:10 -0600 (MDT) Cc: current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 04:42:55 -0000 In message: <44E77EF7.6070004@ngo.org.uk> Nik Clayton writes: : I realise that I need to replace the disk. However, while I'm waiting : until I can schedule the downtime, is there a short term solution I can : use to stop FreeBSD (I'm running current from a couple of months ago) : from trying to use this block? repartition to not have this block in any partition. Ugly, evil, nasty. However, it is a short term solution... Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 05:24:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 382CB16A4E7 for ; Sun, 20 Aug 2006 05:24:52 +0000 (UTC) (envelope-from prvs=julian=38058dedd@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 742D343D45 for ; Sun, 20 Aug 2006 05:24:51 +0000 (GMT) (envelope-from prvs=julian=38058dedd@elischer.org) Received: from unknown (HELO [192.168.2.3]) ([10.251.60.51]) by a50.ironport.com with ESMTP; 19 Aug 2006 22:24:50 -0700 Message-ID: <44E7F223.1090702@elischer.org> Date: Sat, 19 Aug 2006 22:24:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <200608151627.37828.root@solink.ru> <20060815130002.M45647@fledge.watson.org> <200608160959.23100.root@solink.ru> <20060816094944.GC820@turion.vk2pj.dyndns.org> <44E3A2C0.2020801@elischer.org> <20060819195336.GL57815@obiwan.tataz.chchile.org> <20060819125708.B22972@xorpc.icir.org> In-Reply-To: <20060819125708.B22972@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: [fbsd] Re: throughput and interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 05:24:52 -0000 Luigi Rizzo wrote: >On Sat, Aug 19, 2006 at 09:53:36PM +0200, Jeremie Le Hen wrote: > > >>Hi, >> >> >> >>>>natd runs in userland so every packet has to be pushed out to userland, >>>>processed and pushed back into the kernel. The vast majority of the >>>>overhead is the userland/kernel transition so natd gives you a basically >>>>fixed pps rate. Your throughput will vary depending on the packet size. >>>> >>>> >>>> >>>> >>>in 6.1 there is an in kernel version of natd.. >>> >>>man ng_nat >>> >>> >>What about the SoC 2005 project, aiming to push libalias down >>into a kernel module ? IIRC, there have been some patches >>but I saw nothing commited. This thread has stirred this >>up from my memory. >> >> libalias is already there. > >Paolo Pisati is now a committer and hopefully will commit >that stuff when he will be done with his current SoC work > >cheers >luigi > > > >>Thank you, >>-- >>Jeremie Le Hen >>< jeremie at le-hen dot org >< ttz at chchile dot org > >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 05:34:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2EE216A4E5 for ; Sun, 20 Aug 2006 05:34:44 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C0743D76 for ; Sun, 20 Aug 2006 05:34:37 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1141030wxd for ; Sat, 19 Aug 2006 22:34:36 -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=B3Ol0YX8LrQNziclhma/OXWiS/sn/srM/esjZ3/EBJ1OCLmIQIpM8T7MkFG1QOOa3AiXs8+DOtBeSRajQ7jntwGfKRcpxGo43z1R98k6S08f5P/3Pdes4PFkleJdHcAzaYwcF21+ZB1FdB5DVY04EwPXD5cB4RvL2wJBa4OjXeM= Received: by 10.90.25.7 with SMTP id 7mr71079agy; Sat, 19 Aug 2006 22:34:36 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Sat, 19 Aug 2006 22:34:36 -0700 (PDT) Message-ID: <7579f7fb0608192234w26f6badbj8eaf128ad495371b@mail.gmail.com> Date: Sat, 19 Aug 2006 22:34:36 -0700 From: "Matthew Jacob" To: "Mohan Srinivasan" In-Reply-To: <20060818162003.38515.qmail@web30806.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060818162003.38515.qmail@web30806.mail.mud.yahoo.com> Cc: current@freebsd.org Subject: Re: Parsing of /etc/fstab broken in 6.1... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 05:34:45 -0000 As far as I can tell, it's still broken. On 8/18/06, Mohan Srinivasan wrote: > Hi, > > The parsing of entries in /etc/fstab seems to be broken. In particular, in the > case of NFS, mount options (tcp) seem to be ignored. Matt J. reported that > the "ro" option in fstab was bring ignored. > > This is on a releng 6 base about 6 weeks old. > > I vaguely remember there being changes in this area recently. Has anyone else > seen this ? Has this been fixed recently ? > > thanks > > mohan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 07:21:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 210F616A4DD for ; Sun, 20 Aug 2006 07:21:07 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F5543D46 for ; Sun, 20 Aug 2006 07:21:05 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 86B065DAE; Sun, 20 Aug 2006 11:21:04 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 66DAC5DA8; Sun, 20 Aug 2006 11:21:04 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.6/8.13.6) id k7K7L34S013834; Sun, 20 Aug 2006 11:21:03 +0400 (MSD) (envelope-from ru) Date: Sun, 20 Aug 2006 11:21:03 +0400 From: Ruslan Ermilov To: Nik Clayton Message-ID: <20060820072103.GC13513@rambler-co.ru> References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: <200608201227.34510.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: No virus found Cc: freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 07:21:07 -0000 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 20, 2006 at 12:27:26PM +0930, Daniel O'Connor wrote: > On Sunday 20 August 2006 06:43, Nik Clayton wrote: > > I realise that I need to replace the disk. However, while I'm waiting > > until I can schedule the downtime, is there a short term solution I can > > use to stop FreeBSD (I'm running current from a couple of months ago) > > from trying to use this block? >=20 > Reboot into single user mode so swap is not being used and then try > dd if=3D/dev/zero of=3D/dev/XXX bs=3D64k >=20 > (where XXX is your swapdev) >=20 > The disk should remap the sector, if it refuses to write to the sector be= cause=20 > it's out of remappable sectors then you could try splitting your swap int= o 2=20 > partitions around the dead sector and then using them both (should be no= =20 > appreciable speed decrease) >=20 I can confirm using this technique. You can also confirm with smartctl(8) that it was indeed relocated (I assume your disk is modern enough to support SMART). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE6A1fqRfpzJluFF4RAndSAJ4ncjeTAsVRSIZwEjOj/yWdWRKD1gCff7eT l2dixkPtr23yY7LyyLs1Zc8= =9d4M -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 08:04:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820E616A4E0 for ; Sun, 20 Aug 2006 08:04:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 81EC443D58 for ; Sun, 20 Aug 2006 08:04:58 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 25224 invoked by uid 399); 20 Aug 2006 08:04:57 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 20 Aug 2006 08:04:57 -0000 Message-ID: <44E817A6.30405@FreeBSD.org> Date: Sun, 20 Aug 2006 01:04:54 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Daniel O'Connor References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> In-Reply-To: <200608201227.34510.doconnor@gsoft.com.au> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 08:04:59 -0000 Daniel O'Connor wrote: > The disk should remap the sector, if it refuses to write to the sector because > it's out of remappable sectors You forgot to add, "and then immediately go out and buy a new disk because that one is toast." :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 08:04:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BC6416A4E2 for ; Sun, 20 Aug 2006 08:04:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 8205343D5C for ; Sun, 20 Aug 2006 08:04:58 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 25224 invoked by uid 399); 20 Aug 2006 08:04:57 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 20 Aug 2006 08:04:57 -0000 Message-ID: <44E817A6.30405@FreeBSD.org> Date: Sun, 20 Aug 2006 01:04:54 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Daniel O'Connor References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> In-Reply-To: <200608201227.34510.doconnor@gsoft.com.au> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 08:04:59 -0000 Daniel O'Connor wrote: > The disk should remap the sector, if it refuses to write to the sector because > it's out of remappable sectors You forgot to add, "and then immediately go out and buy a new disk because that one is toast." :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 08:24:45 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85DC216A4DA; Sun, 20 Aug 2006 08:24:45 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAD7A43D49; Sun, 20 Aug 2006 08:24:42 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k7K8OZic014237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2006 17:24:41 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 20 Aug 2006 17:24:35 +0900 From: Norikatsu Shigemura To: freebsd-hackers@FreeBSD.org Message-Id: <20060820172435.26c4cc2a.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sun, 20 Aug 2006 17:24:41 +0900 (JST) Cc: freebsd-current@FreeBSD.org Subject: [RFC] prototype of top(1)'s CPU current frequency display X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 08:24:45 -0000 I want to see CPU current frequency on top(1), because I want to see relation of process status (CPU usage) and cpu current frequency using powerd(8) on the fly. In recently, many CPUs for servers like Xeon support frequency changing like Speed Step Technology. I run powerd(8) on these servers. So I should know performance issue, whichever program performance or server performance. I wrote a little usability patch. But I don't think that my code is not good:-(. So please improve my code. Wellknown problem. 1. assume only 1 CPU. 2. assume dev.cpu.0.freq is always exists. 3. display position is good? --- usr.bin/top/machine.c.orig Wed May 18 22:42:51 2005 +++ usr.bin/top/machine.c Sun Aug 20 16:41:59 2006 @@ -153,10 +153,10 @@ /* these are for detailing the process states */ -int process_states[8]; +int process_states[9]; char *procstatenames[] = { "", " starting, ", " running, ", " sleeping, ", " stopped, ", - " zombie, ", " waiting, ", " lock, ", + " zombie, ", " waiting, ", " lock, ", " MHz, ", NULL }; @@ -628,6 +628,9 @@ prev_pp->ki_pctcpu += pp->ki_pctcpu; } } + + /* CPU current frequency */ + GETSYSCTL("dev.cpu.0.freq", process_states[8]); /* if requested, sort the "interesting" processes */ if (compare != NULL) From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 08:30:08 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54D1816A4DA for ; Sun, 20 Aug 2006 08:30:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 775A143D79 for ; Sun, 20 Aug 2006 08:30:01 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 29916261; Sun, 20 Aug 2006 03:30:00 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 9414661C2B; Sun, 20 Aug 2006 03:29:59 -0500 (CDT) Date: Sun, 20 Aug 2006 03:29:59 -0500 From: "Matthew D. Fuller" To: Jeremie Le Hen Message-ID: <20060820082959.GC65866@over-yonder.net> References: <200608151627.37828.root@solink.ru> <20060815130002.M45647@fledge.watson.org> <200608160959.23100.root@solink.ru> <20060816094944.GC820@turion.vk2pj.dyndns.org> <44E3A2C0.2020801@elischer.org> <20060819195336.GL57815@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060819195336.GL57815@obiwan.tataz.chchile.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: freebsd-current@FreeBSD.org Subject: Re: [fbsd] Re: throughput and interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 08:30:08 -0000 On Sat, Aug 19, 2006 at 09:53:36PM +0200 I heard the voice of Jeremie Le Hen, and lo! it spake thus: > > What about the SoC 2005 project, aiming to push libalias down into a > kernel module ? I've been half-waiting for that all (particularly the ipfw side) to land too. Forget performance; I just want to be able to add and remove and change forwardings without losing all the existing state of the NAT engine. natd doesn't do it. I can't see any way that pf does it. But hey, at least you can do it in ppp... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 09:52:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68F9416A4DA; Sun, 20 Aug 2006 09:52:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCBC43D55; Sun, 20 Aug 2006 09:52:39 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-48.lns1.adl2.internode.on.net [203.122.219.48]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7K9qWJ3089609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2006 19:22:35 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Doug Barton Date: Sun, 20 Aug 2006 19:22:06 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> <44E817A6.30405@FreeBSD.org> In-Reply-To: <44E817A6.30405@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1263121.z2aFNky2LZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608201922.26864.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: freebsd-current@freebsd.org, current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 09:52:42 -0000 --nextPart1263121.z2aFNky2LZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 17:34, Doug Barton wrote: > Daniel O'Connor wrote: > > The disk should remap the sector, if it refuses to write to the sector > > because it's out of remappable sectors > > You forgot to add, "and then immediately go out and buy a new disk because > that one is toast." :) Heh, well not necessarily although I personally would be shopping.. If the disk gets a dud sector and can't read it it won't remap it until you= =20 write to it. (I've seen this happen and someone else posted about it too) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1263121.z2aFNky2LZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE6DDa5ZPcIHs/zowRAlToAKCfeyRbwNie2zUVWU+AO9qrmGlydACeNXJG QdmR2lRKbPo/kc1UyIAAi2g= =9p9N -----END PGP SIGNATURE----- --nextPart1263121.z2aFNky2LZ-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 09:52:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68F9416A4DA; Sun, 20 Aug 2006 09:52:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCBC43D55; Sun, 20 Aug 2006 09:52:39 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp219-48.lns1.adl2.internode.on.net [203.122.219.48]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7K9qWJ3089609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Aug 2006 19:22:35 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Doug Barton Date: Sun, 20 Aug 2006 19:22:06 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> <44E817A6.30405@FreeBSD.org> In-Reply-To: <44E817A6.30405@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1263121.z2aFNky2LZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608201922.26864.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: freebsd-current@freebsd.org, current@freebsd.org, Nik Clayton Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 09:52:42 -0000 --nextPart1263121.z2aFNky2LZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 17:34, Doug Barton wrote: > Daniel O'Connor wrote: > > The disk should remap the sector, if it refuses to write to the sector > > because it's out of remappable sectors > > You forgot to add, "and then immediately go out and buy a new disk because > that one is toast." :) Heh, well not necessarily although I personally would be shopping.. If the disk gets a dud sector and can't read it it won't remap it until you= =20 write to it. (I've seen this happen and someone else posted about it too) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1263121.z2aFNky2LZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE6DDa5ZPcIHs/zowRAlToAKCfeyRbwNie2zUVWU+AO9qrmGlydACeNXJG QdmR2lRKbPo/kc1UyIAAi2g= =9p9N -----END PGP SIGNATURE----- --nextPart1263121.z2aFNky2LZ-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 10:04:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D67016A4DA for ; Sun, 20 Aug 2006 10:04:46 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528B243D5A for ; Sun, 20 Aug 2006 10:04:45 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-88-245.sn2.eutelia.it [83.211.88.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 0DC3F11B26A for ; Sun, 20 Aug 2006 12:04:42 +0200 (CEST) Received: from newluxor.wired.org (localhost [127.0.0.1]) by newluxor.wired.org (8.13.8/8.13.8) with ESMTP id k7KA2vPP000946 for ; Sun, 20 Aug 2006 12:02:57 +0200 (CEST) (envelope-from flag@newluxor.wired.org) Received: (from flag@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id k7KA2vie000945 for freebsd-current@freebsd.org; Sun, 20 Aug 2006 12:02:57 +0200 (CEST) (envelope-from flag) Date: Sun, 20 Aug 2006 12:02:56 +0200 From: Paolo Pisati To: FreeBSD_Current Message-ID: <20060820100256.GA854@tin.it> References: <20060819211853.GA1016@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060819211853.GA1016@tin.it> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Subject: Re: Fatal trap 30 when loading if_xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 10:04:46 -0000 On Sat, Aug 19, 2006 at 11:18:53PM +0200, Paolo Pisati wrote: > Today's CURRENT panic my box everytime i load > if_xl: and i got an identical panic while loading if_wi too: Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc04ef25b stack pointer = 0x28:0xe3491c34 frame pointer = 0x28:0xe3491c50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (swi4: clock sio) panic: from debugger cpuid = 0 Uptime: 1m16s Physical memory: 2031 MB Dumping 61 MB: 46 30 14 #0 doadump () at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc04f9cd4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04fa0b3 in panic (fmt=0xc06976c3 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0451b47 in db_panic (addr=-1068567973, have_addr=0, count=-1, modif=0xe3491a1c "") at /usr/src/sys/ddb/db_command.c:428 #4 0xc0451ada in db_command (last_cmdp=0xc06ef7c4, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:396 #5 0xc0451ba1 in db_command_loop () at /usr/src/sys/ddb/db_command.c:448 #6 0xc0453ae9 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc051bcde in kdb_trap (type=0, code=0, tf=0xe3491bf4) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc066f602 in trap_fatal (frame=0xe3491bf4, eva=0) at /usr/src/sys/i386/i386/trap.c:858 #9 0xc066f04d in trap (frame= {tf_fs = -1066467320, tf_es = -481755096, tf_ds = 40, tf_edi = -997181328, tf_esi = -993720208, tf_ebp = -481747888, tf_isp = -481747936, tf_ebx = -1066453624, tf_edx = 4, tf_ecx = -993720208, tf_eax = 582, tf_trapno = 30, tf_err = 0, tf_eip = -1068567973, tf_cs = 32, tf_eflags = 582, tf_esp = -1066453624, tf_ss = -1066446508}) at /usr/src/sys/i386/i386/trap.c:658 #10 0xc065766a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #11 0xc04ef25b in _mtx_lock_sleep (m=0xc06f3588, tid=3297785968, opts=0, file=0x0, line=0) at cpufunc.h:317 #12 0xc050c028 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:240 #13 0xc04dfbbf in ithread_execute_handlers (p=0xc49028d0, ie=0xc4957180) at /usr/src/sys/kern/kern_intr.c:662 #14 0xc04dfd05 in ithread_loop (arg=0xc48c68f0) at /usr/src/sys/kern/kern_intr.c:745 #15 0xc04de558 in fork_exit (callout=0xc04dfca1 , arg=0x246, frame=0x246) at /usr/src/sys/kern/kern_fork.c:818 #16 0xc06576cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 (kgdb) Sometimes it panics this way, others it panics in acpi_cpu_idle(), but i was unable to get a dump in that case. bye -- Paolo Piso's first law: nothing works as expected! From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 10:24:57 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDF9416A4DA for ; Sun, 20 Aug 2006 10:24:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BA3A43D5C for ; Sun, 20 Aug 2006 10:24:56 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A804551394; Sun, 20 Aug 2006 12:24:54 +0200 (CEST) Received: from localhost (public-gprs3175.centertel.pl [87.96.12.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E6B945138F; Sun, 20 Aug 2006 12:24:35 +0200 (CEST) Date: Sun, 20 Aug 2006 12:24:05 +0200 From: Pawel Jakub Dawidek To: Yar Tikhiy Message-ID: <20060820102405.GC1326@garage.freebsd.pl> References: <20060818184656.GB16008@comp.chem.msu.su> <20060818191457.GA78998@xor.obsecurity.org> <20060818202508.GA88159@garage.freebsd.pl> <20060819070804.GA23066@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20060819070804.GA23066@comp.chem.msu.su> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: current@FreeBSD.org, Kris Kennaway Subject: Re: mount * 2 + umount + lookup = GEOM panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 10:24:57 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 19, 2006 at 11:08:05AM +0400, Yar Tikhiy wrote: > On Fri, Aug 18, 2006 at 10:25:08PM +0200, Pawel Jakub Dawidek wrote: > > No, it's difficult to solve in a architectural clean way, but IMHO this > > bug should be fixed. I've a fix for this (which allows for multiple > > read-only mounts). It's hackish, but works. > >=20 > > Unfortunately phk@ didn't agree on committing it, so next time, please > > CC him:) >=20 > Just to satisfy my curiosity: Do you have references to a discussion > of the problem? When such a simple script triggers an architectural > issue, the latter is definitely worth taking a glance at. :-) I'm not sure if this was discussed in public. Anyway, the patch is here: http://people.freebsd.org/~pjd/patches/mro_mount.patch (I hope it is up-to-date). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE6DhFForvXbEpPzQRAiryAJ9yWZmG2kAoayINgtgT//IcNPrxiwCeJRlf 9Kgi3BkRyiWoHBvTcSOwplc= =EY+r -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 10:20:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7590016A4E6; Sun, 20 Aug 2006 10:20:06 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E68F143D45; Sun, 20 Aug 2006 10:20:05 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id B7D4833C46; Sun, 20 Aug 2006 14:20:03 +0400 (MSD) Message-ID: <44E83900.4020108@inse.ru> Date: Sun, 20 Aug 2006 14:27:12 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.12) Gecko/20060103 ASPLinux/1.7.12-1.5.1.1asp X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Daniel O'Connor References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> <44E817A6.30405@FreeBSD.org> <200608201922.26864.doconnor@gsoft.com.au> In-Reply-To: <200608201922.26864.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 20 Aug 2006 11:25:17 +0000 Cc: Doug Barton , current@freebsd.org, Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 10:20:06 -0000 Hi, Daniel O'Connor: >On Sunday 20 August 2006 17:34, Doug Barton wrote: > > >>Daniel O'Connor wrote: >> >> >>>The disk should remap the sector, if it refuses to write to the sector >>>because it's out of remappable sectors >>> >>> >>You forgot to add, "and then immediately go out and buy a new disk because >>that one is toast." :) >> >> > >Heh, well not necessarily although I personally would be shopping.. > >If the disk gets a dud sector and can't read it it won't remap it until you >write to it. (I've seen this happen and someone else posted about it too) > > 1) So why not just dd seek=xx count=1 to it to perform a write? 2) Before some one would read it, some one should write to it... Have I missed smth? rik From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 10:20:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7590016A4E6; Sun, 20 Aug 2006 10:20:06 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E68F143D45; Sun, 20 Aug 2006 10:20:05 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id B7D4833C46; Sun, 20 Aug 2006 14:20:03 +0400 (MSD) Message-ID: <44E83900.4020108@inse.ru> Date: Sun, 20 Aug 2006 14:27:12 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.12) Gecko/20060103 ASPLinux/1.7.12-1.5.1.1asp X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Daniel O'Connor References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> <44E817A6.30405@FreeBSD.org> <200608201922.26864.doconnor@gsoft.com.au> In-Reply-To: <200608201922.26864.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 20 Aug 2006 11:25:26 +0000 Cc: Doug Barton , current@freebsd.org, Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 10:20:06 -0000 Hi, Daniel O'Connor: >On Sunday 20 August 2006 17:34, Doug Barton wrote: > > >>Daniel O'Connor wrote: >> >> >>>The disk should remap the sector, if it refuses to write to the sector >>>because it's out of remappable sectors >>> >>> >>You forgot to add, "and then immediately go out and buy a new disk because >>that one is toast." :) >> >> > >Heh, well not necessarily although I personally would be shopping.. > >If the disk gets a dud sector and can't read it it won't remap it until you >write to it. (I've seen this happen and someone else posted about it too) > > 1) So why not just dd seek=xx count=1 to it to perform a write? 2) Before some one would read it, some one should write to it... Have I missed smth? rik From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 12:36:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA1B716A4DA for ; Sun, 20 Aug 2006 12:36:57 +0000 (UTC) (envelope-from paul@ifdnrg.com) Received: from ifdnrg5.ifdnrg.com (imap.ifdnrg.com [80.71.1.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09D7543D45 for ; Sun, 20 Aug 2006 12:36:56 +0000 (GMT) (envelope-from paul@ifdnrg.com) Received: from [192.168.1.77] (82-41-73-47.cable.ubr10.edin.blueyonder.co.uk [82.41.73.47]) (authenticated bits=0) by ifdnrg5.ifdnrg.com (8.12.11/8.12.11) with ESMTP id k7KCaqg8020752 for ; Sun, 20 Aug 2006 13:36:52 +0100 Message-ID: <44E85761.5090909@ifdnrg.com> Date: Sun, 20 Aug 2006 13:36:49 +0100 From: Paul Macdonald User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD 6.1 + Dell 1950 + Broadcom NetXtreme II BCM5708 1000Base-T X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 12:36:57 -0000 If anyones having problems with this setup, i put together a quick guide here http://www.ifdnrg.com/freebsd_broadcom_dell_1950.htm will hopefully save someone some time. paul. -- *web and video services* *Paul Macdonald* /Director/ IFDNRG Edinburgh paul@ifdnrg.com www.ifdnrg.com tel: +44.131.4770730 mob: +44.7813133612 ------------------------------------------------------------------------ * Featured Projects* www.internetfootball.co.uk www.nexusliveshow.com www.easystream.co.uk From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 13:45:29 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 035A116A4DE for ; Sun, 20 Aug 2006 13:45:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F5E43D45 for ; Sun, 20 Aug 2006 13:45:28 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp6-g19.free.fr (Postfix) with ESMTP id C08A822621; Sun, 20 Aug 2006 15:45:26 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id BC8E89B4D7; Sun, 20 Aug 2006 13:46:05 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id AA8DC405B; Sun, 20 Aug 2006 15:46:05 +0200 (CEST) Date: Sun, 20 Aug 2006 15:46:05 +0200 From: Jeremie Le Hen To: "Matthew D. Fuller" Message-ID: <20060820134605.GN57815@obiwan.tataz.chchile.org> References: <200608151627.37828.root@solink.ru> <20060815130002.M45647@fledge.watson.org> <200608160959.23100.root@solink.ru> <20060816094944.GC820@turion.vk2pj.dyndns.org> <44E3A2C0.2020801@elischer.org> <20060819195336.GL57815@obiwan.tataz.chchile.org> <20060820082959.GC65866@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060820082959.GC65866@over-yonder.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: [fbsd] Re: throughput and interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 13:45:29 -0000 Hi Matthew, On Sun, Aug 20, 2006 at 03:29:59AM -0500, Matthew D. Fuller wrote: > On Sat, Aug 19, 2006 at 09:53:36PM +0200 I heard the voice of > Jeremie Le Hen, and lo! it spake thus: > > > > What about the SoC 2005 project, aiming to push libalias down into a > > kernel module ? > > I've been half-waiting for that all (particularly the ipfw side) to > land too. Forget performance; I just want to be able to add and > remove and change forwardings without losing all the existing state of > the NAT engine. natd doesn't do it. I can't see any way that pf does > it. But hey, at least you can do it in ppp... IPFilter does it. ipnat -C flushes rules, ipnat -F flushes states. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 14:07:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 104E916A4DA for ; Sun, 20 Aug 2006 14:07:13 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2600443D58 for ; Sun, 20 Aug 2006 14:07:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) id 44A2F19F00AD3E91 for freebsd-current@freebsd.org; Sun, 20 Aug 2006 16:07:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Sun, 20 Aug 2006 16:07:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F5CD@royal64.emp.zapto.org> In-Reply-To: <44E83900.4020108@inse.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding bad sectors? Thread-Index: AcbES4BngYbYnSnzSf20y7mLMr+cKAAFQ9wg From: "Daniel Eriksson" To: Subject: RE: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 14:07:13 -0000 First thing you should do is run a SMART selftest on the device using smartmontools: smartctl -t long /dev/adX Poll the status of the selftest using: smartctl -a /dev/adX until the selftest has finished (an hour or two) or aborted. This can be done while in multiuser mode, but beware that disc accesses will be slower than usual. If you want to "fix" the problem and avoid downtime, then move swap to another slice (possibly an inode-backed md device, if that is possible) and fill the bad slice using 'dd'. Not sure if taking the data from /dev/random instead of /dev/zero makes any difference, but it will not hurt you other than by adding some time to the operation. Once you've written to the bad slice you probably want to re-run the SMART selftest to make sure it passes without any more failures. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 18:02:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC0616A4DA for ; Sun, 20 Aug 2006 18:02:59 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F9143D45 for ; Sun, 20 Aug 2006 18:02:57 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-72-66-211-114.ronkva.east.verizon.net [72.66.211.114]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7KI2rQV010679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Aug 2006 14:02:55 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7KI2p3C032034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Aug 2006 14:02:52 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7KI2pgn032033 for freebsd-current@freebsd.org; Sun, 20 Aug 2006 14:02:51 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 20 Aug 2006 14:02:50 -0400 Message-Id: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Subject: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 18:02:59 -0000 Since updating my -CURRENT system circa 16th August I'm getting an error like this when my daily Tivoli backup runs: Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented I don't know whether this is a -CURRENT problem or a problem with linux_base-fc4, but I lean towards the former because the same nightly backup setup I'm running on a 6.1-STABLE system runs without problems. I recall a discussion about merging Linux 2.6 kernel support into HEAD around the time I updated. Could this be related to that? Here is what I have for my Linux compat sysctls: compat.linux.oss_version: 198144 compat.linux.osrelease: 2.4.2 compat.linux.osname: Linux Is anyone else having this "syscall statfs64 not implemented" problem? Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 18:22:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FAAD16A4E2 for ; Sun, 20 Aug 2006 18:22:10 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1703D43D45 for ; Sun, 20 Aug 2006 18:22:04 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.165]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7KILho3077466; Sun, 20 Aug 2006 22:21:54 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GEruW-0000CP-LA; Sun, 20 Aug 2006 22:20:36 +0400 To: Paul Mather References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> From: Boris Samorodov Date: Sun, 20 Aug 2006 22:20:36 +0400 In-Reply-To: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> (Paul Mather's message of "Sun, 20 Aug 2006 14:02:50 -0400") Message-ID: <69990395@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: Divacky Roman , freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 18:22:10 -0000 CCing to Roman as he may be interested. On Sun, 20 Aug 2006 14:02:50 -0400 Paul Mather wrote: > Since updating my -CURRENT system circa 16th August I'm getting an error > like this when my daily Tivoli backup runs: > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented Thanks for the report. I think Roman knows what to do. ;-) > I don't know whether this is a -CURRENT problem or a problem with > linux_base-fc4, but I lean towards the former because the same nightly > backup setup I'm running on a 6.1-STABLE system runs without problems. The issue belongs only to -CURRENT. > I recall a discussion about merging Linux 2.6 kernel support into HEAD > around the time I updated. Could this be related to that? Here is what > I have for my Linux compat sysctls: > compat.linux.oss_version: 198144 > compat.linux.osrelease: 2.4.2 > compat.linux.osname: Linux This is related to the latest changes at linux emulation code, but not related to 2.6 Linux support (as you see, the default is 2.4). BTW, which platform do you use? (i.e. uname -srm) > Is anyone else having this "syscall statfs64 not implemented" problem? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 18:33:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88FCD16A4DE for ; Sun, 20 Aug 2006 18:33:12 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A9543D68 for ; Sun, 20 Aug 2006 18:33:07 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-72-66-211-114.ronkva.east.verizon.net [72.66.211.114]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7KIX32r010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 14:33:06 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7KIX2hj032164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 14:33:03 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7KIX0x5032163; Sun, 20 Aug 2006 14:33:00 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Boris Samorodov In-Reply-To: <69990395@bsam.ru> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <69990395@bsam.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 20 Aug 2006 14:32:59 -0400 Message-Id: <1156098779.32130.2.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: Divacky Roman , freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 18:33:12 -0000 On Sun, 2006-08-20 at 22:20 +0400, Boris Samorodov wrote: > CCing to Roman as he may be interested. > > On Sun, 20 Aug 2006 14:02:50 -0400 Paul Mather wrote: > > > Since updating my -CURRENT system circa 16th August I'm getting an error > > like this when my daily Tivoli backup runs: > > > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented > BTW, which platform do you use? (i.e. uname -srm) Thanks for the reply. I'm running FreeBSD 7.0-CURRENT i386. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 20:43:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C3F016A4DF for ; Sun, 20 Aug 2006 20:43:46 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BA0C43D5C for ; Sun, 20 Aug 2006 20:43:44 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7KKhd1A076969 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Aug 2006 22:43:39 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7KKhdT6076968; Sun, 20 Aug 2006 22:43:39 +0200 (CEST) Date: Sun, 20 Aug 2006 22:43:39 +0200 From: Divacky Roman To: Paul Mather Message-ID: <20060820204338.GA76869@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 20:43:46 -0000 On Sun, Aug 20, 2006 at 02:02:50PM -0400, Paul Mather wrote: > Since updating my -CURRENT system circa 16th August I'm getting an error > like this when my daily Tivoli backup runs: > > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented > > I don't know whether this is a -CURRENT problem or a problem with > linux_base-fc4, but I lean towards the former because the same nightly > backup setup I'm running on a 6.1-STABLE system runs without problems. > > I recall a discussion about merging Linux 2.6 kernel support into HEAD > around the time I updated. Could this be related to that? Here is what > I have for my Linux compat sysctls: > > compat.linux.oss_version: 198144 > compat.linux.osrelease: 2.4.2 > compat.linux.osname: Linux > > Is anyone else having this "syscall statfs64 not implemented" problem? yes, everyone. statfs64 syscalls is not implemented. I might implement if its important and you are willing to test. it should be quite trivial but I need the testing. roman From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 20:53:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6636B16A4DE for ; Sun, 20 Aug 2006 20:53:16 +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 BD6FD43D55 for ; Sun, 20 Aug 2006 20:53:15 +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 k7KKqreV010062; Mon, 21 Aug 2006 00:52:54 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 21 Aug 2006 00:52:53 +0400 (MSD) From: Maxim Konovalov To: Andriy Gapon In-Reply-To: <44E5FFF3.9040908@icyb.net.ua> Message-ID: <20060821004825.F9919@mp2.macomnet.net> References: <1155864187.00584864.1155853201@10.7.7.3> <1155882183.00584920.1155870001@10.7.7.3> <44E5C008.9010008@icyb.net.ua> <20060818204915.S42981@atlantis.atlantis.dp.ua> <44E5FFF3.9040908@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Dmitry Pryanishnikov , "Devon H. O'Dell" , freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: no kld in minidumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 20:53:16 -0000 On Fri, 18 Aug 2006, 20:59+0300, Andriy Gapon wrote: > on 18/08/2006 20:50 Dmitry Pryanishnikov said the following: > > Hello! > > > > On Fri, 18 Aug 2006, Andriy Gapon wrote: > >> BTW, has anyone contemplated or even done this - some sort of a script > >> to automatically add all modules that were loaded at a time of crash ? > > > > Hmm, isn't this the task for asf(8). If not, what is asf(8) for? > > This is a very nice command, thank you! But it does not seem to be > directly applicable to postmortem situation i.e. crash dump > debugging. Or maybe it will be easier to teach kldstat to work with > dumps/images in addition to what it does now ? There is some support in /usr/src/tools/debugscripts/ but I didn't try it recently. To make it work you need to to do smth like that: cd /usr/obj/usr/src/sys/GENERIC/ && make gdbinit -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 20:55:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D5C916A4DA for ; Sun, 20 Aug 2006 20:55:28 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A44B443D55 for ; Sun, 20 Aug 2006 20:55:27 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id YCX68018; Sun, 20 Aug 2006 13:55:18 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4C78E45042; Sun, 20 Aug 2006 13:55:18 -0700 (PDT) To: "Daniel Eriksson" In-reply-to: Your message of "Sun, 20 Aug 2006 16:07:11 +0200." <4F9C9299A10AE74E89EA580D14AA10A605F5CD@royal64.emp.zapto.org> Date: Sun, 20 Aug 2006 13:55:18 -0700 From: "Kevin Oberman" Message-Id: <20060820205518.4C78E45042@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 20:55:28 -0000 > Date: Sun, 20 Aug 2006 16:07:11 +0200 > From: "Daniel Eriksson" > Sender: owner-freebsd-current@freebsd.org > > > First thing you should do is run a SMART selftest on the device using > smartmontools: > > smartctl -t long /dev/adX > > Poll the status of the selftest using: > > smartctl -a /dev/adX > > until the selftest has finished (an hour or two) or aborted. This can be > done while in multiuser mode, but beware that disc accesses will be > slower than usual. > > If you want to "fix" the problem and avoid downtime, then move swap to > another slice (possibly an inode-backed md device, if that is possible) > and fill the bad slice using 'dd'. Not sure if taking the data from > /dev/random instead of /dev/zero makes any difference, but it will not > hurt you other than by adding some time to the operation. > > Once you've written to the bad slice you probably want to re-run the > SMART selftest to make sure it passes without any more failures. There have been some excellent suggestions in this thread, but one simple detail looks like it's been over-looked. If the disk has marked the sector as bad, which it should have, and it there are redirection sectors available. a reboot is all that is required. After reboot the entire swap space will be unused and the first access to any sector will be a write. The sector will be remapped on any write attempt, so as soon as that sector is used after boot, it will be remapped to a spare sector and the error will be gone. No need to force a write to that sector. That said, using smartctl is an excellent suggestion. If it's just a random block failure, it's no big deal and smart should tell you if the problem is worse and it's time to go buy a new drive. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 21:14:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A90016A4E1 for ; Sun, 20 Aug 2006 21:14:02 +0000 (UTC) (envelope-from carl@UDel.Edu) Received: from md3.nss.udel.edu (md3.nss.udel.edu [128.175.1.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A2E543D9A for ; Sun, 20 Aug 2006 21:12:58 +0000 (GMT) (envelope-from carl@UDel.Edu) Received: from ms1.nss.udel.edu (ms1.nss.udel.edu [128.175.1.21]) by md3.nss.udel.edu (MOS 3.7.1-GA) with ESMTP id DBD24104; Sun, 20 Aug 2006 17:12:44 -0400 (EDT) Received: (from ms1.nss.udel.edu [68.82.120.39]) by ms1.nss.udel.edu (MOS 3.7.1-GA) with HTTPS/1.1 id BTA31151 (AUTH carl); Sun, 20 Aug 2006 17:12:44 -0400 (EDT) From: To: freebsd-current@freebsd.org X-Mailer: Mirapoint Webmail Direct 3.7.1-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060820171244.BTA31151@ms1.nss.udel.edu> Date: Sun, 20 Aug 2006 17:12:44 -0400 (EDT) X-Junkmail-Status: score=10/50, host=md3.nss.udel.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090208.44E8CF50.003B,ss=1,fgs=0, ip=128.175.1.21, so=2005-09-30 22:39:37, dmn=5.2.113/2006-07-26 Cc: carl@UDel.Edu Subject: a problem setting screen resolution with Xorg-6.9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 21:14:02 -0000 Fellow FreeBSDers, I originally sent this to FreeBSD-X11, but this may be a more appropriate venue. I have recently installed FreeBSD 6.1 on a Pentium III box, using an NVidia GeForce 2 GTS card and a CTX PL9 monitor. Running "X -configure" as root generates the file xorg.conf.new, and then running "X -config xorg.conf.new", pulls up a generic X screen with a resolution of 1600x1200. I go in and modify the xorg.conf.new file to make the default resolution 1280x1024, and rerun "X -config xorg.conf.new", but the resolution is still 1600x1200. This is a wonderful resolution, but it makes everything rather small, and the icons are difficult to see. I am obviously setting something wrong, but I do not know what it is. Might anyone have any suggestions. I really would rather have the resolution be 1280x1024. Thanks for your help! Carl The following is the file xorg.conf.new: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/TTF/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" EndSection Section "Module" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 360 270 # mm Identifier "Monitor0" VendorName "CTX" ModelName "3700" ### Comment all HorizSync and VertSync values to use DDC: HorizSync 30.0 - 95.0 VertRefresh 50.0 - 160.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "UseFBDev" # [] #Option "Rotate" # [] #Option "VideoKey" # #Option "FlatPanel" # [] #Option "FPDither" # [] #Option "CrtcNumber" # #Option "FPScale" # [] #Option "FPTweak" # Identifier "Card0" Driver "nv" VendorName "nVidia Corporation" BoardName "NV15 [GeForce2 GTS/Pro]" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 24 Modes "1280x1024" EndSubSection EndSection From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 21:54:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2403116A4DA for ; Sun, 20 Aug 2006 21:54:03 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA18943D58 for ; Sun, 20 Aug 2006 21:54:01 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.142]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7KLre7D000966; Mon, 21 Aug 2006 01:53:50 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GEvDR-0000BF-HT; Mon, 21 Aug 2006 01:52:21 +0400 To: Divacky Roman References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> From: Boris Samorodov Date: Mon, 21 Aug 2006 01:52:21 +0400 In-Reply-To: <20060820204338.GA76869@stud.fit.vutbr.cz> (Divacky Roman's message of "Sun, 20 Aug 2006 22:43:39 +0200") Message-ID: <14630010@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: Paul Mather , freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 21:54:03 -0000 On Sun, 20 Aug 2006 22:43:39 +0200 Divacky Roman wrote: > On Sun, Aug 20, 2006 at 02:02:50PM -0400, Paul Mather wrote: > > Since updating my -CURRENT system circa 16th August I'm getting an error > > like this when my daily Tivoli backup runs: > > > > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented > > > > I don't know whether this is a -CURRENT problem or a problem with > > linux_base-fc4, but I lean towards the former because the same nightly > > backup setup I'm running on a 6.1-STABLE system runs without problems. > > > > I recall a discussion about merging Linux 2.6 kernel support into HEAD > > around the time I updated. Could this be related to that? Here is what > > I have for my Linux compat sysctls: > > > > compat.linux.oss_version: 198144 > > compat.linux.osrelease: 2.4.2 > > compat.linux.osname: Linux > > > > Is anyone else having this "syscall statfs64 not implemented" problem? > yes, everyone. statfs64 syscalls is not implemented. > I might implement if its important and you are willing to test. it should be > quite trivial but I need the testing. I can test it at -CURRENT amd64. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 23:22:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F0F516A4DA; Sun, 20 Aug 2006 23:22:12 +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 DFB8743D53; Sun, 20 Aug 2006 23:22:10 +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 57EED1A4DF6; Sun, 20 Aug 2006 16:22:10 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 975915164F; Sun, 20 Aug 2006 19:22:08 -0400 (EDT) Date: Sun, 20 Aug 2006 19:22:08 -0400 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060820232208.GA84554@xor.obsecurity.org> References: <20060818140047.GA53670@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20060818140047.GA53670@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: current@FreeBSD.org, mohans@FreeBSD.org Subject: Re: null pointer deref from mount/umount + rm -rf loop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 23:22:12 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 18, 2006 at 10:00:47AM -0400, Kris Kennaway wrote: > I ran mount -o ro -t nfs ...; sleep 2; umount -f nfs together with rm > -rf in a loop, and after some time the machine panicked with: I got another 2 instances of the panic (mohan: your patch did not help, so it's probably a different issue to the other umount bug you looked at) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x80 fault code = supervisor read, page not present instruction pointer = 0x20:0xc053a461 stack pointer = 0x28:0xec89ea64 frame pointer = 0x28:0xec89ea80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 9060 (rm) [thread pid 9060 tid 100182 ] Stopped at _mtx_lock_flags+0x1b: movl 0x10(%ecx),%eax db> wh Tracing pid 9060 tid 100182 td 0xc594a360 _mtx_lock_flags(70,0,c075f612,1a3,0,...) at _mtx_lock_flags+0x1b vfs_ref(0,c07a2f80,ec89eaf4,ec89ead0,c0728940,...) at vfs_ref+0x32 vop_stdgetwritemount(ec89eaf4,c077d0ce,c4912300,ec89eb28,cd6e4690,...) at vop_stdgetwritemount+0x1d VOP_GETWRITEMOUNT_APV(c07ab460,ec89eaf4,c07c5d10,2,c07578f7,...) at VOP_GETWRITEMOUNT_APV+0x8a vn_start_write(cd6e4690,ec89eb28,1,6,cd6e46e8,...) at vn_start_write+0x34 vn_close(cd6e4690,5,c5188280,c594a360,0,...) at vn_close+0x3d vn_closefile(c4ca6510,c594a360,c0752864,871,cd6e4690,...) at vn_closefile+0x8b fdrop_locked(c4ca6510,c594a360,ec89ec18,c053a5f1,ce3b3540,0,0,c594a360,c594a4f0,c594d69c,ec89ec2c,c0559e05,c07c5d10,c585262c,3e9,c0752864,ec89ec50,c053a81f,c585262c,1,c07551ce,16a,0) at fdrop_locked+0xb9 closef(c4ca6510,c594a360,c0752864,3e9,c594a360,...) at closef+0x1f7 kern_close(c594a360,4,4,158,1,...) at kern_close+0x188 syscall(3b,821003b,bfbf003b,8250130,804b4d8,...) at syscall+0x152 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x2815ba4f, esp = 0xbfbfe69c, ebp = 0xbfbfe6b8 --- db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xc594a360: pid 9060 "rm" curpcb = 0xec89ed90 fpcurthread = none idlethread = 0xc490fa20: pid 13 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xc4dedd80: pid 9062 "umount" curpcb = 0xec730d90 fpcurthread = none idlethread = 0xc490f870: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid = 2 curthread = 0xc4ff8a20: pid 9056 "find" curpcb = 0xec77ed90 fpcurthread = none idlethread = 0xc490f6c0: pid 11 "idle: cpu2" APIC ID = 2 currentldt = 0x50 cpuid = 3 curthread = 0xc490fbd0: pid 14 "swi4: clock sio" curpcb = 0xe8950d90 fpcurthread = none idlethread = 0xc490f510: pid 10 "idle: cpu3" APIC ID = 3 currentldt = 0x50 db> wh 9062 Tracing pid 9062 tid 100120 td 0xc4dedd80 cpustop_handler(ec730960,c0710fe2,3,1,c07c8158,...) at cpustop_handler+0x2c ipi_nmi_handler(3,1,c07c8158,c07c7920,c508c8d0,...) at ipi_nmi_handler+0x2a trap(8,28,28,f5,df30a000,...) at trap+0x38a calltrap() at calltrap+0x5 --- trap 0x13, eip = 0xc0707834, esp = 0xec7309a8, ebp = 0xec7309c4 --- smp_tlb_shootdown(df30b000,df30b000,c0778ebb,2f8,df30a000,...) at smp_tlb_shootdown+0x71 pmap_invalidate_range(c07ff340,df30a000,df30b000) at pmap_invalidate_range+0x114 pmap_qremove(df30a000,1,c075e1ed,606,dda37874,...) at pmap_qremove+0x44 vfs_vmio_release(cc18d3c0,0,c075e1ed,51a,c05366c1,...) at vfs_vmio_release+0x13f brelse(dda37874,202122,cf0609f8,c4dedd80,20609f8,...) at brelse+0x942 flushbuflist(cf060a30,0,0,3e7,c4dedd80,...) at flushbuflist+0x14a bufobj_invalbuf(cf060a30,1,c4dedd80,0,0,...) at bufobj_invalbuf+0x79 vgonel(cf0609f8,0,c075fe76,909,d084d8ec,...) at vgonel+0xca vflush(d084d87c,1,2,c4dedd80,0,...) at vflush+0x2a6 nfs_unmount(d084d87c,8080000,c4dedd80,c4dedd80,0,...) at nfs_unmount+0x56 dounmount(d084d87c,8080000,c4dedd80,43e,539ff4c,...) at dounmount+0x250 unmount(c4dedd80,ec730d04,8,ec730d38,2,...) at unmount+0x217 syscall(3b,3b,3b,804a610,8201c38,...) at syscall+0x152 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c369b, esp = 0xbfbfe08c, ebp = 0xbfbfe148 --- db> wh 9056 Tracing pid 9056 tid 100137 td 0xc4ff8a20 cpustop_handler(ec77ea34,c0710fe2,3041,c4c3bad8,40,...) at cpustop_handler+0x2c ipi_nmi_handler(3041,c4c3bad8,40,c07c5740,225,...) at ipi_nmi_handler+0x2a trap(c0720008,c05b0028,c06a0028,c4ff8a20,15a4c8,...) at trap+0x38a calltrap() at calltrap+0x5 --- trap 0x13, eip = 0xc053a572, esp = 0xec77ea7c, ebp = 0xec77ea9c --- _mtx_lock_spin(c07e6cc8,c4ff8a20,0,c0773c9b,56e,...) at _mtx_lock_spin+0x4a _mtx_lock_spin_flags(c07e6cc8,0,c0773c9b,56e,ec77eb04,...) at _mtx_lock_spin_flags+0x90 siointr(c4a24800,c07c5d10,2,c4ff8a20,0,...) at siointr+0x2a intr_execute_handlers(c4907cc4,ec77eb20,ec77eb80,c06fa6a3,38,...) at intr_execute_handlers+0xcc lapic_handle_intr(38) at lapic_handle_intr+0x2d Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053a3d9, esp = 0xec77eb60, ebp = 0xec77eb80 --- _mtx_lock_sleep(c07c5d28,c4ff8a20,0,c0751dac,137,...) at _mtx_lock_sleep+0x12e _mtx_lock_flags(c07c5d28,0,c0751dac,137,6,...) at _mtx_lock_flags+0x8e giant_write(c508d300,ec77ec64,0,c508d300,c07a08a0,...) at giant_write+0x2e devfs_write_f(c4f8a3f0,ec77ec64,c5186b80,0,c4ff8a20,...) at devfs_write_f+0x82 dofilewrite(c4f8a3f0,ec77ec64,ffffffff,ffffffff,0,...) at dofilewrite+0x7c kern_writev(c4ff8a20,2,ec77ec64,bfbfe1c0,6,...) at kern_writev+0x6b write(c4ff8a20,ec77ed04,c,ec77ed38,3,...) at write+0x4d syscall(825003b,bfbf003b,bfbf003b,bfbfe1c0,6,...) at syscall+0x152 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x28157a6f, esp = 0xbfbfe03c, ebp = 0xbfbfe058 --- db> db> show lockedvnods Locked vnodes 0xcb8c1690: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0xd084d87c flags () v_object 0xce353870 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc4dedd80 (pid 9062)#0 0xc0536188 at lockmgr+0x541 #1 0xc069059e at ffs_lock+0x59 #2 0xc072bba4 at VOP_LOCK_APV+0x76 #3 0xc05c305a at vn_lock+0x67 #4 0xc05ae4fb at dounmount+0x51 #5 0xc05aecac at unmount+0x217 #6 0xc0711507 at syscall+0x152 #7 0xc06fa33f at Xint0x80_syscall+0x1f ino 353827, on dev da0s1e 0xcf060930: tag nfs, type VDIR usecount 0, writecount 0, refcount 47 mountedhere 0 flags (VI_DOOMED) v_object 0xcc18d3c0 ref 0 pages 87 lock type nfs: EXCL (count 1) by thread 0xc4dedd80 (pid 9062)#0 0xc0536188 at lockmgr+0x541 #1 0xc05aa8e4 at vop_stdlock+0x32 #2 0xc072bba4 at VOP_LOCK_APV+0x76 #3 0xc05c305a at vn_lock+0x67 #4 0xc05b7b64 at vflush+0x23c #5 0xc064b3c6 at nfs_unmount+0x56 #6 0xc05ae6fa at dounmount+0x250 #7 0xc05aecac at unmount+0x217 #8 0xc0711507 at syscall+0x152 #9 0xc06fa33f at Xint0x80_syscall+0x1f [hung again here] This time I was able to save a core though. Kris --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE6O6gWry0BWjoQKURAozcAKDqQUfI1juv6zWE5URXYxcm+PKVegCfSRkx Sbp7hWvPqvEa6FDrBYYY9GM= =5Fbn -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 23:28:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD7D16A4DD for ; Sun, 20 Aug 2006 23:28:32 +0000 (UTC) (envelope-from dwoolworth@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id A040143D49 for ; Sun, 20 Aug 2006 23:28:27 +0000 (GMT) (envelope-from dwoolworth@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1956012nfc for ; Sun, 20 Aug 2006 16:28:26 -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; b=kOdL3ymyiwIpB4z6rIxhrCc52ahZWxyYsJZt3EZKMFJmDyiY1uKnUh6E18oNHbQstkhBggM+i2aGKg6dbwY4mU20MaayJ61+7zoY17I5F0XKtST0249ofUIefTV0CD09Jilb5fIzjgZ22A3F04HfkZbcIxDWimrSAJ+Htt3K524= Received: by 10.49.29.3 with SMTP id g3mr7020462nfj; Sun, 20 Aug 2006 16:28:26 -0700 (PDT) Received: by 10.48.207.16 with HTTP; Sun, 20 Aug 2006 16:28:26 -0700 (PDT) Message-ID: <10fd06c60608201628o51d6a5beof512e907b4d53872@mail.gmail.com> Date: Sun, 20 Aug 2006 18:28:26 -0500 From: "Derrick T. Woolworth" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SYN Flood X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 23:28:32 -0000 I forwarded a message to the security officer about this issue, but I still haven't been able to narrow down whats happening enough to guarantee its just not a bug. I'm running -CURRENT on one server. Our Internet router/firewall is a 6.1-STABLE system running PF, routing two class C's or a /23 subnet actually. I didn't have any trouble until I put the -CURRENT system on our LAN and attempted to make it a router/firewall system. The route is 64.199.142.240/28 => 64.199.142.60, so I'm merely routing a few IP's at the -CURRENT system uname -a FreeBSD mbfw.mb.rndkc.com 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Aug 20 15:29:02 CDT 2006 root@mbfw.mb.rndkc.com:/usr/src/sys/amd64/compile/MBFW amd64 router's ethernet addr: 00:0d:87:e9:c0:40 'vr' driver new -current system's public interface eth addr: 00:16:e6:52:cd:47 'nve' driver After leaving tcpdump running until this happens (which, things run away for 2 to 3 minutes and then stop), I've captured this: 17:42:33.829685 00:0d:87:e9:c0:40 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8cd 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 @../.P....!.zp.. 0x0020: 5012 4000 8330 0000 0715 9e32 ef00 P.@..0.....2.. 17:42:33.831281 00:16:e6:52:cd:47 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5906 bacd 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 @../.P....!.zp.. 0x0020: 5012 4000 8330 0000 P.@..0.. 17:42:33.832700 00:0d:87:e9:c0:40 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8a4 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 @..X.P......R... 0x0020: 5012 4000 f095 0000 d443 0000 69d9 P.@......C..i. 17:42:33.833752 00:16:e6:52:cd:47 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5906 baa4 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 @..X.P......R... 0x0020: 5012 4000 f095 0000 P.@..... 17:42:33.851227 00:0d:87:e9:c0:40 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5b06 b868 51b0 455c E..(..@.[..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 @....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 0050 4f20 0001 P.@......PO... 17:42:33.852111 00:16:e6:52:cd:47 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5906 ba68 51b0 455c E..(..@.Y..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 @....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 P.@..... 17:42:33.854137 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5b06 b714 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 0000 0000 0000 P.@.o......... 17:42:33.854177 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5906 b914 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P.@.o... 17:42:33.854338 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5806 ee5e 51b0 455c E..(....X..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 03f3 e59a 3200 P.@.o.......2. 17:42:33.854365 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5606 f05e 51b0 455c E..(....V..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P.@.o... I'm watching this on the -current system's public interface and on the router's LAN facing interface. I suppose the first odd thing is why or how is my switch is showing the -current system's public/LAN facing interface this SYN packet that isn't destined for it. Even worse, however, is the -current's nve interface duplicates these packets - and where is the 81.176.69.92 IP address coming from? The packets occur often and from different IP addresses. I can't tell if the first SYN packet in is actually valid or not, but since these max out a 100mb connection, you can imagine that our main firewall/router's LAN interface is maxing out the CPU (swi1: net has used 545 hours of CPU time and irq23: vr0 588 hours). The -current system is similar with the nve driver. Has anyone seen this kind of behavior? Do I have some kind of weird viral thing happening or a switch problem? The switch has been really stable for us - a Cisco 4003 with 68 ports... I just haven't seen anything like this before - getting a SYN flood from all kinds of addresses and yet if I watch the public router/firewall interface, I only have outbound packets from the network. Sorry if I'm posting to the wrong list, but this only started occuring when we added this -current server to our network... I'm just wondering if there could be some odd behavior with the updates to the nve driver? Thanks, D -- Derrick T. Woolworth R&D Technology, LLC. http://www.rndtechnology.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 00:22:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5400A16A4DA; Mon, 21 Aug 2006 00:22:10 +0000 (UTC) (envelope-from fbsd-current@mawer.org) Received: from customer-domains.icp-qv1-irony8.iinet.net.au (customer-domains.icp-qv1-irony8.iinet.net.au [203.59.1.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0242643D45; Mon, 21 Aug 2006 00:22:08 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [127.0.0.1]) ([203.206.173.235]) by customer-domains.icp-qv1-irony8.iinet.net.au with ESMTP; 21 Aug 2006 08:22:07 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,149,1154880000"; d="scan'208"; a="442553457:sNHT299754984" Message-ID: <44E8FC8F.3010801@mawer.org> Date: Mon, 21 Aug 2006 10:21:35 +1000 From: Antony Mawer User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Daniel O'Connor References: <44E77EF7.6070004@ngo.org.uk> <200608201227.34510.doconnor@gsoft.com.au> <44E817A6.30405@FreeBSD.org> <200608201922.26864.doconnor@gsoft.com.au> In-Reply-To: <200608201922.26864.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 00:22:10 -0000 On 20/08/2006 7:52 PM, Daniel O'Connor wrote: > On Sunday 20 August 2006 17:34, Doug Barton wrote: >> Daniel O'Connor wrote: >>> The disk should remap the sector, if it refuses to write to the sector >>> because it's out of remappable sectors >> You forgot to add, "and then immediately go out and buy a new disk because >> that one is toast." :) > > Heh, well not necessarily although I personally would be shopping.. > > If the disk gets a dud sector and can't read it it won't remap it until you > write to it. (I've seen this happen and someone else posted about it too) I brought this up on -stable the other day... see the thread titled "The need for initialising disks before use?" (17/08/06). I've seen numerously "young" disks showing up plenty of read errors (which smartctl seems to confirm are coming from the disk, and not driver etc related), and would love to see some way to easily "fix" the problem... these are all < 6mth old SATA drives... Unfortunately dd'ing parts of an existing filesystem are a little more complicated than when dealing with a swap partition :-( -Antony From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 00:39:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D29DB16A4E0; Mon, 21 Aug 2006 00:39:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C77943D58; Mon, 21 Aug 2006 00:39:38 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7L0dbq4031711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 10:09:37 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Antony Mawer Date: Mon, 21 Aug 2006 10:09:36 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> <200608201922.26864.doconnor@gsoft.com.au> <44E8FC8F.3010801@mawer.org> In-Reply-To: <44E8FC8F.3010801@mawer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5378386.KqkvS3dgya"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608211009.37626.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: Doug Barton , Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 00:39:40 -0000 --nextPart5378386.KqkvS3dgya Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 21 August 2006 09:51, Antony Mawer wrote: > I brought this up on -stable the other day... see the thread titled "The > need for initialising disks before use?" (17/08/06). Knew it was somewhere recent :) > I've seen numerously "young" disks showing up plenty of read errors > (which smartctl seems to confirm are coming from the disk, and not > driver etc related), and would love to see some way to easily "fix" the > problem... these are all < 6mth old SATA drives... Ouch.. Time to switch drive maker. > Unfortunately dd'ing parts of an existing filesystem are a little more > complicated than when dealing with a swap partition :-( Yeah, you can do it but it is more complicated. There was a patch floating around for fsdb which showed what file a particu= lar=20 block was associated with. I'm not sure if it ever got merged though. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5378386.KqkvS3dgya Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE6QDJ5ZPcIHs/zowRAmiGAKCTZde+5bqo64KP6PyNMKpV6tsfvACfTyOH gnw4nC7pjRIqqj0s6mPmBiE= =g1g6 -----END PGP SIGNATURE----- --nextPart5378386.KqkvS3dgya-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 00:58:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCA916A4E0 for ; Mon, 21 Aug 2006 00:58:43 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66BDD43D45 for ; Mon, 21 Aug 2006 00:58:42 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-72-66-211-114.ronkva.east.verizon.net [72.66.211.114]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7L0wbAo013070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 20:58:40 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7L0wak0034068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Aug 2006 20:58:36 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7L0wXjR034067; Sun, 20 Aug 2006 20:58:33 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Divacky Roman In-Reply-To: <20060820204338.GA76869@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 20 Aug 2006 20:58:32 -0400 Message-Id: <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 00:58:43 -0000 On Sun, 2006-08-20 at 22:43 +0200, Divacky Roman wrote: > On Sun, Aug 20, 2006 at 02:02:50PM -0400, Paul Mather wrote: > > Since updating my -CURRENT system circa 16th August I'm getting an error > > like this when my daily Tivoli backup runs: > > > > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented > > > > I don't know whether this is a -CURRENT problem or a problem with > > linux_base-fc4, but I lean towards the former because the same nightly > > backup setup I'm running on a 6.1-STABLE system runs without problems. > > > > I recall a discussion about merging Linux 2.6 kernel support into HEAD > > around the time I updated. Could this be related to that? Here is what > > I have for my Linux compat sysctls: > > > > compat.linux.oss_version: 198144 > > compat.linux.osrelease: 2.4.2 > > compat.linux.osname: Linux > > > > Is anyone else having this "syscall statfs64 not implemented" problem? > > yes, everyone. statfs64 syscalls is not implemented. > > I might implement if its important and you are willing to test. it should be > quite trivial but I need the testing. I guess I might be missing something subtle, here. Is there some kind of rewrite-from-scratch of the Linuxulator going on at the moment, because obviously the statfs64 syscall used to be implemented (until recently) in the i386 Linux kernel compat code, but now it has vanished? (Your response above makes it sound like it never was present at all.) Nevertheless, because it seems like statfs64 is vital to having the Tivoli Storage Manager client work (it just hangs around and the backup fails without it), then I figure at least I consider it "important" and, yes, I'd be willing to help test. :-) (Working backups are a good thing.:) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 03:30:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B64F16A4DF for ; Mon, 21 Aug 2006 03:30:42 +0000 (UTC) (envelope-from rnsanchez@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id A714243D55 for ; Mon, 21 Aug 2006 03:30:41 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1413442wxd for ; Sun, 20 Aug 2006 20:30:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=qJTyS54EXo+bESzxzcaVbZQtnQpRJm7CyQfynSVyMg/LpIaZ3jzfFNqtkE9OO1UbAI8Us4c5HPOr15rZL/+KrOhfwFlLZUZs9l/Qq0FQeVvCSykEX5jz6+madyo8Z+DTHjEBY9S/Ifdf+qcUVs10tV13k5HxPSf0LgBlTd7L55E= Received: by 10.70.69.2 with SMTP id r2mr8795410wxa; Sun, 20 Aug 2006 20:29:00 -0700 (PDT) Received: from sauron.lan.box ( [200.180.187.110]) by mx.gmail.com with ESMTP id 33sm1002392wra.2006.08.20.20.28.58; Sun, 20 Aug 2006 20:29:00 -0700 (PDT) Date: Mon, 21 Aug 2006 00:28:56 -0300 From: Ricardo Nabinger Sanchez To: freebsd-current@freebsd.org Message-Id: <20060821002856.601c8dfd.rnsanchez@gmail.com> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [RFC] (very) small ifmedia.c cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 03:30:42 -0000 Hello, I was looking at src/sbin/ifconfig/ifmedia.c source, and noticed that the handling of IFM_ETHER and IFM_ATM was identical. Also noticed the use of goto that, IMHO, could be clearer if made with a plain if (), very similar to the condition a few lines above each occurence of the gotos. Now I'm wondering if this diff looks good, as it is a first one I'm sending over here. The send-pr(1) seemed to be just too much noise, but if that's the correct way, please let me know. The diff is against -current. Index: src/sbin/ifconfig/ifmedia.c =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifmedia.c,v retrieving revision 1.20 diff -u -r1.20 ifmedia.c --- src/sbin/ifconfig/ifmedia.c 11 Jan 2006 22:37:59 -0000 1.20 +++ src/sbin/ifconfig/ifmedia.c 21 Aug 2006 03:16:44 -0000 @@ -145,6 +145,7 @@ if (ifmr.ifm_status & IFM_AVALID) { printf("\tstatus: "); switch (IFM_TYPE(ifmr.ifm_active)) { + case IFM_ATM: case IFM_ETHER: if (ifmr.ifm_status & IFM_ACTIVE) printf("active"); @@ -160,13 +161,6 @@ printf("no ring"); break; - case IFM_ATM: - if (ifmr.ifm_status & IFM_ACTIVE) - printf("active"); - else - printf("no carrier"); - break; - case IFM_IEEE80211: /* XXX: Different value for adhoc? */ if (ifmr.ifm_status & IFM_ACTIVE) @@ -692,14 +686,11 @@ /* Find subtype. */ desc = get_subtype_desc(ifmw, ttos); - if (desc != NULL) - goto got_subtype; - - /* Falling to here means unknown subtype. */ - printf(""); - return; + if (desc == NULL) { + printf(""); + return; + } - got_subtype: if (print_toptype) putchar(' '); @@ -750,14 +741,11 @@ /* Find subtype. */ desc = get_subtype_desc(ifmw, ttos); - if (desc != NULL) - goto got_subtype; - - /* Falling to here means unknown subtype. */ - printf(""); - return; + if (desc == NULL) { + printf(""); + return; + } - got_subtype: printf("media %s", desc->ifmt_string); desc = get_mode_desc(ifmw, ttos); Thanks in advance. ps: in case it is corrupted, it is also available at . -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 05:12:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B74F216A4DD; Mon, 21 Aug 2006 05:12:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6167C43D79; Mon, 21 Aug 2006 05:12:21 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7L5C7s6037188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 14:42:09 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Roman Kurakin Date: Mon, 21 Aug 2006 14:41:36 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> <200608201922.26864.doconnor@gsoft.com.au> <44E83900.4020108@inse.ru> In-Reply-To: <44E83900.4020108@inse.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6570041.IzQmpX71Z9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608211442.04551.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: Doug Barton , current@freebsd.org, Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 05:12:40 -0000 --nextPart6570041.IzQmpX71Z9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 19:57, Roman Kurakin wrote: > >Heh, well not necessarily although I personally would be shopping.. > > > >If the disk gets a dud sector and can't read it it won't remap it until > > you write to it. (I've seen this happen and someone else posted about it > > too) =20 > 1) So why not just dd seek=3Dxx count=3D1 to it to perform a write? > 2) Before some one would read it, some one should write to it... > Have I missed smth? 1) It's just swap, it's less thinking to nuke the whole partition 2) The command dd's from /dev/zero to the disk. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6570041.IzQmpX71Z9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE6UCk5ZPcIHs/zowRApM3AJ4hO82/OzuoPGkNfrF4UEWzR6F45gCfZy9+ pf0Vue45SlKbDUJPgcaZI4Q= =h7Cg -----END PGP SIGNATURE----- --nextPart6570041.IzQmpX71Z9-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 05:12:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B74F216A4DD; Mon, 21 Aug 2006 05:12:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6167C43D79; Mon, 21 Aug 2006 05:12:21 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7L5C7s6037188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 14:42:09 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Roman Kurakin Date: Mon, 21 Aug 2006 14:41:36 +0930 User-Agent: KMail/1.9.3 References: <44E77EF7.6070004@ngo.org.uk> <200608201922.26864.doconnor@gsoft.com.au> <44E83900.4020108@inse.ru> In-Reply-To: <44E83900.4020108@inse.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6570041.IzQmpX71Z9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608211442.04551.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: Doug Barton , current@freebsd.org, Nik Clayton , freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 05:12:40 -0000 --nextPart6570041.IzQmpX71Z9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 20 August 2006 19:57, Roman Kurakin wrote: > >Heh, well not necessarily although I personally would be shopping.. > > > >If the disk gets a dud sector and can't read it it won't remap it until > > you write to it. (I've seen this happen and someone else posted about it > > too) =20 > 1) So why not just dd seek=3Dxx count=3D1 to it to perform a write? > 2) Before some one would read it, some one should write to it... > Have I missed smth? 1) It's just swap, it's less thinking to nuke the whole partition 2) The command dd's from /dev/zero to the disk. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6570041.IzQmpX71Z9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBE6UCk5ZPcIHs/zowRApM3AJ4hO82/OzuoPGkNfrF4UEWzR6F45gCfZy9+ pf0Vue45SlKbDUJPgcaZI4Q= =h7Cg -----END PGP SIGNATURE----- --nextPart6570041.IzQmpX71Z9-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 05:44:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF7B616A4DA for ; Mon, 21 Aug 2006 05:44:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 4152243D5A for ; Mon, 21 Aug 2006 05:44:16 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 2399 invoked by uid 399); 21 Aug 2006 05:44:15 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 21 Aug 2006 05:44:15 -0000 Message-ID: <44E9482B.5030603@FreeBSD.org> Date: Sun, 20 Aug 2006 22:44:11 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Kevin Oberman References: <20060820205518.4C78E45042@ptavv.es.net> In-Reply-To: <20060820205518.4C78E45042@ptavv.es.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Daniel Eriksson Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 05:44:16 -0000 Kevin Oberman wrote: > There have been some excellent suggestions in this thread, but one simple > detail looks like it's been over-looked. > > If the disk has marked the sector as bad, which it should have, and it > there are redirection sectors available. a reboot is all that is > required. Not so much overlooked as ignored, methinks. :) If we wanted to reboot all the time, we would run windows. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 05:52:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8303216A4DD; Mon, 21 Aug 2006 05:52:01 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163CB43D46; Mon, 21 Aug 2006 05:52:01 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.51] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm29.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k7L5pr5x000647; Mon, 21 Aug 2006 01:51:54 -0400 Message-ID: <44E949E3.1060809@root.org> Date: Sun, 20 Aug 2006 22:51:31 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Vacation from FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 05:52:01 -0000 I'll be away from FreeBSD mail until October. Please direct questions to the lists and not to me directly. Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 06:49:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04CFE16A4DD for ; Mon, 21 Aug 2006 06:49:41 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3160743D45 for ; Mon, 21 Aug 2006 06:49:39 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.192] (enigma.cc.rsu.ru [195.208.252.192]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7L6nbvT027556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Aug 2006 10:49:38 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <44E9582C.2010400@rsu.ru> Date: Mon, 21 Aug 2006 10:52:28 +0400 From: Michael Bushkov User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Subject: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 06:49:41 -0000 Hi, First, thanks to all FreeBSD people and to Google for the great summer! As the SoC deadline has almost arrived, I'm glad to post most of this summer's work results. OpenLDAP + rewritten-from-scratch nss_ldap + nsswitch with separate shared nss-modules patch. Patch for -current: http://www.rsu.ru/~bushman/soc2006/openldap_merged.diff Nss_ldap was rewritten to be under BSD license and to support FreeBSD specific issues, like pw_class field of struct passwd. It supports rfc2307 and have nss_ldap.conf file similar to PADL's nss_ldap. To have it in the tree, OpenLDAP was also needed to be placed in the tree. Separation of nss-modules from libc makes libc more lightweight, and makes nsswitch much more general and flexible. It also adds the 'perform-actual-lookups' option support in the caching daemon (cached) for all nsswitch databases. From the developer point of view, one can effectively use nsdispatch(3) anywhere (not only in libc). That was impossible before. Nsswitch regression tools patch. Patch for -current: http://www.rsu.ru/~bushman/soc2006/regression.diff This is a set of regression tests, that check nsswitch functions (getpw***(), getgr**(), getserv**(), etc...) results for correctness. There is also a "snapshot" feature. You can, for example, make a snapshot of the "services" nsswitch database results on RELENG_6, and then check -CURRENT "services" sources implementation to be compatible with RELENG_6 implementation using this snapshot. Updated cached version with 'precache [cachename] yes|no' option added. Patch for -current: http://www.rsu.ru/~bushman/soc2006/cached.diff "precache [cachename] yes|no" option can be used for the particular cachename with "peform-actual-lookups" option and can significantly improve cached (and system) performance for huge databases like "services". Note: if the database is really huge, you should also set "keep-hot-count" option to the appropriate value. The detailed description of the above projects can be found here: http://wiki.freebsd.org/LdapCachedDetailedDescription I'll be glad to hear your comments and suggestions on these patches. Though, the SoC has almost ended, I will be able to steadily spend my time contributing to these projects and (hopefully) to something else. With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 07:19:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63AAD16A4DD for ; Mon, 21 Aug 2006 07:19:46 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060E343D55 for ; Mon, 21 Aug 2006 07:19:46 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id 5F4665C560; Mon, 21 Aug 2006 09:19:45 +0200 (CEST) Date: Mon, 21 Aug 2006 09:19:45 +0200 From: Thomas Quinot To: Ricardo Nabinger Sanchez Message-ID: <20060821071945.GA75839@melamine.cuivre.fr.eu.org> References: <20060821002856.601c8dfd.rnsanchez@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060821002856.601c8dfd.rnsanchez@gmail.com> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: [RFC] (very) small ifmedia.c cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 07:19:46 -0000 * Ricardo Nabinger Sanchez, 2006-08-21 : > I was looking at src/sbin/ifconfig/ifmedia.c source, and noticed that the > handling of IFM_ETHER and IFM_ATM was identical. Also noticed the use of > goto that, IMHO, could be clearer if made with a plain if (), very similar > to the condition a few lines above each occurence of the gotos. Looks good to me. The more factoring, the merrier! I think you could even push things a little further and aggressively factor what can be factored between print_media_word and print_media_word_ifconfig. > Now I'm wondering if this diff looks good, as it is a first one I'm sending > over here. The send-pr(1) seemed to be just too much noise, but if that's > the correct way, please let me know. The diff is against -current. It never hurts to submit a PR, it helps keeping track of the discussion of a patch, the commit, and any possible subsequent action. Thomas. From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 08:07:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5816A4DA for ; Mon, 21 Aug 2006 08:07:55 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 807FE43D46 for ; Mon, 21 Aug 2006 08:07:54 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7L87mxG014063 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Aug 2006 10:07:48 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7L87mHe014062; Mon, 21 Aug 2006 10:07:48 +0200 (CEST) Date: Mon, 21 Aug 2006 10:07:48 +0200 From: Divacky Roman To: Paul Mather Message-ID: <20060821080748.GA14037@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 08:07:55 -0000 On Sun, Aug 20, 2006 at 08:58:32PM -0400, Paul Mather wrote: > On Sun, 2006-08-20 at 22:43 +0200, Divacky Roman wrote: > > > On Sun, Aug 20, 2006 at 02:02:50PM -0400, Paul Mather wrote: > > > Since updating my -CURRENT system circa 16th August I'm getting an error > > > like this when my daily Tivoli backup runs: > > > > > > Aug 20 02:18:50 zappa kernel: linux: pid 768 (dsmc): syscall statfs64 not implemented > > > > > > I don't know whether this is a -CURRENT problem or a problem with > > > linux_base-fc4, but I lean towards the former because the same nightly > > > backup setup I'm running on a 6.1-STABLE system runs without problems. > > > > > > I recall a discussion about merging Linux 2.6 kernel support into HEAD > > > around the time I updated. Could this be related to that? Here is what > > > I have for my Linux compat sysctls: > > > > > > compat.linux.oss_version: 198144 > > > compat.linux.osrelease: 2.4.2 > > > compat.linux.osname: Linux > > > > > > Is anyone else having this "syscall statfs64 not implemented" problem? > > > > yes, everyone. statfs64 syscalls is not implemented. > > > > I might implement if its important and you are willing to test. it should be > > quite trivial but I need the testing. > > I guess I might be missing something subtle, here. Is there some kind > of rewrite-from-scratch of the Linuxulator going on at the moment, > because obviously the statfs64 syscall used to be implemented (until > recently) in the i386 Linux kernel compat code, but now it has vanished? > (Your response above makes it sound like it never was present at all.) the syscall was never presented > Nevertheless, because it seems like statfs64 is vital to having the > Tivoli Storage Manager client work (it just hangs around and the backup > fails without it), then I figure at least I consider it "important" and, > yes, I'd be willing to help test. :-) it seems like very trivial so expect patch today ;) From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 09:29:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C2CD16A4DD; Mon, 21 Aug 2006 09:29:06 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E78A43D45; Mon, 21 Aug 2006 09:29:04 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E1AD.dip.t-dialin.net [84.165.225.173]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7L9BdoH014669; Mon, 21 Aug 2006 11:11:40 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7L9T8hE051273; Mon, 21 Aug 2006 11:29:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 21 Aug 2006 11:29:07 +0200 Message-ID: <20060821112907.q4u7y5v1ckcowwwo@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 21 Aug 2006 11:29:07 +0200 From: Alexander Leidinger To: carl@UDel.Edu References: <20060820171244.BTA31151@ms1.nss.udel.edu> In-Reply-To: <20060820171244.BTA31151@ms1.nss.udel.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org, x11@freebsd.org Subject: Re: a problem setting screen resolution with Xorg-6.9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 09:29:06 -0000 Quoting carl@UDel.Edu (from Sun, 20 Aug 2006 17:12:44 -0400 (EDT)): > I originally sent this to FreeBSD-X11, but this may be a more > appropriate venue. No. x11@ is appropriate, (questions@ too I think). > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Modes "1280x1024" > EndSubSection > EndSection Bye, Alexander. -- Even though they raised the rate for first class mail in the United States we really shouldn't complain -- it's still only two cents a day. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 11:40:09 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E193216A4DE for ; Mon, 21 Aug 2006 11:40:09 +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 DFB3943D55 for ; Mon, 21 Aug 2006 11:40:08 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (sxeryj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k7LBe0uK027615; Mon, 21 Aug 2006 13:40: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 k7LBdskN027603; Mon, 21 Aug 2006 13:39:54 +0200 (CEST) (envelope-from olli) Date: Mon, 21 Aug 2006 13:39:54 +0200 (CEST) Message-Id: <200608211139.k7LBdskN027603@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, doconnor@gsoft.com.au, nik@ngo.org.uk In-Reply-To: X-Newsgroups: list.freebsd-current 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]); Mon, 21 Aug 2006 13:40:07 +0200 (CEST) Cc: Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, doconnor@gsoft.com.au, nik@ngo.org.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 11:40:10 -0000 Daniel O'Connor wrote: > Nik Clayton wrote: > > I realise that I need to replace the disk. However, while I'm waiting > > until I can schedule the downtime, is there a short term solution I can > > use to stop FreeBSD (I'm running current from a couple of months ago) > > from trying to use this block? > > Reboot into single user mode so swap is not being used and then try > dd if=/dev/zero of=/dev/XXX bs=64k > > (where XXX is your swapdev) I recommend also adding "conv=noerror" to the dd command, so it won't stop if an error occurs. 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. "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 13:46:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC87716A4DE for ; Mon, 21 Aug 2006 13:46:48 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C9F043D80 for ; Mon, 21 Aug 2006 13:46:42 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7LDkaWw027375 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Aug 2006 15:46:36 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7LDkZic027374; Mon, 21 Aug 2006 15:46:35 +0200 (CEST) Date: Mon, 21 Aug 2006 15:46:35 +0200 From: Divacky Roman To: Paul Mather Message-ID: <20060821134635.GA27362@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060821080748.GA14037@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 13:46:48 -0000 > it seems like very trivial so expect patch today ;) www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch pls tell me if this works, thnx From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 14:17:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FFF916A4E9; Mon, 21 Aug 2006 14:17:00 +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 A75E743DD2; Mon, 21 Aug 2006 14:16:24 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.6/8.13.6) with ESMTP id k7LEG7Vw088379; Mon, 21 Aug 2006 18:16:07 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 21 Aug 2006 18:16:07 +0400 (MSD) From: Dmitry Morozovsky To: Doug Barton In-Reply-To: <44E9482B.5030603@FreeBSD.org> Message-ID: <20060821181520.Y83770@woozle.rinet.ru> References: <20060820205518.4C78E45042@ptavv.es.net> <44E9482B.5030603@FreeBSD.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]); Mon, 21 Aug 2006 18:16:07 +0400 (MSD) Cc: freebsd-current@freebsd.org, Daniel Eriksson Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 14:17:00 -0000 On Sun, 20 Aug 2006, Doug Barton wrote: DB> > There have been some excellent suggestions in this thread, but one simple DB> > detail looks like it's been over-looked. DB> > DB> > If the disk has marked the sector as bad, which it should have, and it DB> > there are redirection sectors available. a reboot is all that is DB> > required. DB> DB> Not so much overlooked as ignored, methinks. :) If we wanted to reboot all DB> the time, we would run windows. Well, swapoff/swapon pair should do the trick avoiding reboot, unless swapoff deadlocked. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 14:32:36 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6965916A4E0; Mon, 21 Aug 2006 14:32:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6596943D4C; Mon, 21 Aug 2006 14:32:13 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k7LEW1Gp051088; Mon, 21 Aug 2006 18:32:01 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k7LEW0Tk051087; Mon, 21 Aug 2006 18:32:00 +0400 (MSD) (envelope-from yar) Date: Mon, 21 Aug 2006 18:32:00 +0400 From: Yar Tikhiy To: Pawel Jakub Dawidek Message-ID: <20060821143200.GB50800@comp.chem.msu.su> References: <20060818184656.GB16008@comp.chem.msu.su> <20060818191457.GA78998@xor.obsecurity.org> <20060818202508.GA88159@garage.freebsd.pl> <20060819070804.GA23066@comp.chem.msu.su> <20060820102405.GC1326@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060820102405.GC1326@garage.freebsd.pl> User-Agent: Mutt/1.5.9i Cc: current@FreeBSD.org, Kris Kennaway Subject: Re: mount * 2 + umount + lookup = GEOM panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 14:32:36 -0000 On Sun, Aug 20, 2006 at 12:24:05PM +0200, Pawel Jakub Dawidek wrote: > On Sat, Aug 19, 2006 at 11:08:05AM +0400, Yar Tikhiy wrote: > > On Fri, Aug 18, 2006 at 10:25:08PM +0200, Pawel Jakub Dawidek wrote: > > > No, it's difficult to solve in a architectural clean way, but IMHO this > > > bug should be fixed. I've a fix for this (which allows for multiple > > > read-only mounts). It's hackish, but works. > > > > > > Unfortunately phk@ didn't agree on committing it, so next time, please > > > CC him:) > > > > Just to satisfy my curiosity: Do you have references to a discussion > > of the problem? When such a simple script triggers an architectural > > issue, the latter is definitely worth taking a glance at. :-) > > I'm not sure if this was discussed in public. Anyway, the patch is here: > > http://people.freebsd.org/~pjd/patches/mro_mount.patch > > (I hope it is up-to-date). Works for me! That is, I can no longer reproduce the panic with it applied. I'm afraid I'm too ignorant to dig the patch though. -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 13:51:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AA6616A4E1 for ; Mon, 21 Aug 2006 13:51:07 +0000 (UTC) (envelope-from rtarrant@sympatico.ca) Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27F2F43D6B for ; Mon, 21 Aug 2006 13:51:05 +0000 (GMT) (envelope-from rtarrant@sympatico.ca) Received: from [192.168.55.4] ([64.230.35.51]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060821135104.GKPL29052.tomts13-srv.bellnexxia.net@[192.168.55.4]> for ; Mon, 21 Aug 2006 09:51:04 -0400 Message-ID: <44E9B88E.2020208@sympatico.ca> Date: Mon, 21 Aug 2006 09:43:42 -0400 From: Ron Tarrant User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Aug 2006 14:37:19 +0000 Subject: [patch] new moused and psm patchset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 13:51:07 -0000 Hi Jordan, I'm very interested in your work on the newmoused project. I have a set-up that just can't find psm0 (USB mouse with USB to PS/2 adaptor plugged into a 4-port KVM switch). When I tried to download the source from: www.semicomplete.com/blog/projects/newpsm/old/index.html I get a "the page you are looking for is not available" error. Would it be possible for you to either e-mail the source to me or point me at a site where I can download it? I'm using FBSD 6.1-RELEASE so I'm not sure I want to deal with the patch you've made available for 6.1-CURRENT. I'm guessing it will break something. Also, can I still follow the instructions you've outlined on the above-mentioned page for 6.1-RELEASE? Take care. -Ron T. -- Ron Tarrant Blog:PHP-Gtk2 From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 14:32:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76CCC16A4DE for ; Mon, 21 Aug 2006 14:32:07 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8082343D64 for ; Mon, 21 Aug 2006 14:31:54 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id 35C6D33C46; Mon, 21 Aug 2006 18:31:43 +0400 (MSD) Message-ID: <44E9C632.3020106@inse.ru> Date: Mon, 21 Aug 2006 18:41:54 +0400 From: Roman Kurakin User-Agent: Thunderbird 1.5.0.5 (X11/20060813) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20060820205518.4C78E45042@ptavv.es.net> <44E9482B.5030603@FreeBSD.org> <20060821181520.Y83770@woozle.rinet.ru> In-Reply-To: <20060821181520.Y83770@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Aug 2006 14:37:26 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Avoiding bad sectors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 14:32:07 -0000 Dmitry Morozovsky wrote: > On Sun, 20 Aug 2006, Doug Barton wrote: > > DB> > There have been some excellent suggestions in this thread, but one simple > DB> > detail looks like it's been over-looked. > DB> > > DB> > If the disk has marked the sector as bad, which it should have, and it > DB> > there are redirection sectors available. a reboot is all that is > DB> > required. > DB> > DB> Not so much overlooked as ignored, methinks. :) If we wanted to reboot all > DB> the time, we would run windows. > > Well, swapoff/swapon pair should do the trick avoiding reboot, unless swapoff > deadlocked. > How about creating a file and attach it as a swap as a short term solution? eq use smth instead of buggy swap partition, if it is impossible without swap. rik > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 15:55:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B51D16A4E0 for ; Mon, 21 Aug 2006 15:55:44 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (dsl081-142-072.chi1.dsl.speakeasy.net [64.81.142.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8149E43D53 for ; Mon, 21 Aug 2006 15:55:42 +0000 (GMT) (envelope-from derek@computinginnovations.com) Received: from p17.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.13.6/8.12.11) with ESMTP id k7LFtEFF012180; Mon, 21 Aug 2006 10:55:14 -0500 (CDT) Message-Id: <6.0.0.22.2.20060821105209.025a6870@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 21 Aug 2006 10:54:53 -0500 To: , freebsd-current@freebsd.org From: Derek Ragona In-Reply-To: <20060820171244.BTA31151@ms1.nss.udel.edu> References: <20060820171244.BTA31151@ms1.nss.udel.edu> Mime-Version: 1.0 X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: carl@UDel.Edu Subject: Re: a problem setting screen resolution with Xorg-6.9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 15:55:44 -0000 Run the text based xorgconfig and interactively set the values you want. -Derek At 04:12 PM 8/20/2006, carl@UDel.Edu wrote: >Fellow FreeBSDers, > >I originally sent this to FreeBSD-X11, but this may be a more appropriate >venue. > >I have recently installed FreeBSD 6.1 on a Pentium III box, using an >NVidia GeForce 2 GTS card and a CTX PL9 monitor. Running "X -configure" >as root generates the file xorg.conf.new, and then running "X -config >xorg.conf.new", pulls up a generic X screen with a resolution of >1600x1200. I go in and modify the xorg.conf.new file to make the default >resolution 1280x1024, and rerun "X -config xorg.conf.new", but the >resolution is still 1600x1200. This is a wonderful resolution, but it >makes everything rather small, and the icons are difficult to see. I am >obviously setting something wrong, but I do not know what it is. Might >anyone have any suggestions. I really would rather have the resolution be >1280x1024. Thanks for your help! > > >Carl > >The following is the file xorg.conf.new: > >Section "ServerLayout" > Identifier "X.org Configured" > Screen 0 "Screen0" 0 0 > InputDevice "Mouse0" "CorePointer" > InputDevice "Keyboard0" "CoreKeyboard" >EndSection > > >Section "Files" > RgbPath "/usr/X11R6/lib/X11/rgb" > ModulePath "/usr/X11R6/lib/modules" > FontPath "/usr/X11R6/lib/X11/fonts/misc/" > FontPath "/usr/X11R6/lib/X11/fonts/TTF/" > FontPath "/usr/X11R6/lib/X11/fonts/Type1/" > FontPath "/usr/X11R6/lib/X11/fonts/CID/" > FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" > FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" >EndSection > > >Section "Module" > Load "dbe" > Load "dri" > Load "extmod" > Load "glx" > Load "record" > Load "xtrap" > Load "freetype" > Load "type1" >EndSection > > >Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" >EndSection > > >Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" >EndSection > > >Section "Monitor" > #DisplaySize 360 270 # mm > Identifier "Monitor0" > VendorName "CTX" > ModelName "3700" > ### Comment all HorizSync and VertSync values to use DDC: > HorizSync 30.0 - 95.0 > VertRefresh 50.0 - 160.0 > Option "DPMS" >EndSection > > >Section "Device" > ### Available Driver options are:- > >### Values: : integer, : float, : "True"/"False", > ### : "String", : " Hz/kHz/MHz" > ### [arg]: arg optional > #Option "SWcursor" # [] > #Option "HWcursor" # [] > #Option "NoAccel" # [] > #Option "ShadowFB" # [] > #Option "UseFBDev" # [] > #Option "Rotate" # [] > #Option "VideoKey" # > #Option "FlatPanel" # [] > #Option "FPDither" # [] > #Option "CrtcNumber" # > #Option "FPScale" # [] > #Option "FPTweak" # > Identifier "Card0" > Driver "nv" > VendorName "nVidia Corporation" > BoardName "NV15 [GeForce2 GTS/Pro]" > BusID "PCI:1:0:0" >EndSection > > >Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 24 > Modes "1280x1024" > EndSubSection >EndSection > > > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. >MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 16:37:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ABB216A4DF for ; Mon, 21 Aug 2006 16:37:57 +0000 (UTC) (envelope-from rnsanchez@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72E0643D4C for ; Mon, 21 Aug 2006 16:37:56 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so263211wra for ; Mon, 21 Aug 2006 09:37:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=RuIcT4EkLrHZgG3v2XOwQ7ZSt1HAhYiiiGns1A2qNlaEDzQj+L3tYscaClRmIviGglo0wVpylOMxgL4gf+nnYIbTEQjTXwQE0szOBaLQghbUawhB3auZJ2P3kjJzGfybEMoRY05auKHGZe6hWOWiR6jgs2FUdxxzOL5LmdlJsE4= Received: by 10.90.105.19 with SMTP id d19mr176045agc; Mon, 21 Aug 2006 09:37:55 -0700 (PDT) Received: from sauron.lan.box ( [201.3.138.62]) by mx.gmail.com with ESMTP id 33sm249289wra.2006.08.21.09.37.54; Mon, 21 Aug 2006 09:37:55 -0700 (PDT) Date: Mon, 21 Aug 2006 13:37:50 -0300 From: Ricardo Nabinger Sanchez To: Thomas Quinot Message-Id: <20060821133750.ab3143a9.rnsanchez@gmail.com> In-Reply-To: <20060821071945.GA75839@melamine.cuivre.fr.eu.org> References: <20060821002856.601c8dfd.rnsanchez@gmail.com> <20060821071945.GA75839@melamine.cuivre.fr.eu.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [RFC] (very) small ifmedia.c cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 16:37:57 -0000 Hello, On Mon, 21 Aug 2006 09:19:45 +0200, Thomas Quinot wrote: > > I was looking at src/sbin/ifconfig/ifmedia.c source, and noticed that > > the handling of IFM_ETHER and IFM_ATM was identical. Also noticed the > > use of goto that, IMHO, could be clearer if made with a plain if (), > > very similar to the condition a few lines above each occurence of the > > gotos. > > Looks good to me. The more factoring, the merrier! I think you could even > push things a little further and aggressively factor what can be factored > between print_media_word and print_media_word_ifconfig. Thanks for your comments -- I'll surely check what can I do considering your suggestion, and this time will fill a PR. > > > Now I'm wondering if this diff looks good, as it is a first one I'm > > sending over here. The send-pr(1) seemed to be just too much noise, > > but if that's the correct way, please let me know. The diff is against > > -current. > > It never hurts to submit a PR, it helps keeping track of the discussion > of a patch, the commit, and any possible subsequent action. Then I'll submit a PR for this one. Thanks again :) -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Mon Aug 21 18:05:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53E2316A4DD for ; Mon, 21 Aug 2006 18:05:19 +0000 (UTC) (envelope-from fred.letter@lacave.net) Received: from talisker.lacave.net (talisker.lacave.net [217.145.39.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 24D3A43D79 for ; Mon, 21 Aug 2006 18:05:17 +0000 (GMT) (envelope-from fred.letter@lacave.net) Received: (qmail 54328 invoked from network); 21 Aug 2006 18:05:12 -0000 X-Spam-Score: -1.4/5.0 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on talisker.lacave.net X-Spam-Report: ALL_TRUSTED=-1.44,REPTO_OVERQUOTE_THEBAT=0 Received: from localhost (HELO GLENALLACHIE.local) (127.0.0.1) by talisker.lacave.net with SMTP; 21 Aug 2006 18:05:12 -0000 Date: Mon, 21 Aug 2006 20:05:11 +0200 From: "F. Senault" X-Mailer: The Bat! (v3.80.06) Professional Organization: Secte de l'Elephant Fuschia X-Priority: 3 (Normal) Message-ID: <368727378.20060821200511@lacave.net> To: ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanner: F-prot v4.6.5 (engine 3.16.13) X-Virus-Definitions: SIGN.DEF (20 August 2006), SIGN2.DEF (20 August 2006), MACRO.DEF (20 August 2006) X-Virus-Flag: NO X-Remote-IP: 127.0.0.1 Cc: current@freebsd.org Subject: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "F. Senault" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 18:05:19 -0000 Hi all. I mentioned on -current a time ago that I was ready to make a port out of Alistair G. Crooks' ISCSI-target implementation for NetBSD. It was four months ago, and I realize I hadn't had any time to spend on this project, and that it's not going to change in a near future. The core of the work is about done. The version I used probably needs to be updated, a tarball has to be made and uploaded, and the port has to be commited. If someone wants to step in and take the work in progress, I'll be glad to help if I can. Don't hesitate to send me a word. TIA, Fred (Crossposted on both -current where the first discussion took part in may, and -ports where it logically belongs.) -- Do you know how far this has gone ? Just how damaged have I become ? When I think I can overcome It runs even deeper Everything that matters is gone All the hands of hope have withdrawn Could you try to help me hang on ? (Nine Inch Nails, Even Deeper) From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 04:20:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CEE916A4DE for ; Tue, 22 Aug 2006 04:20:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D0D43D67 for ; Tue, 22 Aug 2006 04:20:40 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2686561pye for ; Mon, 21 Aug 2006 21:20:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=pDD5ji/+6OyqrjoURdZnSauWRqmpox1k/l9bFinLB+Bs5CnYg/XqGk7+q1WpaWPxePor8Mwve7rVMzwp6UFbB8MZc2VJ4qTV3dOAh4dlWTWBUd52Ryl7f7OLx98A0Qj4cZqgVd7ibnNXGTyGVLEwPSNrJ/DvFTn2jKrv+g2rQTs= Received: by 10.35.41.12 with SMTP id t12mr14692774pyj; Mon, 21 Aug 2006 21:20:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 17sm74932nzo.2006.08.21.21.20.39; Mon, 21 Aug 2006 21:20:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7M4KOSk014085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Aug 2006 13:20:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7M4KNYm014084 for freebsd-current@FreeBSD.org; Tue, 22 Aug 2006 13:20:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 22 Aug 2006 13:20:23 +0900 From: Pyun YongHyeon To: freebsd-current@FreeBSD.org Message-ID: <20060822042023.GC12848@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 04:20:48 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, After fixing em(4) watchdog bug, I looked over bge(4) and I think bge(4) may suffer from the same issue. So if you have seen occasional watchdog timeout errors on bge(4) please give the attached patch a try. The patch does fix false watchdog timeout error only. Typical pheonoma for false watchdog timeout error are o polling(4) fix the issue o random watchdog error If my patch fix the issue you could see the following messages. "missing Tx completion interrupt!" or "link lost -- resetting" Thanks. -- Regards, Pyun YongHyeon --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.watchdog.patch" Index: if_bge.c =================================================================== RCS file: /pool/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.138 diff -u -r1.138 if_bge.c --- if_bge.c 18 Aug 2006 13:53:53 -0000 1.138 +++ if_bge.c 22 Aug 2006 04:18:12 -0000 @@ -3452,12 +3452,29 @@ sc = ifp->if_softc; - if_printf(ifp, "watchdog timeout -- resetting\n"); + BGE_LOCK(sc); + /* + * Reclaim first as there is a possibility of losing Tx completion + * interrupts. Possible cause of missing Tx completion interrupts + * comes from Tx interrupt moderation mechanism(delayed interrupts) + * or chipset bug. + */ + bge_txeof(sc); + if (sc->bge_txcnt == 0) { + if_printf(ifp, "missing Tx completion interrupt!\n"); + BGE_UNLOCK(sc); + return; + } + if (sc->bge_link) + if_printf(ifp, "watchdog timeout -- resetting\n"); + else + if_printf(ifp, "link lost -- resetting\n"); ifp->if_drv_flags &= ~IFF_DRV_RUNNING; - bge_init(sc); + bge_init_locked(sc); ifp->if_oerrors++; + BGE_UNLOCK(sc); } /* --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 06:20:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF9216A584 for ; Tue, 22 Aug 2006 06:20:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90A5143D55 for ; Tue, 22 Aug 2006 06:20:20 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 01AC2EB3FD1; Tue, 22 Aug 2006 14:20:13 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id vpyUMhhsDjLY; Tue, 22 Aug 2006 14:20:06 +0800 (CST) Received: from [10.217.12.46] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A6CEAEB3EB7; Tue, 22 Aug 2006 14:20:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=cIlDBkMdXbMgh9+Z2g9am+jqp1rrtPmIIeu0DrYyqLbV9uIk1O3VG/l2DIqTiP8qq S3mP0EGK6KPcYkXGLvhZA== Message-ID: <44EAA213.6010507@delphij.net> Date: Tue, 22 Aug 2006 14:20:03 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Michael Bushkov References: <44E9582C.2010400@rsu.ru> In-Reply-To: <44E9582C.2010400@rsu.ru> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig2ED9353D8A09C512BA638595" Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 06:20:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2ED9353D8A09C512BA638595 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Bushkov wrote: > [snip] > OpenLDAP + rewritten-from-scratch nss_ldap + nsswitch with separate > shared nss-modules patch. > Patch for -current: > http://www.rsu.ru/~bushman/soc2006/openldap_merged.diff > Nss_ldap was rewritten to be under BSD license and to support FreeBSD > specific issues, like pw_class field of struct passwd. It supports > rfc2307 and have nss_ldap.conf file similar to PADL's nss_ldap. To > have it in the tree, OpenLDAP was also needed to be placed in the tree.= > Separation of nss-modules from libc makes libc more lightweight, and > makes nsswitch much more general and flexible. It also adds the > 'perform-actual-lookups' option support in the caching daemon (cached) > for all nsswitch databases. From the developer point of view, one can > effectively use nsdispatch(3) anywhere (not only in libc). That was > impossible before. Great work! Would you please consider having the imported OpenLDAP to install shared objects under alternative names? It might be painful for users who wants OpenLDAP installation from the ports collection (as OpenLDAP team moves fast and fixes bug from time to time) if they get a same library in /usr/lib... Cheers, --------------enig2ED9353D8A09C512BA638595 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6qITOfuToMruuMARA5TrAJ9TwMyjJ3hcrsGLrfHdNs/QQa39DwCeMCVI pD/VCvoJ3iib7z/JuqD+dyM= =P32B -----END PGP SIGNATURE----- --------------enig2ED9353D8A09C512BA638595-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 07:13:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AADC16A54D for ; Tue, 22 Aug 2006 07:13:12 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E00143D53 for ; Tue, 22 Aug 2006 07:13:10 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from carrera ([82.179.80.107]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7M7CnEG080394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 11:12:52 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <002901c6c5ba$628b67d0$9800a8c0@carrera> From: "Michael Bushkov" To: "LI Xin" References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> Date: Tue, 22 Aug 2006 11:12:40 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 07:13:12 -0000 Hi, Li Xin wrote: >Would you please consider having the imported OpenLDAP to install shared >objects under alternative names? It might be painful for users who >wants OpenLDAP installation from the ports collection (as OpenLDAP team >moves fast and fixes bug from time to time) if they get a same library >in /usr/lib... I've been thinking about that. Would names like "libldap_i.so" and "liblber_i.so" be ok ("_i" means "imported", or "internal")? With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 07:13:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E94C916A4E8 for ; Tue, 22 Aug 2006 07:13:12 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A2343D49 for ; Tue, 22 Aug 2006 07:13:12 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 16540984BC; Tue, 22 Aug 2006 09:13:11 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-7-64.dynamic.mnet-online.de [82.135.7.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.m-online.net (Postfix) with ESMTP id 096FE91F91; Tue, 22 Aug 2006 09:13:10 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.6/8.13.4/Submit) with ESMTP id k7M7DAoZ004018; Tue, 22 Aug 2006 09:13:10 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 22 Aug 2006 09:13:10 +0200 (CEST) From: Michael Reifenberger To: Pyun YongHyeon In-Reply-To: <20060822042023.GC12848@cdnetworks.co.kr> Message-ID: <20060822091107.A3909@fw.reifenberger.com> References: <20060822042023.GC12848@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 07:13:13 -0000 On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > After fixing em(4) watchdog bug, I looked over bge(4) and I think > bge(4) may suffer from the same issue. So if you have seen occasional > watchdog timeout errors on bge(4) please give the attached patch a try. Could this affect vge(4) too? I see occasionally: ... vge0: watchdog timeout vge0: link state changed to DOWN vge0: link state changed to UP ... Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 07:20:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEEBD16A4E2 for ; Tue, 22 Aug 2006 07:20:22 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id B954F43D78 for ; Tue, 22 Aug 2006 07:20:17 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 6CC59984FD; Tue, 22 Aug 2006 09:20:16 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-7-64.dynamic.mnet-online.de [82.135.7.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.m-online.net (Postfix) with ESMTP id 2EEF991FFC; Tue, 22 Aug 2006 09:20:15 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.6/8.13.4/Submit) with ESMTP id k7M7KFoW004042; Tue, 22 Aug 2006 09:20:15 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 22 Aug 2006 09:20:15 +0200 (CEST) From: Michael Reifenberger To: Michael Bushkov In-Reply-To: <002901c6c5ba$628b67d0$9800a8c0@carrera> Message-ID: <20060822091845.D3909@fw.reifenberger.com> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 07:20:23 -0000 On Tue, 22 Aug 2006, Michael Bushkov wrote: ... >> Would you please consider having the imported OpenLDAP to install shared >> objects under alternative names? It might be painful for users who >> wants OpenLDAP installation from the ports collection (as OpenLDAP team >> moves fast and fixes bug from time to time) if they get a same library >> in /usr/lib... > > I've been thinking about that. Would names like "libldap_i.so" and > "liblber_i.so" be ok ("_i" means "imported", or "internal")? > Or like our XML library(libbsdxml*): libbsdldab* Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 07:32:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1E5B16A4F8 for ; Tue, 22 Aug 2006 07:32:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81A6243DCD for ; Tue, 22 Aug 2006 07:32:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f25so2694813pyf for ; Tue, 22 Aug 2006 00:32:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=uXkngEMxCWFCmbEJHymk93SkURmczrUFSz8ZUJSd5d1vpPQoKbtcZCVEv4lSJQe+xEovMYWh8zPhRFP3ue3ozM1KFBrUApb7d/tim3UVh/bzCVENdeBOXofVk4gP0oqjUSsjRjZdv5Br8gVV4It0oKuUH6DHvrEOe31J6yoh4fA= Received: by 10.35.26.14 with SMTP id d14mr15025477pyj; Tue, 22 Aug 2006 00:32:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 8sm699480nzn.2006.08.22.00.32.19; Tue, 22 Aug 2006 00:32:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7M7W2Lu014765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 16:32:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7M7W1bG014764; Tue, 22 Aug 2006 16:32:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 22 Aug 2006 16:32:01 +0900 From: Pyun YongHyeon To: Michael Reifenberger Message-ID: <20060822073201.GI12848@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822091107.A3909@fw.reifenberger.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 07:32:46 -0000 On Tue, Aug 22, 2006 at 09:13:10AM +0200, Michael Reifenberger wrote: > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > >After fixing em(4) watchdog bug, I looked over bge(4) and I think > >bge(4) may suffer from the same issue. So if you have seen occasional > >watchdog timeout errors on bge(4) please give the attached patch a try. > > Could this affect vge(4) too? > I see occasionally: > ... > vge0: watchdog timeout > vge0: link state changed to DOWN > vge0: link state changed to UP > ... > I'm not familiar with vge(4) and don't have hardwares supported by vge(4). Because vge(4) supports a kind of interrupt moderation, there is a possiblity to have the same issue seen on em(4). If you want my blind patch I can send a patch for you. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 07:54:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E3416A4DF for ; Tue, 22 Aug 2006 07:54:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEC6A43D86 for ; Tue, 22 Aug 2006 07:54:17 +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 mail20.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k7M7rrZ7017846 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Aug 2006 17:53:54 +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 k7M7rraL001008; Tue, 22 Aug 2006 17:53:53 +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 k7M7rrmJ001007; Tue, 22 Aug 2006 17:53:53 +1000 (EST) (envelope-from peter) Date: Tue, 22 Aug 2006 17:53:53 +1000 From: Peter Jeremy To: LI Xin Message-ID: <20060822075353.GA743@turion.vk2pj.dyndns.org> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <44EAA213.6010507@delphij.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 07:54:40 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Aug-22 14:20:03 +0800, LI Xin wrote: >Would you please consider having the imported OpenLDAP to install shared >objects under alternative names? It might be painful for users who >wants OpenLDAP installation from the ports collection (as OpenLDAP team >moves fast and fixes bug from time to time) if they get a same library >in /usr/lib... I'll take an opposing view: If the two libraries are compatible, I believe they should have the same name. LD_LIBRARY_PATH, rpath and ldconfig can be used to control the search path if a particular .so variant is desired. One difficulty with changing the .so names is that (eg) configure scripts expect to find libraries under fixed names - if a package has 'foo' as a dependency, it will usually look for libfoo.{a,so} and generally won't have any way to say "use libfoo_i.{a,so} instead of libfoo.{a,so}". I'd also note that (eg) openssl exists in both the base system and ports without any obvious problems. --=20 Peter Jeremy --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE6rgR/opHv/APuIcRAtWOAKCaTqPem0jJYECBmspfitXKYZnfwgCgwUkU jBftJgfrlzAl1NbrHZHDap8= =36bJ -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 08:15:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D140E16A4DA for ; Tue, 22 Aug 2006 08:15:51 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id E62C543D45 for ; Tue, 22 Aug 2006 08:15:50 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 69301EB4148; Tue, 22 Aug 2006 16:15:46 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id jsWCONlNCmEf; Tue, 22 Aug 2006 16:15:39 +0800 (CST) Received: from [10.217.12.46] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id D8757EB3F89; Tue, 22 Aug 2006 16:15:38 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=I35kAFVYaDaQv4stGdDjMMBR6TUmiUC6fYVysuiBOqFJV1m5OLzjtGf9myZvt3Gv8 AY+LvbJbaDI6dqtNNvQHw== Message-ID: <44EABD26.9010803@delphij.net> Date: Tue, 22 Aug 2006 16:15:34 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Michael Bushkov References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> In-Reply-To: <002901c6c5ba$628b67d0$9800a8c0@carrera> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig81B5E39EFD83A6FEAC169946" Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 08:15:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81B5E39EFD83A6FEAC169946 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Bushkov wrote: > Hi, > Li Xin wrote: >> Would you please consider having the imported OpenLDAP to install shar= ed >> objects under alternative names? It might be painful for users who >> wants OpenLDAP installation from the ports collection (as OpenLDAP tea= m >> moves fast and fixes bug from time to time) if they get a same library= >> in /usr/lib... > > I've been thinking about that. Would names like "libldap_i.so" and > "liblber_i.so" be ok ("_i" means "imported", or "internal")? I am not an expert in this area :-) It seems that we call libxml "libbsdxml" in the base system, though. Consult -arch@ if you like. Cheers, --------------enig81B5E39EFD83A6FEAC169946 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6r0mOfuToMruuMARA/8rAJwJpiM6AcXJ38o90NKEt0dLqJKPbACfetPz CjlH8vybdZP6oEgCT8mv/2g= =Gv59 -----END PGP SIGNATURE----- --------------enig81B5E39EFD83A6FEAC169946-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 09:01:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63A2016A4DD for ; Tue, 22 Aug 2006 09:01:22 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C3C743D45 for ; Tue, 22 Aug 2006 09:01:20 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.131]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7M90lt6054083; Tue, 22 Aug 2006 13:00:58 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GFS6f-0000FX-KR; Tue, 22 Aug 2006 12:59:33 +0400 To: Peter Jeremy References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <20060822075353.GA743@turion.vk2pj.dyndns.org> From: Boris Samorodov Date: Tue, 22 Aug 2006 12:59:33 +0400 In-Reply-To: <20060822075353.GA743@turion.vk2pj.dyndns.org> (Peter Jeremy's message of "Tue, 22 Aug 2006 17:53:53 +1000") Message-ID: <02138042@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 09:01:22 -0000 On Tue, 22 Aug 2006 17:53:53 +1000 Peter Jeremy wrote: > On Tue, 2006-Aug-22 14:20:03 +0800, LI Xin wrote: > >Would you please consider having the imported OpenLDAP to install shared > >objects under alternative names? It might be painful for users who > >wants OpenLDAP installation from the ports collection (as OpenLDAP team > >moves fast and fixes bug from time to time) if they get a same library > >in /usr/lib... > I'll take an opposing view: If the two libraries are compatible, I > believe they should have the same name. LD_LIBRARY_PATH, rpath and > ldconfig can be used to control the search path if a particular .so > variant is desired. Using LD_LIBRARY_PATH may break some progs. Ex., when using linuxulator searching for the needed Linux libraries ends up with finding the FreeBSD ones. > One difficulty with changing the .so names is that (eg) configure > scripts expect to find libraries under fixed names - if a package > has 'foo' as a dependency, it will usually look for libfoo.{a,so} > and generally won't have any way to say "use libfoo_i.{a,so} instead > of libfoo.{a,so}". Can't those packages be suffixed, say libfoo[_i].{a,so} or else? > I'd also note that (eg) openssl exists in both the base system and > ports without any obvious problems. But using kerberos from ports with LDAP (having a kerberised host) is a real pain. Not to say about upgrading that system. Said that I'd like to show that the problem is complex one and it would be great to find the best way to solve it. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 10:45:38 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E08F16A4DD; Tue, 22 Aug 2006 10:45:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6514043D45; Tue, 22 Aug 2006 10:45:36 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CC7C45133B; Tue, 22 Aug 2006 12:45:34 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 77EAC5131F; Tue, 22 Aug 2006 12:45:27 +0200 (CEST) Date: Tue, 22 Aug 2006 12:45:16 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060822104516.GB16033@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org Subject: Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 10:45:38 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I started porting the ZFS file system to the FreeBSD operating system. There is a lot to do, but I'm making good progress, I think. I'm doing my work in those directories: contrib/opensolaris/ - userland files taken directly from OpenSolaris (libzfs, zpool, zfs and others) sys/contrib/opensolaris/ - kernel files taken directly from OpenSolaris (zfs, taskq, callb and others) compat/opensolaris/ - compatibility userland layer, so I can reduce diffs against vendor files sys/compat/opensolaris/ - compatibility kernel layer, so I can reduce diffs against vendor files (kmem based on malloc(9) and uma(9), mutexes based on our sx(9) locks, condvars based on sx(9) locks and more) cddl/ - FreeBSD specific makefiles for userland bits sys/modules/zfs/ - FreeBSD specific makefile for the kernel module You can find all those on FreeBSD perforce server: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/pjd/z= fs&HIDEDEL=3DNO Ok, so where am I? I ported the userland bits (libzfs, zfs and zpool). I had ztest and libzpool compiling and working as well, but I left them behind for now to focus on kernel bits. I'm building in all (except 2) files into zfs.ko (kernel module). I created new VDEV - vdev_geom, which fits to FreeBSD's GEOM infrastructure, so basically you can use any GEOM provider to build your ZFS pool. VDEV_GEOM is implemented as consumers-only GEOM class. I reimplemented ZVOL to also export storage as GEOM provider. This time it is providers-only GEOM class. This way one can create for example RAID-Z on top of GELI encrypted disks or encrypt ZFS volume. The order is free. Basically you can put UFS on ZFS volumes already and it behaves really stable even under heavy load. Currently I'm working on file system bits (ZPL), which is the most hard part of the entire ZFS port, because it talks to one of the most complex part of the FreeBSD kernel - VFS. I can already mount ZFS-created file systems (with 'zfs create' command), create files/directories, change permissions/owner/etc., list directories content, and perform few other minor operation. Some "screenshots": lcf:root:~# uname -a FreeBSD lcf 7.0-CURRENT FreeBSD 7.0-CURRENT #74: Tue Aug 22 03:04:01 UTC 2= 006 root@lcf:/usr/obj/zoo/pjd/lcf/sys/LCF i386 lcf:root:~# zpool create tank raidz /dev/ad4a /dev/ad6a /dev/ad5a lcf:root:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 35,8G 11,7M 35,7G 0% ONLINE - lcf:root:~# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4a ONLINE 0 0 0 ad6a ONLINE 0 0 0 ad5a ONLINE 0 0 0 errors: No known data errors lcf:root:# zfs create -V 10g tank/vol lcf:root:# newfs /dev/zvol/tank/vol lcf:root:# mount /dev/zvol/tank/vol /mnt/test lcf:root:# zfs create tank/fs lcf:root:~# mount -t zfs,ufs tank on /tank (zfs, local) tank/fs on /tank/fs (zfs, local) /dev/zvol/tank/vol on /mnt/test (ufs, local) lcf:root:~# df -ht zfs,ufs Filesystem Size Used Avail Capacity Mounted on tank 13G 34K 13G 0% /tank tank/fs 13G 33K 13G 0% /tank/fs /dev/zvol/tank/vol 9.7G 4.0K 8.9G 0% /mnt/test lcf:root:~# mkdir /tank/fs/foo lcf:root:~# touch /tank/fs/foo/bar lcf:root:~# chown root:operator /tank/fs/foo /tank/fs/foo/bar lcf:root:~# chmod 500 /tank/fs/foo lcf:root:~# ls -ld /tank/fs/foo /tank/fs/foo/bar dr-x------ 2 root operator 3 22 sie 05:41 /tank/fs/foo -rw-r--r-- 1 root operator 0 22 sie 05:42 /tank/fs/foo/bar The most important missing pieces: - Most of the ZPL layer. - Autoconfiguration. I need implement vdev discovery based on GEOM's taste mechanism. - .zfs/ control directory (entirely commented out for now). And many more, but hey, this is after 10 days of work. PS. Please contact me privately if your company would like to donate to the ZFS effort. Even without sponsorship the work will be finished, but your contributions will allow me to spend more time working on ZFS. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE6uA8ForvXbEpPzQRAr1vAJ0T/FHgwwNxWYXh3a3298DHiOTeiwCgh/NZ ixnrVrJZoTppOnLxNeAoGfM= =doT1 -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 10:57:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3737116A4DD for ; Tue, 22 Aug 2006 10:57:48 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6731C43D49 for ; Tue, 22 Aug 2006 10:57:47 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2818288pye for ; Tue, 22 Aug 2006 03:57:46 -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=i4Hg2s0OBkVZfE+ytVGmk4rpHMPSOv8T5qdR+iFxqLp++tc/RI9Yjn8WuXWVfdrXdCyyciLlMbnhQo55eQH3LaVz9GYYbxmU/m0Sh7+cLn3u0aMG32W+0FdFKrzfDqPPV8+33GHANksEe3eonLCGjm6r09WqfMTDXwtnYoQ6nWQ= Received: by 10.35.63.2 with SMTP id q2mr15311043pyk; Tue, 22 Aug 2006 03:57:46 -0700 (PDT) Received: by 10.35.114.2 with HTTP; Tue, 22 Aug 2006 03:57:46 -0700 (PDT) Message-ID: <70e8236f0608220357i22767c5dm239b36b10de2158b@mail.gmail.com> Date: Tue, 22 Aug 2006 11:57:46 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <20060822104516.GB16033@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060822104516.GB16033@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 10:57:48 -0000 On 8/22/06, Pawel Jakub Dawidek wrote: > Hi. > > I started porting the ZFS file system to the FreeBSD operating system. > > There is a lot to do, but I'm making good progress, I think. > > And many more, but hey, this is after 10 days of work. Impressive! I'm available for beta testing whenever you feel it's ready to. I also have a machine available if you need it. Very good work! :-) -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 12:04:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4381216A4DA for ; Tue, 22 Aug 2006 12:04:05 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F1A43DA8 for ; Tue, 22 Aug 2006 12:03:02 +0000 (GMT) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id k7MC12UK023768 for ; Tue, 22 Aug 2006 21:31:03 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 22 Aug 2006 21:32:53 +0930 Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au [131.185.2.170]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id k7MBwq700945 for ; Tue, 22 Aug 2006 21:28:52 +0930 (CST) Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC (6.0.3790.1830); Tue, 22 Aug 2006 21:28:52 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.13.7/8.13.7) with ESMTP id k7MBwW9G041860 for ; Tue, 22 Aug 2006 19:58:32 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.13.7/8.13.7/Submit) id k7MBwV8v041859 for freebsd-current@freebsd.org; Tue, 22 Aug 2006 19:58:31 +0800 (WST) (envelope-from wilkinsa) Date: Tue, 22 Aug 2006 19:58:31 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20060822115831.GS50133@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20060822104516.GB16033@garage.freebsd.pl> <70e8236f0608220357i22767c5dm239b36b10de2158b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <70e8236f0608220357i22767c5dm239b36b10de2158b@mail.gmail.com> User-Agent: Mutt/1.5.12-2006-07-14 X-OriginalArrivalTime: 22 Aug 2006 11:58:52.0249 (UTC) FILETIME=[55FBE490:01C6C5E2] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14642.003 X-TM-AS-Result: No--6.047400-0.000000-31 Subject: Re: Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 12:04:05 -0000 0n Tue, Aug 22, 2006 at 11:57:46AM +0100, Joao Barros wrote: >On 8/22/06, Pawel Jakub Dawidek wrote: >>Hi. >> >>I started porting the ZFS file system to the FreeBSD operating system. >> >>There is a lot to do, but I'm making good progress, I think. >> >>And many more, but hey, this is after 10 days of work. > >Impressive! >I'm available for beta testing whenever you feel it's ready to. >I also have a machine available if you need it. ditto ! -aW From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 12:44:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3342416A4DE for ; Tue, 22 Aug 2006 12:44:45 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43CA43D70 for ; Tue, 22 Aug 2006 12:44:36 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 26C6473F6D; Tue, 22 Aug 2006 14:44:35 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-7-64.dynamic.mnet-online.de [82.135.7.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.m-online.net (Postfix) with ESMTP id F217991C24; Tue, 22 Aug 2006 14:44:34 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.6/8.13.4/Submit) with ESMTP id k7MCiYkK005579; Tue, 22 Aug 2006 14:44:34 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 22 Aug 2006 14:44:34 +0200 (CEST) From: Michael Reifenberger To: Pyun YongHyeon In-Reply-To: <20060822073201.GI12848@cdnetworks.co.kr> Message-ID: <20060822144341.L5561@fw.reifenberger.com> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 12:44:45 -0000 On Tue, 22 Aug 2006, Pyun YongHyeon wrote: ... > I'm not familiar with vge(4) and don't have hardwares supported by > vge(4). Because vge(4) supports a kind of interrupt moderation, there > is a possiblity to have the same issue seen on em(4). > If you want my blind patch I can send a patch for you. > Yes, please! I can test it (on RELENG_6 though). Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:30:10 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BCB016A52F; Tue, 22 Aug 2006 14:30:10 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E14C543D73; Tue, 22 Aug 2006 14:30:08 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id BB7649132B; Tue, 22 Aug 2006 16:30:07 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id C8A329C46F; Tue, 22 Aug 2006 14:30:44 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id BF0B9405B; Tue, 22 Aug 2006 16:30:44 +0200 (CEST) Date: Tue, 22 Aug 2006 16:30:44 +0200 From: Jeremie Le Hen To: Pawel Jakub Dawidek Message-ID: <20060822143044.GD58048@obiwan.tataz.chchile.org> References: <20060822104516.GB16033@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822104516.GB16033@garage.freebsd.pl> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:30:10 -0000 Hi Pawel, On Tue, Aug 22, 2006 at 12:45:16PM +0200, Pawel Jakub Dawidek wrote: > I started porting the ZFS file system to the FreeBSD operating system. First, thank you for working on this. I must admit I am quite impressed by the amount of work you've achieved this last months, you are really a coding machine. I don't say others have done less, but maybe I am simply not smart enough to estimate their work. I don't know much about ZFS, but Sun states this is a "128 bits" filesystem. How will you handle this in regards to the FreeBSD kernel interface that is already struggling to be 64 bits compliant ? (I'm stating this based on this URL [1], but maybe it's not fully up-to-date.) [1] http://www.freebsd.org/projects/bigdisk/index.html Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:36:40 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9768916A4DF; Tue, 22 Aug 2006 14:36:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA5D43D49; Tue, 22 Aug 2006 14:36:39 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4C7ED51397; Tue, 22 Aug 2006 16:36:37 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 53D8D51391; Tue, 22 Aug 2006 16:36:31 +0200 (CEST) Date: Tue, 22 Aug 2006 16:36:19 +0200 From: Pawel Jakub Dawidek To: Jeremie Le Hen Message-ID: <20060822143619.GG16033@garage.freebsd.pl> References: <20060822104516.GB16033@garage.freebsd.pl> <20060822143044.GD58048@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KIzF6Cje4W/osXrF" Content-Disposition: inline In-Reply-To: <20060822143044.GD58048@obiwan.tataz.chchile.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:36:40 -0000 --KIzF6Cje4W/osXrF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: > I don't know much about ZFS, but Sun states this is a "128 bits" > filesystem. How will you handle this in regards to the FreeBSD > kernel interface that is already struggling to be 64 bits > compliant ? (I'm stating this based on this URL [1], but maybe > it's not fully up-to-date.) 128 bits is not my goal, but I do want all the other goodies:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --KIzF6Cje4W/osXrF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE6xZjForvXbEpPzQRAoyyAJ9C7jHBvUhrZ/nwBxF84+ir/IiETgCeJPsn ROYooOKJTwdQhVzbyLYRTh0= =tWfl -----END PGP SIGNATURE----- --KIzF6Cje4W/osXrF-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:39:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95BFB16A4E2 for ; Tue, 22 Aug 2006 14:39:29 +0000 (UTC) (envelope-from dan.cojocar@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E02A43D55 for ; Tue, 22 Aug 2006 14:39:26 +0000 (GMT) (envelope-from dan.cojocar@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so76051nfc for ; Tue, 22 Aug 2006 07:39:25 -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=mcyDluvnLR8ACpfRNJer5wM0oGj3EiXr2aqVUczxcRsH7HLuKmWk5AERd80Ir5mo8CmIjaJPD6/nU+hdri5EVh8Yj0RtUjJfNojweB8Vza0pks9TszFWfiulTuOKjiTY4gU+lIMV/pCbSs/oygdIDjRwHFx+pV6xMgOmZ6SR6D8= Received: by 10.49.94.20 with SMTP id w20mr505834nfl; Tue, 22 Aug 2006 07:39:25 -0700 (PDT) Received: by 10.78.150.6 with HTTP; Tue, 22 Aug 2006 07:39:25 -0700 (PDT) Message-ID: Date: Tue, 22 Aug 2006 17:39:25 +0300 From: "Dan Cojocar" To: "Pawel Jakub Dawidek" In-Reply-To: <20060822104516.GB16033@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060822104516.GB16033@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:39:29 -0000 On 8/22/06, Pawel Jakub Dawidek wrote: > Hi. > > I started porting the ZFS file system to the FreeBSD operating system. > > There is a lot to do, but I'm making good progress, I think. > > I'm doing my work in those directories: > > contrib/opensolaris/ - userland files taken directly from > OpenSolaris (libzfs, zpool, zfs and others) > > sys/contrib/opensolaris/ - kernel files taken directly from > OpenSolaris (zfs, taskq, callb and others) > > compat/opensolaris/ - compatibility userland layer, so I can > reduce diffs against vendor files > > sys/compat/opensolaris/ - compatibility kernel layer, so I can > reduce diffs against vendor files (kmem based on > malloc(9) and uma(9), mutexes based on our sx(9) locks, > condvars based on sx(9) locks and more) > > cddl/ - FreeBSD specific makefiles for userland bits > > sys/modules/zfs/ - FreeBSD specific makefile for the kernel > module > > You can find all those on FreeBSD perforce server: > > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/zfs&HIDEDEL=NO > > Ok, so where am I? > > I ported the userland bits (libzfs, zfs and zpool). I had ztest and > libzpool compiling and working as well, but I left them behind for now > to focus on kernel bits. > > I'm building in all (except 2) files into zfs.ko (kernel module). > > I created new VDEV - vdev_geom, which fits to FreeBSD's GEOM > infrastructure, so basically you can use any GEOM provider to build your > ZFS pool. VDEV_GEOM is implemented as consumers-only GEOM class. > > I reimplemented ZVOL to also export storage as GEOM provider. This time > it is providers-only GEOM class. > > This way one can create for example RAID-Z on top of GELI encrypted > disks or encrypt ZFS volume. The order is free. > Basically you can put UFS on ZFS volumes already and it behaves really > stable even under heavy load. > > Currently I'm working on file system bits (ZPL), which is the most hard > part of the entire ZFS port, because it talks to one of the most complex > part of the FreeBSD kernel - VFS. > > I can already mount ZFS-created file systems (with 'zfs create' > command), create files/directories, change permissions/owner/etc., list > directories content, and perform few other minor operation. > > Some "screenshots": > > lcf:root:~# uname -a > FreeBSD lcf 7.0-CURRENT FreeBSD 7.0-CURRENT #74: Tue Aug 22 03:04:01 UTC 2006 root@lcf:/usr/obj/zoo/pjd/lcf/sys/LCF i386 > > lcf:root:~# zpool create tank raidz /dev/ad4a /dev/ad6a /dev/ad5a > > lcf:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 35,8G 11,7M 35,7G 0% ONLINE - > > lcf:root:~# zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad4a ONLINE 0 0 0 > ad6a ONLINE 0 0 0 > ad5a ONLINE 0 0 0 > > errors: No known data errors > > lcf:root:# zfs create -V 10g tank/vol > lcf:root:# newfs /dev/zvol/tank/vol > lcf:root:# mount /dev/zvol/tank/vol /mnt/test > > lcf:root:# zfs create tank/fs > > lcf:root:~# mount -t zfs,ufs > tank on /tank (zfs, local) > tank/fs on /tank/fs (zfs, local) > /dev/zvol/tank/vol on /mnt/test (ufs, local) > > lcf:root:~# df -ht zfs,ufs > Filesystem Size Used Avail Capacity Mounted on > tank 13G 34K 13G 0% /tank > tank/fs 13G 33K 13G 0% /tank/fs > /dev/zvol/tank/vol 9.7G 4.0K 8.9G 0% /mnt/test > > lcf:root:~# mkdir /tank/fs/foo > lcf:root:~# touch /tank/fs/foo/bar > lcf:root:~# chown root:operator /tank/fs/foo /tank/fs/foo/bar > lcf:root:~# chmod 500 /tank/fs/foo > lcf:root:~# ls -ld /tank/fs/foo /tank/fs/foo/bar > dr-x------ 2 root operator 3 22 sie 05:41 /tank/fs/foo > -rw-r--r-- 1 root operator 0 22 sie 05:42 /tank/fs/foo/bar > > The most important missing pieces: > - Most of the ZPL layer. > - Autoconfiguration. I need implement vdev discovery based on GEOM's taste > mechanism. > - .zfs/ control directory (entirely commented out for now). > And many more, but hey, this is after 10 days of work. > > PS. Please contact me privately if your company would like to donate to the > ZFS effort. Even without sponsorship the work will be finished, but > your contributions will allow me to spend more time working on ZFS. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > > Hello Pawel, Thank you for your work. When will you release a patch so we can test this? Thanks, Dan From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:42:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C4116A4DD; Tue, 22 Aug 2006 14:42:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70EAA43D6A; Tue, 22 Aug 2006 14:42:43 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 40F645139A; Tue, 22 Aug 2006 16:42:42 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 90F975133B; Tue, 22 Aug 2006 16:42:37 +0200 (CEST) Date: Tue, 22 Aug 2006 16:42:26 +0200 From: Pawel Jakub Dawidek To: Dan Cojocar Message-ID: <20060822144226.GH16033@garage.freebsd.pl> References: <20060822104516.GB16033@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGu/vTNewDGZ7tmp" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:42:44 -0000 --MGu/vTNewDGZ7tmp Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2006 at 05:39:25PM +0300, Dan Cojocar wrote: > When will you release a patch so we can test this? Sure, when it will be ready for testing:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --MGu/vTNewDGZ7tmp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE6xfSForvXbEpPzQRAvrRAJ0cbwhdsdWys02SJ4g/faSH5YYxcACfWA3T pBWI4gm4trHAtVBhae376JU= =MoM7 -----END PGP SIGNATURE----- --MGu/vTNewDGZ7tmp-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:45:57 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1766C16A4DE; Tue, 22 Aug 2006 14:45:57 +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 69DAB43D77; Tue, 22 Aug 2006 14:45:56 +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 4CBCE1A3C2F; Tue, 22 Aug 2006 07:45:56 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AB4A951305; Tue, 22 Aug 2006 10:45:55 -0400 (EDT) Date: Tue, 22 Aug 2006 10:45:55 -0400 From: Kris Kennaway To: Jeremie Le Hen Message-ID: <20060822144555.GA74174@xor.obsecurity.org> References: <20060822104516.GB16033@garage.freebsd.pl> <20060822143044.GD58048@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20060822143044.GD58048@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:45:57 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: > Hi Pawel, >=20 > On Tue, Aug 22, 2006 at 12:45:16PM +0200, Pawel Jakub Dawidek wrote: > > I started porting the ZFS file system to the FreeBSD operating system. >=20 > First, thank you for working on this. I must admit I am quite impressed > by the amount of work you've achieved this last months, you are really a > coding machine. I don't say others have done less, but maybe I am > simply not smart enough to estimate their work. >=20 > I don't know much about ZFS, but Sun states this is a "128 bits" > filesystem. How will you handle this in regards to the FreeBSD > kernel interface that is already struggling to be 64 bits > compliant ? (I'm stating this based on this URL [1], but maybe > it's not fully up-to-date.) >=20 > [1] http://www.freebsd.org/projects/bigdisk/index.html Actually if you read that URL then it shows that it's only some userland tools + secondary UFS features that do not handle 64-bit filesystem sizes in FreeBSD. Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE6xijWry0BWjoQKURArtHAKDNVYsqnCh1wI8hPHQbSMl8DW6VcgCgtVM1 ooJ/g3rG17jXaAgGnlRcKXE= =/iEZ -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 15:18:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 164E016A4E2 for ; Tue, 22 Aug 2006 15:18:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A58943D55 for ; Tue, 22 Aug 2006 15:18:47 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 199E220A6; Tue, 22 Aug 2006 17:18:40 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id F3F6B20A5; Tue, 22 Aug 2006 17:18:39 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 6285033C24; Tue, 22 Aug 2006 17:18:39 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Michael Bushkov" References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> Date: Tue, 22 Aug 2006 17:18:39 +0200 In-Reply-To: <002901c6c5ba$628b67d0$9800a8c0@carrera> (Michael Bushkov's message of "Tue, 22 Aug 2006 11:12:40 +0400") Message-ID: <86hd0423zk.fsf@xps.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 15:18:56 -0000 "Michael Bushkov" writes: > Li Xin wrote: > > Would you please consider having the imported OpenLDAP to install > > shared objects under alternative names? It might be painful for > > users who wants OpenLDAP installation from the ports collection > > (as OpenLDAP team moves fast and fixes bug from time to time) if > > they get a same library in /usr/lib... > I've been thinking about that. Would names like "libldap_i.so" and > "liblber_i.so" be ok ("_i" means "imported", or "internal")? Please don't. If somebody isn't happy with the base system's libldap, they can add WITHOUT_LDAP to their make.conf. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 14:43:02 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2351116A506; Tue, 22 Aug 2006 14:43:02 +0000 (UTC) (envelope-from Michael.Schuster@Sun.COM) Received: from gmpea-pix-1.sun.com (gmpea-pix-1.sun.com [192.18.1.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA9A43D7B; Tue, 22 Aug 2006 14:43:00 +0000 (GMT) (envelope-from Michael.Schuster@Sun.COM) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MEgx1J020119; Tue, 22 Aug 2006 15:42:59 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4E00E01M486A00@d1-emea-09.sun.com> (original mail from Michael.Schuster@Sun.COM); Tue, 22 Aug 2006 15:42:59 +0100 (BST) Received: from [129.157.133.195] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4E00M5ZM7L3E1S@d1-emea-09.sun.com>; Tue, 22 Aug 2006 15:42:58 +0100 (BST) Date: Tue, 22 Aug 2006 16:42:57 +0200 From: Michael Schuster - Sun Microsystems In-reply-to: <20060822143619.GG16033@garage.freebsd.pl> Sender: Michael.Schuster@Sun.COM To: Pawel Jakub Dawidek Message-id: <44EB17F1.7070407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20060822104516.GB16033@garage.freebsd.pl> <20060822143044.GD58048@obiwan.tataz.chchile.org> <20060822143619.GG16033@garage.freebsd.pl> User-Agent: Thunderbird 1.5.0.2 (X11/20060602) X-Mailman-Approved-At: Tue, 22 Aug 2006 16:22:40 +0000 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: [zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 14:43:02 -0000 Pawel Jakub Dawidek wrote: > On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: >> I don't know much about ZFS, but Sun states this is a "128 bits" >> filesystem. How will you handle this in regards to the FreeBSD >> kernel interface that is already struggling to be 64 bits >> compliant ? (I'm stating this based on this URL [1], but maybe >> it's not fully up-to-date.) > > 128 bits is not my goal, but I do want all the other goodies:) are you going to attempt on-disk compatibility? Michael -- Michael Schuster +49 89 46008-2974 / x62974 visit the online support center: http://www.sun.com/osc/ Recursion, n.: see 'Recursion' From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 15:11:11 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ECE416A4DA; Tue, 22 Aug 2006 15:11:11 +0000 (UTC) (envelope-from eschrock@zion.eng.sun.com) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2651643D72; Tue, 22 Aug 2006 15:11:07 +0000 (GMT) (envelope-from eschrock@zion.eng.sun.com) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MFB7Gm013675; Tue, 22 Aug 2006 09:11:07 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7MFB7IP007028; Tue, 22 Aug 2006 08:11:07 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7MFB77t014822; Tue, 22 Aug 2006 08:11:07 -0700 (PDT) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id k7MFB7Sf014821; Tue, 22 Aug 2006 08:11:07 -0700 (PDT) Date: Tue, 22 Aug 2006 08:11:07 -0700 From: Eric Schrock To: Michael Schuster - Sun Microsystems Message-ID: <20060822151107.GA13426@eng.sun.com> References: <20060822104516.GB16033@garage.freebsd.pl> <20060822143044.GD58048@obiwan.tataz.chchile.org> <20060822143619.GG16033@garage.freebsd.pl> <44EB17F1.7070407@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EB17F1.7070407@sun.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 22 Aug 2006 16:23:07 +0000 Cc: freebsd-fs@FreeBSD.org, Jeremie Le Hen , zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: [zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 15:11:11 -0000 On Tue, Aug 22, 2006 at 04:42:57PM +0200, Michael Schuster - Sun Microsystems wrote: > Pawel Jakub Dawidek wrote: > >On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: > >>I don't know much about ZFS, but Sun states this is a "128 bits" > >>filesystem. How will you handle this in regards to the FreeBSD > >>kernel interface that is already struggling to be 64 bits > >>compliant ? (I'm stating this based on this URL [1], but maybe > >>it's not fully up-to-date.) > > > >128 bits is not my goal, but I do want all the other goodies:) > > are you going to attempt on-disk compatibility? Please note that the '128-bitness' of ZFS currently only comes into play in the on-disk format, and the allowed size of the storage pool. This should be very easy to maintain compatability with. However, each filesystem is currently limited to 64-bits, due largely to the lack of 128-bit support in the POSIX interfaces. So there's very little 128-bit code floating around except at the SPA layer, and as long as you have an unsigned 64-bit type there shouldn't be any problems at higher layers. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 16:02:17 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFF5D16A4DD; Tue, 22 Aug 2006 16:02:17 +0000 (UTC) (envelope-from Mark.Maybee@Sun.COM) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE1C43D6D; Tue, 22 Aug 2006 16:02:11 +0000 (GMT) (envelope-from Mark.Maybee@Sun.COM) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MG2B65027098; Tue, 22 Aug 2006 10:02:11 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4E00B01PT71X00@mail-amer.sun.com> (original mail from Mark.Maybee@Sun.COM); Tue, 22 Aug 2006 10:02:11 -0600 (MDT) Received: from [192.168.0.100] ([199.45.247.21]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4E00ESKPVLSUZN@mail-amer.sun.com>; Tue, 22 Aug 2006 10:02:11 -0600 (MDT) Date: Tue, 22 Aug 2006 10:02:09 -0600 From: Mark Maybee In-reply-to: <44EB17F1.7070407@sun.com> Sender: Mark.Maybee@Sun.COM To: Pawel Jakub Dawidek Message-id: <44EB2A81.9050300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <20060822104516.GB16033@garage.freebsd.pl> <20060822143044.GD58048@obiwan.tataz.chchile.org> <20060822143619.GG16033@garage.freebsd.pl> <44EB17F1.7070407@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Mailman-Approved-At: Tue, 22 Aug 2006 16:23:17 +0000 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Jeremie Le Hen , Michael Schuster - Sun Microsystems Subject: Re: [zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 16:02:18 -0000 Michael Schuster - Sun Microsystems wrote: > Pawel Jakub Dawidek wrote: > >> On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: >> >>> I don't know much about ZFS, but Sun states this is a "128 bits" >>> filesystem. How will you handle this in regards to the FreeBSD >>> kernel interface that is already struggling to be 64 bits >>> compliant ? (I'm stating this based on this URL [1], but maybe >>> it's not fully up-to-date.) >> >> >> 128 bits is not my goal, but I do want all the other goodies:) > > > are you going to attempt on-disk compatibility? > > Michael Amazing work Pawel! Please do try to maintain on-disk compatibility! Let us know if you run into anything that might prevent that (or any other issues that you run across). -Mark From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 16:23:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 206B716A5AC for ; Tue, 22 Aug 2006 16:23:57 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FA9343D76 for ; Tue, 22 Aug 2006 16:23:51 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.192] (enigma.cc.rsu.ru [195.208.252.192]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7MGNJg2069309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Aug 2006 20:23:24 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <44EB302A.7010106@rsu.ru> Date: Tue, 22 Aug 2006 20:26:18 +0400 From: Michael Bushkov User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> In-Reply-To: <86hd0423zk.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 16:23:57 -0000 Dag-Erling Smørgrav wrote: >"Michael Bushkov" writes: > > >>Li Xin wrote: >> >> >>>Would you please consider having the imported OpenLDAP to install >>>shared objects under alternative names? It might be painful for >>>users who wants OpenLDAP installation from the ports collection >>>(as OpenLDAP team moves fast and fixes bug from time to time) if >>>they get a same library in /usr/lib... >>> >>> >>I've been thinking about that. Would names like "libldap_i.so" and >>"liblber_i.so" be ok ("_i" means "imported", or "internal")? >> >> > >Please don't. If somebody isn't happy with the base system's libldap, >they can add WITHOUT_LDAP to their make.conf. > >DES > > This issue turned to be more complex than I originally expected. I believe that "not having 2 different entities in the system, that do the same thing" is the good rule. So maybe, leaving libldap.so(a) in /usr/lib is not an absolutely good decision. But renaming libldap to some other name and leaving it there (and enforcing everything beside the base system to use almost the same ports' libldap) is probably much more worse. So, after all, I'd prefer to leave libldap (and nss_ldap, which can also conflict with PADL's nss_ldap) as is and let users use WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 16:30:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6A3216A4DA for ; Tue, 22 Aug 2006 16:30:58 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBAC43D46 for ; Tue, 22 Aug 2006 16:30:58 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2936572pye for ; Tue, 22 Aug 2006 09:30:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QUngFLiN/m53t2kHRsKe5MCB2hj5oyJzZ1t92mAtppO5m91VUyZj+Sqszjg3LSUH+6TUyzdE7VNueRc49QTlcPLC51u8mBNm0DTZkg9qGNTS81358PTwQ0qzWIlEIMZBJbQvhfZVyjch1haAZEymi9bxWhpQvv1vVz9GIVdSUuQ= Received: by 10.35.51.19 with SMTP id d19mr10095887pyk; Tue, 22 Aug 2006 09:30:57 -0700 (PDT) Received: by 10.35.61.12 with HTTP; Tue, 22 Aug 2006 09:30:56 -0700 (PDT) Message-ID: Date: Wed, 23 Aug 2006 00:30:56 +0800 From: "Xin LI" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86hd0423zk.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> Cc: freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 16:30:58 -0000 On 8/22/06, Dag-Erling Sm=F8rgrav wrote: > "Michael Bushkov" writes: > > Li Xin wrote: > > > Would you please consider having the imported OpenLDAP to install > > > shared objects under alternative names? It might be painful for > > > users who wants OpenLDAP installation from the ports collection > > > (as OpenLDAP team moves fast and fixes bug from time to time) if > > > they get a same library in /usr/lib... > > I've been thinking about that. Would names like "libldap_i.so" and > > "liblber_i.so" be ok ("_i" means "imported", or "internal")? > > Please don't. If somebody isn't happy with the base system's libldap, > they can add WITHOUT_LDAP to their make.conf. Fair to me. I think this is a better solution for the issue. Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 20:43:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0519816A4E1 for ; Tue, 22 Aug 2006 20:43:52 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id A50D843D6E for ; Tue, 22 Aug 2006 20:43:44 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7MKhguV009536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 00:43:42 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7MKhgfb009535; Wed, 23 Aug 2006 00:43:42 +0400 (MSD) (envelope-from oleg) Date: Wed, 23 Aug 2006 00:43:42 +0400 From: Oleg Bulyzhin To: Michael Reifenberger Message-ID: <20060822204342.GA4943@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20060822144341.L5561@fw.reifenberger.com> User-Agent: Mutt/1.5.11 Cc: Pyun YongHyeon , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 20:43:52 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > ... > >I'm not familiar with vge(4) and don't have hardwares supported by > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > >is a possiblity to have the same issue seen on em(4). > >If you want my blind patch I can send a patch for you. > > > Yes, please! > I can test it (on RELENG_6 though). I have an idea why those timeouts can happen. Could you please test attached patch? It may help (or may not). Anyway would be fine to know results. > > Bye/2 > --- > Michael Reifenberger, Business Development Manager SAP-Basis, Plaut > Consulting > Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com > http://www.plaut.de | http://www.Reifenberger.com > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Oleg. --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vge_ifmedia_lock.diff" Index: if_vge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/vge/if_vge.c,v retrieving revision 1.24 diff -u -r1.24 if_vge.c --- if_vge.c 14 Feb 2006 12:44:56 -0000 1.24 +++ if_vge.c 22 Aug 2006 20:35:23 -0000 @@ -2129,8 +2129,10 @@ struct mii_data *mii; sc = ifp->if_softc; + VGE_LOCK(sc); mii = device_get_softc(sc->vge_miibus); mii_mediachg(mii); + VGE_UNLOCK(sc); return (0); } @@ -2147,11 +2149,13 @@ struct mii_data *mii; sc = ifp->if_softc; + VGE_LOCK(sc); mii = device_get_softc(sc->vge_miibus); mii_pollstat(mii); ifmr->ifm_active = mii->mii_media_active; ifmr->ifm_status = mii->mii_media_status; + VGE_UNLOCK(sc); return; } --WIyZ46R2i8wDzkSu-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 21:00:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E751D16A4F3 for ; Tue, 22 Aug 2006 21:00:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF6CA43D64 for ; Tue, 22 Aug 2006 21:00:29 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id D1A8553150; Tue, 22 Aug 2006 23:00:28 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 90D389C47C; Tue, 22 Aug 2006 21:01:05 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 70F3B405B; Tue, 22 Aug 2006 23:01:05 +0200 (CEST) Date: Tue, 22 Aug 2006 23:01:05 +0200 From: Jeremie Le Hen To: Michael Bushkov Message-ID: <20060822210105.GF58048@obiwan.tataz.chchile.org> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EB302A.7010106@rsu.ru> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 21:00:34 -0000 Hi Michael, On Tue, Aug 22, 2006 at 08:26:18PM +0400, Michael Bushkov wrote: > This issue turned to be more complex than I originally expected. I > believe that "not having 2 different entities in the system, that do the > same thing" is the good rule. So maybe, leaving libldap.so(a) in > /usr/lib is not an absolutely good decision. But renaming libldap to > some other name and leaving it there (and enforcing everything beside > the base system to use almost the same ports' libldap) is probably much > more worse. > So, after all, I'd prefer to leave libldap (and nss_ldap, which can also > conflict with PADL's nss_ldap) as is and let users use WITHOUT_LDAP and > WITHOUT_NSS_LDAP when appropriate. Besides, this avoids to break POLA IMHO. If OpenLDAP has to be imported (is it something sure now ?), I strongly expect libldap to have its real name, as other imported softwares. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 21:11:38 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F74116A4DF; Tue, 22 Aug 2006 21:11:38 +0000 (UTC) (envelope-from ryanb@FreeBSD.org) Received: from pds.uberhacker.org (uberhacker.org [71.5.14.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A5C843D5C; Tue, 22 Aug 2006 21:11:33 +0000 (GMT) (envelope-from ryanb@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pds.uberhacker.org (Postfix) with ESMTP id 33C27A2E; Tue, 22 Aug 2006 14:11:33 -0700 (PDT) Received: from pds.uberhacker.org ([127.0.0.1]) by localhost (pds.uberhacker.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00203-03; Tue, 22 Aug 2006 14:11:28 -0700 (PDT) Received: from [192.168.82.33] (unknown [74.134.233.192]) by pds.uberhacker.org (Postfix) with ESMTP id 7709E5F; Tue, 22 Aug 2006 14:11:27 -0700 (PDT) Message-ID: <44EB72FC.8040508@FreeBSD.org> Date: Tue, 22 Aug 2006 16:11:24 -0500 From: Ryan Beasley User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: current@FreeBSD.org, multimedia@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uberhacker.org Cc: Subject: [RFC] Summer of Code -- OSSv4 audio compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 21:11:38 -0000 Hello, current@ & multimedia@! ====== Summary ====== I participated in Google's Summer of Code this year, working on adding support for 4Front's OSSv4 API. Unfortunately, more of the API specifications were still under construction than I expected, so I focused entirely on the audio collection of ioctls and maybe just one or two mixer ioctls. While official documentation isn't yet available, the mixer extensions, which are one of the coolest parts of the new API, are my top priority. (I think I now have enough reference material to begin work in that area.) For information on the ioctls, please take a look at http://wiki.freebsd.org/RyanBeasley/ioctlref . ====== Patch Info ====== A patch against recent -CURRENT is available at http://www.leidinger.net/FreeBSD/sound/rbeasley_sound.diff . Comments, suggestions, etc., would be hugely appreciated! To apply, cd /usr/src/sys patch --quiet < rbeasley_sound.diff Then rebuild the sound/sound module and whichever modules are appropriate for your sound card. You should also install the new sys/soundcard.h. ====== Testing ====== Please beat down on audio as much as possible. Note that some applications might need to be recompiled in order to access the new ioctls (sys/soundcard.h was tweaked). Two areas that were least tested by me were ioctls intended to be used with mmap() (ex: SNDCTL_DSP_CURRENT_OPTR) and recording. Please keep an eye on these. Also, note that a LOR was detected with the SNDCTL_MIXERINFO ioctl. Please do not report this for now. LOR details: kernel: lock order reversal: kernel: 1st 0xc3fe25c0 pcm0 (sound cdev) @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:791 kernel: 2nd 0xc9c9f320 pcm0:mixer (pcm mixer) @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/mixer.c:815 If you encounter bugs or have any questions, please e-mail me. ====== Misc. ====== Thanks to Google, the FreeBSD Project, my mentors Alexander Leidinger & Ariff Abdullah, and Dev & Hannu @ 4Front for everything! -- Ryan Beasley From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 22:40:03 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2817816A4DD for ; Tue, 22 Aug 2006 22:40:03 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [128.32.206.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD98A43D45 for ; Tue, 22 Aug 2006 22:40:02 +0000 (GMT) (envelope-from michael@rancid.berkeley.edu) Received: from [169.229.152.11] (barr-60-wlan1.LIPS.Berkeley.EDU [169.229.152.11]) (authenticated bits=0) by malcolm.berkeley.edu (8.13.6/8.13.3) with ESMTP id k7MMdum4023594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Aug 2006 15:40:02 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) Message-ID: <44EB87B7.2050701@rancid.berkeley.edu> Date: Tue, 22 Aug 2006 15:39:51 -0700 From: Michael Sinatra User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (malcolm.berkeley.edu [128.32.206.239]); Tue, 22 Aug 2006 15:40:02 -0700 (PDT) Cc: Subject: 7-CURRENT 8/15/06 hangs: Tyan s2895 LSI 1030 mpt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 22:40:03 -0000 Hi, In the past FreeBSD 6-CURRENT and RELENG_6 would (and still do) hang when booting on a Tyan Thunder s2895 mobo with integrated LSI 1030 SCSI controller, just after resetting the scsi bus and scanning for disks. One workaround was to not use SCSI disks, and instead use SATA. Another workaround was to go into the BIOS config and do the following: o disable Slave MAC (second nVidia ethernet) o disable IEEE 1394 o enable bus master on the SCSI controller In this configuration, RELENG_6/amd64 runs like a champ on this mobo. Unfortunately, my attempts to boot with 7-CURRENT, either the snapshot 8/06 CD or a version build from source supped as of 8/15/06, have met with complete failure. A complete dmesg is included below. The only way I can get 7-CURRENT to boot is by disabling the SCSI controller. However, this box has a nice SCSI backplane and plenty of SCSI disks, and no room for SATA. o The same configuration that works for RELENG_6 doesn't work for CURRENT. I have gone even further and disabled just about everything that the system needs to boot except for the SCSI controller and it still hangs. o The SCSI controller is running the latest BIOS and firmware. o The problem occurs regardless of the version of BIOS that is on this mobo (including beta versions)--I have tested several versions. o I have tried both an amd64 kernel and an i386 kernel, both with the same result. o I built a custom, minimal kernel (using a non-mpt amd64 build machine), that also failed on the s2895. Any ideas? It appears that the driver either isn't understanding this card's handshake registers or it's not able to read the responses to SCSI commands. Here's the dmesg. Let me know if there is other information that I can provide. I'd like to test the nfe driver on the nVidia ethernet interfaces on this box, but I can't boot it under these circumstances. michael Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #2: Fri Aug 18 23:19:57 PDT 2006 michael@ncs-211.net.berkeley.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 250 (2411.12-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 usable memory = 3208052736 (3059 MB) avail memory = 3102224384 (2958 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard kbd0 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xc8000000-0xc8000fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 ata0: on atapci0 ata1: on atapci0 pcib1: at device 9.0 on pci0 pci1: on pcib1 nve0: port 0x1410-0x1417 mem 0xc8001000-0xc8001fff irq 21 at device 10.0 on pci0 nve0: Ethernet address 00:e0:81:54:a9:26 miibus0: on nve0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: Ethernet address: 00:e0:81:54:a9:26 pcib2: at device 14.0 on pci0 pci2: on pcib2 vgapci0: port 0x2000-0x20ff mem 0xd0000000-0xd7ffffff,0xc8200000-0xc820ffff irq 16 at device 0.0 on pci2 vgapci1: mem 0xc8210000-0xc821ffff at device 0.1 on pci2 pcib3: port 0xcf8-0xcff on acpi0 pci8: on pcib3 pcib4: at device 10.0 on pci8 pci9: on pcib4 em0: port 0x3000-0x303f mem 0xd8140000-0xd815ffff,0xd8100000-0xd813ffff irq 24 at device 4.0 on pci9 em0: Ethernet address: 00:04:23:b5:d8:7a em0: [FAST] em1: port 0x3040-0x307f mem 0xd8160000-0xd817ffff,0xd8180000-0xd81bffff irq 25 at device 4.1 on pci9 em1: Ethernet address: 00:04:23:b5:d8:7b em1: [FAST] pci8: at device 10.1 (no driver attached) pcib5: at device 11.0 on pci8 pci10: on pcib5 em2: port 0x4800-0x483f mem 0xd8240000-0xd825ffff,0xd8200000-0xd823ffff irq 28 at device 4.0 on pci10 em2: Ethernet address: 00:04:23:b6:2c:c4 em2: [FAST] em3: port 0x4840-0x487f mem 0xd8260000-0xd827ffff,0xd8280000-0xd82bffff irq 29 at device 4.1 on pci10 em3: Ethernet address: 00:04:23:b6:2c:c5 em3: [FAST] mpt0: port 0x4000-0x40ff mem 0xd8400000-0xd84fffff,0xd8300000-0xd83fffff irq 30 at device 6.0 on pci10 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.14.0 mpt1: port 0x4400-0x44ff mem 0xd8600000-0xd86fffff,0xd8500000-0xd85fffff irq 31 at device 6.1 on pci10 mpt1: [GIANT-LOCKED] mpt1: MPI Version=1.2.14.0 mpt1: mpt_wait_req(4) timed out mpt1: read_cfg_header timed out mpt1: mpt_wait_req(6) timed out mpt1: port 0 enable timed out mpt1: failed to enable port 0 mpt1: personality mpt_core attached but would not enable (6) pci8: at device 11.1 (no driver attached) pcib6: port 0xcf8-0xcff on acpi0 pci128: on pcib6 pci128: at device 0.0 (no driver attached) pci128: at device 1.0 (no driver attached) pcib7: at device 14.0 on pci128 pci129: on pcib7 atkbdc0: port 0x60,0x64 irq 1 on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FAST] fdc0: port 0-0x5,0 on acpi0 fdc0: cannot reserve interrupt line device_attach: fdc0 attach returned 6 fdc0: port 0-0x5,0 on acpi0 fdc0: cannot reserve interrupt line device_attach: fdc0 attach returned 6 ppc0: port 0-0x7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec mpt0: Default Handler Called: req=0xffffffff80e48ff8:94 reply_descriptor=dc913900 frame=0xffffffffacc7a200 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003005d mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49050:95 reply_descriptor=dc913980 frame=0xffffffffacc7a300 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003005e mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e490a8:96 reply_descriptor=dc913a00 frame=0xffffffffacc7a400 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a400 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003005f mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49100:97 reply_descriptor=dc913a80 frame=0xffffffffacc7a500 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a500 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030060 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49158:98 reply_descriptor=dc913b00 frame=0xffffffffacc7a600 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a600 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030061 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e491b0:99 reply_descriptor=dc913b80 frame=0xffffffffacc7a700 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a700 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030062 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49208:100 reply_descriptor=dc913c00 frame=0xffffffffacc7a800 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a800 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030063 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49260:101 reply_descriptor=dc913c80 frame=0xffffffffacc7a900 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a900 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030064 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e492b8:102 reply_descriptor=dc913d00 frame=0xffffffffacc7aa00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7aa00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030065 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49310:103 reply_descriptor=dc913d80 frame=0xffffffffacc7ab00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ab00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030066 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49368:104 reply_descriptor=dc913e00 frame=0xffffffffacc7ac00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ac00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030067 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e493c0:105 reply_descriptor=dc913e80 frame=0xffffffffacc7ad00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ad00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030068 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49418:106 reply_descriptor=dc913f00 frame=0xffffffffacc7ae00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ae00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030069 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49470:107 reply_descriptor=dc913800 frame=0xffffffffacc7a000 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a000 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006a mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e494c8:108 reply_descriptor=dc913880 frame=0xffffffffacc7a100 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a100 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006b mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49520:109 reply_descriptor=dc913900 frame=0xffffffffacc7a200 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006c mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49578:110 reply_descriptor=dc913980 frame=0xffffffffacc7a300 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006d mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e495d0:111 reply_descriptor=dc913a00 frame=0xffffffffacc7a400 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a400 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006e mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49628:112 reply_descriptor=dc913a80 frame=0xffffffffacc7a500 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a500 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003006f mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49680:113 reply_descriptor=dc913b00 frame=0xffffffffacc7a600 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a600 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030070 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e496d8:114 reply_descriptor=dc913b80 frame=0xffffffffacc7a700 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a700 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030071 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49730:115 reply_descriptor=dc913c00 frame=0xffffffffacc7a800 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a800 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030072 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49788:116 reply_descriptor=dc913c80 frame=0xffffffffacc7a900 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a900 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030073 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e497e0:117 reply_descriptor=dc913d00 frame=0xffffffffacc7aa00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7aa00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030074 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49838:118 reply_descriptor=dc913d80 frame=0xffffffffacc7ab00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ab00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030075 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49890:119 reply_descriptor=dc913e00 frame=0xffffffffacc7ac00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ac00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030076 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e498e8:120 reply_descriptor=dc913e80 frame=0xffffffffacc7ad00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ad00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030077 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49940:121 reply_descriptor=dc913f00 frame=0xffffffffacc7ae00 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7ae00 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030078 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49998:122 reply_descriptor=dc913800 frame=0xffffffffacc7a000 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a000 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x00030079 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e499f0:123 reply_descriptor=dc913880 frame=0xffffffffacc7a100 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a100 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003007a mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49a48:124 reply_descriptor=dc913900 frame=0xffffffffacc7a200 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003007b mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49aa0:125 reply_descriptor=dc913980 frame=0xffffffffacc7a300 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003007c mpt0: Reply Frame Ignored em1: link state changed to UP em2: link state changed to UP em3: link state changed to UP acd0: CDROM at ata0-master UDMA33 Waiting 5 seconds for SCSI devices to settle mpt0: Default Handler Called: req=0xffffffff80e47160:126 reply_descriptor=dc913a00 frame=0xffffffffacc7a400 mpt0: Address Reply: SCSI Task Management Reply @ 0xffffffffacc7a400 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x06 MsgFlags 0x00 MsgContext 0x00020004 mpt0: Reply Frame Ignored mpt0: mpt_wait_req(1) timed out mpt0: mpt_bus_reset: Reset timed-out. Resetting controller. mpt0: Default Handler Called: req=0xffffffff80e47160:126 reply_descriptor=20004 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Task Management Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00020004 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49aa0:125 reply_descriptor=3007c frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003007c mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49a48:124 reply_descriptor=3007b frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003007b mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e499f0:123 reply_descriptor=3007a frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003007a mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49998:122 reply_descriptor=30079 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030079 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49940:121 reply_descriptor=30078 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030078 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e498e8:120 reply_descriptor=30077 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030077 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49890:119 reply_descriptor=30076 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030076 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49838:118 reply_descriptor=30075 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030075 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e497e0:117 reply_descriptor=30074 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030074 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49788:116 reply_descriptor=30073 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030073 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49730:115 reply_descriptor=30072 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030072 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e496d8:114 reply_descriptor=30071 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030071 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49680:113 reply_descriptor=30070 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030070 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49628:112 reply_descriptor=3006f frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006f mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e495d0:111 reply_descriptor=3006e frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006e mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49578:110 reply_descriptor=3006d frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006d mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49520:109 reply_descriptor=3006c frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006c mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e494c8:108 reply_descriptor=3006b frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006b mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49470:107 reply_descriptor=3006a frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003006a mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49418:106 reply_descriptor=30069 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030069 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e493c0:105 reply_descriptor=30068 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030068 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49368:104 reply_descriptor=30067 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030067 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49310:103 reply_descriptor=30066 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030066 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e492b8:102 reply_descriptor=30065 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030065 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49260:101 reply_descriptor=30064 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030064 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49208:100 reply_descriptor=30063 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030063 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e491b0:99 reply_descriptor=30062 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030062 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49158:98 reply_descriptor=30061 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030061 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49100:97 reply_descriptor=30060 frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00030060 mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e490a8:96 reply_descriptor=3005f frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003005f mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e49050:95 reply_descriptor=3005e frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003005e mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=0xffffffff80e48ff8:94 reply_descriptor=3005d frame=0xffffffff80b49b10 mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0003005d mpt0: Reply Frame Ignored mpt0: mpt_cam_event: 0x0 mpt0: Default Handler Called: req=0xffffffff80e49ba8:129 reply_descriptor=1007f frame=0 mpt0: Reply Frame Ignored mpt0: request 0xffffffff80e49ba8:129 timed out for ccb 0xffffff00b7d81800 (req->ccb 0xffffff00b7d81800) mpt0: attempting to abort req 0xffffffff80e49ba8:129 function 0 mpt0: Default Handler Called: req=0xffffffff80e47160:130 reply_descriptor=dc913900 frame=0xffffffffacc7a200 mpt0: Address Reply: SCSI Task Management Reply @ 0xffffffffacc7a200 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x06 MsgFlags 0x00 MsgContext 0x00020004 mpt0: Reply Frame Ignored mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: Default Handler Called: req=0xffffffff80e47160:130 reply_descriptor=20004 frame=0xffffffffac25db90 mpt0: Address Reply: SCSI Task Management Reply @ 0xffffffffac25db90 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x00020004 mpt0: Reply Frame Ignored mpt0: mpt_cam_event: 0x0 mpt0: Default Handler Called: req=0xffffffff80e49ba8:129 reply_descriptor=1007f frame=0xffffffffac25db70 mpt0: Address Reply: SCSI IO Request Reply @ 0xffffffffac25db70 IOC Status IOC: Invalid State IOCLogInfo 0x00000000 MsgLength 0x14 MsgFlags 0x00 MsgContext 0x0001007f Bus: 0 TargetID 0 CDBLength 0 SCSI Status: OK SCSI State: (0x00000000) TransferCnt 0xffffffff SenseCnt 0x803104e7 ResponseInfo 0xffffffff mpt0: Reply Frame Ignored From owner-freebsd-current@FreeBSD.ORG Tue Aug 22 23:04:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9315116A4DA for ; Tue, 22 Aug 2006 23:04:53 +0000 (UTC) (envelope-from Chris@lainos.org) Received: from mail.neovanglist.net (blackacid.neovanglist.net [69.16.150.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1289D43D45 for ; Tue, 22 Aug 2006 23:04:52 +0000 (GMT) (envelope-from Chris@lainos.org) Received: from localhost (localhost.neovanglist.net [127.0.0.1]) by mail.neovanglist.net (Postfix) with ESMTP id AF2996D436; Tue, 22 Aug 2006 16:04:49 -0700 (MST) X-Virus-Scanned: amavisd-new at neovanglist.net Received: from mail.neovanglist.net ([127.0.0.1]) by localhost (blackacid.neovanglist.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57IJe-OOAybp; Tue, 22 Aug 2006 16:04:47 -0700 (MST) Received: from melchior (kbhn-vbrg-sr0-vl202-021.perspektivbredband.net [85.235.18.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.neovanglist.net (Postfix) with ESMTP id CBBF76D42F; Tue, 22 Aug 2006 16:04:45 -0700 (MST) From: Chris Gilbert To: freebsd-current@freebsd.org Date: Wed, 23 Aug 2006 01:04:37 +0200 User-Agent: KMail/1.8.2 References: <44EB87B7.2050701@rancid.berkeley.edu> In-Reply-To: <44EB87B7.2050701@rancid.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608230104.37558.Chris@lainos.org> Cc: Michael Sinatra Subject: Re: 7-CURRENT 8/15/06 hangs: Tyan s2895 LSI 1030 mpt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 23:04:53 -0000 I've had similar issues with SCSI on the s2895, but with Adaptec PCI-X raid instead of the onboard LSI raid. If I put the card in the PCI-X 133Mhz slot, then it fails to see the OptionROM on boot, however if I put it in the second from last slot with an Audigy 2 in the last slot... it freezes in the exact point you describe. However if I put it in the third from last and the Audigy in the second from last then it runs like a charm! I think there are some serious issues with this mainboard in regard to these PCI-X slots. I've seen nothing but strangeness with them since I got this mainboard. On a related note, I have a GeForce 7900 and a Radeon X1800XT in my two PCIe slots. If the GeForce is in PCIe PCIe slot1 and the Radeon in PCIe slot2 while using the Adaptec SCSI, it hardlocks in the area you described. However once I swapped those two graphics cards it booted fine... maybe it's some kind of crazy resource mapping issue? Have you tried running the latest BIOS version on the board? I think it's up to 1.3l now, with tons of bug fixes. -- Regards, Chris Gilbert On Wednesday 23 August 2006 00:39, Michael Sinatra wrote: > Hi, > > In the past FreeBSD 6-CURRENT and RELENG_6 would (and still do) hang > when booting on a Tyan Thunder s2895 mobo with integrated LSI 1030 SCSI > controller, just after resetting the scsi bus and scanning for disks. > One workaround was to not use SCSI disks, and instead use SATA. Another > workaround was to go into the BIOS config and do the following: > > o disable Slave MAC (second nVidia ethernet) > o disable IEEE 1394 > o enable bus master on the SCSI controller > > In this configuration, RELENG_6/amd64 runs like a champ on this mobo. > > Unfortunately, my attempts to boot with 7-CURRENT, either the snapshot > 8/06 CD or a version build from source supped as of 8/15/06, have met > with complete failure. A complete dmesg is included below. > > The only way I can get 7-CURRENT to boot is by disabling the SCSI > controller. However, this box has a nice SCSI backplane and plenty of > SCSI disks, and no room for SATA. > > o The same configuration that works for RELENG_6 doesn't work for > CURRENT. I have gone even further and disabled just about everything > that the system needs to boot except for the SCSI controller and it > still hangs. > o The SCSI controller is running the latest BIOS and firmware. > o The problem occurs regardless of the version of BIOS that is on this > mobo (including beta versions)--I have tested several versions. > o I have tried both an amd64 kernel and an i386 kernel, both with the > same result. > o I built a custom, minimal kernel (using a non-mpt amd64 build > machine), that also failed on the s2895. > > Any ideas? It appears that the driver either isn't understanding this > card's handshake registers or it's not able to read the responses to > SCSI commands. > > Here's the dmesg. Let me know if there is other information that I can > provide. I'd like to test the nfe driver on the nVidia ethernet > interfaces on this box, but I can't boot it under these circumstances. > > michael > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2006 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 7.0-CURRENT #2: Fri Aug 18 23:19:57 PDT 2006 > michael@ncs-211.net.berkeley.edu:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Opteron(tm) Processor 250 (2411.12-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 > > Features=0x78bfbff,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> AMD > Features=0xe0500800 > usable memory = 3208052736 (3059 MB) > avail memory = 3102224384 (2958 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-27 on motherboard > ioapic2 irqs 28-31 on motherboard > kbd0 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xc8000000-0xc8000fff irq 20 > at device 2.0 on pci0 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 10 ports with 10 removable, self powered > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > nve0: port 0x1410-0x1417 mem > 0xc8001000-0xc8001fff irq 21 at device 10.0 on pci0 > nve0: Ethernet address 00:e0:81:54:a9:26 > miibus0: on nve0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nve0: Ethernet address: 00:e0:81:54:a9:26 > pcib2: at device 14.0 on pci0 > pci2: on pcib2 > vgapci0: port 0x2000-0x20ff mem > 0xd0000000-0xd7ffffff,0xc8200000-0xc820ffff irq 16 at device 0.0 on pci2 > vgapci1: mem 0xc8210000-0xc821ffff at device > 0.1 on pci2 > pcib3: port 0xcf8-0xcff on acpi0 > pci8: on pcib3 > pcib4: at device 10.0 on pci8 > pci9: on pcib4 > em0: port > 0x3000-0x303f mem 0xd8140000-0xd815ffff,0xd8100000-0xd813ffff irq 24 at > device 4.0 on pci9 > em0: Ethernet address: 00:04:23:b5:d8:7a > em0: [FAST] > em1: port > 0x3040-0x307f mem 0xd8160000-0xd817ffff,0xd8180000-0xd81bffff irq 25 at > device 4.1 on pci9 > em1: Ethernet address: 00:04:23:b5:d8:7b > em1: [FAST] > pci8: at device 10.1 (no driver > attached) > pcib5: at device 11.0 on pci8 > pci10: on pcib5 > em2: port > 0x4800-0x483f mem 0xd8240000-0xd825ffff,0xd8200000-0xd823ffff irq 28 at > device 4.0 on pci10 > em2: Ethernet address: 00:04:23:b6:2c:c4 > em2: [FAST] > em3: port > 0x4840-0x487f mem 0xd8260000-0xd827ffff,0xd8280000-0xd82bffff irq 29 at > device 4.1 on pci10 > em3: Ethernet address: 00:04:23:b6:2c:c5 > em3: [FAST] > mpt0: port 0x4000-0x40ff mem > 0xd8400000-0xd84fffff,0xd8300000-0xd83fffff irq 30 at device 6.0 on pci10 > mpt0: [GIANT-LOCKED] > mpt0: MPI Version=1.2.14.0 > mpt1: port 0x4400-0x44ff mem > 0xd8600000-0xd86fffff,0xd8500000-0xd85fffff irq 31 at device 6.1 on pci10 > mpt1: [GIANT-LOCKED] > mpt1: MPI Version=1.2.14.0 > mpt1: mpt_wait_req(4) timed out > mpt1: read_cfg_header timed out > mpt1: mpt_wait_req(6) timed out > mpt1: port 0 enable timed out > mpt1: failed to enable port 0 > mpt1: personality mpt_core attached but would not enable (6) > pci8: at device 11.1 (no driver > attached) > pcib6: port 0xcf8-0xcff on acpi0 > pci128: on pcib6 > pci128: at device 0.0 (no driver attached) > pci128: at device 1.0 (no driver attached) > pcib7: at device 14.0 on pci128 > pci129: on pcib7 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A, console > sio0: [FAST] > fdc0: port 0-0x5,0 on acpi0 > fdc0: cannot reserve interrupt line > device_attach: fdc0 attach returned 6 > fdc0: port 0-0x5,0 on acpi0 > fdc0: cannot reserve interrupt line > device_attach: fdc0 attach returned 6 > ppc0: port 0-0x7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: cannot reserve interrupt, failed. > lpt0: on ppbus0 > lpt0: Polled port > ppi0: on ppbus0 > orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd0fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > mpt0: Default Handler Called: req=0xffffffff80e48ff8:94 > reply_descriptor=dc913900 frame=0xffffffffacc7a200 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003005d > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49050:95 > reply_descriptor=dc913980 frame=0xffffffffacc7a300 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003005e > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e490a8:96 > reply_descriptor=dc913a00 frame=0xffffffffacc7a400 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a400 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003005f > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49100:97 > reply_descriptor=dc913a80 frame=0xffffffffacc7a500 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a500 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030060 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49158:98 > reply_descriptor=dc913b00 frame=0xffffffffacc7a600 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a600 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030061 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e491b0:99 > reply_descriptor=dc913b80 frame=0xffffffffacc7a700 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a700 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030062 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49208:100 > reply_descriptor=dc913c00 frame=0xffffffffacc7a800 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a800 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030063 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49260:101 > reply_descriptor=dc913c80 frame=0xffffffffacc7a900 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a900 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030064 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e492b8:102 > reply_descriptor=dc913d00 frame=0xffffffffacc7aa00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7aa00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030065 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49310:103 > reply_descriptor=dc913d80 frame=0xffffffffacc7ab00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ab00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030066 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49368:104 > reply_descriptor=dc913e00 frame=0xffffffffacc7ac00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ac00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030067 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e493c0:105 > reply_descriptor=dc913e80 frame=0xffffffffacc7ad00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ad00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030068 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49418:106 > reply_descriptor=dc913f00 frame=0xffffffffacc7ae00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ae00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030069 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49470:107 > reply_descriptor=dc913800 frame=0xffffffffacc7a000 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a000 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006a > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e494c8:108 > reply_descriptor=dc913880 frame=0xffffffffacc7a100 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a100 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006b > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49520:109 > reply_descriptor=dc913900 frame=0xffffffffacc7a200 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006c > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49578:110 > reply_descriptor=dc913980 frame=0xffffffffacc7a300 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006d > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e495d0:111 > reply_descriptor=dc913a00 frame=0xffffffffacc7a400 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a400 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006e > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49628:112 > reply_descriptor=dc913a80 frame=0xffffffffacc7a500 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a500 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003006f > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49680:113 > reply_descriptor=dc913b00 frame=0xffffffffacc7a600 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a600 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030070 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e496d8:114 > reply_descriptor=dc913b80 frame=0xffffffffacc7a700 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a700 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030071 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49730:115 > reply_descriptor=dc913c00 frame=0xffffffffacc7a800 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a800 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030072 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49788:116 > reply_descriptor=dc913c80 frame=0xffffffffacc7a900 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a900 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030073 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e497e0:117 > reply_descriptor=dc913d00 frame=0xffffffffacc7aa00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7aa00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030074 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49838:118 > reply_descriptor=dc913d80 frame=0xffffffffacc7ab00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ab00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030075 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49890:119 > reply_descriptor=dc913e00 frame=0xffffffffacc7ac00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ac00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030076 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e498e8:120 > reply_descriptor=dc913e80 frame=0xffffffffacc7ad00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ad00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030077 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49940:121 > reply_descriptor=dc913f00 frame=0xffffffffacc7ae00 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7ae00 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030078 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49998:122 > reply_descriptor=dc913800 frame=0xffffffffacc7a000 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a000 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x00030079 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e499f0:123 > reply_descriptor=dc913880 frame=0xffffffffacc7a100 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a100 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003007a > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49a48:124 > reply_descriptor=dc913900 frame=0xffffffffacc7a200 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003007b > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49aa0:125 > reply_descriptor=dc913980 frame=0xffffffffacc7a300 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffffacc7a300 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x05 > MsgFlags 0x00 > MsgContext 0x0003007c > mpt0: Reply Frame Ignored > em1: link state changed to UP > em2: link state changed to UP > em3: link state changed to UP > acd0: CDROM at ata0-master UDMA33 > Waiting 5 seconds for SCSI devices to settle > mpt0: Default Handler Called: req=0xffffffff80e47160:126 > reply_descriptor=dc913a00 frame=0xffffffffacc7a400 > mpt0: Address Reply: > SCSI Task Management Reply @ 0xffffffffacc7a400 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x06 > MsgFlags 0x00 > MsgContext 0x00020004 > mpt0: Reply Frame Ignored > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_bus_reset: Reset timed-out. Resetting controller. > mpt0: Default Handler Called: req=0xffffffff80e47160:126 > reply_descriptor=20004 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Task Management Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00020004 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49aa0:125 > reply_descriptor=3007c frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003007c > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49a48:124 > reply_descriptor=3007b frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003007b > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e499f0:123 > reply_descriptor=3007a frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003007a > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49998:122 > reply_descriptor=30079 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030079 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49940:121 > reply_descriptor=30078 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030078 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e498e8:120 > reply_descriptor=30077 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030077 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49890:119 > reply_descriptor=30076 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030076 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49838:118 > reply_descriptor=30075 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030075 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e497e0:117 > reply_descriptor=30074 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030074 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49788:116 > reply_descriptor=30073 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030073 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49730:115 > reply_descriptor=30072 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030072 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e496d8:114 > reply_descriptor=30071 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030071 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49680:113 > reply_descriptor=30070 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030070 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49628:112 > reply_descriptor=3006f frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006f > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e495d0:111 > reply_descriptor=3006e frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006e > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49578:110 > reply_descriptor=3006d frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006d > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49520:109 > reply_descriptor=3006c frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006c > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e494c8:108 > reply_descriptor=3006b frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006b > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49470:107 > reply_descriptor=3006a frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003006a > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49418:106 > reply_descriptor=30069 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030069 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e493c0:105 > reply_descriptor=30068 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030068 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49368:104 > reply_descriptor=30067 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030067 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49310:103 > reply_descriptor=30066 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030066 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e492b8:102 > reply_descriptor=30065 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030065 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49260:101 > reply_descriptor=30064 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030064 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49208:100 > reply_descriptor=30063 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030063 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e491b0:99 > reply_descriptor=30062 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030062 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49158:98 > reply_descriptor=30061 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030061 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49100:97 > reply_descriptor=30060 frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00030060 > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e490a8:96 > reply_descriptor=3005f frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003005f > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e49050:95 > reply_descriptor=3005e frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003005e > mpt0: Reply Frame Ignored > mpt0: Default Handler Called: req=0xffffffff80e48ff8:94 > reply_descriptor=3005d frame=0xffffffff80b49b10 > mpt0: Address Reply: > SCSI Target Command Buffer Reply @ 0xffffffff80b49b10 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0003005d > mpt0: Reply Frame Ignored > mpt0: mpt_cam_event: 0x0 > mpt0: Default Handler Called: req=0xffffffff80e49ba8:129 > reply_descriptor=1007f frame=0 > mpt0: Reply Frame Ignored > mpt0: request 0xffffffff80e49ba8:129 timed out for ccb > 0xffffff00b7d81800 (req->ccb 0xffffff00b7d81800) > mpt0: attempting to abort req 0xffffffff80e49ba8:129 function 0 > mpt0: Default Handler Called: req=0xffffffff80e47160:130 > reply_descriptor=dc913900 frame=0xffffffffacc7a200 > mpt0: Address Reply: > SCSI Task Management Reply @ 0xffffffffacc7a200 > IOC Status Success > IOCLogInfo 0x00000000 > MsgLength 0x06 > MsgFlags 0x00 > MsgContext 0x00020004 > mpt0: Reply Frame Ignored > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_recover_commands: abort timed-out. Resetting controller > mpt0: Default Handler Called: req=0xffffffff80e47160:130 > reply_descriptor=20004 frame=0xffffffffac25db90 > mpt0: Address Reply: > SCSI Task Management Reply @ 0xffffffffac25db90 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x00020004 > mpt0: Reply Frame Ignored > mpt0: mpt_cam_event: 0x0 > mpt0: Default Handler Called: req=0xffffffff80e49ba8:129 > reply_descriptor=1007f frame=0xffffffffac25db70 > mpt0: Address Reply: > SCSI IO Request Reply @ 0xffffffffac25db70 > IOC Status IOC: Invalid State > IOCLogInfo 0x00000000 > MsgLength 0x14 > MsgFlags 0x00 > MsgContext 0x0001007f > Bus: 0 > TargetID 0 > CDBLength 0 > SCSI Status: OK > SCSI State: (0x00000000) > TransferCnt 0xffffffff > SenseCnt 0x803104e7 > ResponseInfo 0xffffffff > mpt0: Reply Frame Ignored > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 00:56:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45ED816A4E7 for ; Wed, 23 Aug 2006 00:56:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3971C43D45 for ; Wed, 23 Aug 2006 00:56:03 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3096955pye for ; Tue, 22 Aug 2006 17:56:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Y+kqDSQNokxckT7hwAey6bFDfzcbOcD/RBc2lLuwlwezDTqdzSQrHs6GFocPdF+LOBB+3a2bNiYspZs/DXfTlMsbWnfCYUDhemI+vt+FYyUHaxGfWBnDiLMBBT7xQreOSdEajSot7odLGxymRu/nMKOSNE57yyuXKExSqSs6oSE= Received: by 10.35.66.12 with SMTP id t12mr16699471pyk; Tue, 22 Aug 2006 17:56:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 17sm2659398nzo.2006.08.22.17.56.01; Tue, 22 Aug 2006 17:56:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7N0tvEP018226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 09:55:57 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7N0tsnv018225; Wed, 23 Aug 2006 09:55:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 09:55:54 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060823005554.GC17902@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822204342.GA4943@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 00:56:04 -0000 On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > ... > > >I'm not familiar with vge(4) and don't have hardwares supported by > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > >is a possiblity to have the same issue seen on em(4). > > >If you want my blind patch I can send a patch for you. > > > > > Yes, please! > > I can test it (on RELENG_6 though). > > I have an idea why those timeouts can happen. Could you please test > attached patch? It may help (or may not). Anyway would be fine > to know results. > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is protected with the mutex I guess it wouldn't help much. I guess it needs a seperate mutex to protect miibus(4) handler and should remove the use of MTX_RECURSE. vge(4) also has a bug if mbuf chain is too long(7 or higher) and defragmentation with m_defrag(9) fails it would access an invalid mbuf chain. All these requires lots of work and need a real hardware. Oleg, if you have hardware, would you fix it? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 07:51:58 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CE8816A4DD; Wed, 23 Aug 2006 07:51:58 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB4143D58; Wed, 23 Aug 2006 07:51:56 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.0.5) with ESMTP id md50000420225.msg; Wed, 23 Aug 2006 11:51:28 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Aug 2006 11:51:24 +0400 Content-class: urn:content-classes:message Message-ID: <78664C02FF341B4FAC63E561846E3BCC546A@ex.hhp.local> In-Reply-To: <44EB72FC.8040508@FreeBSD.org> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] Summer of Code -- OSSv4 audio compatibility Thread-Index: AcbGL7OAH/PYGjRvRGWfKbeo32L8DQASCvhA From: "Yuriy Tsibizov" To: "Ryan Beasley" X-Spam-Processed: mx.gfk.ru, Wed, 23 Aug 2006 11:51:28 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDAV-Processed: mx.gfk.ru, Wed, 23 Aug 2006 11:51:28 +0400 Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: RE: [RFC] Summer of Code -- OSSv4 audio compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 07:51:58 -0000 > Hello, current@ & multimedia@! >=20 > =3D=3D=3D=3D=3D=3D Summary =3D=3D=3D=3D=3D=3D > I participated in Google's Summer of Code this year, working on adding > support for 4Front's OSSv4 API. >=20 > Unfortunately, more of the API specifications were still under > construction than I expected, so I focused entirely on the audio > collection of ioctls and maybe just one or two mixer ioctls. While > official documentation isn't yet available, the mixer=20 > extensions, which > are one of the coolest parts of the new API, are my top priority. (I > think I now have enough reference material to begin work in=20 > that area.) >=20 > For information on the ioctls, please take a look at > http://wiki.freebsd.org/RyanBeasley/ioctlref . >=20 > =3D=3D=3D=3D=3D=3D Patch Info =3D=3D=3D=3D=3D=3D > A patch against recent -CURRENT is available at > http://www.leidinger.net/FreeBSD/sound/rbeasley_sound.diff . >=20 > Comments, suggestions, etc., would be hugely appreciated! Ryan, will there be any changes for hardware drivers? And, as I know you have emu10kx-compatible sound card, can you=20 test your sound buffering changes with EMU_PLAY_BUFSZ set to=20 EMUPAGESIZE*2 or larger (dev/sound/pci/emu10kx.h, line49). With 4K (=3DEMUPAGESIZE) playback buffer sound does not has lag or lost samples, but there was problems with large one (http://docs.freebsd.org/cgi/mid.cgi?D562966835368E4C8DDF68BC113A97B15F0 643). On opposite side, with small buffer I have a lot of noise when my system has a lot of disk activity or kernel printf's. You can use http://www.linksplace.com/wavsounds/pong.wav as a good sample of "bad file" for large buffer. Yuriy. From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 08:48:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 941F116A4DF for ; Wed, 23 Aug 2006 08:48:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C61243D4C for ; Wed, 23 Aug 2006 08:48:19 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so101080pye for ; Wed, 23 Aug 2006 01:48:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=NWQvw/y71Y70nMGLjvjdXoerwq0ARA9NwCPe0jcn2Vx5QL8jcFOJcSR8Cwd9wVos+FjRML2o62KYZLfSqm3ujW8Es33Caa8qpwqVsXIorN1iN8yaSMMzyCz3kxLJYBGQxzMVSqzlx6/fTNJk6k9xd7Va5GQ6nA40J5TT1e1zdaY= Received: by 10.35.22.17 with SMTP id z17mr125787pyi; Wed, 23 Aug 2006 01:48:19 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 18sm690973nzo.2006.08.23.01.48.18; Wed, 23 Aug 2006 01:48:19 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7N8mIHA019730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 17:48:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7N8mHLv019729; Wed, 23 Aug 2006 17:48:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 17:48:17 +0900 From: Pyun YongHyeon To: Paolo Pisati Message-ID: <20060823084817.GH17902@cdnetworks.co.kr> References: <20060819211853.GA1016@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060819211853.GA1016@tin.it> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD_Current Subject: Re: Fatal trap 30 when loading if_xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 08:48:20 -0000 On Sat, Aug 19, 2006 at 11:18:53PM +0200, Paolo Pisati wrote: > Today's CURRENT panic my box everytime i load > if_xl: > [...] > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f mem 0xff8ffc00-0xff8ffc7f irq 18 at device 2.0 on pci1 > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc04ef25b > stack pointer = 0x28:0xe3491c34 > frame pointer = 0x28:0xe3491c50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 12 (swi4: clock sio) > panic: from debugger > cpuid = 0 > Uptime: 2m36s > Physical memory: 2031 MB > Dumping 61 MB: 46 30 14 > I've run into this too. It seems loading kernel module drivers with kldload(8) triggers the issue. Any ideas? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 09:37:44 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D86416A4DD for ; Wed, 23 Aug 2006 09:37:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B24D43D45 for ; Wed, 23 Aug 2006 09:37:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7N9bf9Z074455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 13:37:41 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7N9bfi9074454; Wed, 23 Aug 2006 13:37:41 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Aug 2006 13:37:41 +0400 From: Gleb Smirnoff To: Pyun YongHyeon Message-ID: <20060823093741.GF96644@FreeBSD.org> References: <20060822042023.GC12848@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060822042023.GC12848@cdnetworks.co.kr> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 09:37:44 -0000 On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: P> After fixing em(4) watchdog bug, I looked over bge(4) and I think P> bge(4) may suffer from the same issue. So if you have seen occasional P> watchdog timeout errors on bge(4) please give the attached patch a try. P> The patch does fix false watchdog timeout error only. P> Typical pheonoma for false watchdog timeout error are P> o polling(4) fix the issue P> o random watchdog error P> P> If my patch fix the issue you could see the following messages. P> "missing Tx completion interrupt!" or "link lost -- resetting" I still think that this fix is incorrect. It is just a more gentle recovery from a fake watchdog timeout. The more I think, the more I doubt that we really need the watchdog infrastructure that comes from old days. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 09:55:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A4D816A4F2 for ; Wed, 23 Aug 2006 09:55:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51FDA43D53 for ; Wed, 23 Aug 2006 09:55:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so123683pye for ; Wed, 23 Aug 2006 02:55:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=NP/NnZXn75SACb2UPs1WUXHpXqBYDKgBfOXUgtH3ff3zeexn3J0MR9ocoTLF40YSJBzV56iyfOBRDUl7JkyUQR9wrGM5jiBDi6iJtGmh/fhMARcBhnKCVBiEChHorC5W4PxqMPevYTR8jFJP8He8hkGT3iC8V92aY7IyAR8kxXI= Received: by 10.35.36.13 with SMTP id o13mr233687pyj; Wed, 23 Aug 2006 02:55:04 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 18sm850973nzo.2006.08.23.02.55.03; Wed, 23 Aug 2006 02:55:04 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7N9t4IK019952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 18:55:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7N9t4Bl019951; Wed, 23 Aug 2006 18:55:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 18:55:04 +0900 From: Pyun YongHyeon To: Gleb Smirnoff Message-ID: <20060823095504.GI17902@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823093741.GF96644@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 09:55:23 -0000 On Wed, Aug 23, 2006 at 01:37:41PM +0400, Gleb Smirnoff wrote: > On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: > P> After fixing em(4) watchdog bug, I looked over bge(4) and I think > P> bge(4) may suffer from the same issue. So if you have seen occasional > P> watchdog timeout errors on bge(4) please give the attached patch a try. > P> The patch does fix false watchdog timeout error only. > P> Typical pheonoma for false watchdog timeout error are > P> o polling(4) fix the issue > P> o random watchdog error > P> > P> If my patch fix the issue you could see the following messages. > P> "missing Tx completion interrupt!" or "link lost -- resetting" > > I still think that this fix is incorrect. It is just a more gentle > recovery from a fake watchdog timeout. > Its sole purpose is to reinitialize hardware for real watchdog timeouts. It's not fix for general watchdog timeouts. As I said other mails, the fake watchdog timeout(losing Tx interrupts) for hardwares with Tx interrupt moderation capability could be normal thing. So I just want to know bge(4) also has the same feature(bug). > The more I think, the more I doubt that we really need the > watchdog infrastructure that comes from old days. > Would you give other way to recover from Tx stuck condition without using watchdog? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:04:36 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 958E816A4E2 for ; Wed, 23 Aug 2006 10:04:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D21443D69 for ; Wed, 23 Aug 2006 10:04:22 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7NA4LC7074710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 14:04:21 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7NA4K9P074709; Wed, 23 Aug 2006 14:04:20 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Aug 2006 14:04:20 +0400 From: Gleb Smirnoff To: Pyun YongHyeon Message-ID: <20060823100420.GG96644@cell.sick.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> <20060823095504.GI17902@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060823095504.GI17902@cdnetworks.co.kr> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:04:36 -0000 On Wed, Aug 23, 2006 at 06:55:04PM +0900, Pyun YongHyeon wrote: P> On Wed, Aug 23, 2006 at 01:37:41PM +0400, Gleb Smirnoff wrote: P> > On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: P> > P> After fixing em(4) watchdog bug, I looked over bge(4) and I think P> > P> bge(4) may suffer from the same issue. So if you have seen occasional P> > P> watchdog timeout errors on bge(4) please give the attached patch a try. P> > P> The patch does fix false watchdog timeout error only. P> > P> Typical pheonoma for false watchdog timeout error are P> > P> o polling(4) fix the issue P> > P> o random watchdog error P> > P> P> > P> If my patch fix the issue you could see the following messages. P> > P> "missing Tx completion interrupt!" or "link lost -- resetting" P> > P> > I still think that this fix is incorrect. It is just a more gentle P> > recovery from a fake watchdog timeout. P> P> Its sole purpose is to reinitialize hardware for real watchdog P> timeouts. It's not fix for general watchdog timeouts. As I said other P> mails, the fake watchdog timeout(losing Tx interrupts) for hardwares P> with Tx interrupt moderation capability could be normal thing. So I P> just want to know bge(4) also has the same feature(bug). According to several emails about em(4) fake watchdog timeouts, the problem can be fixed by setting debug.mpsafenet=0. This makes me think that the problem isn't caused by TX interrupt moderation, but some race in the kernel. Really, if_slowtimo() doesn't acquire driver lock before checking and modifying the if_timer field. Afaik, NIC drivers that can do interrupt moderation should set a timer to a sane value, based on interrupt moderation settings, so that the watchdog won't be ever called fakely. P> > The more I think, the more I doubt that we really need the P> > watchdog infrastructure that comes from old days. P> P> Would you give other way to recover from Tx stuck condition without P> using watchdog? May be driver should take care of that theirselves, why not? At least the callout routine will have access to the driver mutex, contrary to if_slowtimo(). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:12:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 742DC16A4DD for ; Wed, 23 Aug 2006 10:12:29 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC4F943D45 for ; Wed, 23 Aug 2006 10:12:28 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E135.dip.t-dialin.net [84.165.225.53]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7N9s4lw025443; Wed, 23 Aug 2006 11:54:07 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7NABwqe091419; Wed, 23 Aug 2006 12:11:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 23 Aug 2006 12:11:57 +0200 Message-ID: <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 23 Aug 2006 12:11:57 +0200 From: Alexander Leidinger To: Michael Bushkov References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> In-Reply-To: <44EB302A.7010106@rsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Dag-Erling =?utf-8?b?U23DuHJncmF2?= , freebsd-current@freebsd.org, LI Xin Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:12:29 -0000 Quoting Michael Bushkov (from Tue, 22 Aug 2006 =20 20:26:18 +0400): > Dag-Erling Sm=C3=B8rgrav wrote: > >> "Michael Bushkov" writes: >> >>> Li Xin wrote: >>> >>>> Would you please consider having the imported OpenLDAP to install >>>> shared objects under alternative names? It might be painful for >>>> users who wants OpenLDAP installation from the ports collection >>>> (as OpenLDAP team moves fast and fixes bug from time to time) if >>>> they get a same library in /usr/lib... >>>> >>> I've been thinking about that. Would names like "libldap_i.so" and >>> "liblber_i.so" be ok ("_i" means "imported", or "internal")? >>> >> >> Please don't. If somebody isn't happy with the base system's libldap, >> they can add WITHOUT_LDAP to their make.conf. >> >> DES >> > This issue turned to be more complex than I originally expected. I > believe that "not having 2 different entities in the system, that do > the same thing" is the good rule. So maybe, leaving libldap.so(a) in > /usr/lib is not an absolutely good decision. But renaming libldap to > some other name and leaving it there (and enforcing everything beside > the base system to use almost the same ports' libldap) is probably much > more worse. > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > also conflict with PADL's nss_ldap) as is and let users use > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. If someone doesn't like the base system libldap, but wants the =20 nss_ldap stuff, this way will not work out. While building the base =20 system, no 3rd party libs are known to the build infrastructure. Conflicting libs aren't good and some people may want to have more =20 recent versions of a lib installed. To solve this issue phk didn't =20 importet "libxml", but renamed it to "libbsdxml" (we only need to =20 update the lib if we need a new feature, or if there's a security =20 problem). This way base system tools are able to use a XML lib while =20 ports can use a more recent version of it (ports aren't using our =20 version of the lib). So this is not like the openssl or kerberos cases from the =20 lib-handling point of view (I'm talking about the ports<->basesystem =20 interaction, not about updating the lib in the basesystem). An idea which wasn't suggested yet is to install a renamed version (I =20 would suggest libbaseldap instead of libbsdldap or libldap_i, but I =20 don't really care about the name) and a link from the original name =20 (only the .so and .a, but not the .so.X) to the new name. This link =20 can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way =20 around... depending on what we want to achieve). This way it is =20 possible to link with the renamed lib in the base system, to use the =20 base system version of the lib in ports, and to use the lib from ports =20 if desired (a recompile of ports may be needed in the last case, yes). Bye, Alexander. --=20 The gent who wakes up and finds himself a success hasn't been asleep. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:35:27 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3184816A4E7; Wed, 23 Aug 2006 10:35:27 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B37A43D76; Wed, 23 Aug 2006 10:35:24 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E135.dip.t-dialin.net [84.165.225.53]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7NAHa2K025556; Wed, 23 Aug 2006 12:17:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7NAZTsi094790; Wed, 23 Aug 2006 12:35:29 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 23 Aug 2006 12:35:29 +0200 Message-ID: <20060823123529.06d3ayec08wwgwgc@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 23 Aug 2006 12:35:29 +0200 From: Alexander Leidinger To: Ryan Beasley References: <44EB72FC.8040508@FreeBSD.org> In-Reply-To: <44EB72FC.8040508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: [RFC] Summer of Code -- OSSv4 audio compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:35:27 -0000 Quoting Ryan Beasley (from Tue, 22 Aug 2006 =20 16:11:24 -0500): > Hello, current@ & multimedia@! > > =3D=3D=3D=3D=3D=3D Summary =3D=3D=3D=3D=3D=3D > I participated in Google's Summer of Code this year, working on adding > support for 4Front's OSSv4 API. > > Unfortunately, more of the API specifications were still under > construction than I expected, so I focused entirely on the audio > collection of ioctls and maybe just one or two mixer ioctls. While > official documentation isn't yet available, the mixer extensions, which > are one of the coolest parts of the new API, are my top priority. (I > think I now have enough reference material to begin work in that area.) Clarification: his top priority is not part of the SoC 2006 anymore. =20 The patch presented here is the outcome of the Soc. Anything from now =20 on (bugfixes and enhancements to this code) is not covered by the SoC =20 anymore but purely based upon his interest in improving his work. > For information on the ioctls, please take a look at > http://wiki.freebsd.org/RyanBeasley/ioctlref . > > =3D=3D=3D=3D=3D=3D Patch Info =3D=3D=3D=3D=3D=3D > A patch against recent -CURRENT is available at > http://www.leidinger.net/FreeBSD/sound/rbeasley_sound.diff . > > Comments, suggestions, etc., would be hugely appreciated! > > To apply, > =09cd /usr/src/sys > =09patch --quiet < rbeasley_sound.diff > > Then rebuild the sound/sound module and whichever modules are > appropriate for your sound card. You should also install the new > sys/soundcard.h. Building/installing the world and kernel after patching will do this =20 (in case you want to test this but don't know how to do this). > =3D=3D=3D=3D=3D=3D Testing =3D=3D=3D=3D=3D=3D > Please beat down on audio as much as possible. Note that some > applications might need to be recompiled in order to access the new > ioctls (sys/soundcard.h was tweaked). We are interested in the behavior of the applications without =20 recompiling them (ideally there's no change in behavior), and after =20 recompiling. > Two areas that were least tested by me were ioctls intended to be used > with mmap() (ex: SNDCTL_DSP_CURRENT_OPTR) and recording. Please keep an > eye on these. Bye, Alexander. --=20 Love is an ideal thing, marriage a real thing; a confusion of the real with the ideal never goes unpunished. =09=09-- Goethe http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:38:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C816816A4DA for ; Wed, 23 Aug 2006 10:38:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CBD43D8F for ; Wed, 23 Aug 2006 10:37:43 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k7NAa4Le027493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 13:36:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k7NAa5r1077724; Wed, 23 Aug 2006 13:36:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k7NAa48I077723; Wed, 23 Aug 2006 13:36:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2006 13:36:04 +0300 From: Kostik Belousov To: Alexander Leidinger Message-ID: <20060823103604.GB64800@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:38:34 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: > If someone doesn't like the base system libldap, but wants the =20 > nss_ldap stuff, this way will not work out. While building the base =20 > system, no 3rd party libs are known to the build infrastructure. >=20 > Conflicting libs aren't good and some people may want to have more =20 > recent versions of a lib installed. To solve this issue phk didn't =20 > importet "libxml", but renamed it to "libbsdxml" (we only need to =20 > update the lib if we need a new feature, or if there's a security =20 > problem). This way base system tools are able to use a XML lib while =20 > ports can use a more recent version of it (ports aren't using our =20 > version of the lib). >=20 > So this is not like the openssl or kerberos cases from the =20 > lib-handling point of view (I'm talking about the ports<->basesystem =20 > interaction, not about updating the lib in the basesystem). >=20 > An idea which wasn't suggested yet is to install a renamed version (I =20 > would suggest libbaseldap instead of libbsdldap or libldap_i, but I =20 > don't really care about the name) and a link from the original name =20 > (only the .so and .a, but not the .so.X) to the new name. This link =20 > can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way =20 > around... depending on what we want to achieve). This way it is =20 > possible to link with the renamed lib in the base system, to use the =20 > base system version of the lib in ports, and to use the lib from ports = =20 > if desired (a recompile of ports may be needed in the last case, yes). This will not work. bsdxml is used inside the system binaries. No binary links again expat and bsdxml simultaneously. Would such binary exists, it could experience problems. On the other hand, application using openldap from the ports has high chance loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against renamed library, this would cause the crash. In fact, similar problem was fixed not so long time ago by Dag-Erling in the pam_ssh (duplicating existing symbols by the pam). --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7C+UC3+MBN1Mb4gRAv7yAKCm6UCzJqHEnHDOUjEQaLn0LrDlNQCgkdS0 iv2EP6RcrT+TMDEtG5EkhUw= =LeKh -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:48:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D246116A4DD; Wed, 23 Aug 2006 10:48:09 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ECAF43E30; Wed, 23 Aug 2006 10:45:28 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E135.dip.t-dialin.net [84.165.225.53]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7NAQoCb025590; Wed, 23 Aug 2006 12:26:50 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7NAihux096093; Wed, 23 Aug 2006 12:44:43 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 23 Aug 2006 12:44:43 +0200 Message-ID: <20060823124443.4uwx8nnv488sw0so@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 23 Aug 2006 12:44:43 +0200 From: Alexander Leidinger To: Yuriy Tsibizov References: <78664C02FF341B4FAC63E561846E3BCC546A@ex.hhp.local> In-Reply-To: <78664C02FF341B4FAC63E561846E3BCC546A@ex.hhp.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: ryanb@freebsd.org, current@freebsd.org, multimedia@freebsd.org Subject: RE: [RFC] Summer of Code -- OSSv4 audio compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:48:10 -0000 Quoting Yuriy Tsibizov (from Wed, 23 Aug 2006 11:51:24 +0400): >> ====== Patch Info ====== >> A patch against recent -CURRENT is available at >> http://www.leidinger.net/FreeBSD/sound/rbeasley_sound.diff . >> >> Comments, suggestions, etc., would be hugely appreciated! > Ryan, will there be any changes for hardware drivers? There will be no changes to hardware drivers as part of the SoC (it's over now). The code you see is what is supposed to get committed to CVS (some bugfixes may be applied first, in case some show up) after review and testing. But yes, the mixer stuff (and maybe other things) may end up in drivers and he is looking at what can be done for the drivers he has hardware for. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:52:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D733016A4E2 for ; Wed, 23 Aug 2006 10:52:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ACDE43D83 for ; Wed, 23 Aug 2006 10:50:15 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 4C3DEEB430F; Wed, 23 Aug 2006 18:50:13 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id M1kCuMfaYbVq; Wed, 23 Aug 2006 18:50:11 +0800 (CST) Received: from [10.217.12.217] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 0E9F5EB4307; Wed, 23 Aug 2006 18:50:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type: organization:date:message-id:mime-version:x-mailer; b=NiTjKZqqj+/cD8gedZqWiIrQdttZ9OMthKmsM+D2wbAialeIBY7rlEgAYTl3pZejo N7xK5mPxVAIBSMgLqFF3w== From: =?UTF-8?Q?=E6=9D=8E=E9=91=AB?= "(LI Xin)" To: Kostik Belousov In-Reply-To: <20060823103604.GB64800@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SKcN1qA4YI7r16QG72Sq" Organization: The FreeBSD Project Date: Wed, 23 Aug 2006 18:49:55 +0800 Message-Id: <1156330195.2444.35.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: Alexander Leidinger , freebsd-current@freebsd.org, Michael Bushkov , Dag-Erling Sm??rgrav Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:52:58 -0000 --=-SKcN1qA4YI7r16QG72Sq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2006-08-23=E4=B8=89=E7=9A=84 13:36 +0300=EF=BC=8CKostik Belousov= =E5=86=99=E9=81=93=EF=BC=9A [snip] > > An idea which wasn't suggested yet is to install a renamed version (I =20 > > would suggest libbaseldap instead of libbsdldap or libldap_i, but I =20 > > don't really care about the name) and a link from the original name =20 > > (only the .so and .a, but not the .so.X) to the new name. This link =20 > > can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way =20 > > around... depending on what we want to achieve). This way it is =20 > > possible to link with the renamed lib in the base system, to use the =20 > > base system version of the lib in ports, and to use the lib from ports = =20 > > if desired (a recompile of ports may be needed in the last case, yes). >=20 > This will not work. bsdxml is used inside the system binaries. No binary > links again expat and bsdxml simultaneously. Would such binary exists, > it could experience problems. >=20 > On the other hand, application using openldap from the ports has high cha= nce > loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against > renamed library, this would cause the crash. >=20 > In fact, similar problem was fixed not so long time ago by Dag-Erling > in the pam_ssh (duplicating existing symbols by the pam). Maybe we can help him to extract some necessary routines out of the lber and ldap libraries, and make it an internal library (say, put into the nss module rather than installing a separate .so file)? Cheers, --=20 Xin LI http://www.delphij.net/ --=-SKcN1qA4YI7r16QG72Sq Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBE7DLThcUczkLqiksRAn9hAKDnHj4qaSuz0OU4phxLCChY+0rs9gCfYAO9 u9w6FBZHEDaFhPgnOSoiSfQ= =/VGS -----END PGP SIGNATURE----- --=-SKcN1qA4YI7r16QG72Sq-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 10:54:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E110C16A4E0 for ; Wed, 23 Aug 2006 10:54:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id E151643F22 for ; Wed, 23 Aug 2006 10:51:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so142031pye for ; Wed, 23 Aug 2006 03:51:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=BMaR7x4NDbLKO6LoN8uSmV7IRN/GrmMtuw0li3R6uV3JvF8iQKugk9+Kzobohq2BSZ8ssjmLkgl9eQe0SBekhjBpJDe/MbOCN1q7llZPBcphO+3CnNyYFG8P48VA3HNzeLvJ/AvbxgXQ3R51ujGNrRq0tSH0O/Inm6DdfCPegY8= Received: by 10.35.66.12 with SMTP id t12mr358374pyk; Wed, 23 Aug 2006 03:51:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 10sm689920nzo.2006.08.23.03.51.20; Wed, 23 Aug 2006 03:51:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7NApIba020158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 19:51:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7NApIh6020157; Wed, 23 Aug 2006 19:51:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 19:51:18 +0900 From: Pyun YongHyeon To: Gleb Smirnoff Message-ID: <20060823105118.GJ17902@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> <20060823095504.GI17902@cdnetworks.co.kr> <20060823100420.GG96644@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823100420.GG96644@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 10:54:47 -0000 On Wed, Aug 23, 2006 at 02:04:20PM +0400, Gleb Smirnoff wrote: > On Wed, Aug 23, 2006 at 06:55:04PM +0900, Pyun YongHyeon wrote: > P> On Wed, Aug 23, 2006 at 01:37:41PM +0400, Gleb Smirnoff wrote: > P> > On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: > P> > P> After fixing em(4) watchdog bug, I looked over bge(4) and I think > P> > P> bge(4) may suffer from the same issue. So if you have seen occasional > P> > P> watchdog timeout errors on bge(4) please give the attached patch a try. > P> > P> The patch does fix false watchdog timeout error only. > P> > P> Typical pheonoma for false watchdog timeout error are > P> > P> o polling(4) fix the issue > P> > P> o random watchdog error > P> > P> > P> > P> If my patch fix the issue you could see the following messages. > P> > P> "missing Tx completion interrupt!" or "link lost -- resetting" > P> > > P> > I still think that this fix is incorrect. It is just a more gentle > P> > recovery from a fake watchdog timeout. > P> > P> Its sole purpose is to reinitialize hardware for real watchdog > P> timeouts. It's not fix for general watchdog timeouts. As I said other > P> mails, the fake watchdog timeout(losing Tx interrupts) for hardwares > P> with Tx interrupt moderation capability could be normal thing. So I > P> just want to know bge(4) also has the same feature(bug). > > According to several emails about em(4) fake watchdog timeouts, the > problem can be fixed by setting debug.mpsafenet=0. This makes me think > that the problem isn't caused by TX interrupt moderation, but some race > in the kernel. Really, if_slowtimo() doesn't acquire driver lock before > checking and modifying the if_timer field. > Hmm... I didn't say the problem was caused by TX interrupt moderation. I can't sure but I'm under the impression it has *two* different issues. If you think fake watchdog timeout fix is not adequate one please let me know. I'll backout the change if you want. > Afaik, NIC drivers that can do interrupt moderation should set a timer > to a sane value, based on interrupt moderation settings, so that the > watchdog won't be ever called fakely. > Yes. Normally it should. But I saw the issues on Marvell Yukon too. > P> > The more I think, the more I doubt that we really need the > P> > watchdog infrastructure that comes from old days. > P> > P> Would you give other way to recover from Tx stuck condition without > P> using watchdog? > > May be driver should take care of that theirselves, why not? At least > the callout routine will have access to the driver mutex, contrary to > if_slowtimo(). > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:03:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BCDF16A4DD for ; Wed, 23 Aug 2006 11:03:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9660943D7C for ; Wed, 23 Aug 2006 11:03:30 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k7NB2v2j028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 14:02:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k7NB2x2P082625; Wed, 23 Aug 2006 14:02:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k7NB2x7b082624; Wed, 23 Aug 2006 14:02:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2006 14:02:59 +0300 From: Kostik Belousov To: LI Xin Message-ID: <20060823110258.GC64800@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <1156330195.2444.35.camel@spirit> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:03:32 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 06:49:55PM +0800, ?????? (LI Xin) wrote: > ??? 2006-08-23?????? 13:36 +0300???Kostik Belousov????????? > [snip] > > > An idea which wasn't suggested yet is to install a renamed version (I= =20 > > > would suggest libbaseldap instead of libbsdldap or libldap_i, but I = =20 > > > don't really care about the name) and a link from the original name = =20 > > > (only the .so and .a, but not the .so.X) to the new name. This link = =20 > > > can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way= =20 > > > around... depending on what we want to achieve). This way it is =20 > > > possible to link with the renamed lib in the base system, to use the = =20 > > > base system version of the lib in ports, and to use the lib from port= s =20 > > > if desired (a recompile of ports may be needed in the last case, yes). > >=20 > > This will not work. bsdxml is used inside the system binaries. No binary > > links again expat and bsdxml simultaneously. Would such binary exists, > > it could experience problems. > >=20 > > On the other hand, application using openldap from the ports has high c= hance > > loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked again= st > > renamed library, this would cause the crash. > >=20 > > In fact, similar problem was fixed not so long time ago by Dag-Erling > > in the pam_ssh (duplicating existing symbols by the pam). >=20 > Maybe we can help him to extract some necessary routines out of the lber > and ldap libraries, and make it an internal library (say, put into the > nss module rather than installing a separate .so file)? May be. Moreover, this module (and any nss module) shall export only symbols needed by nss interface, not polluting the global namespace of process. --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7DXiC3+MBN1Mb4gRAmJFAKCfSfhib/qpwz3kkfifhHal+n2cpgCfevee rST517myFjvcLH59c5ZfpuY= =RL3b -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:06:23 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC60616A4DD for ; Wed, 23 Aug 2006 11:06:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F070A43D45 for ; Wed, 23 Aug 2006 11:06:22 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7NB6KCK075202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 15:06:20 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7NB6Jks075201; Wed, 23 Aug 2006 15:06:19 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Aug 2006 15:06:19 +0400 From: Gleb Smirnoff To: Pyun YongHyeon Message-ID: <20060823110619.GL96644@cell.sick.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> <20060823095504.GI17902@cdnetworks.co.kr> <20060823100420.GG96644@cell.sick.ru> <20060823105118.GJ17902@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060823105118.GJ17902@cdnetworks.co.kr> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:06:23 -0000 On Wed, Aug 23, 2006 at 07:51:18PM +0900, Pyun YongHyeon wrote: P> > P> Its sole purpose is to reinitialize hardware for real watchdog P> > P> timeouts. It's not fix for general watchdog timeouts. As I said other P> > P> mails, the fake watchdog timeout(losing Tx interrupts) for hardwares P> > P> with Tx interrupt moderation capability could be normal thing. So I P> > P> just want to know bge(4) also has the same feature(bug). P> > P> > According to several emails about em(4) fake watchdog timeouts, the P> > problem can be fixed by setting debug.mpsafenet=0. This makes me think P> > that the problem isn't caused by TX interrupt moderation, but some race P> > in the kernel. Really, if_slowtimo() doesn't acquire driver lock before P> > checking and modifying the if_timer field. P> > P> P> Hmm... I didn't say the problem was caused by TX interrupt moderation. P> I can't sure but I'm under the impression it has *two* different issues. P> If you think fake watchdog timeout fix is not adequate one please P> let me know. I'll backout the change if you want. I don't think you should backout it until we find a solution. However, I'd ask you don't MFC it. P> > Afaik, NIC drivers that can do interrupt moderation should set a timer P> > to a sane value, based on interrupt moderation settings, so that the P> > watchdog won't be ever called fakely. P> P> Yes. Normally it should. But I saw the issues on Marvell Yukon too. Does Marvell Yukon have interrupt moderation? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:11:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B477D16A4DD for ; Wed, 23 Aug 2006 11:11:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB16B43D66 for ; Wed, 23 Aug 2006 11:11:08 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so148383pye for ; Wed, 23 Aug 2006 04:11:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Yzz1LFZ9g9K/Y9PD/4Wkg6lMPjx34/XRY45+A6M00qamYy3U3E1av4ExgAg4uI4+A1LFZqqoCk2F60n3e0r/ZhF+5fd0UEr1q3A/yLC8umb0FRwAPq8AntdqyyaXq3zvKdudvSw8s7xZGW2Tb8JBQ/9R4isNxDKWNISXDCNFG6Y= Received: by 10.35.38.17 with SMTP id q17mr383949pyj; Wed, 23 Aug 2006 04:11:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm41926nzp.2006.08.23.04.11.06; Wed, 23 Aug 2006 04:11:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7NBB8eD020255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 20:11:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7NBB8kw020254; Wed, 23 Aug 2006 20:11:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 20:11:08 +0900 From: Pyun YongHyeon To: Gleb Smirnoff Message-ID: <20060823111108.GK17902@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> <20060823095504.GI17902@cdnetworks.co.kr> <20060823100420.GG96644@cell.sick.ru> <20060823105118.GJ17902@cdnetworks.co.kr> <20060823110619.GL96644@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823110619.GL96644@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:11:17 -0000 On Wed, Aug 23, 2006 at 03:06:19PM +0400, Gleb Smirnoff wrote: > On Wed, Aug 23, 2006 at 07:51:18PM +0900, Pyun YongHyeon wrote: > P> > P> Its sole purpose is to reinitialize hardware for real watchdog > P> > P> timeouts. It's not fix for general watchdog timeouts. As I said other > P> > P> mails, the fake watchdog timeout(losing Tx interrupts) for hardwares > P> > P> with Tx interrupt moderation capability could be normal thing. So I > P> > P> just want to know bge(4) also has the same feature(bug). > P> > > P> > According to several emails about em(4) fake watchdog timeouts, the > P> > problem can be fixed by setting debug.mpsafenet=0. This makes me think > P> > that the problem isn't caused by TX interrupt moderation, but some race > P> > in the kernel. Really, if_slowtimo() doesn't acquire driver lock before > P> > checking and modifying the if_timer field. > P> > > P> > P> Hmm... I didn't say the problem was caused by TX interrupt moderation. > P> I can't sure but I'm under the impression it has *two* different issues. > P> If you think fake watchdog timeout fix is not adequate one please > P> let me know. I'll backout the change if you want. > > I don't think you should backout it until we find a solution. > However, I'd ask you don't MFC it. > ok. Lets find out real cause of bug. > P> > Afaik, NIC drivers that can do interrupt moderation should set a timer > P> > to a sane value, based on interrupt moderation settings, so that the > P> > watchdog won't be ever called fakely. > P> > P> Yes. Normally it should. But I saw the issues on Marvell Yukon too. > > Does Marvell Yukon have interrupt moderation? > Yes. Check archives for sk(4) watchdog. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:42:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D814D16A557 for ; Wed, 23 Aug 2006 11:42:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D60243D68 for ; Wed, 23 Aug 2006 11:41:05 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1445220A5; Wed, 23 Aug 2006 13:40:56 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id E2C252084; Wed, 23 Aug 2006 13:40:55 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 40B3833C24; Wed, 23 Aug 2006 13:40:55 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Kostik Belousov References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> <20060823110258.GC64800@deviant.kiev.zoral.com.ua> Date: Wed, 23 Aug 2006 13:40:55 +0200 In-Reply-To: <20060823110258.GC64800@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Wed, 23 Aug 2006 14:02:59 +0300") Message-ID: <86y7tfznlk.fsf@xps.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:42:10 -0000 Kostik Belousov writes: > LI Xin writes: > > Kostik Belousov writes: > > > In fact, similar problem was fixed not so long time ago by Dag-Erling > > > in the pam_ssh (duplicating existing symbols by the pam). No, that was not a comparable scenario. > > Maybe we can help him to extract some necessary routines out of the lber > > and ldap libraries, and make it an internal library (say, put into the > > nss module rather than installing a separate .so file)? > May be. Moreover, this module (and any nss module) shall export only symb= ols > needed by nss interface, not polluting the global namespace of process. Please stop the madness. The simplest solution is to import OpenLDAP unmodified, and if someone is unhappy with the base system's libldap, they can build world WITHOUT_OPENLDAP. Now run along and find another bikeshed to paint, please. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:46:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47E2016A4DD for ; Wed, 23 Aug 2006 11:46:45 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A3B43D45 for ; Wed, 23 Aug 2006 11:46:44 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 45D7720A5; Wed, 23 Aug 2006 13:46:41 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id B10622084; Wed, 23 Aug 2006 13:46:40 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 7522933C24; Wed, 23 Aug 2006 13:46:40 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Alexander Leidinger References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> Date: Wed, 23 Aug 2006 13:46:40 +0200 In-Reply-To: <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> (Alexander Leidinger's message of "Wed, 23 Aug 2006 12:11:57 +0200") Message-ID: <86u043znbz.fsf@xps.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:46:45 -0000 Alexander Leidinger writes: > Michael Bushkov writes:(from Tue, 22 Aug 2006 > > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > > also conflict with PADL's nss_ldap) as is and let users use > > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. > If someone doesn't like the base system libldap, but wants the > nss_ldap stuff, this way will not work out. While building the base > system, no 3rd party libs are known to the build infrastructure. Wrong. It is already possible in today's tree to build the base system's Kerberos with OpenLDAP support using the OpenLDAP port, and there are similar provisions for using OpenSSL from ports. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 11:59:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E44316A4DD for ; Wed, 23 Aug 2006 11:59:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA26343D5D for ; Wed, 23 Aug 2006 11:59:49 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 47815 invoked from network); 23 Aug 2006 11:47:27 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Aug 2006 11:47:27 -0000 Message-ID: <44EC4334.20706@freebsd.org> Date: Wed, 23 Aug 2006 13:59:48 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> <20060823110258.GC64800@deviant.kiev.zoral.com.ua> <86y7tfznlk.fsf@xps.des.no> In-Reply-To: <86y7tfznlk.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Kostik Belousov , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 11:59:51 -0000 Dag-Erling Smørgrav wrote: > Kostik Belousov writes: > >>LI Xin writes: >> >>>Kostik Belousov writes: >>> >>>>In fact, similar problem was fixed not so long time ago by Dag-Erling >>>>in the pam_ssh (duplicating existing symbols by the pam). > > > No, that was not a comparable scenario. > > >>>Maybe we can help him to extract some necessary routines out of the lber >>>and ldap libraries, and make it an internal library (say, put into the >>>nss module rather than installing a separate .so file)? >> >>May be. Moreover, this module (and any nss module) shall export only symbols >>needed by nss interface, not polluting the global namespace of process. > > > Please stop the madness. The simplest solution is to import OpenLDAP > unmodified, and if someone is unhappy with the base system's libldap, > they can build world WITHOUT_OPENLDAP. OpenLDAP is really big and has different parts. We should certainly not import the OpenLDAP serve stuff into base. But then the problem comes up how to install just the server from ports and have the library already in the base system. As someone else said OpenLDAP moves pretty fast and does a lot of releases and fixes. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 12:09:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8319D16A4EC for ; Wed, 23 Aug 2006 12:09:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 223D343D78 for ; Wed, 23 Aug 2006 12:09:28 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 20656EB3652; Wed, 23 Aug 2006 20:09:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id hQc36PQcCyYO; Wed, 23 Aug 2006 20:09:21 +0800 (CST) Received: from [10.217.12.217] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id C81EFEB0E3A; Wed, 23 Aug 2006 20:09:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type: organization:date:message-id:mime-version:x-mailer; b=GKckCdKe9qK7tsCbPodlzrTa1pqzOaGRrYYA7quPgln8dbw58o525BqkCuSfiI9TF awpVSFWy4mtl5AfCDS/1w== From: =?UTF-8?Q?=E6=9D=8E=E9=91=AB?= "(LI Xin)" To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86y7tfznlk.fsf@xps.des.no> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> <20060823110258.GC64800@deviant.kiev.zoral.com.ua> <86y7tfznlk.fsf@xps.des.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TNmnlFE4pBfuT40sOERJ" Organization: The FreeBSD Project Date: Wed, 23 Aug 2006 20:09:17 +0800 Message-Id: <1156334957.3396.2.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: Kostik Belousov , freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 12:09:38 -0000 --=-TNmnlFE4pBfuT40sOERJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2006-08-23=E4=B8=89=E7=9A=84 13:40 +0200=EF=BC=8CDag-Erling Sm=C3= =B8rgrav=E5=86=99=E9=81=93=EF=BC=9A [...] > > > Maybe we can help him to extract some necessary routines out of the l= ber > > > and ldap libraries, and make it an internal library (say, put into th= e > > > nss module rather than installing a separate .so file)? > > May be. Moreover, this module (and any nss module) shall export only sy= mbols > > needed by nss interface, not polluting the global namespace of process. >=20 > Please stop the madness. The simplest solution is to import OpenLDAP > unmodified, and if someone is unhappy with the base system's libldap, > they can build world WITHOUT_OPENLDAP. I think I can live with this. The only (slight) problem remains is that we should provide either a mechanism to remove installed base OpenLDAP libraries, or a sysinstall(8) option. Cheers, --=20 Xin LI http://www.delphij.net/ --=-TNmnlFE4pBfuT40sOERJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBE7EVthcUczkLqiksRAtnrAJ4wqNNIBfcWBbEUs5LHgeJfIHELsQCeOjBY uFUG5vwjv7WkxANO77u559k= =qFtk -----END PGP SIGNATURE----- --=-TNmnlFE4pBfuT40sOERJ-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 12:18:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D5B16A4DF for ; Wed, 23 Aug 2006 12:18:31 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBEC143D45 for ; Wed, 23 Aug 2006 12:18:30 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.164]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7NCHfRr006242; Wed, 23 Aug 2006 16:17:51 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GFrek-0000Dw-C1; Wed, 23 Aug 2006 16:16:26 +0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> From: Boris Samorodov Date: Wed, 23 Aug 2006 16:16:26 +0400 In-Reply-To: <86u043znbz.fsf@xps.des.no> (Dag-Erling =?iso-8859-1?Q?Sm=F8r?= =?iso-8859-1?Q?grav's?= message of "Wed, 23 Aug 2006 13:46:40 +0200") Message-ID: <93154117@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: Boris Samorodov Cc: Alexander Leidinger , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 12:18:31 -0000 On Wed, 23 Aug 2006 13:46:40 +0200 Dag-Erling Sm=F8rgrav wrote: > Alexander Leidinger writes: > > Michael Bushkov writes:(from Tue, 22 Aug 2006 > > > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > > > also conflict with PADL's nss_ldap) as is and let users use > > > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. > > If someone doesn't like the base system libldap, but wants the > > nss_ldap stuff, this way will not work out. While building the base > > system, no 3rd party libs are known to the build infrastructure. > Wrong. It is already possible in today's tree to build the base > system's Kerberos with OpenLDAP support using the OpenLDAP port, and > there are similar provisions for using OpenSSL from ports. Can you point me where I can read about this capability? Thanks. WBR --=20 Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 12:24:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 975AD16A4DE; Wed, 23 Aug 2006 12:24:10 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12DAC43D5D; Wed, 23 Aug 2006 12:24:10 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 79A4820A5; Wed, 23 Aug 2006 14:24:04 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id E8A4F2084; Wed, 23 Aug 2006 14:24:03 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id CD53B33C24; Wed, 23 Aug 2006 14:24:03 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Andre Oppermann References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> <20060823110258.GC64800@deviant.kiev.zoral.com.ua> <86y7tfznlk.fsf@xps.des.no> <44EC4334.20706@freebsd.org> Date: Wed, 23 Aug 2006 14:24:03 +0200 In-Reply-To: <44EC4334.20706@freebsd.org> (Andre Oppermann's message of "Wed, 23 Aug 2006 13:59:48 +0200") Message-ID: <86lkpfzllo.fsf@xps.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 12:24:10 -0000 Andre Oppermann writes: > OpenLDAP is really big and has different parts. We should certainly not > import the OpenLDAP serve stuff into base. But then the problem comes up > how to install just the server from ports and have the library already in > the base system. As someone else said OpenLDAP moves pretty fast and does > a lot of releases and fixes. Split the port into library and server parts, as is usual in the Linux world. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 12:40:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0886116A4E1 for ; Wed, 23 Aug 2006 12:40:46 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B36043DD1 for ; Wed, 23 Aug 2006 12:40:37 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7NCeZ0F018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 16:40:35 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7NCeZg3018982; Wed, 23 Aug 2006 16:40:35 +0400 (MSD) (envelope-from oleg) Date: Wed, 23 Aug 2006 16:40:35 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060823124035.GA18628@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823005554.GC17902@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 12:40:46 -0000 On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > ... > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > >is a possiblity to have the same issue seen on em(4). > > > >If you want my blind patch I can send a patch for you. > > > > > > > Yes, please! > > > I can test it (on RELENG_6 though). > > > > I have an idea why those timeouts can happen. Could you please test > > attached patch? It may help (or may not). Anyway would be fine > > to know results. > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > protected with the mutex I guess it wouldn't help much. > I guess it needs a seperate mutex to protect miibus(4) handler > and should remove the use of MTX_RECURSE. Hmm. 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. 2) As i can see MII layer is not protected by anything, unless you specially acquire driver lock prior to calling mii_ function. Locking ifmedia callbacks should be done (though, it may not help with watchdogs timeout), otherwise we have race on accessing PHY registers. (kern/98738). As i can see, random watchdog timeouts was reported for em, bge, vge, sk (and maybe others, those ones which i remember) drivers. All of them has unlocked _ifmedia_ functions. My idea was: perhaps, under certain condition, concurrent access to PHY could lead to hardware deadlock. > vge(4) also has a bug > if mbuf chain is too long(7 or higher) and defragmentation with > m_defrag(9) fails it would access an invalid mbuf chain. > All these requires lots of work and need a real hardware. > Oleg, if you have hardware, would you fix it? Unfortunately i don't have vge hardware. > > -- > Regards, > Pyun YongHyeon -- Oleg. From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 12:54:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 927CA16A4E2 for ; Wed, 23 Aug 2006 12:54:41 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA9343D86 for ; Wed, 23 Aug 2006 12:54:36 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7NCsZ4n019218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 16:54:35 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7NCsYWs019217; Wed, 23 Aug 2006 16:54:34 +0400 (MSD) (envelope-from oleg) Date: Wed, 23 Aug 2006 16:54:34 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060823125434.GA19111@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823124035.GA18628@lath.rinet.ru> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 12:54:41 -0000 On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > ... > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > >is a possiblity to have the same issue seen on em(4). > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > Yes, please! > > > > I can test it (on RELENG_6 though). > > > > > > I have an idea why those timeouts can happen. Could you please test > > > attached patch? It may help (or may not). Anyway would be fine > > > to know results. > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > protected with the mutex I guess it wouldn't help much. > > I guess it needs a seperate mutex to protect miibus(4) handler > > and should remove the use of MTX_RECURSE. > > Hmm. > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > 2) As i can see MII layer is not protected by anything, unless you > specially acquire driver lock prior to calling mii_ function. > Locking ifmedia callbacks should be done (though, it may not help > with watchdogs timeout), otherwise we have race on accessing PHY registers. > (kern/98738). > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > (and maybe others, those ones which i remember) drivers. > All of them has unlocked _ifmedia_ functions. > > My idea was: perhaps, under certain condition, concurrent access to PHY could > lead to hardware deadlock. > > > > vge(4) also has a bug > > if mbuf chain is too long(7 or higher) and defragmentation with > > m_defrag(9) fails it would access an invalid mbuf chain. > > All these requires lots of work and need a real hardware. > > Oleg, if you have hardware, would you fix it? > > Unfortunately i don't have vge hardware. > > > > -- > > Regards, > > Pyun YongHyeon > > -- > Oleg. > Forgot one thing: i think we need no dedicated mutex for mii layer if we lock ifmedia callbacks. -- Oleg. From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 13:45:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D3AA16A4DA for ; Wed, 23 Aug 2006 13:45:40 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5932843D45 for ; Wed, 23 Aug 2006 13:45:39 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-88-245.sn2.eutelia.it [83.211.88.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id EB08511B324; Wed, 23 Aug 2006 15:45:39 +0200 (CEST) Received: from newluxor.wired.org (localhost [127.0.0.1]) by newluxor.wired.org (8.13.8/8.13.8) with ESMTP id k7NDhdlZ001506; Wed, 23 Aug 2006 15:43:40 +0200 (CEST) (envelope-from flag@newluxor.wired.org) Received: (from flag@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id k7NDhdqT001504; Wed, 23 Aug 2006 15:43:39 +0200 (CEST) (envelope-from flag) Date: Wed, 23 Aug 2006 15:43:34 +0200 From: Paolo Pisati To: Pyun YongHyeon Message-ID: <20060823134334.GB1424@tin.it> References: <20060819211853.GA1016@tin.it> <20060823084817.GH17902@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823084817.GH17902@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: FreeBSD_Current Subject: Re: Fatal trap 30 when loading if_xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 13:45:40 -0000 On Wed, Aug 23, 2006 at 05:48:17PM +0900, Pyun YongHyeon wrote: > > I've run into this too. It seems loading kernel module drivers > with kldload(8) triggers the issue. Any ideas? Nope, didn't have time to investigate, so i workarounded the issue loading all modules at boot time. bye -- Paolo Piso's first law: nothing works as expected! From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 14:41:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B92BA16A4DA for ; Wed, 23 Aug 2006 14:41:44 +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 2F4F043D4C for ; Wed, 23 Aug 2006 14:41:41 +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 <20060823144139m910087qhde>; Wed, 23 Aug 2006 14:41:40 +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 k7NEfQif025016; Wed, 23 Aug 2006 09:41:32 -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 k7NEfODv025015; Wed, 23 Aug 2006 09:41:24 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 09:41:24 -0500 From: Brooks Davis To: "?????? (LI Xin)" Message-ID: <20060823144124.GA24652@lor.one-eyed-alien.net> References: <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <1156330195.2444.35.camel@spirit> <20060823110258.GC64800@deviant.kiev.zoral.com.ua> <86y7tfznlk.fsf@xps.des.no> <1156334957.3396.2.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <1156334957.3396.2.camel@spirit> User-Agent: Mutt/1.5.11 Cc: Kostik Belousov , Dag-Erling Sm?rgrav , freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 14:41:44 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 08:09:17PM +0800, ?????? (LI Xin) wrote: > ??? 2006-08-23?????? 13:40 +0200???Dag-Erling Sm??rgrav????????? > [...] > > > > Maybe we can help him to extract some necessary routines out of the= lber > > > > and ldap libraries, and make it an internal library (say, put into = the > > > > nss module rather than installing a separate .so file)? > > > May be. Moreover, this module (and any nss module) shall export only = symbols > > > needed by nss interface, not polluting the global namespace of proces= s. > >=20 > > Please stop the madness. The simplest solution is to import OpenLDAP > > unmodified, and if someone is unhappy with the base system's libldap, > > they can build world WITHOUT_OPENLDAP. >=20 > I think I can live with this. The only (slight) problem remains is that > we should provide either a mechanism to remove installed base OpenLDAP > libraries, or a sysinstall(8) option. Set WITHOUT_OPENLDAP and use the delete-old and delete-old-libs targets in src/Makefile. As long as WITHOUT_OPENLDAP is implemented correctly this will work. -- Brooks --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7GkUXY6L6fI4GtQRAisPAJ0cmyCBt770nUwFIYHfj/ft4Jl7HACg5h75 bT10Npq+FffvMrZ05y+0GiQ= =ZVps -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 14:43:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D0AE16A4E0 for ; Wed, 23 Aug 2006 14:43:56 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A389E43D58 for ; Wed, 23 Aug 2006 14:43:54 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.143]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7NEhasj045940; Wed, 23 Aug 2006 18:43:46 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GFtvy-0000Bh-O0; Wed, 23 Aug 2006 18:42:22 +0400 To: Divacky Roman References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> From: Boris Samorodov Date: Wed, 23 Aug 2006 18:42:22 +0400 In-Reply-To: <20060821134635.GA27362@stud.fit.vutbr.cz> (Divacky Roman's message of "Mon, 21 Aug 2006 15:46:35 +0200") Message-ID: <37794465@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: Paul Mather , freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 14:43:56 -0000 On Mon, 21 Aug 2006 15:46:35 +0200 Divacky Roman wrote: > > it seems like very trivial so expect patch today ;) > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch Applied cleanly but didn't compile: ----- Warning: Object directory not changed from original /usr/src/sys/modules/linux cc -O2 -fno-strict-aliasing -pipe -DDEBUG -DCOMPAT_IA32 -DCOMPAT_LINUX32 -DDEBUG -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/linux/../../compat/linux/linux_stats.c /usr/src/sys/modules/linux/../../compat/linux/linux_stats.c: In function `linux_statfs64': /usr/src/sys/modules/linux/../../compat/linux/linux_stats.c:427: error: structure has no member named `path' /usr/src/sys/modules/linux/../../compat/linux/linux_stats.c:438: error: structure has no member named `buf' *** Error code 1 Stop in /usr/src/sys/modules/linux. ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 14:44:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3621116A4EA for ; Wed, 23 Aug 2006 14:44:07 +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 96CD243D49 for ; Wed, 23 Aug 2006 14:44:06 +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 <20060823144400m910086agle>; Wed, 23 Aug 2006 14:44:05 +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 k7NEholl025033; Wed, 23 Aug 2006 09:43:51 -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 k7NEhmVq025032; Wed, 23 Aug 2006 09:43:48 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 09:43:47 -0500 From: Brooks Davis To: Dag-Erling Sm?rgrav Message-ID: <20060823144347.GB24652@lor.one-eyed-alien.net> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline In-Reply-To: <86u043znbz.fsf@xps.des.no> User-Agent: Mutt/1.5.11 Cc: Alexander Leidinger , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 14:44:07 -0000 --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 01:46:40PM +0200, Dag-Erling Sm?rgrav wrote: > Alexander Leidinger writes: > > Michael Bushkov writes:(from Tue, 22 Aug 2006 > > > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > > > also conflict with PADL's nss_ldap) as is and let users use > > > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. > > If someone doesn't like the base system libldap, but wants the > > nss_ldap stuff, this way will not work out. While building the base > > system, no 3rd party libs are known to the build infrastructure. >=20 > Wrong. It is already possible in today's tree to build the base > system's Kerberos with OpenLDAP support using the OpenLDAP port, and > there are similar provisions for using OpenSSL from ports. It's also possible to build sendmail with SASL support: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/smtp-auth.html -- Brooks --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7GmjXY6L6fI4GtQRAlh2AJ9646axggDaVAFYz1Z3UdTGQEoqTgCfXNh/ tMhrP6516iCH6n4nPGehDF8= =nTd4 -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 15:23:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 559B716A4DE for ; Wed, 23 Aug 2006 15:23:31 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DCF843D4C for ; Wed, 23 Aug 2006 15:23:29 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E135.dip.t-dialin.net [84.165.225.53]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7NF5KFp026514; Wed, 23 Aug 2006 17:05:21 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7NFNG1R036460; Wed, 23 Aug 2006 17:23:16 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 23 Aug 2006 17:23:16 +0200 Message-ID: <20060823172316.dh1k8h6940ogw8o8@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 23 Aug 2006 17:23:16 +0200 From: Alexander Leidinger To: Kostik Belousov References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> In-Reply-To: <20060823103604.GB64800@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 15:23:31 -0000 Quoting Kostik Belousov (from Wed, 23 Aug 2006 =20 13:36:04 +0300): > On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: >> An idea which wasn't suggested yet is to install a renamed version (I >> would suggest libbaseldap instead of libbsdldap or libldap_i, but I >> don't really care about the name) and a link from the original name >> (only the .so and .a, but not the .so.X) to the new name. This link >> can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way >> around... depending on what we want to achieve). This way it is >> possible to link with the renamed lib in the base system, to use the >> base system version of the lib in ports, and to use the lib from ports >> if desired (a recompile of ports may be needed in the last case, yes). > > This will not work. bsdxml is used inside the system binaries. No binary > links again expat and bsdxml simultaneously. Would such binary exists, > it could experience problems. > > On the other hand, application using openldap from the ports has high chan= ce > loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against > renamed library, this would cause the crash. And this can't be solved with symbol versioning? Bye, Alexander. --=20 cobweb site n. A World Wide Web Site that hasn't been updated so long it has figuratively grown cobwebs. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 15:47:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A16A16A4E5 for ; Wed, 23 Aug 2006 15:47:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 231D043D5F for ; Wed, 23 Aug 2006 15:47:16 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k7NFkp1X036180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 18:46:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k7NFkr80060550; Wed, 23 Aug 2006 18:46:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k7NFkqcu060549; Wed, 23 Aug 2006 18:46:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2006 18:46:52 +0300 From: Kostik Belousov To: Alexander Leidinger Message-ID: <20060823154652.GA84619@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <20060823172316.dh1k8h6940ogw8o8@netchild.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20060823172316.dh1k8h6940ogw8o8@netchild.homeip.net> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 15:47:28 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 05:23:16PM +0200, Alexander Leidinger wrote: > Quoting Kostik Belousov (from Wed, 23 Aug 2006 =20 > 13:36:04 +0300): >=20 > >On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: >=20 > >>An idea which wasn't suggested yet is to install a renamed version (I > >>would suggest libbaseldap instead of libbsdldap or libldap_i, but I > >>don't really care about the name) and a link from the original name > >>(only the .so and .a, but not the .so.X) to the new name. This link > >>can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way > >>around... depending on what we want to achieve). This way it is > >>possible to link with the renamed lib in the base system, to use the > >>base system version of the lib in ports, and to use the lib from ports > >>if desired (a recompile of ports may be needed in the last case, yes). > > > >This will not work. bsdxml is used inside the system binaries. No binary > >links again expat and bsdxml simultaneously. Would such binary exists, > >it could experience problems. > > > >On the other hand, application using openldap from the ports has high=20 > >chance > >loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against > >renamed library, this would cause the crash. >=20 > And this can't be solved with symbol versioning? Probably not. Default openldap build produces unversioned libraries. Application linked against such library would happily resolve symbols from the versioned lib. --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7HhrC3+MBN1Mb4gRArRQAKDMz3YDO3TzdV0eaZr/rACgj6BZlACdE4vh auLwA3F0p6o/aMuL+ym9fpY= =o6zh -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 15:50:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A04C16A4FE for ; Wed, 23 Aug 2006 15:50:32 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F17F43DAD for ; Wed, 23 Aug 2006 15:49:58 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-71-254-64-250.ronkva.east.verizon.net [71.254.64.250]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7NFnuUK096983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Aug 2006 11:49:57 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7NFnuSG050273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Aug 2006 11:49:56 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7NFntfK050272; Wed, 23 Aug 2006 11:49:55 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Divacky Roman In-Reply-To: <20060821134635.GA27362@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2006 11:49:53 -0400 Message-Id: <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 15:50:32 -0000 On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > it seems like very trivial so expect patch today ;) > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > pls tell me if this works, thnx The patch applied and built on i386. However, when I run the resultant kernel, the problem of the "syscall statfs64 not implemented" messages goes away but my Tivoli backup still fails (in a different way). (The same Tivoli client and setup worked on i386 -CURRENT prior to mid-August, and currently is working on an i386 6.1-STABLE system.) Now, when the scheduled backup runs, I get things like this in my dsmerror.log: 08/23/06 02:58:37 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 02:58:38 ANS1228E Sending of object '/backup' failed 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' failed 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' failed 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. 08/23/06 02:58:40 ANS1512E Scheduled event 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. I don't know if this indicates that there is a problem with the implementation of statfs64/statfs, now. (I don't know if it complicates matters, but I'm backing up mounted snapshots.) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 16:14:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 964AD16A580 for ; Wed, 23 Aug 2006 16:14:03 +0000 (UTC) (envelope-from amurphy@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 159AA43D46 for ; Wed, 23 Aug 2006 16:14:02 +0000 (GMT) (envelope-from amurphy@gsoft.com.au) Received: from [203.31.81.19] (dialin2.gsoft.com.au [203.31.81.19]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k7NGDmcD065856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 01:43:50 +0930 (CST) (envelope-from amurphy@gsoft.com.au) Message-ID: <44EC7EBA.7080303@gsoft.com.au> Date: Thu, 24 Aug 2006 01:43:46 +0930 From: Adrian Murphy User-Agent: Thunderbird 1.5.0.5 (X11/20060810) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.604 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Subject: Cardbus problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 16:14:03 -0000 Hi, I have had a problem using the ndis driver for my wireless cardbus adapter since I updated current in April. The wireless card is an Alloy WLT245401 model with a Texas Instruments chipset. With a current from November 2005, I used the wireless adapter successfully. I updated current yesterday and still no joy: FreeBSD priscilla.gsoft.com.au 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Wed Aug 23 08:34:10 CST 2006 root@priscilla.gsoft.com.au:/usr/obj/usr/src/sys/PRISCILLA i386 When I insert the wireless card, I see the following in /var/log/messages: Aug 21 18:29:53 priscilla kernel: cardbus0: CIS pointer is 0x1c02 Aug 21 18:29:53 priscilla kernel: cardbus0: CIS in BAR 0x14 Aug 21 18:29:53 priscilla kernel: cardbus0: Expecting link target, got 0x8 Aug 21 18:29:53 priscilla kernel: cardbus0: Warning: Bogus CIS ignored Aug 21 18:29:53 priscilla kernel: ndis0: mem 0xf2020000-0xf203ffff,0xf2002000-0xf2003fff at device 0.0 on cardbus0 Aug 21 18:29:53 priscilla kernel: ndis0: NDIS API version: 5.1 Aug 21 18:29:53 priscilla kernel: ndis0: init handler failed Aug 21 18:29:53 priscilla kernel: device_attach: ndis0 attach returned 6 pciconf says: cbb0@pci2:15:0: class=0x060700 card=0x00a41028 chip=0xac42104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI4451 PC card CardBus Controller' class = bridge subclass = PCI-CardBus cbb1@pci2:15:1: class=0x060700 card=0x00a41028 chip=0xac42104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI4451 PC card CardBus Controller' class = bridge subclass = PCI-CardBus ndis0@pci5:0:0: class=0x028000 card=0x9067104c chip=0x9066104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' class = network I wound back the versions of the cardbus module. The wireless card worked again when I made a cardbus module dated < December 29, 2005. If I advance further than that I get the problem above. Does anyone else have this problem? Regards, Adrian From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 17:14:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8699716A4E0 for ; Wed, 23 Aug 2006 17:14:25 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id B25FA43D49 for ; Wed, 23 Aug 2006 17:14:21 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E135.dip.t-dialin.net [84.165.225.53]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7NGuBgf026890; Wed, 23 Aug 2006 18:56:12 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7NHE7ex052206; Wed, 23 Aug 2006 19:14:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Wed, 23 Aug 2006 19:16:19 +0200 From: Alexander Leidinger To: Kostik Belousov Message-ID: <20060823191619.0ea9504b@Magellan.Leidinger.net> In-Reply-To: <20060823154652.GA84619@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <20060823172316.dh1k8h6940ogw8o8@netchild.homeip.net> <20060823154652.GA84619@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 17:14:25 -0000 Quoting Kostik Belousov (Wed, 23 Aug 2006 18:46:52 +0300): > On Wed, Aug 23, 2006 at 05:23:16PM +0200, Alexander Leidinger wrote: > > Quoting Kostik Belousov (from Wed, 23 Aug 2006 > > 13:36:04 +0300): > > > > >On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: > > > > >>An idea which wasn't suggested yet is to install a renamed version (I > > >>would suggest libbaseldap instead of libbsdldap or libldap_i, but I > > >>don't really care about the name) and a link from the original name > > >>(only the .so and .a, but not the .so.X) to the new name. This link > > >>can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way > > >>around... depending on what we want to achieve). This way it is > > >>possible to link with the renamed lib in the base system, to use the > > >>base system version of the lib in ports, and to use the lib from ports > > >>if desired (a recompile of ports may be needed in the last case, yes). > > > > > >This will not work. bsdxml is used inside the system binaries. No binary > > >links again expat and bsdxml simultaneously. Would such binary exists, > > >it could experience problems. > > > > > >On the other hand, application using openldap from the ports has high > > >chance > > >loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against > > >renamed library, this would cause the crash. > > > > And this can't be solved with symbol versioning? > > Probably not. Default openldap build produces unversioned libraries. > Application linked against such library would happily resolve symbols > from the versioned lib. Why? In which case does this make sense? Is this an implementation detail or the spec? Bye, Alexander. -- If you care, you just get disappointed all the time. If you don't care nothing matters so you are never upset. -- Calvin http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 17:19:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0703316A4DA for ; Wed, 23 Aug 2006 17:19:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F59D43D45 for ; Wed, 23 Aug 2006 17:18:59 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k7NHIjhI038466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 20:18:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k7NHIkeE062276; Wed, 23 Aug 2006 20:18:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k7NHIjhD062275; Wed, 23 Aug 2006 20:18:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Aug 2006 20:18:45 +0300 From: Kostik Belousov To: Alexander Leidinger Message-ID: <20060823171845.GC84619@deviant.kiev.zoral.com.ua> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <20060823103604.GB64800@deviant.kiev.zoral.com.ua> <20060823172316.dh1k8h6940ogw8o8@netchild.homeip.net> <20060823154652.GA84619@deviant.kiev.zoral.com.ua> <20060823191619.0ea9504b@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline In-Reply-To: <20060823191619.0ea9504b@Magellan.Leidinger.net> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 17:19:01 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 07:16:19PM +0200, Alexander Leidinger wrote: > Quoting Kostik Belousov (Wed, 23 Aug 2006 18:46:52 = +0300): >=20 > > On Wed, Aug 23, 2006 at 05:23:16PM +0200, Alexander Leidinger wrote: > > > Quoting Kostik Belousov (from Wed, 23 Aug 2006 = =20 > > > 13:36:04 +0300): > > >=20 > > > >On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: > > >=20 > > > >>An idea which wasn't suggested yet is to install a renamed version = (I > > > >>would suggest libbaseldap instead of libbsdldap or libldap_i, but I > > > >>don't really care about the name) and a link from the original name > > > >>(only the .so and .a, but not the .so.X) to the new name. This link > > > >>can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other w= ay > > > >>around... depending on what we want to achieve). This way it is > > > >>possible to link with the renamed lib in the base system, to use the > > > >>base system version of the lib in ports, and to use the lib from po= rts > > > >>if desired (a recompile of ports may be needed in the last case, ye= s). > > > > > > > >This will not work. bsdxml is used inside the system binaries. No bi= nary > > > >links again expat and bsdxml simultaneously. Would such binary exist= s, > > > >it could experience problems. > > > > > > > >On the other hand, application using openldap from the ports has hig= h=20 > > > >chance > > > >loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked ag= ainst > > > >renamed library, this would cause the crash. > > >=20 > > > And this can't be solved with symbol versioning? > >=20 > > Probably not. Default openldap build produces unversioned libraries. > > Application linked against such library would happily resolve symbols > > from the versioned lib. >=20 > Why? In which case does this make sense? Is this an implementation > detail or the spec? If you have old system with unversioned library and built app on that box, you could still want to run app on new shiny system that supports versionin= g. This is the case with glibc 2.0 (no version info) and glibc 2.1 (where GNU versioning, i.e. version attached to symbols was introduced). --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7I31C3+MBN1Mb4gRAo97AKCe7nxynwn1P5T8fp4ZE7H9UT8ePACg2z1W kuR33+2Z7QVEYbJYNMSL5zU= =xwGj -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 17:38:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 927B916A4DF for ; Wed, 23 Aug 2006 17:38:31 +0000 (UTC) (envelope-from amogilny@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0A6443D6E for ; Wed, 23 Aug 2006 17:38:26 +0000 (GMT) (envelope-from amogilny@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so409286nfc for ; Wed, 23 Aug 2006 10:38:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=QQ202zZW1g4ApSt616gjNiOKqE+oKQq8EYSTJ7mofSfK164FrqaoK4bEgscbCexgFlsb8lRKIcebrWoNIhoV3U8PBTtodgvMXDuIx/4oT5UEC+pWWeNpVRLleJAT1TZaEfm7bCpmmZWag/GUPsNwKa02dju/rEXmsqD35fM52to= Received: by 10.49.29.2 with SMTP id g2mr2344006nfj; Wed, 23 Aug 2006 10:38:21 -0700 (PDT) Received: from localhost ( [193.28.87.193]) by mx.gmail.com with ESMTP id i1sm2774426nfe.2006.08.23.10.38.18; Wed, 23 Aug 2006 10:38:21 -0700 (PDT) Date: Wed, 23 Aug 2006 20:38:17 +0300 From: "Alexander I. Mogilny" To: freebsd-current@freebsd.org Message-ID: <20060823173817.GA37159@astral.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: glebius@freebsd.org, sg@astral.ntu-kpi.kiev.ua Subject: [patch] buildkernel crash [brgphy.c.patch] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 17:38:31 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=koi8-r Content-Disposition: inline I have just tried to migrate from i386 to amd64 architecture on my nx6125 laptop and failed to build kernel: make TARGET_ARCH=amd64 buildkernel error was: /usr/src/sys/dev/mii/brgphy.c: In function `brgphy_reset': /usr/src/sys/dev/mii/brgphy.c:646: error: structure has no member named `bge_no_3_led' *** Error code 1 Stop in /usr/obj/amd64/usr/src/sys/GENERIC. *** Error code 1 I have checked recent commits to bge driver and found that glebius made some changes to if_bgereg.h file which removed bge_no_3_led field from bge_softc struct. Here is the patch fixing it: --- brgphy.c.orig Wed Aug 23 20:18:28 2006 +++ brgphy.c Wed Aug 23 20:35:37 2006 @@ -643,7 +643,7 @@ PHY_WRITE(sc, BRGPHY_MII_AUXCTL, val | (1 << 15) | (1 << 4)); /* Enable Link LED on Dell boxes */ - if (bge_sc->bge_no_3_led) { + if (bge_sc->bge_flags & BGE_FLAG_NO3LED) { PHY_WRITE(sc, BRGPHY_MII_PHY_EXTCTL, PHY_READ(sc, BRGPHY_MII_PHY_EXTCTL) & ~BRGPHY_PHY_EXTCTL_3_LED); -- AIM-UANIC +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@portaone.com +---------------------+ --liOOAslEiF7prFVr Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="brgphy.c.patch" --- brgphy.c.orig Wed Aug 23 20:18:28 2006 +++ brgphy.c Wed Aug 23 20:35:37 2006 @@ -643,7 +643,7 @@ PHY_WRITE(sc, BRGPHY_MII_AUXCTL, val | (1 << 15) | (1 << 4)); /* Enable Link LED on Dell boxes */ - if (bge_sc->bge_no_3_led) { + if (bge_sc->bge_flags & BGE_FLAG_NO3LED) { PHY_WRITE(sc, BRGPHY_MII_PHY_EXTCTL, PHY_READ(sc, BRGPHY_MII_PHY_EXTCTL) & ~BRGPHY_PHY_EXTCTL_3_LED); --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 17:47:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52F7416A4DE for ; Wed, 23 Aug 2006 17:47:51 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38AFA43D60 for ; Wed, 23 Aug 2006 17:47:50 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7NHlfWf083431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Aug 2006 19:47:41 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7NHlfnn083430; Wed, 23 Aug 2006 19:47:41 +0200 (CEST) Date: Wed, 23 Aug 2006 19:47:41 +0200 From: Divacky Roman To: Paul Mather Message-ID: <20060823174741.GA83282@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 17:47:51 -0000 On Wed, Aug 23, 2006 at 11:49:53AM -0400, Paul Mather wrote: > On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > > > it seems like very trivial so expect patch today ;) > > > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > > > pls tell me if this works, thnx > > The patch applied and built on i386. However, when I run the resultant > kernel, the problem of the "syscall statfs64 not implemented" messages > goes away but my Tivoli backup still fails (in a different way). (The > same Tivoli client and setup worked on i386 -CURRENT prior to > mid-August, and currently is working on an i386 6.1-STABLE system.) > > Now, when the scheduled backup runs, I get things like this in my > dsmerror.log: > > 08/23/06 02:58:37 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 > 08/23/06 02:58:38 ANS1228E Sending of object '/backup' failed > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' failed > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' failed > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > 08/23/06 02:58:40 ANS1512E Scheduled event 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. > > > I don't know if this indicates that there is a problem with the > implementation of statfs64/statfs, now. (I don't know if it complicates > matters, but I'm backing up mounted snapshots.) pls, can you build -DDEBUG version of linuxolator and show me what it prints? From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 18:09:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDA4116A4DD for ; Wed, 23 Aug 2006 18:09:11 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE5543D49 for ; Wed, 23 Aug 2006 18:09:10 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.177]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id k7NI8qIR075422; Wed, 23 Aug 2006 22:09:02 +0400 (MSD) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GFx8d-0000BN-SI; Wed, 23 Aug 2006 22:07:39 +0400 To: Divacky Roman References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> <20060823174741.GA83282@stud.fit.vutbr.cz> From: Boris Samorodov Date: Wed, 23 Aug 2006 22:07:39 +0400 In-Reply-To: <20060823174741.GA83282@stud.fit.vutbr.cz> (Divacky Roman's message of "Wed, 23 Aug 2006 19:47:41 +0200") Message-ID: <37796436@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: Paul Mather , freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 18:09:11 -0000 On Wed, 23 Aug 2006 19:47:41 +0200 Divacky Roman wrote: > On Wed, Aug 23, 2006 at 11:49:53AM -0400, Paul Mather wrote: > > On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > > > > > it seems like very trivial so expect patch today ;) > > > > > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > > > > > pls tell me if this works, thnx > > > > The patch applied and built on i386. However, when I run the resultant > > kernel, the problem of the "syscall statfs64 not implemented" messages > > goes away but my Tivoli backup still fails (in a different way). (The > > same Tivoli client and setup worked on i386 -CURRENT prior to > > mid-August, and currently is working on an i386 6.1-STABLE system.) > > > > Now, when the scheduled backup runs, I get things like this in my > > dsmerror.log: > > > > 08/23/06 02:58:37 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:40 ANS1512E Scheduled event 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. > > > > > > I don't know if this indicates that there is a problem with the > > implementation of statfs64/statfs, now. (I don't know if it complicates > > matters, but I'm backing up mounted snapshots.) > pls, can you build -DDEBUG version of linuxolator and show me what it prints? For me just -DDEBUG at command line doesn't work. I do it by changing /sys/modules/linux/Makefile (add -DDEBUG to CFLAFS). And then compile and install the module: #cd /sys/modules/linux #make clean && make && make install To use a new version you just do: #kldunload linux.ko #kldload linux.ko WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 18:57:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECD516A4DA for ; Wed, 23 Aug 2006 18:57:12 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C43343D53 for ; Wed, 23 Aug 2006 18:57:11 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-71-254-64-250.ronkva.east.verizon.net [71.254.64.250]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7NIv08L016813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Aug 2006 14:57:01 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7NIuxYi051235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Aug 2006 14:57:00 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7NIuxgM051234; Wed, 23 Aug 2006 14:56:59 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Divacky Roman In-Reply-To: <20060823174741.GA83282@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> <20060823174741.GA83282@stud.fit.vutbr.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2006 14:56:57 -0400 Message-Id: <1156359417.51081.10.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 18:57:12 -0000 On Wed, 2006-08-23 at 19:47 +0200, Divacky Roman wrote: > On Wed, Aug 23, 2006 at 11:49:53AM -0400, Paul Mather wrote: > > On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > > > > > it seems like very trivial so expect patch today ;) > > > > > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > > > > > pls tell me if this works, thnx > > > > The patch applied and built on i386. However, when I run the resultant > > kernel, the problem of the "syscall statfs64 not implemented" messages > > goes away but my Tivoli backup still fails (in a different way). (The > > same Tivoli client and setup worked on i386 -CURRENT prior to > > mid-August, and currently is working on an i386 6.1-STABLE system.) > > > > Now, when the scheduled backup runs, I get things like this in my > > dsmerror.log: > > > > 08/23/06 02:58:37 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' failed > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > 08/23/06 02:58:40 ANS1512E Scheduled event 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. > > > > > > I don't know if this indicates that there is a problem with the > > implementation of statfs64/statfs, now. (I don't know if it complicates > > matters, but I'm backing up mounted snapshots.) > > pls, can you build -DDEBUG version of linuxolator and show me what it prints? Here is the output and debug output in /var/log/messages resulting from running the following command: zappa# /compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc incremental /backup/var Output: IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.1 Client date/time: 08/23/06 14:37:48 (c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved. Node Name: ZAPPA.DLIB.VT.EDU Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 2, Level 6.3 Server date/time: 08/23/06 14:37:48 Last access: 08/23/06 14:28:26 Incremental backup of volume '/backup/var' ANS1228E Sending of object '/backup/var' failed ANS1063E The specified path is not a valid file system or logical volume name. =====>===== Output appended to dsmerror.log (error log maintained by dsmc): 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:48 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:49 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 08/23/06 14:37:50 ANS1228E Sending of object '/backup/var' failed 08/23/06 14:37:50 ANS1063E The specified path is not a valid file system or logical volume name. =====>===== Output in /var/log/messages: Aug 23 14:37:48 zappa kernel: linux(69712): brk(0) Aug 23 14:37:48 zappa kernel: linux(69712): newuname(*) Aug 23 14:37:48 zappa kernel: linux(69712): access(/etc/ld.so.preload, 4) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 11663, 1, 0x00000002, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libcrypt.so.1, 0x0, 0x0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 180508, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 180508, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28347000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x2834b000, 8192, 3, 0x00000812, 3, 16384) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x2834b000, 8192, 3, 0x00000812, 3, 0x4000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2834b000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x2834d000, 155932, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x2834d000, 155932, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2834d000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/obsolete/linuxthreads/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/obsolete/linuxthreads/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28374000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 339108, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 339108, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28375000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28384000, 8192, 3, 0x00000812, 3, 57344) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28384000, 8192, 3, 0x00000812, 3, 0xe000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28384000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28386000, 269476, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28386000, 269476, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28386000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libdl.so.2, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 12408, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 12408, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283c8000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x283ca000, 8192, 3, 0x00000812, 3, 4096) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x283ca000, 8192, 3, 0x00000812, 3, 0x1000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283ca000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libgpfs.so, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 35364, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 35364, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283cc000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x283d4000, 4096, 3, 0x00000812, 3, 28672) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x283d4000, 4096, 3, 0x00000812, 3, 0x7000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283d4000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libdmapi.so, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 24036, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 24036, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283d5000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x283da000, 4096, 3, 0x00000812, 3, 16384) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x283da000, 4096, 3, 0x00000812, 3, 0x4000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283da000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/tls/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/tls/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/usr/lib/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/obsolete/linuxthreads/tls/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/obsolete/linuxthreads/librt.so.1, 0x0, 0x283325ab) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 77496, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 77496, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283db000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x283e2000, 8192, 3, 0x00000812, 3, 24576) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x283e2000, 8192, 3, 0x00000812, 3, 0x6000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283e2000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x283e4000, 40632, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x283e4000, 40632, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283e4000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libha_gs_r.so, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 122928, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 122928, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283ee000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x2840a000, 8192, 3, 0x00000812, 3, 110592) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x2840a000, 8192, 3, 0x00000812, 3, 0x1b000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840a000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x2840c000, 48, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x2840c000, 48, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840c000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/usr/lib/libstdc++.so.5, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840d000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 757044, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 757044, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840e000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x284bd000, 20480, 3, 0x00000812, 3, 712704) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x284bd000, 20480, 3, 0x00000812, 3, 0xae000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284bd000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x284c2000, 19764, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x284c2000, 19764, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284c2000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/tls/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/tls/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/obsolete/linuxthreads/tls/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/obsolete/linuxthreads/libm.so.6, 0x0, 0x3) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 151712, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 151712, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284c7000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x284eb000, 8192, 3, 0x00000812, 3, 143360) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x284eb000, 8192, 3, 0x00000812, 3, 0x23000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284eb000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libgcc_s.so.1, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 37576, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 37576, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284ed000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x284f6000, 4096, 3, 0x00000812, 3, 36864) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x284f6000, 4096, 3, 0x00000812, 3, 0x9000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284f6000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/tls/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/tls/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/usr/lib/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/lib/obsolete/linuxthreads/tls/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 2 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/obsolete/linuxthreads/libc.so.6, 0x0, 0x2840d788) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 1174676, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 1174676, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284f7000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28610000, 16384, 3, 0x00000812, 3, 1150976) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28610000, 16384, 3, 0x00000812, 3, 0x119000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28610000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28614000, 7316, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28614000, 7316, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28614000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libct_cu.so, 0x0, 0x0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 299624, 5, 0x00000802, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 299624, 5, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28616000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x2865d000, 12288, 3, 0x00000812, 3, 286720) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x2865d000, 12288, 3, 0x00000812, 3, 0x46000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2865d000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28660000) Aug 23 14:37:48 zappa kernel: linux(69712): getrlimit(3, 0xbfbfe85c) Aug 23 14:37:48 zappa kernel: linux(69712): setrlimit(3, 0xbfbfe85c) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(32, 0xbfbfe7c8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(33, 0xbfbfe7c8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(34, 0xbfbfe7c8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(0, 0xbfbfeb20, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(1, 0xbfbfeb20, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): brk(0) Aug 23 14:37:48 zappa kernel: linux(69712): brk(0x83ac000) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(1, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/dev/console, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(1, *) Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(1, 5413, *) Aug 23 14:37:48 zappa kernel: linux(69712): open(/dev/tty, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(3, 5405, *) Aug 23 14:37:48 zappa kernel: LINUX: BSD termios structure (input): Aug 23 14:37:48 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 23 14:37:48 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 23 14:37:48 zappa kernel: LINUX: LINUX termios structure (output): Aug 23 14:37:48 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 23 14:37:48 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28661000) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(13, 0xbfbfda28, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(0, 0xbfbfdb9c, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(4, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(8, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(7, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(11, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(10, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(6, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigaction(5, 0xbfbfdad8, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69712): newuname(*) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/TIVGUID, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, *) Aug 23 14:37:48 zappa kernel: linux(69712): access(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, 1) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, *) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.opt, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28704000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x287a7000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): readlink(/var/log/tsm/dsmerror.log, 0xbfbfc8a0, 1024) Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8441, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): llseek(3, 0:47355, 0) Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmprune.log, 0x8241, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): open(/etc/localtime, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(5, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(5, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmprune.log, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8241, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): unlink(/var/log/tsm/dsmprune.log) Aug 23 14:37:48 zappa kernel: linux(69712): open(/var/log/tsm/dsmerror.log, 0x8441, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(3, *) Aug 23 14:37:48 zappa kernel: linux(69712): llseek(3, 0:47355, 0) Aug 23 14:37:48 zappa kernel: linux(69712): open(/dev/null, 0x10800, 0x28611ff4) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins, *) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins, 0x18800, 0x28611ff4) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(4, 00000002, *) Aug 23 14:37:48 zappa kernel: linux(69712): getdents64(4, *, 4096) Aug 23 14:37:48 zappa kernel: linux(69712): getdents64(4, *, 4096) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins/libPiIMG.so, 0x0, 0x2837f372) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 437044, 5, 0x00000802, 4, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 437044, 5, 0x00000802, 4, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2884a000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x288a7000, 36864, 3, 0x00000812, 4, 376832) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x288a7000, 36864, 3, 0x00000812, 4, 0x5c000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288a7000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x288b0000, 19252, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x288b0000, 19252, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288b0000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 11663, 1, 0x00000002, 4, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 4, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libApiDS.so, 0x0, 0x0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 2639584, 5, 0x00000802, 4, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 2639584, 5, 0x00000802, 4, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288b5000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28ae9000, 278528, 3, 0x00000812, 4, 2310144) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28ae9000, 278528, 3, 0x00000812, 4, 0x234000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28ae9000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28b2d000, 50912, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28b2d000, 50912, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b2d000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins/libPiSNAP.so, 0x0, 0x0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 330852, 5, 0x00000802, 4, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 330852, 5, 0x00000802, 4, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b3a000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28b78000, 40960, 3, 0x00000812, 4, 253952) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28b78000, 40960, 3, 0x00000812, 4, 0x3e000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b78000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28b82000, 35940, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28b82000, 35940, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b82000) Aug 23 14:37:48 zappa kernel: linux(69712): newuname(*) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.opt, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(4, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): llseek(4, 0:0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/inclexcl.opt, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(5, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): brk(0x83ce000) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 23 14:37:48 zappa kernel: linux(69712): pipe(*) Aug 23 14:37:48 zappa kernel: linux(69712): clone(flags f00, stack 83af744, parent tid: bfbfe0e0, child tid: 28377fea) Aug 23 14:37:48 zappa kernel: linux(69712): clone: successful rfork to 69713, stack 0x83af744 sig = 0 Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfe15c, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfe08c, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigsuspend(0xbfbfe08c, 8) Aug 23 14:37:48 zappa kernel: linux(69713): rt_sigprocmask(2, 0x83af6b4, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69713): mmap(0xbf200000, 2097152, 7, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0xbf200000, 2097152, 7, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbf200000) Aug 23 14:37:48 zappa kernel: linux(69713): clone(flags f21, stack bf3ffbc4, parent tid: 0, child tid: ffc00000) Aug 23 14:37:48 zappa kernel: linux(69713): clone: successful rfork to 69714, stack 0xbf3ffbc4 sig = 33 Aug 23 14:37:48 zappa kernel: linux(69713): kill(69712, 32) Aug 23 14:37:48 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:48 zappa kernel: linux(69712): sigreturn(0xbfbfdd94) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigprocmask(2, 0xbf3ffc74, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): sched_setscheduler(69714, 0, 0xbf3ffcf8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(2, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(3, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(15, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(24, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(25, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigaction(30, 0xbf3ff724, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigprocmask(0, 0, 0xbf3ff8ac, 8) Aug 23 14:37:48 zappa kernel: linux(69714): rt_sigsuspend(0xbf3ff9b8, 8) Aug 23 14:37:48 zappa kernel: linux(69712): newuname(*) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(1, *) Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(1, 5401, *) Aug 23 14:37:48 zappa kernel: LINUX: BSD termios structure (input): Aug 23 14:37:48 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 23 14:37:48 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 23 14:37:48 zappa kernel: LINUX: LINUX termios structure (output): Aug 23 14:37:48 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 23 14:37:48 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/nsswitch.conf, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(6, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(6, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 11663, 1, 0x00000002, 6, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 6, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8b000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libnss_files.so.2, 0x0, 0x28611be0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(6, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 41620, 5, 0x00000802, 6, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 41620, 5, 0x00000802, 6, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8e000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28b97000, 8192, 3, 0x00000812, 6, 32768) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28b97000, 8192, 3, 0x00000812, 6, 0x8000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b97000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/etc/passwd, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000001, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(6, 00000002, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(6, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): open(/etc/resolv.conf, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/host.conf, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/etc/hosts, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000001, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000002, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 11663, 1, 0x00000002, 7, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 7, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8b000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libnss_dns.so.2, 0x0, 0xbfbfb9d8) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 20612, 5, 0x00000802, 7, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 20612, 5, 0x00000802, 7, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b99000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28b9d000, 8192, 3, 0x00000812, 7, 12288) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28b9d000, 8192, 3, 0x00000812, 7, 0x3000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b9d000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/lib/libresolv.so.2, 0x0, 0x0) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 71784, 5, 0x00000802, 7, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 71784, 5, 0x00000802, 7, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b9f000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28bad000, 8192, 3, 0x00000812, 7, 53248) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28bad000, 8192, 3, 0x00000812, 7, 0xd000) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bad000) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0x28baf000, 6248, 3, 0x00000032, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0x28baf000, 6248, 3, 0x00001012, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28baf000) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(7, 541b, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc340, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc340, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(0, 540f, *) Aug 23 14:37:48 zappa kernel: linux(69712): newuname(*) Aug 23 14:37:48 zappa kernel: linux(69712): open(/etc/hosts, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000001, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000002, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000003, *) Aug 23 14:37:48 zappa kernel: linux(69712): fcntl64(7, 00000004, *) Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(7, 541b, *) Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc7d0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc7d0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc3a0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc3a0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/adsm/TSM.PWD, 0x8000, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc590, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc590, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc780, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfc780, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa last message repeated 3 times Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfcb10, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfcb10, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfced0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfced0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfced0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): select(7, 0xbfbfced0, 0, 0, 0) Aug 23 14:37:48 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:48 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfcffc, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfcf2c, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigsuspend(0xbfbfcf2c, 8) Aug 23 14:37:48 zappa kernel: linux(69713): mmap(0xbf000000, 2097152, 7, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0xbf000000, 2097152, 7, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbf000000) Aug 23 14:37:48 zappa kernel: linux(69713): clone(flags f21, stack bf1ffbc4, parent tid: 0, child tid: ffa00000) Aug 23 14:37:48 zappa kernel: linux(69713): clone: successful rfork to 69715, stack 0xbf1ffbc4 sig = 33 Aug 23 14:37:48 zappa kernel: linux(69713): kill(69712, 32) Aug 23 14:37:48 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:48 zappa kernel: linux(69712): sigreturn(0xbfbfcc34) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigprocmask(2, 0xbf1ffc74, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69715): sched_setscheduler(69715, 0, 0xbf1ffcf8) Aug 23 14:37:48 zappa kernel: linux(69715): time(*) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff89c, 8) Aug 23 14:37:48 zappa kernel: linux(69713): mmap(0xbee00000, 2097152, 7, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0xbee00000, 2097152, 7, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbee00000) Aug 23 14:37:48 zappa kernel: linux(69713): clone(flags f21, stack befffbc4, parent tid: 0, child tid: ff800000) Aug 23 14:37:48 zappa kernel: linux(69713): clone: successful rfork to 69716, stack 0xbefffbc4 sig = 33 Aug 23 14:37:48 zappa kernel: linux(69713): kill(69715, 32) Aug 23 14:37:48 zappa kernel: linux(69716): rt_sigprocmask(2, 0xbefffc74, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69716): sched_setscheduler(69716, 0, 0xbefffcf8) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff7cc, 8) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff7cc, 8) Aug 23 14:37:48 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:48 zappa kernel: linux(69715): sigreturn(0xbf1ff4d4) Aug 23 14:37:48 zappa kernel: linux(69716): rt_sigprocmask(2, 0, 0xbefff8f8, 8) Aug 23 14:37:48 zappa kernel: linux(69716): rt_sigsuspend(0xbefff8f8, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfcffc, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfcf2c, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigsuspend(0xbfbfcf2c, 8) Aug 23 14:37:48 zappa kernel: linux(69713): mmap(0xbec00000, 2097152, 7, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0xbec00000, 2097152, 7, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbec00000) Aug 23 14:37:48 zappa kernel: linux(69713): clone(flags f21, stack bedffbc4, parent tid: 0, child tid: ff600000) Aug 23 14:37:48 zappa kernel: linux(69713): clone: successful rfork to 69717, stack 0xbedffbc4 sig = 33 Aug 23 14:37:48 zappa kernel: linux(69713): kill(69712, 32) Aug 23 14:37:48 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:48 zappa kernel: linux(69712): sigreturn(0xbfbfcc34) Aug 23 14:37:48 zappa kernel: linux(69717): rt_sigprocmask(2, 0xbedffc74, 0, 8) Aug 23 14:37:48 zappa kernel: linux(69717): sched_setscheduler(69717, 0, 0xbedffcf8) Aug 23 14:37:48 zappa kernel: linux(69717): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 23 14:37:48 zappa kernel: linux(69717): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff848, 8) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff848, 8) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(1, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/dev/console, *) Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(1, *) Aug 23 14:37:48 zappa kernel: linux(69712): ioctl(1, 5413, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 512000, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 512000, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bb1000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/compat/linux/usr, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/compat/linux/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/data, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/tmp, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/usr, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 512000, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 512000, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bb1000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/compat/linux/usr, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/compat/linux/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/data, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/tmp, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/usr, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: Linux-emul(69712): getcwd(0xbfbfcdb0, 1025) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): brk(0x83ff000) Aug 23 14:37:48 zappa kernel: linux(69712): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:48 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:48 zappa kernel: linux(69712): fstat64(7, *) Aug 23 14:37:48 zappa kernel: linux(69712): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:48 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:48 zappa kernel: linux(69712): brk(0x83e6000) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): statfs(/backup/var, *) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:48 zappa kernel: linux(69712): access(/backup/var, 0) Aug 23 14:37:48 zappa kernel: linux(69712): kill(69715, 32) Aug 23 14:37:48 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:48 zappa kernel: linux(69715): sigreturn(0xbf1ff550) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff7e8, 8) Aug 23 14:37:48 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff7e8, 8) Aug 23 14:37:48 zappa kernel: linux(69712): kill(69715, 32) Aug 23 14:37:48 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:48 zappa kernel: linux(69715): sigreturn(0xbf1ff4f0) Aug 23 14:37:48 zappa kernel: linux(69715): select(0, 0, 0, 0, 0xbf1ff9b8) Aug 23 14:37:48 zappa kernel: linux(69715): incoming timeout (1/0) Aug 23 14:37:48 zappa kernel: linux(69712): time(*) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(0, 0, 0xbfbfcf28, 8) Aug 23 14:37:48 zappa kernel: linux(69712): rt_sigprocmask(1, 0xbfbfd028, 0xbfbfcfa8, 8) Aug 23 14:37:49 zappa kernel: linux(69717): rt_sigprocmask(2, 0xbedff768, 0, 8) Aug 23 14:37:49 zappa kernel: linux(69717): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 23 14:37:49 zappa kernel: linux(69717): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 23 14:37:49 zappa kernel: linux(69715): real select returns 0 Aug 23 14:37:49 zappa kernel: linux(69715): outgoing timeout (0/0) Aug 23 14:37:49 zappa kernel: linux(69715): select_out -> 0 Aug 23 14:37:49 zappa kernel: linux(69715): select(7, 0xbf1ff740, 0, 0, 0) Aug 23 14:37:49 zappa kernel: linux(69712): rt_sigprocmask(2, 0xbfbfcfa8, 0, 8) Aug 23 14:37:49 zappa kernel: linux(69712): time(*) Aug 23 14:37:49 zappa kernel: linux(69712): rt_sigprocmask(0, 0, 0xbfbfcf28, 8) Aug 23 14:37:49 zappa kernel: linux(69712): rt_sigprocmask(1, 0xbfbfd028, 0xbfbfcfa8, 8) Aug 23 14:37:49 zappa kernel: linux(69715): real select returns 0 Aug 23 14:37:49 zappa kernel: linux(69715): select_out -> 0 Aug 23 14:37:49 zappa kernel: linux(69715): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:49 zappa kernel: linux(69715): open returns error 0 Aug 23 14:37:49 zappa kernel: linux(69715): fstat64(7, *) Aug 23 14:37:49 zappa kernel: linux(69715): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:49 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:49 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:49 zappa kernel: linux(69715): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 23 14:37:49 zappa kernel: linux(69715): open returns error 0 Aug 23 14:37:49 zappa kernel: linux(69715): fstat64(7, *) Aug 23 14:37:49 zappa kernel: linux(69715): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 23 14:37:49 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 23 14:37:49 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 23 14:37:49 zappa kernel: linux(69715): brk(0x8418000) Aug 23 14:37:49 zappa kernel: linux(69715): brk(0x83ff000) Aug 23 14:37:49 zappa kernel: linux(69715): brk(0x83e6000) Aug 23 14:37:49 zappa kernel: linux(69715): statfs(/backup/var, *) Aug 23 14:37:49 zappa kernel: linux(69715): time(*) Aug 23 14:37:49 zappa kernel: linux(69715): stat64(/etc/localtime, *) Aug 23 14:37:49 zappa kernel: linux(69715): stat64(/etc/localtime, *) Aug 23 14:37:49 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff848, 8) Aug 23 14:37:49 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff848, 8) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigprocmask(2, 0xbedff768, 0, 8) Aug 23 14:37:50 zappa kernel: linux(69717): kill(69715, 32) Aug 23 14:37:50 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:50 zappa kernel: linux(69715): sigreturn(0xbf1ff550) Aug 23 14:37:50 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff7e8, 8) Aug 23 14:37:50 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff7e8, 8) Aug 23 14:37:50 zappa kernel: linux(69717): kill(69715, 32) Aug 23 14:37:50 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:50 zappa kernel: linux(69715): sigreturn(0xbf1ff4f0) Aug 23 14:37:50 zappa kernel: linux(69715): kill(69716, 32) Aug 23 14:37:50 zappa kernel: linux(69716): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 23 14:37:50 zappa kernel: linux(69716): sigreturn(0xbefff600) Aug 23 14:37:50 zappa kernel: linux(69716): rt_sigprocmask(2, 0, 0xbefff898, 8) Aug 23 14:37:50 zappa kernel: linux(69716): rt_sigsuspend(0xbefff898, 8) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 23 14:37:50 zappa kernel: linux(69715): kill(69716, 32) Aug 23 14:37:50 zappa kernel: linux(69716): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 23 14:37:50 zappa kernel: linux(69716): sigreturn(0xbefff5a0) Aug 23 14:37:50 zappa kernel: linux(69716): kill(69717, 32) Aug 23 14:37:50 zappa kernel: linux(69717): sendsig(0x2837cfa4, 32, 0xd584fc24, 0) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigprocmask(2, 0xbedff6e8, 0, 8) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigprocmask(2, 0, 0xbedff798, 8) Aug 23 14:37:50 zappa kernel: linux(69717): rt_sigsuspend(0xbedff798, 8) Aug 23 14:37:50 zappa kernel: linux(69715): rt_sigprocmask(2, 0, 0xbf1ff80c, 8) Aug 23 14:37:50 zappa kernel: linux(69715): rt_sigsuspend(0xbf1ff80c, 8) Aug 23 14:37:50 zappa kernel: linux(69716): kill(69717, 32) Aug 23 14:37:50 zappa kernel: linux(69717): sendsig(0x2837cfa4, 32, 0xd584fc24, 0) Aug 23 14:37:50 zappa kernel: linux(69717): sigreturn(0xbedff4a0) Aug 23 14:37:50 zappa kernel: linux(69717): kill(69715, 32) Aug 23 14:37:50 zappa kernel: linux(69715): sendsig(0x2837cfa4, 32, 0xd582bc24, 0) Aug 23 14:37:50 zappa kernel: linux(69715): sigreturn(0xbf1ff514) Aug 23 14:37:50 zappa kernel: linux(69715): exit_group(0) Aug 23 14:37:50 zappa kernel: linux(69713): sendsig(0x2837d028, 33, 0xd586ac24, 0) Aug 23 14:37:50 zappa kernel: linux(69713): sigreturn(0x83af2b8) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69716): exit_group(0) Aug 23 14:37:50 zappa kernel: linux(69713): sendsig(0x2837d028, 33, 0xd586ac24, 0) Aug 23 14:37:50 zappa kernel: linux(69713): sigreturn(0x83af2b8) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69717): kill(69712, 32) Aug 23 14:37:50 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:50 zappa kernel: linux(69712): rt_sigprocmask(2, 0xbfbfcf28, 0, 8) Aug 23 14:37:50 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfcfd8, 8) Aug 23 14:37:50 zappa kernel: linux(69712): rt_sigsuspend(0xbfbfcfd8, 8) Aug 23 14:37:50 zappa kernel: linux(69717): kill(69712, 32) Aug 23 14:37:50 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:50 zappa kernel: linux(69712): sigreturn(0xbfbfcce0) Aug 23 14:37:50 zappa kernel: linux(69712): time(*) Aug 23 14:37:50 zappa kernel: linux(69712): time(*) Aug 23 14:37:50 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:50 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:50 zappa kernel: linux(69712): time(*) Aug 23 14:37:50 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:50 zappa kernel: linux(69712): stat64(/etc/localtime, *) Aug 23 14:37:50 zappa kernel: linux(69712): time(*) Aug 23 14:37:50 zappa last message repeated 3 times Aug 23 14:37:50 zappa kernel: linux(69712): kill(69714, 10) Aug 23 14:37:50 zappa kernel: linux(69717): exit_group(0) Aug 23 14:37:50 zappa kernel: linux(69713): sendsig(0x2837d028, 33, 0xd586ac24, 0) Aug 23 14:37:50 zappa kernel: linux(69713): sigreturn(0x83af2b8) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69713): waitpid(-1, 0x83af598, -2147483647) Aug 23 14:37:50 zappa kernel: linux(69712): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 23 14:37:50 zappa kernel: linux(69712): select(0, 0, 0, 0, 0xbfbfeb58) Aug 23 14:37:50 zappa kernel: linux(69712): incoming timeout (1/0) Aug 23 14:37:51 zappa kernel: linux(69712): real select returns 0 Aug 23 14:37:51 zappa kernel: linux(69712): outgoing timeout (0/0) Aug 23 14:37:51 zappa kernel: linux(69712): select_out -> 0 Aug 23 14:37:51 zappa kernel: linux(69712): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 23 14:37:51 zappa kernel: linux(69712): open(/dev/tty, 0x8000, 0x1b6) Aug 23 14:37:51 zappa kernel: linux(69712): open returns error 0 Aug 23 14:37:51 zappa kernel: linux(69712): ioctl(6, 540f, *) Aug 23 14:37:51 zappa kernel: linux(69712): ioctl(6, 5406, *) Aug 23 14:37:51 zappa kernel: LINUX: LINUX termios structure (input): Aug 23 14:37:51 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 23 14:37:51 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 23 14:37:51 zappa kernel: LINUX: BSD termios structure (output): Aug 23 14:37:51 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 23 14:37:51 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 23 14:37:51 zappa kernel: linux(69712): rt_sigprocmask(2, 0, 0xbfbfea5c, 8) Aug 23 14:37:51 zappa kernel: linux(69712): rt_sigsuspend(0xbfbfea5c, 8) Aug 23 14:37:51 zappa kernel: linux(69713): kill(69714, 33) Aug 23 14:37:51 zappa kernel: linux(69714): sendsig(0x2837d028, 33, 0xd5846c24, 0) Aug 23 14:37:51 zappa kernel: linux(69714): exit_group(12) Aug 23 14:37:51 zappa kernel: linux(69713): sendsig(0x2837d028, 33, 0xd586ac24, 0) Aug 23 14:37:51 zappa kernel: linux(69713): sigreturn(0x83af2c8) Aug 23 14:37:51 zappa kernel: linux(69713): waitpid(69714, 0, -2147483648) Aug 23 14:37:51 zappa kernel: linux(69713): kill(69712, 32) Aug 23 14:37:51 zappa kernel: linux(69712): sendsig(0x2837cfa4, 32, 0xd58a3c24, 0) Aug 23 14:37:51 zappa kernel: linux(69712): sigreturn(0xbfbfe764) Aug 23 14:37:51 zappa kernel: linux(69712): waitpid(69713, 0, -2147483648) Aug 23 14:37:51 zappa kernel: linux(69713): exit_group(0) Aug 23 14:37:51 zappa kernel: linux(69712): exit_group(12) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 19:20:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 909D416A51B; Wed, 23 Aug 2006 19:20:25 +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 4FFAD43D9E; Wed, 23 Aug 2006 19:20:14 +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 k7NJK95E045766; Wed, 23 Aug 2006 23:20:10 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 23 Aug 2006 23:20:09 +0400 (MSD) From: Maxim Konovalov To: "Alexander I. Mogilny" In-Reply-To: <20060823173817.GA37159@astral.ntu-kpi.kiev.ua> Message-ID: <20060823231846.S45478@mp2.macomnet.net> References: <20060823173817.GA37159@astral.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, glebius@freebsd.org, sg@astral.ntu-kpi.kiev.ua Subject: Re: [patch] buildkernel crash [brgphy.c.patch] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 19:20:25 -0000 On Wed, 23 Aug 2006, 20:38+0300, Alexander I. Mogilny wrote: > I have just tried to migrate from i386 to amd64 architecture on my > nx6125 laptop and failed to build kernel: > > make TARGET_ARCH=amd64 buildkernel > > error was: > > /usr/src/sys/dev/mii/brgphy.c: In function `brgphy_reset': > /usr/src/sys/dev/mii/brgphy.c:646: error: structure has no member named `bge_no_3_led' > *** Error code 1 > > Stop in /usr/obj/amd64/usr/src/sys/GENERIC. > *** Error code 1 > > I have checked recent commits to bge driver and found that glebius > made some changes to if_bgereg.h file which removed bge_no_3_led > field from bge_softc struct. > > Here is the patch fixing it: > > > --- brgphy.c.orig Wed Aug 23 20:18:28 2006 > +++ brgphy.c Wed Aug 23 20:35:37 2006 > @@ -643,7 +643,7 @@ > PHY_WRITE(sc, BRGPHY_MII_AUXCTL, val | (1 << 15) | (1 << 4)); > > /* Enable Link LED on Dell boxes */ > - if (bge_sc->bge_no_3_led) { > + if (bge_sc->bge_flags & BGE_FLAG_NO3LED) { > PHY_WRITE(sc, BRGPHY_MII_PHY_EXTCTL, > PHY_READ(sc, BRGPHY_MII_PHY_EXTCTL) > & ~BRGPHY_PHY_EXTCTL_3_LED); The code is already there, you need rev. 1.45. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 19:32:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CDE816A4E1 for ; Wed, 23 Aug 2006 19:32:48 +0000 (UTC) (envelope-from alexandre.delay@free.fr) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4832443D58 for ; Wed, 23 Aug 2006 19:32:47 +0000 (GMT) (envelope-from alexandre.delay@free.fr) Received: from Cerbere-de-Troyes.cerbere23.com (ns.muntz.fr [82.241.181.23]) by smtp6-g19.free.fr (Postfix) with ESMTP id 90190226FA for ; Wed, 23 Aug 2006 21:32:46 +0200 (CEST) Received: from artemis ([192.168.2.2]) by Cerbere-de-Troyes.cerbere23.com (8.13.3/8.13.3) with ESMTP id k7NJWj6T000842 for ; Wed, 23 Aug 2006 21:32:46 +0200 (CEST) (envelope-from alexandre.delay@free.fr) From: "Alexandre DELAY" To: Date: Wed, 23 Aug 2006 21:32:45 +0200 Message-ID: <000e01c6c6ea$e925e6e0$0202a8c0@artemis> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Iomega Rev USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 19:32:48 -0000 Hi, I would like to know if USB Iomega Rev works under freebsd. If not, is it about to be supported? Thanks Cheers Alex From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 20:33:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D02B16A4DE for ; Wed, 23 Aug 2006 20:33:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FF9E43D55 for ; Wed, 23 Aug 2006 20:33:05 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 18392 invoked by uid 399); 23 Aug 2006 20:33:04 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Aug 2006 20:33:04 -0000 Message-ID: <44ECBB7D.4090905@FreeBSD.org> Date: Wed, 23 Aug 2006 13:33:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Michael Bushkov References: <44E9582C.2010400@rsu.ru> In-Reply-To: <44E9582C.2010400@rsu.ru> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 20:33:07 -0000 Michael Bushkov wrote: > Hi, > First, thanks to all FreeBSD people and to Google for the great summer! > As the SoC deadline has almost arrived, I'm glad to post most of this > summer's work results. Congratulations on your success with this project! > OpenLDAP + rewritten-from-scratch nss_ldap + nsswitch with separate > shared nss-modules patch. > To have > it in the tree, OpenLDAP was also needed to be placed in the tree. Here is where (once again) we have a difference of opinion. I still believe strongly that the nss_ldap part of your work should be a port, with a dependency on the openldap in ports. I've stated my reasoning on this in the previous thread, so I won't rehash it here unless someone asks. I would like to point out though that I feel the numerous problems raised in this thread give even more weight to the request that I, and others made not to have it incorporated into the base. This in no way is meant to indicate that your work has no value, or is somehow "less valuable" than work that is actually in the base. It is simply a realistic reflection of the fact that this facility will be needed by a small percentage of FreeBSD users, and the difficulties (costs) outweigh the corresponding benefit. A compromise position, if it can be made to work, would be to import your original work on the nss_ldap module, but have it use openldap from ports rather than having to import openldap. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 20:47:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EAB916A4DD; Wed, 23 Aug 2006 20:47:31 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC43843D46; Wed, 23 Aug 2006 20:47:30 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 7308798019; Wed, 23 Aug 2006 22:47:29 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-3-14.dynamic.mnet-online.de [82.135.3.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.m-online.net (Postfix) with ESMTP id 62CB2928EC; Wed, 23 Aug 2006 22:47:29 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.6/8.13.4/Submit) with ESMTP id k7NKlS7Y012984; Wed, 23 Aug 2006 22:47:28 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Wed, 23 Aug 2006 22:47:28 +0200 (CEST) From: Michael Reifenberger To: Oleg Bulyzhin In-Reply-To: <20060822204342.GA4943@lath.rinet.ru> Message-ID: <20060823224337.W12953@fw.reifenberger.com> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pyun YongHyeon , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 20:47:31 -0000 On Wed, 23 Aug 2006, Oleg Bulyzhin wrote: ... >> Yes, please! >> I can test it (on RELENG_6 though). > > I have an idea why those timeouts can happen. Could you please test > attached patch? It may help (or may not). Anyway would be fine > to know results. > After applying the patch I havn't seen any timeouts. So its seems it helped. Thanks! Shall I commit the patch to -current? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 20:55:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8E2116A4DA; Wed, 23 Aug 2006 20:55:28 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 539A443D46; Wed, 23 Aug 2006 20:55:28 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060823205526m92002s838e>; Wed, 23 Aug 2006 20:55:27 +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 k7NKtObK028219; Wed, 23 Aug 2006 15:55:24 -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 k7NKtN6F028218; Wed, 23 Aug 2006 15:55:23 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 15:55:23 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20060823205523.GB27961@lor.one-eyed-alien.net> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <44ECBB7D.4090905@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 20:55:29 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 01:33:01PM -0700, Doug Barton wrote: > Michael Bushkov wrote: > > Hi, > > First, thanks to all FreeBSD people and to Google for the great summer! > > As the SoC deadline has almost arrived, I'm glad to post most of this > > summer's work results. >=20 > Congratulations on your success with this project! >=20 > > OpenLDAP + rewritten-from-scratch nss_ldap + nsswitch with separate > > shared nss-modules patch. > > To have > > it in the tree, OpenLDAP was also needed to be placed in the tree. >=20 > Here is where (once again) we have a difference of opinion. I still belie= ve > strongly that the nss_ldap part of your work should be a port, with a > dependency on the openldap in ports. I've stated my reasoning on this in = the > previous thread, so I won't rehash it here unless someone asks. I would l= ike > to point out though that I feel the numerous problems raised in this thre= ad > give even more weight to the request that I, and others made not to have = it > incorporated into the base. >=20 > This in no way is meant to indicate that your work has no value, or is > somehow "less valuable" than work that is actually in the base. It is sim= ply > a realistic reflection of the fact that this facility will be needed by a > small percentage of FreeBSD users, and the difficulties (costs) outweigh = the > corresponding benefit. I disagree. Having authentication functions outside the base makes them more vulnerable to configuration problems and general library cross threading. It also means they can't work out of the box. I think the costs are likely fairly small (no worse than those associated with OpenSSL) and the benefits are substantial. I suspect you are correct that a large portion of FreeBSD users don't need LDAP authentication, but I believe our long-term future depends in part on attracting the types of institutional users who do need it. I think we need to get to the point where we can authenticate against LDAPish systems such as Active Directory without substantially more configuration then is currently required for nis. Currently joining the NIS/NFS cluster in our department requires adding the following lines to /etc/rc.conf and copying over our standard amd.conf: nisdomainname=3D"XXX" nis_client_enable=3D"YES" amd_enable=3D"YES" amd_flags=3D"" nfs_client_enable=3D"YES" That's it and that's where we need to be with regard to modern LDAP based directory services if we want people with central authentication and authorization system to take us seriously. Personally, I'd like to see at least some of the command line client tools imported as well and the ldap libraries. -- Brooks --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7MC6XY6L6fI4GtQRAtBVAKCgeeOKMHDTvuenOXLge9/B4g7x0ACgg4A4 nkjVXD6mCFvOCUdCk8iq9ZU= =24Vr -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 21:20:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE0C816A4E1 for ; Wed, 23 Aug 2006 21:20:18 +0000 (UTC) (envelope-from pbowen@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0216743D55 for ; Wed, 23 Aug 2006 21:20:09 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id B1AB3D9E6C5 for ; Wed, 23 Aug 2006 17:20:08 -0400 (EDT) Received: from heartbeat2.internal ([10.202.2.161]) by frontend3.internal (MEProxy); Wed, 23 Aug 2006 17:20:09 -0400 X-Sasl-enc: VT04buKhN2oPSfX2mFzQSyAYTzIU22FS1CsqpPeFqysq 1156368005 Received: from [192.168.1.169] (unknown [205.246.14.234]) by mail.messagingengine.com (Postfix) with ESMTP id 2371AFCC for ; Wed, 23 Aug 2006 17:20:02 -0400 (EDT) Message-ID: <44ECC67C.9070904@fastmail.fm> Date: Wed, 23 Aug 2006 16:19:56 -0500 From: Patrick Bowen User-Agent: Thunderbird 1.5.0.4 (X11/20060723) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <44EC7EBA.7080303@gsoft.com.au> In-Reply-To: <44EC7EBA.7080303@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Cardbus problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 21:20:19 -0000 Adrian Murphy wrote: > Hi, > > I have had a problem using the ndis driver for my wireless cardbus > adapter since I updated current in April. > > The wireless card is an Alloy WLT245401 model with a Texas Instruments > chipset. > > With a current from November 2005, I used the wireless adapter > successfully. > > I updated current yesterday and still no joy: > FreeBSD priscilla.gsoft.com.au 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Wed > Aug 23 08:34:10 CST 2006 > root@priscilla.gsoft.com.au:/usr/obj/usr/src/sys/PRISCILLA i386 > > > When I insert the wireless card, I see the following in > /var/log/messages: > > Aug 21 18:29:53 priscilla kernel: cardbus0: CIS pointer is 0x1c02 > Aug 21 18:29:53 priscilla kernel: cardbus0: CIS in BAR 0x14 > Aug 21 18:29:53 priscilla kernel: cardbus0: Expecting link target, got > 0x8 > Aug 21 18:29:53 priscilla kernel: cardbus0: Warning: Bogus CIS ignored > Aug 21 18:29:53 priscilla kernel: ndis0: Cardbus/PCI Adapter> mem 0xf2020000-0xf203ffff,0xf2002000-0xf2003fff > at device 0.0 on cardbus0 > Aug 21 18:29:53 priscilla kernel: ndis0: NDIS API version: 5.1 > Aug 21 18:29:53 priscilla kernel: ndis0: init handler failed > Aug 21 18:29:53 priscilla kernel: device_attach: ndis0 attach returned 6 > > > pciconf says: > cbb0@pci2:15:0: class=0x060700 card=0x00a41028 chip=0xac42104c > rev=0x00 hdr=0x02 > vendor = 'Texas Instruments (TI)' > device = 'PCI4451 PC card CardBus Controller' > class = bridge > subclass = PCI-CardBus > cbb1@pci2:15:1: class=0x060700 card=0x00a41028 chip=0xac42104c > rev=0x00 hdr=0x02 > vendor = 'Texas Instruments (TI)' > device = 'PCI4451 PC card CardBus Controller' > class = bridge > subclass = PCI-CardBus > ndis0@pci5:0:0: class=0x028000 card=0x9067104c chip=0x9066104c > rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' > class = network > > I wound back the versions of the cardbus module. The wireless card > worked again when I made a cardbus module dated < December 29, 2005. > If I advance further than that I get the problem above. > > Does anyone else have this problem? > > Regards, Adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > Adrian; There were some changes made by imp@ to cardbus.h around the turn of the year that were subsequently backed out of -stable, but left in -current. You can read the details at cvsweb.freebsd.org. Perhaps this is what you're seeing. Regards, Patrick From owner-freebsd-current@FreeBSD.ORG Wed Aug 23 14:07:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D4C716A503; Wed, 23 Aug 2006 14:07:27 +0000 (UTC) (envelope-from lscharf@vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77A3E43D45; Wed, 23 Aug 2006 14:07:26 +0000 (GMT) (envelope-from lscharf@vt.edu) Received: from steiner.cc.vt.edu (IDENT:mirapoint@evil-steiner.cc.vt.edu [10.1.1.14]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k7NDvp7H021842; Wed, 23 Aug 2006 10:07:25 -0400 Received: from authsmtp1.cc.vt.edu (imp.cc.vt.edu [198.82.161.55]) by steiner.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FVN66918; Wed, 23 Aug 2006 10:07:24 -0400 (EDT) Received: from [128.173.14.24] (scharf.cc.vt.edu [128.173.14.24]) (authenticated bits=0) by authsmtp1.cc.vt.edu (8.13.1/8.13.1) with ESMTP id k7NE7N8x023537; Wed, 23 Aug 2006 10:07:24 -0400 Message-ID: <44EC611B.30905@vt.edu> Date: Wed, 23 Aug 2006 10:07:23 -0400 From: Luke Scharf User-Agent: Mail/News 1.5 (X11/20051201) MIME-Version: 1.0 To: Ricardo Correia References: <20060822104516.GB16033@garage.freebsd.pl> <200608221830.29039.zfs-opensolaris@wizy.org> In-Reply-To: <200608221830.29039.zfs-opensolaris@wizy.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020907050702080103080401" X-Mailman-Approved-At: Wed, 23 Aug 2006 23:34:16 +0000 Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: [zfs-discuss] Porting ZFS file system to FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 14:07:27 -0000 This is a cryptographically signed message in MIME format. --------------ms020907050702080103080401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Ricardo Correia wrote: > Wow, congratulations, nice work! > > I'm the one porting ZFS to FUSE and seeing you doing such progress so fast is > very very encouraging :) > I'd like to throw a "me too" into the pile of thank-you messages! I spent part of the weekend expanding and manipulating a set of LVM volumes on a pair of RHEL4-ish Linux servers... And I kept grumbling to myself "if this were ZFS, I could be done by now!" Not only that, but I could have matched the configuration to the needs of the users more closely. [0] I look forward to ZFS on both Linux and FreeBSD. It will be a powerful addition to both platforms! Thanks, -Luke [0] Changing a production server from an RHEL4 clone to Solaris isn't something that I'm likely to just-do in a couple of hours over the weekend on a cross-platform domain where I'm just assisting. If I were the sysadmin there, though, it would be practical. --------------ms020907050702080103080401 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJJTCC Au0wggJWoAMCAQICEB2va7zlCHACQRtrQO7Zi4EwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUxOTAxMjM0NVoX DTA3MDUxOTAxMjM0NVowVzEPMA0GA1UEBBMGU2NoYXJmMQ4wDAYDVQQqEwVMdWNhczEVMBMG A1UEAxMMTHVjYXMgU2NoYXJmMR0wGwYJKoZIhvcNAQkBFg5sc2NoYXJmQHZ0LmVkdTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPF9pURsqTPJtjLd9H0N7YjoL+N9M7hYRrXd Y7H3hL0RBs9H15M2ElmkFe879w+3Z9dAl+A9ZQDriGfs87jBl2012s2ndMPn1viKSj/wtb5u Glg4ZxZOnyQm7eiHriCVq2heGkHG7Siv6PcctfDcUt2YieTezjdvtRYDIxYCPQl1R8gtIWXe 6OpZDBYnA+Lc30nmMxoFcFnGdO1DdMJpnWR/D7TuPhMtAEtR+xTouLoKpnyHVYP0bBGTYflk YHbtBO2XilUMlwi5hkZiw/Ug0qDFqUP5RYoA6NpwpkL6AFKexwKfuf7Qq4GkXLXeJLWB2LKD GlYtUBA4BHZOTge2uOcCAwEAAaMrMCkwGQYDVR0RBBIwEIEObHNjaGFyZkB2dC5lZHUwDAYD VR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCj+E9GE6UIn+R0ySpXrK/yOtghunqmLnm+ R68f8g60/tNhzG416Z42eQlze5Au6cqNRx5hrAK4laXSPu49O3LV9oeayJNRBWlJnHxK5AIh ym/26wmWW5YQYVSAK92X99fsti1GJmH2UPC6GmGsQfEh+tQWW3Llw8SVxBy40W/P/DCCAu0w ggJWoAMCAQICEB2va7zlCHACQRtrQO7Zi4EwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUxOTAxMjM0NVoXDTA3 MDUxOTAxMjM0NVowVzEPMA0GA1UEBBMGU2NoYXJmMQ4wDAYDVQQqEwVMdWNhczEVMBMGA1UE AxMMTHVjYXMgU2NoYXJmMR0wGwYJKoZIhvcNAQkBFg5sc2NoYXJmQHZ0LmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAPF9pURsqTPJtjLd9H0N7YjoL+N9M7hYRrXdY7H3 hL0RBs9H15M2ElmkFe879w+3Z9dAl+A9ZQDriGfs87jBl2012s2ndMPn1viKSj/wtb5uGlg4 ZxZOnyQm7eiHriCVq2heGkHG7Siv6PcctfDcUt2YieTezjdvtRYDIxYCPQl1R8gtIWXe6OpZ DBYnA+Lc30nmMxoFcFnGdO1DdMJpnWR/D7TuPhMtAEtR+xTouLoKpnyHVYP0bBGTYflkYHbt BO2XilUMlwi5hkZiw/Ug0qDFqUP5RYoA6NpwpkL6AFKexwKfuf7Qq4GkXLXeJLWB2LKDGlYt UBA4BHZOTge2uOcCAwEAAaMrMCkwGQYDVR0RBBIwEIEObHNjaGFyZkB2dC5lZHUwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCj+E9GE6UIn+R0ySpXrK/yOtghunqmLnm+R68f 8g60/tNhzG416Z42eQlze5Au6cqNRx5hrAK4laXSPu49O3LV9oeayJNRBWlJnHxK5AIhym/2 6wmWW5YQYVSAK92X99fsti1GJmH2UPC6GmGsQfEh+tQWW3Llw8SVxBy40W/P/DCCAz8wggKo oAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNV HRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNv bS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzR UIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6E sZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHa9rvOUIcAJBG2tA7tmLgTAJBgUrDgMCGgUAoIIB wzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MjMxNDA3 MjNaMCMGCSqGSIb3DQEJBDEWBBQDpgeImZwb8rYKU8t7BBq0Y5hZLzBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB2va7zlCHACQRtrQO7Zi4EwgYcGCyqGSIb3 DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEB2va7zlCHACQRtrQO7Zi4EwDQYJKoZIhvcNAQEBBQAEggEATPhULHac9WyeD5RqEkbO 2o7O88EuNGSlZOJjZYn2R6ilqb4gHLYe9jHma0ALotR2ie38F/aXkYtFHFEPoDJGGv72VxG7 Y4AHzxw7KdMRmG3FulWFGRdEmUKT5j/mv1jN7OW40haWRnP7vxeAupRbzgvRaT09tAJjaWq2 /Fn17RsgDgLdMM6ulEEw2HJmuPynMXGT9KEbLwzNkN69zqK1tDHMfNfO+9ewH1artobLmRk+ aOrxC6CR8VEmI+Q/d+seLDprqUDlD6HOSSKG0M8wodzC+Ht6vzFTjVI/TsH/nxlhpN4Q4QWQ YS1qCZGZG0oRoFVZVOGuIkoar0VzgxFF4AAAAAAAAA== --------------ms020907050702080103080401-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:14:14 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E12D316A4DD; Thu, 24 Aug 2006 00:14:14 +0000 (UTC) (envelope-from ryanb@FreeBSD.org) Received: from pds.uberhacker.org (uberhacker.org [71.5.14.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 949C843D45; Thu, 24 Aug 2006 00:14:14 +0000 (GMT) (envelope-from ryanb@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pds.uberhacker.org (Postfix) with ESMTP id 4B1BCA2E; Wed, 23 Aug 2006 17:14:14 -0700 (PDT) Received: from pds.uberhacker.org ([127.0.0.1]) by localhost (pds.uberhacker.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00206-05; Wed, 23 Aug 2006 17:14:09 -0700 (PDT) Received: from [192.168.82.33] (unknown [74.134.233.192]) by pds.uberhacker.org (Postfix) with ESMTP id 70DA25F; Wed, 23 Aug 2006 17:14:09 -0700 (PDT) Message-ID: <44ECEF4D.5050101@FreeBSD.org> Date: Wed, 23 Aug 2006 19:14:05 -0500 From: Ryan Beasley User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Yuriy Tsibizov References: <78664C02FF341B4FAC63E561846E3BCC546A@ex.hhp.local> In-Reply-To: <78664C02FF341B4FAC63E561846E3BCC546A@ex.hhp.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uberhacker.org Cc: current@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: [RFC] Summer of Code -- OSSv4 audio compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:14:15 -0000 Yuriy Tsibizov wrote: > Ryan, will there be any changes for hardware drivers? Yes, there will, but the nature of the changes are yet to be determined. The mixer extensions specify different control types (toggles, enums, sliders, etc.) for exporting audio hardware (and purely software) controls to userland. E.g., a driver may export channel routings of front, rear, and front+rear as MIXT_ENUM, leaving it to the user to pick a routing. > And, as I know you have emu10kx-compatible sound card, can you > test your sound buffering changes with EMU_PLAY_BUFSZ set to > EMUPAGESIZE*2 or larger (dev/sound/pci/emu10kx.h, line49). Since classes just resumed, I have some homework to take care of first ( :P ), but I'll try to take a look at it tonight or tomorrow. -- Ryan Beasley From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:18:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50AD816A4DD for ; Thu, 24 Aug 2006 00:18:32 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C740D43D45 for ; Thu, 24 Aug 2006 00:18:19 +0000 (GMT) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id k7O0GLUB028087 for ; Thu, 24 Aug 2006 09:46:21 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 24 Aug 2006 09:48:11 +0930 Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au [131.185.2.170]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id k7O0DJ723621 for ; Thu, 24 Aug 2006 09:43:19 +0930 (CST) Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC (6.0.3790.1830); Thu, 24 Aug 2006 09:43:19 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.13.7/8.13.7) with ESMTP id k7O0CsG2009188 for ; Thu, 24 Aug 2006 08:12:54 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.13.7/8.13.7/Submit) id k7O0CsAG009187 for freebsd-current@freebsd.org; Thu, 24 Aug 2006 08:12:54 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 24 Aug 2006 08:12:54 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20060824001254.GA75529@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org> <20060823095504.GI17902@cdnetworks.co.kr> <20060823100420.GG96644@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20060823100420.GG96644@cell.sick.ru> User-Agent: Mutt/1.5.12-2006-07-14 X-OriginalArrivalTime: 24 Aug 2006 00:13:19.0377 (UTC) FILETIME=[1A73C010:01C6C712] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.6.1039-14646.003 X-TM-AS-Result: No--0.315400-0.000000-31 Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:18:32 -0000 0n Wed, Aug 23, 2006 at 02:04:20PM +0400, Gleb Smirnoff wrote: >On Wed, Aug 23, 2006 at 06:55:04PM +0900, Pyun YongHyeon wrote: >P> On Wed, Aug 23, 2006 at 01:37:41PM +0400, Gleb Smirnoff wrote: >P> > On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: >P> > P> After fixing em(4) watchdog bug, I looked over bge(4) and I think >P> > P> bge(4) may suffer from the same issue. So if you have seen occasional >P> > P> watchdog timeout errors on bge(4) please give the attached patch a try. >P> > P> The patch does fix false watchdog timeout error only. >P> > P> Typical pheonoma for false watchdog timeout error are >P> > P> o polling(4) fix the issue >P> > P> o random watchdog error >P> > P> >P> > P> If my patch fix the issue you could see the following messages. >P> > P> "missing Tx completion interrupt!" or "link lost -- resetting" >P> > >P> > I still think that this fix is incorrect. It is just a more gentle >P> > recovery from a fake watchdog timeout. >P> >P> Its sole purpose is to reinitialize hardware for real watchdog >P> timeouts. It's not fix for general watchdog timeouts. As I said other >P> mails, the fake watchdog timeout(losing Tx interrupts) for hardwares >P> with Tx interrupt moderation capability could be normal thing. So I >P> just want to know bge(4) also has the same feature(bug). > >According to several emails about em(4) fake watchdog timeouts, the >problem can be fixed by setting debug.mpsafenet=0. This makes me think >that the problem isn't caused by TX interrupt moderation, but some race >in the kernel. Really, if_slowtimo() doesn't acquire driver lock before >checking and modifying the if_timer field. > >Afaik, NIC drivers that can do interrupt moderation should set a timer >to a sane value, based on interrupt moderation settings, so that the >watchdog won't be ever called fakely. What is interrupt moderation ? -aW From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:26:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D7C16A4E2 for ; Thu, 24 Aug 2006 00:26:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332CD43D5A for ; Thu, 24 Aug 2006 00:26:27 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so411746pye for ; Wed, 23 Aug 2006 17:26:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KbzKGFx3bvlPQcIZilqy8a2/r9eLXdaVkiPgEYVLcTIWmlOzwl6uBiVU63F0gJZK41hfqfkHQJvtfRcYF367UCr/JaZrMCHcJZFtmCYP2bIbe/fN1q1nd5Z+d4KErRFaMpe+yoCmEjNsfkrzICZLm9x3oawEA7T2ZDi22GFSPiM= Received: by 10.35.49.1 with SMTP id b1mr1581151pyk; Wed, 23 Aug 2006 17:26:27 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 14sm1739254nzp.2006.08.23.17.26.25; Wed, 23 Aug 2006 17:26:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O0QXVP022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 09:26:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O0QWdl022871; Thu, 24 Aug 2006 09:26:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 09:26:32 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060824002632.GA22634@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823124035.GA18628@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:26:43 -0000 On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > ... > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > >is a possiblity to have the same issue seen on em(4). > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > Yes, please! > > > > I can test it (on RELENG_6 though). > > > > > > I have an idea why those timeouts can happen. Could you please test > > > attached patch? It may help (or may not). Anyway would be fine > > > to know results. > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > protected with the mutex I guess it wouldn't help much. > > I guess it needs a seperate mutex to protect miibus(4) handler > > and should remove the use of MTX_RECURSE. > > Hmm. > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > 2) As i can see MII layer is not protected by anything, unless you > specially acquire driver lock prior to calling mii_ function. > Locking ifmedia callbacks should be done (though, it may not help > with watchdogs timeout), otherwise we have race on accessing PHY registers. > (kern/98738). > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > (and maybe others, those ones which i remember) drivers. > All of them has unlocked _ifmedia_ functions. > AFAIK all known sk(4) bug were fixed. If it's not please let me know. > My idea was: perhaps, under certain condition, concurrent access to PHY could > lead to hardware deadlock. > Yes. Because MII bus access needs several steps to access PHY registers its operation shouldn't be interrupted until all pending requests are served. I can't sure you remember my mail for MII lock which modifies mii_phy_probe API to take an additional mutex. The driver mutex could be used with MII bus access/callbacks. If interface is up/running and auto negotiation is in progress MII layer would inspect BMSR register periodically to know the state of link. During the time if you run ifconfig(8) to know the state of the link or to change media type/duplex it will access PHY registers. Normally it would end up with "link states coalesced" messages. As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will end up with calling mii_mediachg() or mii_pollstat() which in turn access PHY registers. So if MII access is properly serialized we wouldn't get stale data. I guess your fix solves it by protecting callbacks with driver mutex but it wouldn't fix other cases. For example see vge_miibus_statchg MII interface. > > > vge(4) also has a bug > > if mbuf chain is too long(7 or higher) and defragmentation with > > m_defrag(9) fails it would access an invalid mbuf chain. > > All these requires lots of work and need a real hardware. > > Oleg, if you have hardware, would you fix it? > > Unfortunately i don't have vge hardware. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:30:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A287116A4DF for ; Thu, 24 Aug 2006 00:30:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C434243D4C for ; Thu, 24 Aug 2006 00:30:28 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so412989pye for ; Wed, 23 Aug 2006 17:30:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=SU7YgaJSBY6OeD3Cu5yJA2HfOosbPcGrykpqHlyl4dS1+R6lzrdNG5wsFuo5angPkTt1IJ5KkGkfcSSthCmFGJ276OnUo2H7UJYFDdkbmiIjpjU2gyFl8yGfU6FUj7Nw5cdKhRiwdFMM0MExrzxWJR0Trj86+qi1+Ybou7L/DiA= Received: by 10.35.100.6 with SMTP id c6mr1643297pym; Wed, 23 Aug 2006 17:30:28 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id j7sm854116nzd.2006.08.23.17.30.26; Wed, 23 Aug 2006 17:30:28 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O0UaGe022901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 09:30:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O0UZCT022900; Thu, 24 Aug 2006 09:30:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 09:30:35 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060824003035.GB22634@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060823125434.GA19111@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823125434.GA19111@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:30:30 -0000 On Wed, Aug 23, 2006 at 04:54:34PM +0400, Oleg Bulyzhin wrote: > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > > ... > > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > > >is a possiblity to have the same issue seen on em(4). > > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > > > Yes, please! > > > > > I can test it (on RELENG_6 though). > > > > > > > > I have an idea why those timeouts can happen. Could you please test > > > > attached patch? It may help (or may not). Anyway would be fine > > > > to know results. > > > > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > > protected with the mutex I guess it wouldn't help much. > > > I guess it needs a seperate mutex to protect miibus(4) handler > > > and should remove the use of MTX_RECURSE. > > > > Hmm. > > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > > 2) As i can see MII layer is not protected by anything, unless you > > specially acquire driver lock prior to calling mii_ function. > > Locking ifmedia callbacks should be done (though, it may not help > > with watchdogs timeout), otherwise we have race on accessing PHY registers. > > (kern/98738). > > > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > > (and maybe others, those ones which i remember) drivers. > > All of them has unlocked _ifmedia_ functions. > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > lead to hardware deadlock. > > > > > > > vge(4) also has a bug > > > if mbuf chain is too long(7 or higher) and defragmentation with > > > m_defrag(9) fails it would access an invalid mbuf chain. > > > All these requires lots of work and need a real hardware. > > > Oleg, if you have hardware, would you fix it? > > > > Unfortunately i don't have vge hardware. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > -- > > Oleg. > > > > Forgot one thing: i think we need no dedicated mutex for mii layer if we lock > ifmedia callbacks. > If we use the diver mutex in MII access it would require MTX_RECURSE mutex. I want simple MTX_DEF mutex. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:42:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92A216A4DA for ; Thu, 24 Aug 2006 00:42:31 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A3343D78 for ; Thu, 24 Aug 2006 00:42:26 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O0gP0j027597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 04:42:25 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O0gPMA027596; Thu, 24 Aug 2006 04:42:25 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 04:42:25 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824004225.GB25876@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060824002632.GA22634@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824002632.GA22634@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:42:31 -0000 On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > > ... > > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > > >is a possiblity to have the same issue seen on em(4). > > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > > > Yes, please! > > > > > I can test it (on RELENG_6 though). > > > > > > > > I have an idea why those timeouts can happen. Could you please test > > > > attached patch? It may help (or may not). Anyway would be fine > > > > to know results. > > > > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > > protected with the mutex I guess it wouldn't help much. > > > I guess it needs a seperate mutex to protect miibus(4) handler > > > and should remove the use of MTX_RECURSE. > > > > Hmm. > > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > > 2) As i can see MII layer is not protected by anything, unless you > > specially acquire driver lock prior to calling mii_ function. > > Locking ifmedia callbacks should be done (though, it may not help > > with watchdogs timeout), otherwise we have race on accessing PHY registers. > > (kern/98738). > > > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > > (and maybe others, those ones which i remember) drivers. > > All of them has unlocked _ifmedia_ functions. > > > > AFAIK all known sk(4) bug were fixed. If it's not please let me know. > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > lead to hardware deadlock. > > > > Yes. Because MII bus access needs several steps to access PHY > registers its operation shouldn't be interrupted until all pending > requests are served. > > I can't sure you remember my mail for MII lock which modifies > mii_phy_probe API to take an additional mutex. The driver mutex > could be used with MII bus access/callbacks. Yes, i remember that mail but i didnt had time to dig code deep enough to give an answer. I did it recently, while working on PR. > If interface is up/running and auto negotiation is in progress MII > layer would inspect BMSR register periodically to know the state > of link. During the time if you run ifconfig(8) to know the state > of the link or to change media type/duplex it will access PHY > registers. Normally it would end up with "link states coalesced" > messages. > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > end up with calling mii_mediachg() or mii_pollstat() which in turn > access PHY registers. So if MII access is properly serialized we > wouldn't get stale data. I guess your fix solves it by protecting > callbacks with driver mutex but it wouldn't fix other cases. > For example see vge_miibus_statchg MII interface. MII layer does not have it's own callouts, i.e. those autonegotiation checks of BMSR are triggered by driver's _tick() function, which are locked. So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent access to PHY is impossible. (If we are talking about vge_miibus_statchg(), it would be: vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> mii_phy_update -> vge_miibus_statchg). > > > > > > vge(4) also has a bug > > > if mbuf chain is too long(7 or higher) and defragmentation with > > > m_defrag(9) fails it would access an invalid mbuf chain. > > > All these requires lots of work and need a real hardware. > > > Oleg, if you have hardware, would you fix it? > > > > Unfortunately i don't have vge hardware. > > -- > Regards, > Pyun YongHyeon -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 00:43:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9F8D16A4E6 for ; Thu, 24 Aug 2006 00:43:58 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D1DA43D55 for ; Thu, 24 Aug 2006 00:43:55 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O0hsIL027608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 04:43:54 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O0hsDm027607; Thu, 24 Aug 2006 04:43:54 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 04:43:54 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824004354.GC25876@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060823125434.GA19111@lath.rinet.ru> <20060824003035.GB22634@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824003035.GB22634@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 00:43:59 -0000 On Thu, Aug 24, 2006 at 09:30:35AM +0900, Pyun YongHyeon wrote: > On Wed, Aug 23, 2006 at 04:54:34PM +0400, Oleg Bulyzhin wrote: > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > > > ... > > > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > > > >is a possiblity to have the same issue seen on em(4). > > > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > > > > > Yes, please! > > > > > > I can test it (on RELENG_6 though). > > > > > > > > > > I have an idea why those timeouts can happen. Could you please test > > > > > attached patch? It may help (or may not). Anyway would be fine > > > > > to know results. > > > > > > > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > > > protected with the mutex I guess it wouldn't help much. > > > > I guess it needs a seperate mutex to protect miibus(4) handler > > > > and should remove the use of MTX_RECURSE. > > > > > > Hmm. > > > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > > > 2) As i can see MII layer is not protected by anything, unless you > > > specially acquire driver lock prior to calling mii_ function. > > > Locking ifmedia callbacks should be done (though, it may not help > > > with watchdogs timeout), otherwise we have race on accessing PHY registers. > > > (kern/98738). > > > > > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > > > (and maybe others, those ones which i remember) drivers. > > > All of them has unlocked _ifmedia_ functions. > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > lead to hardware deadlock. > > > > > > > > > > vge(4) also has a bug > > > > if mbuf chain is too long(7 or higher) and defragmentation with > > > > m_defrag(9) fails it would access an invalid mbuf chain. > > > > All these requires lots of work and need a real hardware. > > > > Oleg, if you have hardware, would you fix it? > > > > > > Unfortunately i don't have vge hardware. > > > > > > > > -- > > > > Regards, > > > > Pyun YongHyeon > > > > > > -- > > > Oleg. > > > > > > > Forgot one thing: i think we need no dedicated mutex for mii layer if we lock > > ifmedia callbacks. > > > > If we use the diver mutex in MII access it would require MTX_RECURSE > mutex. I want simple MTX_DEF mutex. Could you please explain why MTX_RECURSE is required? > > -- > Regards, > Pyun YongHyeon -- Oleg. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 01:07:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 670E916A4DA for ; Thu, 24 Aug 2006 01:07:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FEB43D55 for ; Thu, 24 Aug 2006 01:07:40 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so424916pye for ; Wed, 23 Aug 2006 18:07:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=qA7gjO8b6k0e8XTzUEQNYy/Qqn1vSG3dp+QtwLKCIM068M1SIqYEmYgnr3LOimykXe+Opi0iXNZpJ36aVokPgPj2ONmqVyP5oH8gIsxPhcq6vzZFi5W2kw3Wg6xw2BMzZEO1sFmy4YjnyELBQ3WdcZsEeuNxPzj7fwZiaan5Po4= Received: by 10.35.96.11 with SMTP id y11mr1673161pyl; Wed, 23 Aug 2006 18:07:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 20sm2828013nzp.2006.08.23.18.07.38; Wed, 23 Aug 2006 18:07:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O17mxW023039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 10:07:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O17lEb023038; Thu, 24 Aug 2006 10:07:47 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 10:07:46 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060824010746.GC22634@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060823125434.GA19111@lath.rinet.ru> <20060824003035.GB22634@cdnetworks.co.kr> <20060824004354.GC25876@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824004354.GC25876@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:07:43 -0000 On Thu, Aug 24, 2006 at 04:43:54AM +0400, Oleg Bulyzhin wrote: > On Thu, Aug 24, 2006 at 09:30:35AM +0900, Pyun YongHyeon wrote: > > On Wed, Aug 23, 2006 at 04:54:34PM +0400, Oleg Bulyzhin wrote: > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > > > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > > > > ... > > > > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > > > > >is a possiblity to have the same issue seen on em(4). > > > > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > > > > > > > Yes, please! > > > > > > > I can test it (on RELENG_6 though). > > > > > > > > > > > > I have an idea why those timeouts can happen. Could you please test > > > > > > attached patch? It may help (or may not). Anyway would be fine > > > > > > to know results. > > > > > > > > > > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > > > > protected with the mutex I guess it wouldn't help much. > > > > > I guess it needs a seperate mutex to protect miibus(4) handler > > > > > and should remove the use of MTX_RECURSE. > > > > > > > > Hmm. > > > > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > > > > 2) As i can see MII layer is not protected by anything, unless you > > > > specially acquire driver lock prior to calling mii_ function. > > > > Locking ifmedia callbacks should be done (though, it may not help > > > > with watchdogs timeout), otherwise we have race on accessing PHY registers. > > > > (kern/98738). > > > > > > > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > > > > (and maybe others, those ones which i remember) drivers. > > > > All of them has unlocked _ifmedia_ functions. > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > lead to hardware deadlock. > > > > > > > > > > > > > vge(4) also has a bug > > > > > if mbuf chain is too long(7 or higher) and defragmentation with > > > > > m_defrag(9) fails it would access an invalid mbuf chain. > > > > > All these requires lots of work and need a real hardware. > > > > > Oleg, if you have hardware, would you fix it? > > > > > > > > Unfortunately i don't have vge hardware. > > > > > > > > > > -- > > > > > Regards, > > > > > Pyun YongHyeon > > > > > > > > -- > > > > Oleg. > > > > > > > > > > Forgot one thing: i think we need no dedicated mutex for mii layer if we lock > > > ifmedia callbacks. > > > > > > > If we use the diver mutex in MII access it would require MTX_RECURSE > > mutex. I want simple MTX_DEF mutex. > > Could you please explain why MTX_RECURSE is required? > I can't remember what caused this. Need more coffee. :-( If my memory serve me right it's related with ioctls. I guess you can easily experiment with removing MTX_RECURSE flag in the driver. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 01:11:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFB3B16A4DE for ; Thu, 24 Aug 2006 01:11:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1DA143D4C for ; Thu, 24 Aug 2006 01:11:10 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so426046pye for ; Wed, 23 Aug 2006 18:11:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=G/gSWkFlL1LgJIuU/yUtSlXwiKOGZLwvUJ8P5IQ7M39TlXxfdZC0DMLLd2HYdEN5xoRrbwF1LJYt3c1EWvZIEWLZhQ1N9msMZpkA281ZbIKRey3LOnuClIoEYSeGc4XgD3jZxyn7e/NNFPZhUmzQWMCENFvt9A2dCeVP6BaRFfs= Received: by 10.35.121.9 with SMTP id y9mr1651713pym; Wed, 23 Aug 2006 18:11:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id j4sm876755nzd.2006.08.23.18.11.07; Wed, 23 Aug 2006 18:11:09 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O1BGJi023071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 10:11:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O1BGcY023070; Thu, 24 Aug 2006 10:11:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 10:11:16 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060824011116.GD22634@cdnetworks.co.kr> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060824002632.GA22634@cdnetworks.co.kr> <20060824004225.GB25876@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824004225.GB25876@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:11:12 -0000 On Thu, Aug 24, 2006 at 04:42:25AM +0400, Oleg Bulyzhin wrote: > On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: [...] > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > lead to hardware deadlock. > > > > > > > Yes. Because MII bus access needs several steps to access PHY > > registers its operation shouldn't be interrupted until all pending > > requests are served. > > > > I can't sure you remember my mail for MII lock which modifies > > mii_phy_probe API to take an additional mutex. The driver mutex > > could be used with MII bus access/callbacks. > > Yes, i remember that mail but i didnt had time to dig code deep enough > to give an answer. I did it recently, while working on PR. > Glad to hear that. :-) > > If interface is up/running and auto negotiation is in progress MII > > layer would inspect BMSR register periodically to know the state > > of link. During the time if you run ifconfig(8) to know the state > > of the link or to change media type/duplex it will access PHY > > registers. Normally it would end up with "link states coalesced" > > messages. > > > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > > end up with calling mii_mediachg() or mii_pollstat() which in turn > > access PHY registers. So if MII access is properly serialized we > > wouldn't get stale data. I guess your fix solves it by protecting > > callbacks with driver mutex but it wouldn't fix other cases. > > For example see vge_miibus_statchg MII interface. > > MII layer does not have it's own callouts, i.e. those autonegotiation > checks of BMSR are triggered by driver's _tick() function, which are locked. > So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent > access to PHY is impossible. > (If we are talking about vge_miibus_statchg(), it would be: > vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> > mii_phy_update -> vge_miibus_statchg). > If we set media type manually while autonegotiation is in progress, wouldn't it access PHY registers without driver lock? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 01:12:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E13C216A4E1 for ; Thu, 24 Aug 2006 01:12:51 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9583043D60 for ; Thu, 24 Aug 2006 01:12:45 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O1CiwO027983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 05:12:44 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O1CitA027982; Thu, 24 Aug 2006 05:12:44 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 05:12:44 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824011244.GB27699@lath.rinet.ru> References: <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060823125434.GA19111@lath.rinet.ru> <20060824003035.GB22634@cdnetworks.co.kr> <20060824004354.GC25876@lath.rinet.ru> <20060824010746.GC22634@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824010746.GC22634@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:12:52 -0000 On Thu, Aug 24, 2006 at 10:07:46AM +0900, Pyun YongHyeon wrote: > > I can't remember what caused this. Need more coffee. :-( > If my memory serve me right it's related with ioctls. > I guess you can easily experiment with removing MTX_RECURSE flag > in the driver. I'll try tomorrow (oh, today), have to sleep a bit. :) -- Oleg. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 01:24:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D64116A4DD for ; Thu, 24 Aug 2006 01:24:52 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7941B43D4C for ; Thu, 24 Aug 2006 01:24:51 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O1Ookh028069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 05:24:50 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O1Oo5F028068; Thu, 24 Aug 2006 05:24:50 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 05:24:50 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824012450.GC27699@lath.rinet.ru> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060824002632.GA22634@cdnetworks.co.kr> <20060824004225.GB25876@lath.rinet.ru> <20060824011116.GD22634@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824011116.GD22634@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:24:52 -0000 On Thu, Aug 24, 2006 at 10:11:16AM +0900, Pyun YongHyeon wrote: > On Thu, Aug 24, 2006 at 04:42:25AM +0400, Oleg Bulyzhin wrote: > > On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > [...] > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > lead to hardware deadlock. > > > > > > > > > > Yes. Because MII bus access needs several steps to access PHY > > > registers its operation shouldn't be interrupted until all pending > > > requests are served. > > > > > > I can't sure you remember my mail for MII lock which modifies > > > mii_phy_probe API to take an additional mutex. The driver mutex > > > could be used with MII bus access/callbacks. > > > > Yes, i remember that mail but i didnt had time to dig code deep enough > > to give an answer. I did it recently, while working on PR. > > > > Glad to hear that. :-) > > > > If interface is up/running and auto negotiation is in progress MII > > > layer would inspect BMSR register periodically to know the state > > > of link. During the time if you run ifconfig(8) to know the state > > > of the link or to change media type/duplex it will access PHY > > > registers. Normally it would end up with "link states coalesced" > > > messages. > > > > > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > > > end up with calling mii_mediachg() or mii_pollstat() which in turn > > > access PHY registers. So if MII access is properly serialized we > > > wouldn't get stale data. I guess your fix solves it by protecting > > > callbacks with driver mutex but it wouldn't fix other cases. > > > For example see vge_miibus_statchg MII interface. > > > > MII layer does not have it's own callouts, i.e. those autonegotiation > > checks of BMSR are triggered by driver's _tick() function, which are locked. > > So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent > > access to PHY is impossible. > > (If we are talking about vge_miibus_statchg(), it would be: > > vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> > > mii_phy_update -> vge_miibus_statchg). > > > > If we set media type manually while autonegotiation is in progress, > wouldn't it access PHY registers without driver lock? No (if we have _tick() & ifmedia callbacks locked): ioctl -> netioctl -> ifhwioctl -> vge_ioctl(SIOCSIFMEDIA) -> ifmedia_ioctl -> vge_ifmedia_upd (here we obtain lock) -> mii_mediachg -> ciphy_service(MII_MEDIACHG) -> mii_phy_update -> vge_miibus_statchg > > -- > Regards, > Pyun YongHyeon -- Oleg. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 01:41:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEEEB16A4E8 for ; Thu, 24 Aug 2006 01:41:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B25343D49 for ; Thu, 24 Aug 2006 01:41:14 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f25so414384pyf for ; Wed, 23 Aug 2006 18:41:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=OZdEh86Qkt5GZsS0thpc6WqdV/uK0UlLLX/E4BEh8+R1/Y3B2EQ8s0OhIK6s90p1ecwkprpawIXHQB4RwTn4a5IL/Db0F5C3W3r7LHnRS500rUQZ9nN6w2JxiaY2kSycWLqO7xtAdzinBmazETKr4U5vqD9ILzAP2zh2V8ZARQM= Received: by 10.35.105.18 with SMTP id h18mr1675218pym; Wed, 23 Aug 2006 18:41:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 16sm2481938nzo.2006.08.23.18.41.13; Wed, 23 Aug 2006 18:41:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O1fMEk023163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 10:41:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O1fLEK023162; Thu, 24 Aug 2006 10:41:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 10:41:21 +0900 From: Pyun YongHyeon To: Oleg Bulyzhin Message-ID: <20060824014121.GE22634@cdnetworks.co.kr> References: <20060822091107.A3909@fw.reifenberger.com> <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060824002632.GA22634@cdnetworks.co.kr> <20060824004225.GB25876@lath.rinet.ru> <20060824011116.GD22634@cdnetworks.co.kr> <20060824012450.GC27699@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824012450.GC27699@lath.rinet.ru> User-Agent: Mutt/1.4.2.1i Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:41:16 -0000 On Thu, Aug 24, 2006 at 05:24:50AM +0400, Oleg Bulyzhin wrote: > On Thu, Aug 24, 2006 at 10:11:16AM +0900, Pyun YongHyeon wrote: > > On Thu, Aug 24, 2006 at 04:42:25AM +0400, Oleg Bulyzhin wrote: > > > On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > > [...] > > > > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > > lead to hardware deadlock. > > > > > > > > > > > > > Yes. Because MII bus access needs several steps to access PHY > > > > registers its operation shouldn't be interrupted until all pending > > > > requests are served. > > > > > > > > I can't sure you remember my mail for MII lock which modifies > > > > mii_phy_probe API to take an additional mutex. The driver mutex > > > > could be used with MII bus access/callbacks. > > > > > > Yes, i remember that mail but i didnt had time to dig code deep enough > > > to give an answer. I did it recently, while working on PR. > > > > > > > Glad to hear that. :-) > > > > > > If interface is up/running and auto negotiation is in progress MII > > > > layer would inspect BMSR register periodically to know the state > > > > of link. During the time if you run ifconfig(8) to know the state > > > > of the link or to change media type/duplex it will access PHY > > > > registers. Normally it would end up with "link states coalesced" > > > > messages. > > > > > > > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > > > > end up with calling mii_mediachg() or mii_pollstat() which in turn > > > > access PHY registers. So if MII access is properly serialized we > > > > wouldn't get stale data. I guess your fix solves it by protecting > > > > callbacks with driver mutex but it wouldn't fix other cases. > > > > For example see vge_miibus_statchg MII interface. > > > > > > MII layer does not have it's own callouts, i.e. those autonegotiation > > > checks of BMSR are triggered by driver's _tick() function, which are locked. > > > So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent > > > access to PHY is impossible. > > > (If we are talking about vge_miibus_statchg(), it would be: > > > vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> > > > mii_phy_update -> vge_miibus_statchg). > > > > > > > If we set media type manually while autonegotiation is in progress, > > wouldn't it access PHY registers without driver lock? > > No (if we have _tick() & ifmedia callbacks locked): > ioctl -> netioctl -> ifhwioctl -> vge_ioctl(SIOCSIFMEDIA) -> ifmedia_ioctl -> > vge_ifmedia_upd (here we obtain lock) -> mii_mediachg -> > ciphy_service(MII_MEDIACHG) -> mii_phy_update -> vge_miibus_statchg > Ah...I've missed the your assumption ifmedia callbacks were locked. As you said, several drivers don't have locks for ifmedia callback handlers. These drivers would access PHY registers without locks. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 06:14:50 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9825D16A4DA; Thu, 24 Aug 2006 06:14:50 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F4F43D49; Thu, 24 Aug 2006 06:14:49 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from carrera ([82.179.82.167]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7O6EZIn033031 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Aug 2006 10:14:38 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <002e01c6c744$97bc9560$9800a8c0@carrera> From: "Michael Bushkov" To: "Doug Barton" References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> Date: Thu, 24 Aug 2006 10:13:41 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 06:14:50 -0000 Doug Barton wrote: > Michael Bushkov wrote: > Here is where (once again) we have a difference of opinion. I still > believe > strongly that the nss_ldap part of your work should be a port, with a > dependency on the openldap in ports. I've stated my reasoning on this in > the > previous thread, so I won't rehash it here unless someone asks. I would > like > to point out though that I feel the numerous problems raised in this > thread > give even more weight to the request that I, and others made not to have > it > incorporated into the base. > > This in no way is meant to indicate that your work has no value, or is > somehow "less valuable" than work that is actually in the base. It is > simply > a realistic reflection of the fact that this facility will be needed by a > small percentage of FreeBSD users, and the difficulties (costs) outweigh > the > corresponding benefit. > > A compromise position, if it can be made to work, would be to import your > original work on the nss_ldap module, but have it use openldap from ports > rather than having to import openldap. Well, maybe more compromise solution will be to have OpenLDAP and nss_ldap in the base, but to have them turned off by default, so the user would need to specify WITH_LDAP and WITH_NSS_LDAP in the make.conf to build them. More, if the user don't want to have OpenLDAP built with the base, but wants nss_ldap there, he'd have the ability to link nss_ldap against the ports. And we should also have rewritten nss_ldap in ports (call it nss_ldap_bsd, for example). IMHO, It's quite a flexible scheme that should satisfy most number of users. My main concern with such solution is: will it affect the capability of installing OpenLDAP and nss_ldap out of the box? With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 06:51:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B67D16A4DF for ; Thu, 24 Aug 2006 06:51:16 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id D404B43D45 for ; Thu, 24 Aug 2006 06:51:15 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GG93Y-0007kQ-9a for freebsd-current@freebsd.org; Thu, 24 Aug 2006 08:51:12 +0200 To: freebsd-current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Thu, 24 Aug 2006 08:51:12 +0200 Message-Id: Subject: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 06:51:16 -0000 Hi Just a quick poll to fisd out if it's just me or something else. Has anyone managed to compile any of openoffice.org-1.0, openoffice.org-1.1 or openoffice.org-2.0 on a recent(ish) CURRENT? openoffice.org-1.1 fails with: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.5: version GLIBCPP_3.2 required by ./regxpcom not defined dmake: Error code 1, while making './unxfbsd.pro/misc/build/so_moz_runtime_files' openoffice.org-2.0 fails with: Checking DLL ../unxfbsdi.pro/lib/check_libuno_sal.so.3 ...: ERROR: ../unxfbsdi.pro/lib/check_libuno_sal.so.3: Undefined symbol "gethostbyname_r" dmake: Error code 1, while making '../unxfbsdi.pro/lib/libuno_sal.so.3' Is there a quick fix? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 07:53:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B6D16A4DE for ; Thu, 24 Aug 2006 07:53:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E31343D4C for ; Thu, 24 Aug 2006 07:53:22 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D7B4220A6; Thu, 24 Aug 2006 09:53:18 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id BB0A220A5; Thu, 24 Aug 2006 09:53:18 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id E1CC433C24; Thu, 24 Aug 2006 09:53:17 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Boris Samorodov References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> <93154117@bsam.ru> Date: Thu, 24 Aug 2006 09:53:17 +0200 In-Reply-To: <93154117@bsam.ru> (Boris Samorodov's message of "Wed, 23 Aug 2006 16:16:26 +0400") Message-ID: <867j0yin82.fsf@xps.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , freebsd-current@freebsd.org, LI Xin , Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 07:53:24 -0000 Boris Samorodov writes: > On Wed, 23 Aug 2006 13:46:40 +0200 Dag-Erling Sm=F8rgrav wrote: > > Wrong. It is already possible in today's tree to build the base > > system's Kerberos with OpenLDAP support using the OpenLDAP port, and > > there are similar provisions for using OpenSSL from ports. > Can you point me where I can read about this capability? /usr/src DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 07:56:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BC1916A511 for ; Thu, 24 Aug 2006 07:56:33 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id AABD443D45 for ; Thu, 24 Aug 2006 07:56:32 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from msd.mbrd.ru ([172.16.33.193]) by relay-er5.mbrd.ru with esmtpa (Exim 4.x) id 1GGA4h-0005Ke-P0; Thu, 24 Aug 2006 11:56:27 +0400 Message-ID: <44ED5BAE.8030807@FreeBSD.org> Date: Thu, 24 Aug 2006 11:56:30 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 07:56:33 -0000 Ian FREISLICH wrote: > > openoffice.org-2.0 fails with: > Checking DLL ../unxfbsdi.pro/lib/check_libuno_sal.so.3 ...: ERROR: ../unxfbsdi.pro/lib/check_libuno_sal.so.3: Undefined symbol "gethostbyname_r" > dmake: Error code 1, while making '../unxfbsdi.pro/lib/libuno_sal.so.3' > > Is there a quick fix? You should find gethostbyname_r() call and fix arguments. It appears in CURRENT and has a little differ arguments list. I think the questions belong to ports@ mail list. -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 08:08:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35B5516A4DD for ; Thu, 24 Aug 2006 08:08:02 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A1B43D72 for ; Thu, 24 Aug 2006 08:07:35 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7O87Tmc022639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Aug 2006 10:07:29 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7O87Tkk022638; Thu, 24 Aug 2006 10:07:29 +0200 (CEST) Date: Thu, 24 Aug 2006 10:07:29 +0200 From: Divacky Roman To: Paul Mather Message-ID: <20060824080728.GA22406@stud.fit.vutbr.cz> References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <20060820204338.GA76869@stud.fit.vutbr.cz> <1156121912.32130.22.camel@zappa.Chelsea-Ct.Org> <20060821080748.GA14037@stud.fit.vutbr.cz> <20060821134635.GA27362@stud.fit.vutbr.cz> <1156348193.1499.11.camel@zappa.Chelsea-Ct.Org> <20060823174741.GA83282@stud.fit.vutbr.cz> <1156359417.51081.10.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156359417.51081.10.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 08:08:02 -0000 On Wed, Aug 23, 2006 at 02:56:57PM -0400, Paul Mather wrote: > On Wed, 2006-08-23 at 19:47 +0200, Divacky Roman wrote: > > > On Wed, Aug 23, 2006 at 11:49:53AM -0400, Paul Mather wrote: > > > On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > > > > > > > it seems like very trivial so expect patch today ;) > > > > > > > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > > > > > > > pls tell me if this works, thnx > > > > > > The patch applied and built on i386. However, when I run the resultant > > > kernel, the problem of the "syscall statfs64 not implemented" messages > > > goes away but my Tivoli backup still fails (in a different way). (The > > > same Tivoli client and setup worked on i386 -CURRENT prior to > > > mid-August, and currently is working on an i386 6.1-STABLE system.) > > > > > > Now, when the scheduled backup runs, I get things like this in my > > > dsmerror.log: > > > > > > 08/23/06 02:58:37 TransErrno: Unexpected error from GetFSInfo:statfs, errno = 14 > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup' failed > > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' failed > > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' failed > > > 08/23/06 02:58:38 ANS1063E The specified path is not a valid file system or logical volume name. > > > > > > 08/23/06 02:58:40 ANS1512E Scheduled event 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. > > > > > > > > > I don't know if this indicates that there is a problem with the > > > implementation of statfs64/statfs, now. (I don't know if it complicates > > > matters, but I'm backing up mounted snapshots.) > > > > pls, can you build -DDEBUG version of linuxolator and show me what it prints? > > Here is the output and debug output in /var/log/messages resulting from > running the following command: pls, can you apply this patch: --- /tmp/tmp.72430.0 Thu Aug 24 10:06:00 2006 +++ /root/projects/soc2006/compat/linux/linux_stats.c Thu Aug 24 10:04:56 2006 @@ -427,8 +427,8 @@ LCONVPATHEXIST(td, args->path, &path); #ifdef DEBUG - if (ldebug(statfs)) - printf(ARGS(statfs, "%s, *"), path); + if (ldebug(statfs64)) + printf(ARGS(statfs64, "%s, *"), path); #endif error = kern_statfs(td, path, UIO_SYSSPACE, &bsd_statfs); LFREEPATH(path); and show me the output again. (I forgot to change the debuging print so I cannot distinguish call to statfs and statfs64). anyway - in the output you provided me all statfs[64] calls succeeded and I didnt see anything obvious. I might try my own tests... From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 08:24:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD38416A4DA for ; Thu, 24 Aug 2006 08:24:45 +0000 (UTC) (envelope-from mattik@bigpond.net.au) Received: from omta01ps.mx.bigpond.com (omta01ps.mx.bigpond.com [144.140.82.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD25C43D6E for ; Thu, 24 Aug 2006 08:24:43 +0000 (GMT) (envelope-from mattik@bigpond.net.au) Received: from platypus.freebsd.home ([138.130.171.246]) by omta01ps.mx.bigpond.com with ESMTP id <20060824082440.SFWA29999.omta01ps.mx.bigpond.com@platypus.freebsd.home>; Thu, 24 Aug 2006 08:24:40 +0000 Date: Thu, 24 Aug 2006 18:21:42 +1000 From: matti k To: Ian FREISLICH Message-ID: <20060824182142.611de883@platypus.freebsd.home> In-Reply-To: <44ED5BAE.8030807@FreeBSD.org> References: <44ED5BAE.8030807@FreeBSD.org> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 08:24:45 -0000 On Thu, 24 Aug 2006 11:56:30 +0400 Sergey Matveychuk wrote: > Ian FREISLICH wrote: > > > > openoffice.org-2.0 fails with: > > Checking DLL ../unxfbsdi.pro/lib/check_libuno_sal.so.3 ...: > > ERROR: ../unxfbsdi.pro/lib/check_libuno_sal.so.3: Undefined symbol > > "gethostbyname_r" dmake: Error code 1, while making > > '../unxfbsdi.pro/lib/libuno_sal.so.3' > > > > Is there a quick fix? > > You should find gethostbyname_r() call and fix arguments. It appears > in CURRENT and has a little differ arguments list. > > I think the questions belong to ports@ mail list. > Or freebsd-openoffice@ list. Is there anything useful in the archives? http://lists.freebsd.org/pipermail/freebsd-openoffice/2006-August/thread.html My -current is a few days old but I'll try installing OOo-2.0 tonight, after a ports update, to see what happens. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 10:04:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E425916A4DF for ; Thu, 24 Aug 2006 10:04:45 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5546543D58 for ; Thu, 24 Aug 2006 10:04:45 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so576154nfc for ; Thu, 24 Aug 2006 03:04:44 -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=hqFMaks4LTpvDRGoYDLiQsOycbfXO9CS80fQF7GjlgpW2ofx4D+hgywRUO5I0XMWJ39YuoQoHFEq2r17OD6ow0C5/gYob5Kjw8Q2+MzXOq+WT0RDuIv6fis67IZtSncgG8SAcLWVfZg2NFRoV5pQ59kkjQZAzV3MFdEIQdvZjrM= Received: by 10.49.75.2 with SMTP id c2mr3248655nfl; Thu, 24 Aug 2006 03:04:43 -0700 (PDT) Received: by 10.49.59.7 with HTTP; Thu, 24 Aug 2006 03:04:43 -0700 (PDT) Message-ID: <136a340a0608240304t2d95b147j44ebf0ef94900245@mail.gmail.com> Date: Thu, 24 Aug 2006 14:04:43 +0400 From: "Nikolay Kalev" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: who borked the cvsup tree ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 10:04:46 -0000 /usr/src/sys/netinet/ip_fw2.c:37:23: opt_ip6fw.h: No such file or directory /usr/src/sys/netinet6/ip6_forward.c:33:23: opt_ip6fw.h: No such file or directory /usr/src/sys/netinet6/ip6_input.c:64:23: opt_ip6fw.h: No such file or directory /usr/src/sys/netinet6/ip6_output.c:64:23: opt_ip6fw.h: No such file or directory options into my kernel with or without IPV6FIREWALL gives errors on the above line or /usr/src/sys/i386/conf/FW1: unknown option "IPV6FIREWALL_DEFAULT_TO_ACCEPT" *** Error code 1 Stop in /usr/src. *** Error code 1 after update from cvsup5.freebsd.org or what ever other cvsup5-11.x.x :-((( i guess someone forgot to put in /usr/src/sys/conf/options IPV6FIREWALL opt_ip6fw.h IPV6FIREWALL_VERBOSE opt_ip6fw.h IPV6FIREWALL_VERBOSE_LIMIT=100 opt_ip6fw.h IPV6FIREWALL_DEFAULT_TO_ACCEPT opt_ip6fw.h Key fingerprint = 9864 E575 E207 FB90 44C8 26A2 0167 E57E 66ED 0F1D From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 10:10:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 071F816A4DA for ; Thu, 24 Aug 2006 10:10:36 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB7B43D49 for ; Thu, 24 Aug 2006 10:10:35 +0000 (GMT) (envelope-from nkalev@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so577103nfc for ; Thu, 24 Aug 2006 03:10:34 -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=dFgZ/+ZALSXAbHgCOkxpgGFA55VR/SF5kv8eDW0V0OHVh9ualkot2750ueBIhcrzYp7SMmd/HHE/sn476YEfN2w+v92bU5l5XubZLlWbgPIXcqLbA9UDE8hmb9Jy0jXox7TqtRAPrrhZTyq4vuVGT79jyRRu3oBXNxU1OnIuwak= Received: by 10.49.20.5 with SMTP id x5mr3275239nfi; Thu, 24 Aug 2006 03:10:34 -0700 (PDT) Received: by 10.49.59.7 with HTTP; Thu, 24 Aug 2006 03:10:33 -0700 (PDT) Message-ID: <136a340a0608240310v30a709f1h7fd943e6d7a32a7c@mail.gmail.com> Date: Thu, 24 Aug 2006 14:10:33 +0400 From: "Nikolay Kalev" To: freebsd-current@freebsd.org In-Reply-To: <136a340a0608240304t2d95b147j44ebf0ef94900245@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <136a340a0608240304t2d95b147j44ebf0ef94900245@mail.gmail.com> Subject: Re: who borked the cvsup tree ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 10:10:36 -0000 ignore my post that was for 6.1-stable On 8/24/06, Nikolay Kalev wrote: > /usr/src/sys/netinet/ip_fw2.c:37:23: opt_ip6fw.h: No such file or directory > /usr/src/sys/netinet6/ip6_forward.c:33:23: opt_ip6fw.h: No such file > or directory > /usr/src/sys/netinet6/ip6_input.c:64:23: opt_ip6fw.h: No such file or directory > /usr/src/sys/netinet6/ip6_output.c:64:23: opt_ip6fw.h: No such file or directory > > options into my kernel with or without IPV6FIREWALL gives errors on > the above line or > > /usr/src/sys/i386/conf/FW1: unknown option "IPV6FIREWALL_DEFAULT_TO_ACCEPT" > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > after update from cvsup5.freebsd.org or what ever other cvsup5-11.x.x > :-((( > i guess someone forgot to put in > /usr/src/sys/conf/options > > IPV6FIREWALL opt_ip6fw.h > IPV6FIREWALL_VERBOSE opt_ip6fw.h > IPV6FIREWALL_VERBOSE_LIMIT=100 opt_ip6fw.h > IPV6FIREWALL_DEFAULT_TO_ACCEPT opt_ip6fw.h > > > > > Key fingerprint = 9864 E575 E207 FB90 44C8 26A2 0167 E57E 66ED 0F1D > -- Key fingerprint = 9864 E575 E207 FB90 44C8 26A2 0167 E57E 66ED 0F1D From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 11:09:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E09B16A4E2 for ; Thu, 24 Aug 2006 11:09:29 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16FC943D46 for ; Thu, 24 Aug 2006 11:09:28 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from localhost (cpe-68-175-68-211.nyc.res.rr.com [68.175.68.211]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k7OB8xIN014397; Thu, 24 Aug 2006 07:08:59 -0400 (EDT) Date: Thu, 24 Aug 2006 07:08:59 -0400 From: Scott Robbins To: matti k Message-ID: <20060824110859.GA80355@mail.scottro.net> Mail-Followup-To: matti k , Ian FREISLICH , freebsd-current@freebsd.org References: <44ED5BAE.8030807@FreeBSD.org> <20060824182142.611de883@platypus.freebsd.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20060824182142.611de883@platypus.freebsd.home> User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 11:09:29 -0000 On Thu, Aug 24, 2006 at 06:21:42PM +1000, matti k wrote: > On Thu, 24 Aug 2006 11:56:30 +0400 > Sergey Matveychuk wrote: > > > > > Or freebsd-openoffice@ list. > > Is there anything useful in the archives? > > http://lists.freebsd.org/pipermail/freebsd-openoffice/2006-August/thread.html > > My -current is a few days old but I'll try installing OOo-2.0 tonight, > after a ports update, to see what happens. The most common failure point with the last few builds seems to be at build_instset_native. One possible quick fix (that has sometimes worked for me, at least on CURRENT, though not on STABLE) is to build without mozilla. However, as that seems to sometimes fix a different build failure, I'm not sure how helpful the information is to the OP. FWIW, I haven't been able to get the latest devel to build (from 0818) on either CURRENT or STABLE. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Giles: Alright. I'll just jump into my time machine, go back to the 12th century and ask the vampires to postpone their ancient prophecy for a few days while you take in dinner and a show. Buffy: Okay, at this point you're abusing sarcasm. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 12:07:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A856416A4E1 for ; Thu, 24 Aug 2006 12:07:55 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 038B343D6D for ; Thu, 24 Aug 2006 12:07:49 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 4768E32E397; Thu, 24 Aug 2006 12:07:48 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 9A03011435; Thu, 24 Aug 2006 14:07:47 +0200 (CEST) Date: Thu, 24 Aug 2006 14:07:47 +0200 From: "Simon L. Nielsen" To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20060824120745.GE1077@zaphod.nitro.dk> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86u043znbz.fsf@xps.des.no> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: OpenSSL ports/base magic [was: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 12:07:55 -0000 On 2006.08.23 13:46:40 +0200, Dag-Erling Smørgrav wrote: > Alexander Leidinger writes: > > Michael Bushkov writes:(from Tue, 22 Aug 2006 > > > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > > > also conflict with PADL's nss_ldap) as is and let users use > > > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. > > If someone doesn't like the base system libldap, but wants the > > nss_ldap stuff, this way will not work out. While building the base > > system, no 3rd party libs are known to the build infrastructure. > > Wrong. It is already possible in today's tree to build the base > system's Kerberos with OpenLDAP support using the OpenLDAP port, and > there are similar provisions for using OpenSSL from ports. I know there are some magic in ports/ to use the ports version of OpenSSL, but I don't think there is anything done to support this in the base system, or have I missed that? (I'm interested as OpenSSL base system janitor to try to make sure I don't break something in the future by accident :-) ). -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 13:45:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B315716A4DD for ; Thu, 24 Aug 2006 13:45:30 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73FBC43D70 for ; Thu, 24 Aug 2006 13:45:24 +0000 (GMT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10) with ESMTP id k7ODjJfw015451 for ; Thu, 24 Aug 2006 09:45:20 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10/Submit) id k7ODjJWL015450 for current@freebsd.org; Thu, 24 Aug 2006 09:45:19 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 24 Aug 2006 09:45:19 -0400 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: (0) X-Scanned-By: MIMEDefang 2.39 Cc: Subject: panicing -current amd64 with ng_fec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 13:45:30 -0000 Hi, This panics my brand-new amd64 system. # kldload ng_fec.ko # ngctl mkpeer fec dummy fec I have a dump. uname -a, kgdb with backtrace, dmesg,boot, and kernel conf follow. FreeBSD aubsr019.us.add 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Wed Aug 23 12:14:08 EDT 2006 system_mwl@aubsr019.us.add:/usr/obj/usr/src/sys/LOGHOST amd64 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde fined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffffae3bac52 stack pointer = 0x10:0xffffffffae30a6d0 frame pointer = 0x10:0xffffffffae30a740 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1556 (ngctl) trap number = 12 panic: page fault cpuid = 0 Uptime: 45m52s Physical memory: 2039 MB Dumping 100 MB: 85 69 53 37 21 5 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xffffffff80247a79 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff8024750b in panic (fmt=0xffffffff80420cac "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xffffffff803c895a in trap_fatal (frame=0xc, eva=18446742975860538048) at /usr/src/sys/amd64/amd64/trap.c:694 #4 0xffffffff803c8cd3 in trap_pfault (frame=0xffffffffae30a620, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:613 #5 0xffffffff803c8f24 in trap (frame= {tf_rdi = -1098103832576, tf_rsi = -1372543232, tf_rdx = 0, tf_rcx = 5, tf_r8 = 27, tf_r9 = -1097849013568, tf_rax = 0, tf_rbx = -1098070068344, tf_rbp = -1372543168, tf_r10 = 0, tf_r11 = 0, tf_r12 = -1098103832576, tf_r13 = -1098070068352, tf_r14 = -1097855876944, tf_r15 = -1098070068280, tf_trapno = 12, tf_addr = 0, tf_flags = -1097848151808, tf_err = 0, tf_rip = -1371820974, tf_cs = 8, tf_rflags = 66118, tf_rsp = -1372543264, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:381 #6 0xffffffff803b3beb in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0xffffffffae3bac52 in ?? () #8 0xffffffffae30a710 in ?? () #9 0x000000048023d52f in ?? () #10 0xffffff0055ec73b8 in ?? () #11 0xffffff006326a100 in ?? () #12 0x0000000030636566 in ?? () #13 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) (kgdb) Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #1: Wed Aug 23 12:14:08 EDT 2006 system_mwl@aubsr019.us.add:/usr/obj/usr/src/sys/LOGHOST WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 Logical CPUs per core: 2 usable memory = 2139070464 (2039 MB) avail memory = 2064818176 (1969 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xf80f0000-0xf80fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:13:72:64:cc:9d pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:13:72:64:cc:9e pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 em2: port 0xccc0-0xccff mem 0xfe1e0000-0xfe1fffff irq 106 at device 4.0 on pci9 em2: Ethernet address: 00:04:23:ce:45:d6 em3: port 0xcc80-0xccbf mem 0xfe1c0000-0xfe1dffff irq 107 at device 4.1 on pci9 em3: Ethernet address: 00:04:23:ce:45:d7 pcib10: at device 0.2 on pci8 pci10: on pcib10 em4: port 0xbcc0-0xbcff mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff irq 96 at device 2.0 on pci10 em4: Ethernet address: 00:04:23:c2:91:02 em5: port 0xbc80-0xbcbf mem 0xfdfc0000-0xfdfdffff,0xfdf40000-0xfdf7ffff irq 97 at device 2.1 on pci10 em5: Ethernet address: 00:04:23:c2:91:03 em6: port 0xbc40-0xbc7f mem 0xfdf20000-0xfdf3ffff irq 101 at device 3.0 on pci10 em6: Ethernet address: 00:04:23:ce:4c:2a em7: port 0xbc00-0xbc3f mem 0xfdf00000-0xfdf1ffff irq 102 at device 3.1 on pci10 em7: Ethernet address: 00:04:23:ce:4c:2b uhci0: port 0x9ce0-0x9cff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x9cc0-0x9cdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x9ca0-0x9cbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0xac00-0xacff mem 0xf0000000-0xf7ffffff,0xfdcf0000-0xfdcfffff irq 18 at device 13.0 on pci11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 1430400MB (2929459200 sectors) RAID 5 (optimal) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/amrd0s1a # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.464 2006/07/09 16:39:21 mjacob Exp $ cpu HAMMER ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options NTFS # NT File System #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options KDB_UNATTENDED # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Linux 32-bit ABI support options COMPAT_LINUX32 # Compatible with i386 linux binaries options LINPROCFS # Cannot be a module yet. options LINSYSFS # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata #device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family ##device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device rr232x # Highpoint RocketRAID 232x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! #device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) options DEVICE_POLLING options HZ=1000 -- Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 14:44:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30FA816A4DD; Thu, 24 Aug 2006 14:44:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FD9943D46; Thu, 24 Aug 2006 14:44:34 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824144432m92002u0sle>; Thu, 24 Aug 2006 14:44:33 +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 k7OEiVRE036306; Thu, 24 Aug 2006 09:44:31 -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 k7OEiUE3036305; Thu, 24 Aug 2006 09:44:30 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 09:44:29 -0500 From: Brooks Davis To: Michael Bushkov Message-ID: <20060824144429.GB35200@lor.one-eyed-alien.net> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <002e01c6c744$97bc9560$9800a8c0@carrera> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <002e01c6c744$97bc9560$9800a8c0@carrera> User-Agent: Mutt/1.5.11 Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 14:44:35 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 10:13:41AM +0400, Michael Bushkov wrote: > Doug Barton wrote: > >Michael Bushkov wrote: > >Here is where (once again) we have a difference of opinion. I still=20 > >believe > >strongly that the nss_ldap part of your work should be a port, with a > >dependency on the openldap in ports. I've stated my reasoning on this in= =20 > >the > >previous thread, so I won't rehash it here unless someone asks. I would= =20 > >like > >to point out though that I feel the numerous problems raised in this=20 > >thread > >give even more weight to the request that I, and others made not to have= =20 > >it > >incorporated into the base. > > > >This in no way is meant to indicate that your work has no value, or is > >somehow "less valuable" than work that is actually in the base. It is=20 > >simply > >a realistic reflection of the fact that this facility will be needed by a > >small percentage of FreeBSD users, and the difficulties (costs) outweigh= =20 > >the > >corresponding benefit. > > > >A compromise position, if it can be made to work, would be to import your > >original work on the nss_ldap module, but have it use openldap from ports > >rather than having to import openldap. >=20 > Well, maybe more compromise solution will be to have OpenLDAP and nss_lda= p=20 > in the base, but to have them turned off by default, so the user would ne= ed=20 > to specify WITH_LDAP and WITH_NSS_LDAP in the make.conf to build them.=20 > More, if the user don't want to have OpenLDAP built with the base, but=20 > wants nss_ldap there, he'd have the ability to link nss_ldap against the= =20 > ports. And we should also have rewritten nss_ldap in ports (call it=20 > nss_ldap_bsd, for example). IMHO, It's quite a flexible scheme that shoul= d=20 > satisfy most number of users. My main concern with such solution is: will= =20 > it affect the capability of installing OpenLDAP and nss_ldap out of the b= ox? I really think we need it on the install CD which realisticly means it needs to build by default. We could potentially pack it up like kerberos in the install process, but I'm not sure that's really necessicary. -- Brooks --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7btNXY6L6fI4GtQRAuOVAJ0clLN19RDlb7sY44sB/ETcBtBWSQCgwXft O5DLcQayQjUN2SOhOHwzE3s= =dPE7 -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 15:53:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 817CD16A4E1; Thu, 24 Aug 2006 15:53:03 +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 DE31C43D73; Thu, 24 Aug 2006 15:53:02 +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 F208046CDA; Thu, 24 Aug 2006 11:53:01 -0400 (EDT) Date: Thu, 24 Aug 2006 16:53:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20060824144429.GB35200@lor.one-eyed-alien.net> Message-ID: <20060824165202.Q50633@fledge.watson.org> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <002e01c6c744$97bc9560$9800a8c0@carrera> <20060824144429.GB35200@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Doug Barton , freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 15:53:03 -0000 On Thu, 24 Aug 2006, Brooks Davis wrote: >> Well, maybe more compromise solution will be to have OpenLDAP and nss_ldap >> in the base, but to have them turned off by default, so the user would need >> to specify WITH_LDAP and WITH_NSS_LDAP in the make.conf to build them. >> More, if the user don't want to have OpenLDAP built with the base, but >> wants nss_ldap there, he'd have the ability to link nss_ldap against the >> ports. And we should also have rewritten nss_ldap in ports (call it >> nss_ldap_bsd, for example). IMHO, It's quite a flexible scheme that should >> satisfy most number of users. My main concern with such solution is: will >> it affect the capability of installing OpenLDAP and nss_ldap out of the >> box? > > I really think we need it on the install CD which realisticly means it needs > to build by default. We could potentially pack it up like kerberos in the > install process, but I'm not sure that's really necessicary. We actually don't even do that anymore -- we build Kerbreros5 support by default now. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 17:20:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40C9716A4E0 for ; Thu, 24 Aug 2006 17:20:17 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E0243D66 for ; Thu, 24 Aug 2006 17:20:10 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-71-254-64-250.ronkva.east.verizon.net [71.254.64.250]) by gromit.dlib.vt.edu (8.13.6/8.13.4) with ESMTP id k7OHK00B023518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Aug 2006 13:20:01 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7) with ESMTP id k7OHJxgk021820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Aug 2006 13:20:00 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from localhost (localhost [[UNIX: localhost]]) by zappa.Chelsea-Ct.Org (8.13.7/8.13.7/Submit) id k7OHJxn6021819; Thu, 24 Aug 2006 13:19:59 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Divacky Roman Date: Thu, 24 Aug 2006 13:19:56 -0400 User-Agent: KMail/1.9.3 References: <1156096970.19717.12.camel@zappa.Chelsea-Ct.Org> <1156359417.51081.10.camel@zappa.Chelsea-Ct.Org> <20060824080728.GA22406@stud.fit.vutbr.cz> In-Reply-To: <20060824080728.GA22406@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_++d7EpfhJiWR/6y" Message-Id: <200608241319.58390.paul@gromit.dlib.vt.edu> Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator: syscall statfs64 not implemented? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 17:20:17 -0000 --Boundary-00=_++d7EpfhJiWR/6y Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 24 August 2006 04:07, Divacky Roman wrote: > On Wed, Aug 23, 2006 at 02:56:57PM -0400, Paul Mather wrote: > > On Wed, 2006-08-23 at 19:47 +0200, Divacky Roman wrote: > > > On Wed, Aug 23, 2006 at 11:49:53AM -0400, Paul Mather wrote: > > > > On Mon, 2006-08-21 at 15:46 +0200, Divacky Roman wrote: > > > > > > it seems like very trivial so expect patch today ;) > > > > > > > > > > www.stud.fit.vutbr.cz/~xdivac02/statfs64.patch > > > > > > > > > > pls tell me if this works, thnx > > > > > > > > The patch applied and built on i386. However, when I run the > > > > resultant kernel, the problem of the "syscall statfs64 not > > > > implemented" messages goes away but my Tivoli backup still > > > > fails (in a different way). (The same Tivoli client and setup > > > > worked on i386 -CURRENT prior to mid-August, and currently is > > > > working on an i386 6.1-STABLE system.) > > > > > > > > Now, when the scheduled backup runs, I get things like this in > > > > my dsmerror.log: > > > > > > > > 08/23/06 02:58:37 TransErrno: Unexpected error from > > > > GetFSInfo:statfs, errno = 14 08/23/06 02:58:38 ANS1228E > > > > Sending of object '/backup' failed 08/23/06 02:58:38 ANS1063E > > > > The specified path is not a valid file system or logical volume > > > > name. > > > > > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/var' > > > > failed 08/23/06 02:58:38 ANS1063E The specified path is not a > > > > valid file system or logical volume name. > > > > > > > > 08/23/06 02:58:38 ANS1228E Sending of object '/backup/usr' > > > > failed 08/23/06 02:58:38 ANS1063E The specified path is not a > > > > valid file system or logical volume name. > > > > > > > > 08/23/06 02:58:40 ANS1512E Scheduled event > > > > 'DESKTOP_DAILY_BACKUP' failed. Return code = 12. > > > > > > > > > > > > I don't know if this indicates that there is a problem with the > > > > implementation of statfs64/statfs, now. (I don't know if it > > > > complicates matters, but I'm backing up mounted snapshots.) > > > > > > pls, can you build -DDEBUG version of linuxolator and show me > > > what it prints? > > > > Here is the output and debug output in /var/log/messages resulting > > from running the following command: > > pls, can you apply this patch: > > --- /tmp/tmp.72430.0 Thu Aug 24 10:06:00 2006 > +++ /root/projects/soc2006/compat/linux/linux_stats.c Thu Aug 24 > 10:04:56 2006 @@ -427,8 +427,8 @@ > LCONVPATHEXIST(td, args->path, &path); > > #ifdef DEBUG > - if (ldebug(statfs)) > - printf(ARGS(statfs, "%s, *"), path); > + if (ldebug(statfs64)) > + printf(ARGS(statfs64, "%s, *"), path); > #endif > error = kern_statfs(td, path, UIO_SYSSPACE, &bsd_statfs); > LFREEPATH(path); > > and show me the output again. (I forgot to change the debuging print > so I cannot distinguish call to statfs and statfs64). anyway - in the > output you provided me all statfs[64] calls succeeded and I didnt see > anything obvious. I might try my own tests... Attached is the output from running the same command as before, i.e.: zappa# /compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc incremental /backup/var IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.1 Client date/time: 08/24/06 13:06:34 (c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved. Node Name: ZAPPA.DLIB.VT.EDU Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 2, Level 6.3 Server date/time: 08/24/06 13:06:34 Last access: 08/24/06 03:16:06 Incremental backup of volume '/backup/var' ANS1228E Sending of object '/backup/var' failed ANS1063E The specified path is not a valid file system or logical volume name. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa --Boundary-00=_++d7EpfhJiWR/6y Content-Type: text/plain; charset="iso-8859-1"; name="dsmc_debug_output" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dsmc_debug_output" Aug 24 13:06:34 zappa kernel: linux(73861): brk(0) Aug 24 13:06:34 zappa kernel: linux(73861): newuname(*) Aug 24 13:06:34 zappa kernel: linux(73861): access(/etc/ld.so.preload, 4) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 11663, 1, 0x00000002, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libcrypt.so.1, 0x0, 0x0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 180508, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 180508, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28347000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x2834b000, 8192, 3, 0x00000812, 3, 16384) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x2834b000, 8192, 3, 0x00000812, 3, 0x4000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2834b000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x2834d000, 155932, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x2834d000, 155932, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2834d000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/obsolete/linuxthreads/tls/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/obsolete/linuxthreads/libpthread.so.0, 0x0, 0xbfbfe1dc) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28374000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 339108, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 339108, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28375000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28384000, 8192, 3, 0x00000812, 3, 57344) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28384000, 8192, 3, 0x00000812, 3, 0xe000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28384000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28386000, 269476, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28386000, 269476, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28386000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libdl.so.2, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 12408, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 12408, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283c8000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x283ca000, 8192, 3, 0x00000812, 3, 4096) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x283ca000, 8192, 3, 0x00000812, 3, 0x1000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283ca000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libgpfs.so, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 35364, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 35364, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283cc000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x283d4000, 4096, 3, 0x00000812, 3, 28672) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x283d4000, 4096, 3, 0x00000812, 3, 0x7000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283d4000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libdmapi.so, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 24036, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 24036, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283d5000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x283da000, 4096, 3, 0x00000812, 3, 16384) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x283da000, 4096, 3, 0x00000812, 3, 0x4000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283da000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/tls/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/tls/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/usr/lib/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/obsolete/linuxthreads/tls/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/obsolete/linuxthreads/librt.so.1, 0x0, 0x283325ab) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 77496, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 77496, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283db000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x283e2000, 8192, 3, 0x00000812, 3, 24576) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x283e2000, 8192, 3, 0x00000812, 3, 0x6000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283e2000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x283e4000, 40632, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x283e4000, 40632, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283e4000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libha_gs_r.so, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 122928, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 122928, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x283ee000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x2840a000, 8192, 3, 0x00000812, 3, 110592) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x2840a000, 8192, 3, 0x00000812, 3, 0x1b000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840a000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x2840c000, 48, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x2840c000, 48, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840c000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/usr/lib/libstdc++.so.5, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840d000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 757044, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 757044, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2840e000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x284bd000, 20480, 3, 0x00000812, 3, 712704) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x284bd000, 20480, 3, 0x00000812, 3, 0xae000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284bd000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x284c2000, 19764, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x284c2000, 19764, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284c2000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/tls/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/tls/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/obsolete/linuxthreads/tls/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/obsolete/linuxthreads/libm.so.6, 0x0, 0x3) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 151712, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 151712, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284c7000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x284eb000, 8192, 3, 0x00000812, 3, 143360) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x284eb000, 8192, 3, 0x00000812, 3, 0x23000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284eb000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libgcc_s.so.1, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 37576, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 37576, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284ed000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x284f6000, 4096, 3, 0x00000812, 3, 36864) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x284f6000, 4096, 3, 0x00000812, 3, 0x9000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284f6000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/tls/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/tls/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/usr/lib/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/lib/obsolete/linuxthreads/tls/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 2 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/obsolete/linuxthreads/libc.so.6, 0x0, 0x2840d788) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 1174676, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 1174676, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x284f7000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28610000, 16384, 3, 0x00000812, 3, 1150976) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28610000, 16384, 3, 0x00000812, 3, 0x119000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28610000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28614000, 7316, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28614000, 7316, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28614000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libct_cu.so, 0x0, 0x0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 299624, 5, 0x00000802, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 299624, 5, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28616000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x2865d000, 12288, 3, 0x00000812, 3, 286720) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x2865d000, 12288, 3, 0x00000812, 3, 0x46000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2865d000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28660000) Aug 24 13:06:34 zappa kernel: linux(73861): getrlimit(3, 0xbfbfe85c) Aug 24 13:06:34 zappa kernel: linux(73861): setrlimit(3, 0xbfbfe85c) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(32, 0xbfbfe7c8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(33, 0xbfbfe7c8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(34, 0xbfbfe7c8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(0, 0xbfbfeb20, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(1, 0xbfbfeb20, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): brk(0) Aug 24 13:06:34 zappa kernel: linux(73861): brk(0x83ac000) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(1, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/dev/console, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(1, *) Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(1, 5413, *) Aug 24 13:06:34 zappa kernel: linux(73861): open(/dev/tty, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(3, 5405, *) Aug 24 13:06:34 zappa kernel: LINUX: BSD termios structure (input): Aug 24 13:06:34 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 24 13:06:34 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 24 13:06:34 zappa kernel: LINUX: LINUX termios structure (output): Aug 24 13:06:34 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 24 13:06:34 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28661000) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(13, 0xbfbfda28, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(0, 0xbfbfdb9c, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(4, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(8, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(7, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(11, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(10, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(6, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigaction(5, 0xbfbfdad8, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73861): newuname(*) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/TIVGUID, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, *) Aug 24 13:06:34 zappa kernel: linux(73861): access(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, 1) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsmc, *) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.opt, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28704000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/en_US/dsmclientV3.cat, 0x0, 0x28611ff4) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 665244, 1, 0x00000002, 3, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 665244, 1, 0x00000802, 3, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x287a7000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): readlink(/var/log/tsm/dsmerror.log, 0xbfbfc8a0, 1024) Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8441, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x Aug 24 13:06:34 zappa kernel: 28344000) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): llseek(3, 0:51888, 0) Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmprune.log, 0x8241, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): open(/etc/localtime, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(5, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(5, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmprune.log, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8241, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): unlink(/var/log/tsm/dsmprune.log) Aug 24 13:06:34 zappa kernel: linux(73861): open(/var/log/tsm/dsmerror.log, 0x8441, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(3, *) Aug 24 13:06:34 zappa kernel: linux(73861): llseek(3, 0:51888, 0) Aug 24 13:06:34 zappa kernel: linux(73861): open(/dev/null, 0x10800, 0x28611ff4) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins, *) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins, 0x18800, 0x28611ff4) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(4, 00000002, *) Aug 24 13:06:34 zappa kernel: linux(73861): getdents64(4, *, 4096) Aug 24 13:06:34 zappa kernel: linux(73861): getdents64(4, *, 4096) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins/libPiIMG.so, 0x0, 0x2837f372) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 437044, 5, 0x00000802, 4, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 437044, 5, 0x00000802, 4, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x2884a000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x288a7000, 36864, 3, 0x00000812, 4, 376832) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x288a7000, 36864, 3, 0x00000812, 4, 0x5c000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288a7000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x288b0000, 19252, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x288b0000, 19252, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288b0000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 11663, 1, 0x00000002, 4, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 4, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/api/bin/libApiDS.so, 0x0, 0x0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 2639584, 5, 0x00000802, 4, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 2639584, 5, 0x00000802, 4, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x288b5000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28ae9000, 278528, 3, 0x00000812, 4, 2310144) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28ae9000, 278528, 3, 0x00000812, 4, 0x234000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28ae9000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28b2d000, 50912, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28b2d000, 50912, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b2d000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/plugins/libPiSNAP.so, 0x0, 0x0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 330852, 5, 0x00000802, 4, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 330852, 5, 0x00000802, 4, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b3a000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28b78000, 40960, 3, 0x00000812, 4, 253952) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28b78000, 40960, 3, 0x00000812, 4, 0x3e000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b78000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28b82000, 35940, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28b82000, 35940, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b82000) Aug 24 13:06:34 zappa kernel: linux(73861): newuname(*) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.opt, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(4, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): llseek(4, 0:0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/opt/tivoli/tsm/client/ba/bin/inclexcl.opt, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(5, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): brk(0x83ce000) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 24 13:06:34 zappa kernel: linux(73861): pipe(*) Aug 24 13:06:34 zappa kernel: linux(73861): clone(flags f00, stack 83af744, parent tid: bfbfe0e0, child tid: 28377fea) Aug 24 13:06:34 zappa kernel: linux(73861): clone: successful rfork to 73862, stack 0x83af744 sig = 0 Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfe15c, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfe08c, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigsuspend(0xbfbfe08c, 8) Aug 24 13:06:34 zappa kernel: linux(73862): rt_sigprocmask(2, 0x83af6b4, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73862): mmap(0xbf200000, 2097152, 7, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0xbf200000, 2097152, 7, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbf200000) Aug 24 13:06:34 zappa kernel: linux(73862): clone(flags f21, stack bf3ffbc4, parent tid: 0, child tid: ffc00000) Aug 24 13:06:34 zappa kernel: linux(73862): clone: successful rfork to 73863, stack 0xbf3ffbc4 sig = 33 Aug 24 13:06:34 zappa kernel: linux(73862): kill(73861, 32) Aug 24 13:06:34 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:34 zappa kernel: linux(73861): sigreturn(0xbfbfdd94) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigprocmask(2, 0xbf3ffc74, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): sched_setscheduler(73863, 0, 0xbf3ffcf8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(2, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(3, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(15, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(24, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(25, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigaction(30, 0xbf3ff724, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigprocmask(0, 0, 0xbf3ff8ac, 8) Aug 24 13:06:34 zappa kernel: linux(73863): rt_sigsuspend(0xbf3ff9b8, 8) Aug 24 13:06:34 zappa kernel: linux(73861): newuname(*) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(1, *) Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(1, 5401, *) Aug 24 13:06:34 zappa kernel: LINUX: BSD termios structure (input): Aug 24 13:06:34 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 24 13:06:34 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 24 13:06:34 zappa kernel: LINUX: LINUX termios structure (output): Aug 24 13:06:34 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 24 13:06:34 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28344000) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/nsswitch.conf, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(6, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(6, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 11663, 1, 0x00000002, 6, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 6, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8b000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libnss_files.so.2, 0x0, 0x28611be0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(6, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 41620, 5, 0x00000802, 6, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 41620, 5, 0x00000802, 6, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8e000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28b97000, 8192, 3, 0x00000812, 6, 32768) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28b97000, 8192, 3, 0x00000812, 6, 0x8000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b97000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/etc/passwd, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000001, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(6, 00000002, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(6, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): open(/etc/resolv.conf, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/host.conf, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/etc/hosts, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000001, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000002, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/ld.so.cache, 0x0, 0x1) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 11663, 1, 0x00000002, 7, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 11663, 1, 0x00000802, 7, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b8b000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libnss_dns.so.2, 0x0, 0xbfbfb9d8) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 20612, 5, 0x00000802, 7, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 20612, 5, 0x00000802, 7, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b99000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28b9d000, 8192, 3, 0x00000812, 7, 12288) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28b9d000, 8192, 3, 0x00000812, 7, 0x3000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b9d000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/lib/libresolv.so.2, 0x0, 0x0) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 71784, 5, 0x00000802, 7, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 71784, 5, 0x00000802, 7, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28b9f000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28bad000, 8192, 3, 0x00000812, 7, 53248) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28bad000, 8192, 3, 0x00000812, 7, 0xd000) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bad000) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0x28baf000, 6248, 3, 0x00000032, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0x28baf000, 6248, 3, 0x00001012, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28baf000) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(7, 541b, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc340, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc340, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(0, 540f, *) Aug 24 13:06:34 zappa kernel: linux(73861): newuname(*) Aug 24 13:06:34 zappa kernel: linux(73861): open(/etc/hosts, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000001, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000002, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000003, *) Aug 24 13:06:34 zappa kernel: linux(73861): fcntl64(7, 00000004, *) Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(7, 541b, *) Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc7d0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc7d0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc3a0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc3a0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/adsm/TSM.PWD, 0x8000, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc590, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc590, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc780, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfc780, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa last message repeated 3 times Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfcb10, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfcb10, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfced0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfced0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfced0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): select(7, 0xbfbfced0, 0, 0, 0) Aug 24 13:06:34 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:34 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfcffc, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfcf2c, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigsuspend(0xbfbfcf2c, 8) Aug 24 13:06:34 zappa kernel: linux(73862): mmap(0xbf000000, 2097152, 7, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0xbf000000, 2097152, 7, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbf000000) Aug 24 13:06:34 zappa kernel: linux(73862): clone(flags f21, stack bf1ffbc4, parent tid: 0, child tid: ffa00000) Aug 24 13:06:34 zappa kernel: linux(73862): clone: successful rfork to 73864, stack 0xbf1ffbc4 sig = 33 Aug 24 13:06:34 zappa kernel: linux(73862): kill(73861, 32) Aug 24 13:06:34 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:34 zappa kernel: linux(73861): sigreturn(0xbfbfcc34) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigprocmask(2, 0xbf1ffc74, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73864): sched_setscheduler(73864, 0, 0xbf1ffcf8) Aug 24 13:06:34 zappa kernel: linux(73864): time(*) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff89c, 8) Aug 24 13:06:34 zappa kernel: linux(73862): mmap(0xbee00000, 2097152, 7, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0xbee00000, 2097152, 7, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbee00000) Aug 24 13:06:34 zappa kernel: linux(73862): clone(flags f21, stack befffbc4, parent tid: 0, child tid: ff800000) Aug 24 13:06:34 zappa kernel: linux(73862): clone: successful rfork to 73865, stack 0xbefffbc4 sig = 33 Aug 24 13:06:34 zappa kernel: linux(73862): kill(73864, 32) Aug 24 13:06:34 zappa kernel: linux(73865): rt_sigprocmask(2, 0xbefffc74, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73865): sched_setscheduler(73865, 0, 0xbefffcf8) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff7cc, 8) Aug 24 13:06:34 zappa kernel: linux(linux(73865): rt_sigprocmask(2, 0, 0xbefff8f8, 8) Aug 24 13:06:34 zappa kernel: linux(73865): rt_sigsuspend(0xbefff8f8, 8) Aug 24 13:06:34 zappa kernel: 73864): rt_sigsuspend(0xbf1ff7cc, 8) Aug 24 13:06:34 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:34 zappa kernel: linux(73864): sigreturn(0xbf1ff4d4) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfcffc, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfcf2c, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigsuspend(0xbfbfcf2c, 8) Aug 24 13:06:34 zappa kernel: linux(73862): mmap(0xbec00000, 2097152, 7, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0xbec00000, 2097152, 7, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0xbec00000) Aug 24 13:06:34 zappa kernel: linux(73862): clone(flags f21, stack bedffbc4, parent tid: 0, child tid: ff600000) Aug 24 13:06:34 zappa kernel: linux(73862): clone: successful rfork to 73866, stack 0xbedffbc4 sig = 33 Aug 24 13:06:34 zappa kernel: linux(73862): kill(73861, 32) Aug 24 13:06:34 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:34 zappa kernel: linux(73861): sigreturn(0xbfbfcc34) Aug 24 13:06:34 zappa kernel: linux(73866): rt_sigprocmask(2, 0xbedffc74, 0, 8) Aug 24 13:06:34 zappa kernel: linux(73866): sched_setscheduler(73866, 0, 0xbedffcf8) Aug 24 13:06:34 zappa kernel: linux(73866): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 24 13:06:34 zappa kernel: linux(73866): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff848, 8) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigsuspend(0xbf1ff848, 8) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(1, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/dev/console, *) Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(1, *) Aug 24 13:06:34 zappa kernel: linux(73861): ioctl(1, 5413, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 512000, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 512000, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bb1000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/compat/linux/usr, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/compat/linux/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/data, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/tmp, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/usr, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 512000, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 512000, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28bb1000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/compat/linux/usr, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/compat/linux/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/data, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/tmp, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/usr, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: Linux-emul(73861): getcwd(0xbfbfcdb0, 1025) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): brk(0x83ff000) Aug 24 13:06:34 zappa kernel: linux(73861): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:34 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:34 zappa kernel: linux(73861): fstat64(7, *) Aug 24 13:06:34 zappa kernel: linux(73861): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:34 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:34 zappa kernel: linux(73861): brk(0x83e6000) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): statfs64(/backup/var, *) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:34 zappa kernel: linux(73861): access(/backup/var, 0) Aug 24 13:06:34 zappa kernel: linux(73861): kill(73864, 32) Aug 24 13:06:34 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:34 zappa kernel: linux(73864): sigreturn(0xbf1ff550) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff7e8, 8) Aug 24 13:06:34 zappa kernel: linux(73864): rt_sigsuspend(0xbf1ff7e8, 8) Aug 24 13:06:34 zappa kernel: linux(73861): kill(73864, 32) Aug 24 13:06:34 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:34 zappa kernel: linux(73864): sigreturn(0xbf1ff4f0) Aug 24 13:06:34 zappa kernel: linux(73864): select(0, 0, 0, 0, 0xbf1ff9b8) Aug 24 13:06:34 zappa kernel: linux(73864): incoming timeout (1/0) Aug 24 13:06:34 zappa kernel: linux(73861): time(*) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(0, 0, 0xbfbfcf28, 8) Aug 24 13:06:34 zappa kernel: linux(73861): rt_sigprocmask(1, 0xbfbfd028, 0xbfbfcfa8, 8) Aug 24 13:06:35 zappa kernel: linux(73866): rt_sigprocmask(2, 0xbedff768, 0, 8) Aug 24 13:06:35 zappa kernel: linux(73866): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 24 13:06:35 zappa kernel: linux(73866): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 24 13:06:35 zappa kernel: linux(73861): rt_sigprocmask(2, 0xbfbfcfa8, 0, 8) Aug 24 13:06:35 zappa kernel: linux(73861): time(*) Aug 24 13:06:35 zappa kernel: linux(73861): rt_sigprocmask(0, 0, 0xbfbfcf28, 8) Aug 24 13:06:35 zappa kernel: linux(73861): rt_sigprocmask(1, 0xbfbfd028, 0xbfbfcfa8, 8) Aug 24 13:06:35 zappa kernel: linux(73864): real select returns 0 Aug 24 13:06:35 zappa kernel: linux(73864): outgoing timeout (0/0) Aug 24 13:06:35 zappa kernel: linux(73864): select_out -> 0 Aug 24 13:06:35 zappa kernel: linux(73864): select(7, 0xbf1ff740, 0, 0, 0) Aug 24 13:06:35 zappa kernel: linux(73864): real select returns 0 Aug 24 13:06:35 zappa kernel: linux(73864): select_out -> 0 Aug 24 13:06:35 zappa kernel: linux(73864): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:35 zappa kernel: linux(73864): open returns error 0 Aug 24 13:06:35 zappa kernel: linux(73864): fstat64(7, *) Aug 24 13:06:35 zappa kernel: linux(73864): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:35 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:35 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:35 zappa kernel: linux(73864): open(/compat/linux/etc/mtab, 0x0, 0x1b6) Aug 24 13:06:35 zappa kernel: linux(73864): open returns error 0 Aug 24 13:06:35 zappa kernel: linux(73864): fstat64(7, *) Aug 24 13:06:35 zappa kernel: linux(73864): mmap(0, 4096, 3, 0x00000022, -1, 0) Aug 24 13:06:35 zappa kernel: -> linux_mmap_common(0, 4096, 3, 0x00001002, -1, 0x0) Aug 24 13:06:35 zappa kernel: -> linux_mmap_common() return: 0x0 (0x28345000) Aug 24 13:06:35 zappa kernel: linux(73864): brk(0x8418000) Aug 24 13:06:35 zappa kernel: linux(73864): brk(0x83ff000) Aug 24 13:06:35 zappa kernel: linux(73864): brk(0x83e6000) Aug 24 13:06:35 zappa kernel: linux(73864): statfs64(/backup/var, *) Aug 24 13:06:35 zappa kernel: linux(73864): time(*) Aug 24 13:06:35 zappa kernel: linux(73864): stat64(/etc/localtime, *) Aug 24 13:06:35 zappa kernel: linux(73864): stat64(/etc/localtime, *) Aug 24 13:06:35 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff848, 8) Aug 24 13:06:35 zappa kernel: linux(73864): rt_sigsuspend(0xbf1ff848, 8) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigprocmask(2, 0xbedff768, 0, 8) Aug 24 13:06:36 zappa kernel: linux(73866): kill(73864, 32) Aug 24 13:06:36 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:36 zappa kernel: linux(73864): sigreturn(0xbf1ff550) Aug 24 13:06:36 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff7e8, 8) Aug 24 13:06:36 zappa kernel: linux(73864): rt_sigsuspend(0xbf1ff7e8, 8) Aug 24 13:06:36 zappa kernel: linux(73866): kill(73864, 32) Aug 24 13:06:36 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:36 zappa kernel: linux(73864): sigreturn(0xbf1ff4f0) Aug 24 13:06:36 zappa kernel: linux(73864): kill(73865, 32) Aug 24 13:06:36 zappa kernel: linux(73865): sendsig(0x2837cfa4, 32, 0xd58c4c24, 0) Aug 24 13:06:36 zappa kernel: linux(73865): sigreturn(0xbefff600) Aug 24 13:06:36 zappa kernel: linux(73865): rt_sigprocmask(2, 0, 0xbefff898, 8) Aug 24 13:06:36 zappa kernel: linux(73865): rt_sigsuspend(0xbefff898, 8) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigprocmask(0, 0, 0xbedff6e8, 8) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigprocmask(1, 0xbedff7e8, 0xbedff768, 8) Aug 24 13:06:36 zappa kernel: linux(73864): kill(73865, 32) Aug 24 13:06:36 zappa kernel: linux(73865): sendsig(0x2837cfa4, 32, 0xd58c4c24, 0) Aug 24 13:06:36 zappa kernel: linux(73865): sigreturn(0xbefff5a0) Aug 24 13:06:36 zappa kernel: linux(73865): kill(73866, 32) Aug 24 13:06:36 zappa kernel: linux(73866): sendsig(0x2837cfa4, 32, 0xd586dc24, 0) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigprocmask(2, 0xbedff6e8, 0, 8) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigprocmask(2, 0, 0xbedff798, 8) Aug 24 13:06:36 zappa kernel: linux(73866): rt_sigsuspend(0xbedff798, 8) Aug 24 13:06:36 zappa kernel: linux(73864): rt_sigprocmask(2, 0, 0xbf1ff80c, 8) Aug 24 13:06:36 zappa kernel: linux(73864): rt_sigsuspend(0xbf1ff80c, 8) Aug 24 13:06:36 zappa kernel: linux(73865): kill(73866, 32) Aug 24 13:06:36 zappa kernel: linux(73866): sendsig(0x2837cfa4, 32, 0xd586dc24, 0) Aug 24 13:06:36 zappa kernel: linux(73866): sigreturn(0xbedff4a0) Aug 24 13:06:36 zappa kernel: linux(73866): kill(73864, 32) Aug 24 13:06:36 zappa kernel: linux(73864): sendsig(0x2837cfa4, 32, 0xd583ac24, 0) Aug 24 13:06:36 zappa kernel: linux(73864): sigreturn(0xbf1ff514) Aug 24 13:06:36 zappa kernel: linux(73864): exit_group(0) Aug 24 13:06:36 zappa kernel: linux(73862): sendsig(0x2837d028, 33, 0xd5828c24, 0) Aug 24 13:06:36 zappa kernel: linux(73862): sigreturn(0x83af2b8) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73865): exit_group(0) Aug 24 13:06:36 zappa kernel: linux(73862): sendsig(0x2837d028, 33, 0xd5828c24, 0) Aug 24 13:06:36 zappa kernel: linux(73862): sigreturn(0x83af2b8) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73866): kill(73861, 32) Aug 24 13:06:36 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:36 zappa kernel: linux(73861): rt_sigprocmask(2, 0xbfbfcf28, 0, 8) Aug 24 13:06:36 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfcfd8, 8) Aug 24 13:06:36 zappa kernel: linux(73861): rt_sigsuspend(0xbfbfcfd8, 8) Aug 24 13:06:36 zappa kernel: linux(73866): kill(73861, 32) Aug 24 13:06:36 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:36 zappa kernel: linux(73861): sigreturn(0xbfbfcce0) Aug 24 13:06:36 zappa kernel: linux(73861): time(*) Aug 24 13:06:36 zappa kernel: linux(73861): time(*) Aug 24 13:06:36 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:36 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:36 zappa kernel: linux(73861): time(*) Aug 24 13:06:36 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:36 zappa kernel: linux(73861): stat64(/etc/localtime, *) Aug 24 13:06:36 zappa kernel: linux(73861): time(*) Aug 24 13:06:36 zappa last message repeated 3 times Aug 24 13:06:36 zappa kernel: linux(73861): kill(73863, 10) Aug 24 13:06:36 zappa kernel: linux(73866): exit_group(0) Aug 24 13:06:36 zappa kernel: linux(73862): sendsig(0x2837d028, 33, 0xd5828c24, 0) Aug 24 13:06:36 zappa kernel: linux(73862): sigreturn(0x83af2b8) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73862): waitpid(-1, 0x83af598, -2147483647) Aug 24 13:06:36 zappa kernel: linux(73861): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 24 13:06:36 zappa kernel: linux(73861): select(0, 0, 0, 0, 0xbfbfeb58) Aug 24 13:06:36 zappa kernel: linux(73861): incoming timeout (1/0) Aug 24 13:06:37 zappa kernel: linux(73861): real select returns 0 Aug 24 13:06:37 zappa kernel: linux(73861): outgoing timeout (0/0) Aug 24 13:06:37 zappa kernel: linux(73861): select_out -> 0 Aug 24 13:06:37 zappa kernel: linux(73861): stat64(/opt/tivoli/tsm/client/hsm/bin/dsmrecalld, *) Aug 24 13:06:37 zappa kernel: linux(73861): open(/dev/tty, 0x8000, 0x1b6) Aug 24 13:06:37 zappa kernel: linux(73861): open returns error 0 Aug 24 13:06:37 zappa kernel: linux(73861): ioctl(6, 540f, *) Aug 24 13:06:37 zappa kernel: linux(73861): ioctl(6, 5406, *) Aug 24 13:06:37 zappa kernel: LINUX: LINUX termios structure (input): Aug 24 13:06:37 zappa kernel: i=00002d02 o=00000005 c=000004bf l=0000aa3b line=0 Aug 24 13:06:37 zappa kernel: c_cc 03 1c 7f 15 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Aug 24 13:06:37 zappa kernel: LINUX: BSD termios structure (output): Aug 24 13:06:37 zappa kernel: i=00002b02 o=00000003 c=00004b00 l=200005cf ispeed=38400 ospeed=38400 Aug 24 13:06:37 zappa kernel: c_cc 04 ff ff 7f ff 15 ff ff 03 1c ff ff ff ff ff ff 01 00 ff ff Aug 24 13:06:37 zappa kernel: linux(73861): rt_sigprocmask(2, 0, 0xbfbfea5c, 8) Aug 24 13:06:37 zappa kernel: linux(73861): rt_sigsuspend(0xbfbfea5c, 8) Aug 24 13:06:37 zappa kernel: linux(73862): kill(73863, 33) Aug 24 13:06:37 zappa kernel: linux(73863): sendsig(0x2837d028, 33, 0xd58e5c24, 0) Aug 24 13:06:37 zappa kernel: linux(73863): exit_group(12) Aug 24 13:06:37 zappa kernel: linux(73862): sendsig(0x2837d028, 33, 0xd5828c24, 0) Aug 24 13:06:37 zappa kernel: linux(73862): sigreturn(0x83af2c8) Aug 24 13:06:37 zappa kernel: linux(73862): waitpid(73863, 0, -2147483648) Aug 24 13:06:37 zappa kernel: linux(73862): kill(73861, 32) Aug 24 13:06:37 zappa kernel: linux(73861): sendsig(0x2837cfa4, 32, 0xd5966c24, 0) Aug 24 13:06:37 zappa kernel: linux(73861): sigreturn(0xbfbfe764) Aug 24 13:06:37 zappa kernel: linux(73861): waitpid(73862, 0, -2147483648) Aug 24 13:06:37 zappa kernel: linux(73862): exit_group(0) Aug 24 13:06:37 zappa kernel: linux(73861): exit_group(12) --Boundary-00=_++d7EpfhJiWR/6y-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 17:23:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72DC416A4E1 for ; Thu, 24 Aug 2006 17:23:43 +0000 (UTC) (envelope-from faber@ISI.EDU) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44BA043D58 for ; Thu, 24 Aug 2006 17:23:33 +0000 (GMT) (envelope-from faber@ISI.EDU) Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7OHMJY05273; Thu, 24 Aug 2006 10:22:19 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7OHMIOG035468; Thu, 24 Aug 2006 10:22:18 -0700 (PDT) (envelope-from faber) Date: Thu, 24 Aug 2006 10:22:18 -0700 From: Ted Faber To: Ian FREISLICH Message-ID: <20060824172218.GF32588@hut.isi.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JSkcQAAxhB1h8DcT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu Cc: freebsd-current@freebsd.org Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 17:23:43 -0000 --JSkcQAAxhB1h8DcT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 08:51:12AM +0200, Ian FREISLICH wrote: > Hi >=20 > Just a quick poll to fisd out if it's just me or something else. >=20 > Has anyone managed to compile any of openoffice.org-1.0, > openoffice.org-1.1 or openoffice.org-2.0 on a recent(ish) CURRENT? Actually, I've had a problem with openoffice-2.0's java configuration, which I'm happy to take to whoever I need to. The problem is that the /usr/local/jdk1.4.1 path is hard-coded a couple places, but the java/jdk14 port is up to 1.4.2. Paractically, this means when I make the OO port, the first thing it tries to do is install java/jdk14 which fails because java/jdk14 is already installed. Symlinking /usr/local/jdk1.4.1 to /usr/local/jdk1.4.2 fails further down the compilation (the error indicates that one of the later OO configuration steps - not the a ports step - is unhappy about the symbolic link). You should be able to reporduce this by just installing jdk1.4.2 and not jdk1.4.1 and typing make in /usr/ports/editors/openoffice.org-2.0 . --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --JSkcQAAxhB1h8DcT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7eBKaUz3f+Zf+XsRAk7aAKCncwGX7YbnExoTmj4KUfeNm0C7bACgpS7z EvUPI76ngTFF/Zru/JwirXM= =Sv6i -----END PGP SIGNATURE----- --JSkcQAAxhB1h8DcT-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 18:29:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18E5316A4DD for ; Thu, 24 Aug 2006 18:29:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EDEE43D45 for ; Thu, 24 Aug 2006 18:28:53 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id CAA54543; Thu, 24 Aug 2006 11:28:43 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2E41745056; Thu, 24 Aug 2006 11:28:43 -0700 (PDT) To: Scott Robbins In-reply-to: Your message of "Thu, 24 Aug 2006 07:08:59 EDT." <20060824110859.GA80355@mail.scottro.net> Date: Thu, 24 Aug 2006 11:28:43 -0700 From: "Kevin Oberman" Message-Id: <20060824182843.2E41745056@ptavv.es.net> Cc: Ian FREISLICH , freebsd-current@freebsd.org, matti k Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 18:29:02 -0000 > Date: Thu, 24 Aug 2006 07:08:59 -0400 > From: Scott Robbins > Sender: owner-freebsd-current@freebsd.org > > On Thu, Aug 24, 2006 at 06:21:42PM +1000, matti k wrote: > > On Thu, 24 Aug 2006 11:56:30 +0400 > > Sergey Matveychuk wrote: > > > > > > > > > Or freebsd-openoffice@ list. > > > > Is there anything useful in the archives? > > > > http://lists.freebsd.org/pipermail/freebsd-openoffice/2006-August/thread.html > > > > My -current is a few days old but I'll try installing OOo-2.0 tonight, > > after a ports update, to see what happens. > > The most common failure point with the last few builds seems to be at > > build_instset_native. > > One possible quick fix (that has sometimes worked for me, at least on > CURRENT, though not on STABLE) is to build without mozilla. > > However, as that seems to sometimes fix a different build failure, I'm > not sure how helpful the information is to the OP. > > FWIW, I haven't been able to get the latest devel to build (from 0818) > on either CURRENT or STABLE. I just finished building it on my laptop and it's getting close on my desktop running current. I build -DWITHOUT_MOZILLA. OTOH, I can't seem to build, even WITHOUT_MOZILLA, on my 6-Stable desktop system. I get the exact error you report building sal. In file included from conditn.c:37: system.h:542: error: conflicting types for 'gethostbyname_r' /usr/include/netdb.h:228: error: previous declaration of 'gethostbyname_r' was here system.h:542: error: conflicting types for 'gethostbyname_r' /usr/include/netdb.h:228: error: previous declaration of 'gethostbyname_r' was here dmake: Error code 1, while making '../../unxfbsdi.pro/obj/conditn.obj' I suspect it may relate to the fact that I am running JDK1.5 on that system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 18:40:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E630216A4DE for ; Thu, 24 Aug 2006 18:40:56 +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 C097943D7B for ; Thu, 24 Aug 2006 18:40:52 +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 723601A4DCC; Thu, 24 Aug 2006 11:40:52 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5DC1353ADD; Thu, 24 Aug 2006 14:40:51 -0400 (EDT) Date: Thu, 24 Aug 2006 14:40:51 -0400 From: Kris Kennaway To: Ian FREISLICH Message-ID: <20060824184051.GA48619@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Quick poll (openoffice port) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 18:40:57 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 08:51:12AM +0200, Ian FREISLICH wrote: > Hi >=20 > Just a quick poll to fisd out if it's just me or something else. >=20 > Has anyone managed to compile any of openoffice.org-1.0, > openoffice.org-1.1 or openoffice.org-2.0 on a recent(ish) CURRENT? >=20 > openoffice.org-1.1 fails with: > /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.5: version GLIBCPP_3.2 re= quired by ./regxpcom not defined > dmake: Error code 1, while making './unxfbsd.pro/misc/build/so_moz_runti= me_files' >=20 > openoffice.org-2.0 fails with: > Checking DLL ../unxfbsdi.pro/lib/check_libuno_sal.so.3 ...: ERROR: ../unx= fbsdi.pro/lib/check_libuno_sal.so.3: Undefined symbol "gethostbyname_r" > dmake: Error code 1, while making '../unxfbsdi.pro/lib/libuno_sal.so.3' >=20 > Is there a quick fix? >=20 If in doubt about whether a package is buildable, check http://pointyhat.freebsd.org. You'd see the above error there. Kris --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7fKyWry0BWjoQKURAt9hAKDbOrasGvABBbN/9vGFlFp1RRX54wCeIeCM 6mfDhlQKtk4u1vtZOBo4ksI= =KU/j -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:15:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB1E416A4DA for ; Thu, 24 Aug 2006 19:15:43 +0000 (UTC) (envelope-from security@yourdot-mail.com) Received: from jupiter.nswebhost.com (jupiter.nswebhost.com [66.246.252.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4018543D5F for ; Thu, 24 Aug 2006 19:15:42 +0000 (GMT) (envelope-from security@yourdot-mail.com) Received: from 94.60.30.213.rev.vodafone.pt ([213.30.60.94]:34199 helo=[192.168.1.10]) by jupiter.nswebhost.com with esmtpa (Exim 4.52) id 1GGJl8-0004xj-SQ for freebsd-current@freebsd.org; Thu, 24 Aug 2006 13:16:55 -0500 Message-ID: <44EDFAD7.6080503@yourdot-mail.com> Date: Thu, 24 Aug 2006 20:15:35 +0100 From: Carlos Silva User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jupiter.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - yourdot-mail.com X-Source: X-Source-Args: X-Source-Dir: Subject: squid page manipulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:15:43 -0000 Hi, Is that possible to manipulate a page that squid proxies? For example, in that page, there is an javascript alert(); function and i want to discard that so the browser doesn't see that. Basically, I want that squid change the HTML source codes from the pages that i download, with matching criterias. Best Regards, Carlos Silva, CSilva Web: http://www.csilva.org/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:26:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0B9C16A4E5 for ; Thu, 24 Aug 2006 19:26:14 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 219C643D49 for ; Thu, 24 Aug 2006 19:26:13 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so711613nfc for ; Thu, 24 Aug 2006 12:26:10 -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=dERoOBFJWfPb06Eko21r3v2Kx1Tz0GnQ3wkT1soD1IpUgo+ldL+/wZlYuZLAgd5g0vNov+ydsvLOSpE0RmYdvXOP/kUh2LY5JDB7GrypLUQlzcxdBJAqrh09ESN5iZGLD+5ZyAZ1GCO4vpl9KAe3ftLYKSHM0JQNaer0ZjgD310= Received: by 10.66.240.12 with SMTP id n12mr1332018ugh; Thu, 24 Aug 2006 12:26:10 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Thu, 24 Aug 2006 12:26:10 -0700 (PDT) Message-ID: Date: Thu, 24 Aug 2006 15:26:10 -0400 From: "Scott Ullrich" To: "Carlos Silva" In-Reply-To: <44EDFAD7.6080503@yourdot-mail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44EDFAD7.6080503@yourdot-mail.com> Cc: freebsd-current@freebsd.org Subject: Re: squid page manipulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:26:14 -0000 On 8/24/06, Carlos Silva wrote: > Hi, > > Is that possible to manipulate a page that squid proxies? > For example, in that page, there is an javascript alert(); function and > i want to discard that so the browser doesn't see that. > Basically, I want that squid change the HTML source codes from the pages > that i download, with matching criterias. Yes, this should be possible. While this is not exactly what your looking for it does modify the images mid-stream so it should be possible to do the same for the HTML mid-flight. Take a look at http://www.ex-parrot.com/~pete/upside-down-ternet.html which is an interesting idea. Scott From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:26:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE72016A610 for ; Thu, 24 Aug 2006 19:26:23 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5449F43D46 for ; Thu, 24 Aug 2006 19:26:23 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7OJQMUj039921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 23:26:22 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7OJQL1i039920; Thu, 24 Aug 2006 23:26:21 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 23:26:21 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824192621.GB39797@lath.rinet.ru> References: <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060824002632.GA22634@cdnetworks.co.kr> <20060824004225.GB25876@lath.rinet.ru> <20060824011116.GD22634@cdnetworks.co.kr> <20060824012450.GC27699@lath.rinet.ru> <20060824014121.GE22634@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824014121.GE22634@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:26:24 -0000 On Thu, Aug 24, 2006 at 10:41:21AM +0900, Pyun YongHyeon wrote: > On Thu, Aug 24, 2006 at 05:24:50AM +0400, Oleg Bulyzhin wrote: > > On Thu, Aug 24, 2006 at 10:11:16AM +0900, Pyun YongHyeon wrote: > > > On Thu, Aug 24, 2006 at 04:42:25AM +0400, Oleg Bulyzhin wrote: > > > > On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > > > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > > > > [...] > > > > > > > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > > > lead to hardware deadlock. > > > > > > > > > > > > > > > > Yes. Because MII bus access needs several steps to access PHY > > > > > registers its operation shouldn't be interrupted until all pending > > > > > requests are served. > > > > > > > > > > I can't sure you remember my mail for MII lock which modifies > > > > > mii_phy_probe API to take an additional mutex. The driver mutex > > > > > could be used with MII bus access/callbacks. > > > > > > > > Yes, i remember that mail but i didnt had time to dig code deep enough > > > > to give an answer. I did it recently, while working on PR. > > > > > > > > > > Glad to hear that. :-) > > > > > > > > If interface is up/running and auto negotiation is in progress MII > > > > > layer would inspect BMSR register periodically to know the state > > > > > of link. During the time if you run ifconfig(8) to know the state > > > > > of the link or to change media type/duplex it will access PHY > > > > > registers. Normally it would end up with "link states coalesced" > > > > > messages. > > > > > > > > > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > > > > > end up with calling mii_mediachg() or mii_pollstat() which in turn > > > > > access PHY registers. So if MII access is properly serialized we > > > > > wouldn't get stale data. I guess your fix solves it by protecting > > > > > callbacks with driver mutex but it wouldn't fix other cases. > > > > > For example see vge_miibus_statchg MII interface. > > > > > > > > MII layer does not have it's own callouts, i.e. those autonegotiation > > > > checks of BMSR are triggered by driver's _tick() function, which are locked. > > > > So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent > > > > access to PHY is impossible. > > > > (If we are talking about vge_miibus_statchg(), it would be: > > > > vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> > > > > mii_phy_update -> vge_miibus_statchg). > > > > > > > > > > If we set media type manually while autonegotiation is in progress, > > > wouldn't it access PHY registers without driver lock? > > > > No (if we have _tick() & ifmedia callbacks locked): > > ioctl -> netioctl -> ifhwioctl -> vge_ioctl(SIOCSIFMEDIA) -> ifmedia_ioctl -> > > vge_ifmedia_upd (here we obtain lock) -> mii_mediachg -> > > ciphy_service(MII_MEDIACHG) -> mii_phy_update -> vge_miibus_statchg > > > > Ah...I've missed the your assumption ifmedia callbacks were locked. > As you said, several drivers don't have locks for ifmedia callback > handlers. These drivers would access PHY registers without locks. I believe all such drivers should be fixed. > > -- > Regards, > Pyun YongHyeon -- Oleg. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:38:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09BD916A4DE for ; Thu, 24 Aug 2006 19:38:43 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D3D743D49 for ; Thu, 24 Aug 2006 19:38:41 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7OJceRE039995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 23:38:40 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7OJce7q039994; Thu, 24 Aug 2006 23:38:40 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 23:38:40 +0400 From: Oleg Bulyzhin To: Pyun YongHyeon Message-ID: <20060824193840.GC39797@lath.rinet.ru> References: <20060822073201.GI12848@cdnetworks.co.kr> <20060822144341.L5561@fw.reifenberger.com> <20060822204342.GA4943@lath.rinet.ru> <20060823005554.GC17902@cdnetworks.co.kr> <20060823124035.GA18628@lath.rinet.ru> <20060823125434.GA19111@lath.rinet.ru> <20060824003035.GB22634@cdnetworks.co.kr> <20060824004354.GC25876@lath.rinet.ru> <20060824010746.GC22634@cdnetworks.co.kr> <20060824011244.GB27699@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060824011244.GB27699@lath.rinet.ru> User-Agent: Mutt/1.5.11 Cc: Michael Reifenberger , freebsd-current@freebsd.org Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:38:43 -0000 On Thu, Aug 24, 2006 at 05:12:44AM +0400, Oleg Bulyzhin wrote: > On Thu, Aug 24, 2006 at 10:07:46AM +0900, Pyun YongHyeon wrote: > > > > I can't remember what caused this. Need more coffee. :-( > > If my memory serve me right it's related with ioctls. > > I guess you can easily experiment with removing MTX_RECURSE flag > > in the driver. > > I'll try tomorrow (oh, today), have to sleep a bit. :) I've used bge(4) today with WITNESS enabled. Yes, i've got panic about 'recursion on non-recursive mutex' when i tried to issue 'ifconfig bge0 up' command. Though it was easy to fix it. (look at if_bge.c rev. 1.140). bge(4) is somewhat special cause it can handle TBI cards. (it is using bge_ifmedia_upd() inside bge_init_locked, thus i've added bge_ifmedia_upd_locked() in order to avoid mutex recursion). vge(4) (which is copper only, i.e. pure miibus(4) driver) is using mii_mediachg() inside vge_init(), so ifmedia callbacks can be locked 'as is'. Am i mistaken somewhere? -- Oleg. From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:51:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1666F16A4DF for ; Thu, 24 Aug 2006 19:51:14 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F7843D4C for ; Thu, 24 Aug 2006 19:51:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 7BA22607E; Thu, 24 Aug 2006 23:51:08 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 744DE607D; Thu, 24 Aug 2006 23:51:08 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.6/8.13.6) id k7OJpI4Q089666; Thu, 24 Aug 2006 23:51:18 +0400 (MSD) (envelope-from ru) Date: Thu, 24 Aug 2006 23:51:18 +0400 From: Ruslan Ermilov To: "Michael W. Lucas" Message-ID: <20060824195118.GA89620@rambler-co.ru> References: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: No virus found Cc: current@freebsd.org Subject: Re: panicing -current amd64 with ng_fec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:51:14 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 09:45:19AM -0400, Michael W. Lucas wrote: > Hi, >=20 > This panics my brand-new amd64 system. >=20 > # kldload ng_fec.ko > # ngctl mkpeer fec dummy fec >=20 Fixed in ng_fec.c#1.27. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7gM2qRfpzJluFF4RAlbRAJ4y4Fh3/Nbkl9Y4Q3GS6QScgkYlVgCfd+cJ s1jl6gFhXii+kqlFAkOlj7o= =wHR9 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:55:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8863116A4DA; Thu, 24 Aug 2006 19:55:40 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 130D743D70; Thu, 24 Aug 2006 19:55:39 +0000 (GMT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10) with ESMTP id k7OJtdfw017683; Thu, 24 Aug 2006 15:55:39 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10/Submit) id k7OJtcbg017682; Thu, 24 Aug 2006 15:55:38 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 24 Aug 2006 15:55:38 -0400 From: "Michael W. Lucas" To: Ruslan Ermilov Message-ID: <20060824195538.GA17603@bewilderbeast.blackhelicopters.org> References: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> <20060824195118.GA89620@rambler-co.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20060824195118.GA89620@rambler-co.ru> User-Agent: Mutt/1.4.1i X-Spam-Score: (0) X-Scanned-By: MIMEDefang 2.39 Cc: current@freebsd.org Subject: Re: panicing -current amd64 with ng_fec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:55:40 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 11:51:18PM +0400, Ruslan Ermilov wrote: > On Thu, Aug 24, 2006 at 09:45:19AM -0400, Michael W. Lucas wrote: > > Hi, > >=20 > > This panics my brand-new amd64 system. > >=20 > > # kldload ng_fec.ko > > # ngctl mkpeer fec dummy fec > >=20 > Fixed in ng_fec.c#1.27. Thanks Ruslan, you the man! =3D=3Dml --=20 Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequ= itur --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFE7gQ6wHOsVeaMSbwRAvQCAJsGcn4ZrOudK3TeYWsm9gJl4EA7bACdG7U7 xmak2fggYMzarwmFfUKFoGM= =eEUf -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 19:58:40 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45C5716A4DF for ; Thu, 24 Aug 2006 19:58:40 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F5543D70 for ; Thu, 24 Aug 2006 19:58:39 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id B49C35DB0; Thu, 24 Aug 2006 23:58:38 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 93F615D83; Thu, 24 Aug 2006 23:58:38 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.6/8.13.6) id k7OJwnER089841; Thu, 24 Aug 2006 23:58:49 +0400 (MSD) (envelope-from ru) Date: Thu, 24 Aug 2006 23:58:49 +0400 From: Ruslan Ermilov To: "Michael W. Lucas" Message-ID: <20060824195849.GB89748@rambler-co.ru> References: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> <20060824195118.GA89620@rambler-co.ru> <20060824195538.GA17603@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <20060824195538.GA17603@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: No virus found Cc: current@FreeBSD.org Subject: Re: panicing -current amd64 with ng_fec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 19:58:40 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 03:55:38PM -0400, Michael W. Lucas wrote: > On Thu, Aug 24, 2006 at 11:51:18PM +0400, Ruslan Ermilov wrote: > > On Thu, Aug 24, 2006 at 09:45:19AM -0400, Michael W. Lucas wrote: > > > Hi, > > >=20 > > > This panics my brand-new amd64 system. > > >=20 > > > # kldload ng_fec.ko > > > # ngctl mkpeer fec dummy fec > > >=20 > > Fixed in ng_fec.c#1.27. >=20 >=20 > Thanks Ruslan, you the man! >=20 Yes, but I'm also responsible for this particular panic. :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7gT5qRfpzJluFF4RAnCHAJ4/NZu0TboWMglMqXnITSvxD8lcVgCfdIsk W96qiR4Y7nSck2lkqQXKXzE= =eGFu -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 20:14:55 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA5C016A4DF; Thu, 24 Aug 2006 20:14:55 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1A343D6E; Thu, 24 Aug 2006 20:14:50 +0000 (GMT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10) with ESMTP id k7OKEnfw017806; Thu, 24 Aug 2006 16:14:49 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10/Submit) id k7OKEnRh017805; Thu, 24 Aug 2006 16:14:49 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 24 Aug 2006 16:14:49 -0400 From: "Michael W. Lucas" To: Ruslan Ermilov Message-ID: <20060824201449.GA17787@bewilderbeast.blackhelicopters.org> References: <20060824134519.GA15396@bewilderbeast.blackhelicopters.org> <20060824195118.GA89620@rambler-co.ru> <20060824195538.GA17603@bewilderbeast.blackhelicopters.org> <20060824195849.GB89748@rambler-co.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20060824195849.GB89748@rambler-co.ru> User-Agent: Mutt/1.4.1i X-Spam-Score: (0) X-Scanned-By: MIMEDefang 2.39 Cc: current@FreeBSD.org Subject: Re: panicing -current amd64 with ng_fec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 20:14:55 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 11:58:49PM +0400, Ruslan Ermilov wrote: > On Thu, Aug 24, 2006 at 03:55:38PM -0400, Michael W. Lucas wrote: > > On Thu, Aug 24, 2006 at 11:51:18PM +0400, Ruslan Ermilov wrote: > > > On Thu, Aug 24, 2006 at 09:45:19AM -0400, Michael W. Lucas wrote: > > > > Hi, > > > >=20 > > > > This panics my brand-new amd64 system. > > > >=20 > > > > # kldload ng_fec.ko > > > > # ngctl mkpeer fec dummy fec > > > >=20 > > > Fixed in ng_fec.c#1.27. > >=20 > >=20 > > Thanks Ruslan, you the man! > >=20 > Yes, but I'm also responsible for this particular panic. :-) Well, Microsoft, IBM, Cisco, and Linux are responsible for most of the times I panic, and I don't see any of those companies stepping up to fix the stuff they're responsible for, so you *still* the man. :-) =3D=3Dml --=20 Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequ= itur --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFE7gi5wHOsVeaMSbwRAgKeAKDjo3hs7zNt6rhC5ZWFudhBi4W2NgCbBNsJ 44VAYfGLLXNNB1JXa1DQehA= =mJM1 -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 24 22:04:22 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8CA216A4E0 for ; Thu, 24 Aug 2006 22:04:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DFB443D64 for ; Thu, 24 Aug 2006 22:04:19 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 17604 invoked by uid 399); 24 Aug 2006 22:04:19 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 24 Aug 2006 22:04:19 -0000 Message-ID: <44EE2260.80409@FreeBSD.org> Date: Thu, 24 Aug 2006 15:04:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Michael Bushkov References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <002e01c6c744$97bc9560$9800a8c0@carrera> In-Reply-To: <002e01c6c744$97bc9560$9800a8c0@carrera> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 22:04:23 -0000 Michael Bushkov wrote: > Well, maybe more compromise solution will be to have OpenLDAP and > nss_ldap in the base, but to have them turned off by default, so the user > would need to specify WITH_LDAP and WITH_NSS_LDAP in the make.conf to > build them. It isn't requiring the user to build it that I'm worried about. However, I refuse to continue tilting against this windmill. Given that I'm the only one who seems to object to this, I withdraw my objection, and correspondingly reserve the right to wave the "I told you this was a bad idea" sign if it all blows up down the road. Meanwhile, I agree with Brooks, if it's in the base, it needs to be on by default. > More, if the user don't want to have OpenLDAP built with the base, but > wants nss_ldap there, he'd have the ability to link nss_ldap against the > ports. I would say that this is a minimum requirement, and I am glad that your thinking has proceeded in this direction. > And we should also have rewritten nss_ldap in ports (call it > nss_ldap_bsd, for example). Why? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 00:04:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FDF16A4E7 for ; Fri, 25 Aug 2006 00:04:39 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4F2A43D55 for ; Fri, 25 Aug 2006 00:04:35 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from bofh.straycat.dhs.org (bofh.straycat.dhs.org [192.168.2.68]) by straycat.dhs.org (8.13.4/8.13.4) with ESMTP id k7P047Ql005315; Thu, 24 Aug 2006 20:04:08 -0400 (EDT) From: Tom McLaughlin To: Brooks Davis In-Reply-To: <20060823144347.GB24652@lor.one-eyed-alien.net> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> <20060823144347.GB24652@lor.one-eyed-alien.net> Content-Type: text/plain Date: Thu, 24 Aug 2006 20:03:13 -0400 Message-Id: <1156464193.1394.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org, LI Xin , Michael Bushkov , Alexander Leidinger Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 00:04:39 -0000 On Wed, 2006-08-23 at 09:43 -0500, Brooks Davis wrote: > On Wed, Aug 23, 2006 at 01:46:40PM +0200, Dag-Erling Sm?rgrav wrote: > > Alexander Leidinger writes: > > > Michael Bushkov writes:(from Tue, 22 Aug 2006 > > > > So, after all, I'd prefer to leave libldap (and nss_ldap, which can > > > > also conflict with PADL's nss_ldap) as is and let users use > > > > WITHOUT_LDAP and WITHOUT_NSS_LDAP when appropriate. > > > If someone doesn't like the base system libldap, but wants the > > > nss_ldap stuff, this way will not work out. While building the base > > > system, no 3rd party libs are known to the build infrastructure. > > > > Wrong. It is already possible in today's tree to build the base > > system's Kerberos with OpenLDAP support using the OpenLDAP port, and > > there are similar provisions for using OpenSSL from ports. > > It's also possible to build sendmail with SASL support: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/smtp-auth.html > Will it also be possible to build openldap in base with SASL support? My understanding is Windows AD environments by default require all connections to be authenticated via kerberos. (It's also a requirement for the samba+openldap+krb5 setup I'm doing for work. ;) I saw a comment about adding support for krb5_ccname in the config file. That's a very useful option in the PADL version so I'm guessing this was written with supporting SASL in mind? Thanks. tom (Hell, let's import Cyrus-SASL too. It's BSD licensed!... Alright, I'll stop since this ins't my area of the repo. :) -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | | BSD# http://www.mono-project.com/Mono:FreeBSD | From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 00:51:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95BC316A4E0 for ; Fri, 25 Aug 2006 00:51:02 +0000 (UTC) (envelope-from security@yourdot-mail.com) Received: from jupiter.nswebhost.com (jupiter.nswebhost.com [66.246.252.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB5143D45 for ; Fri, 25 Aug 2006 00:51:02 +0000 (GMT) (envelope-from security@yourdot-mail.com) Received: from 94.60.30.213.rev.vodafone.pt ([213.30.60.94]:36893 helo=[192.168.1.10]) by jupiter.nswebhost.com with esmtpa (Exim 4.52) id 1GGOze-00022S-MG; Thu, 24 Aug 2006 18:52:14 -0500 Message-ID: <44EE496E.8010603@yourdot-mail.com> Date: Fri, 25 Aug 2006 01:50:54 +0100 From: Carlos Silva User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Scott Ullrich References: <44EDFAD7.6080503@yourdot-mail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jupiter.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - yourdot-mail.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: squid page manipulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 00:51:02 -0000 hi, that's not what i am looking for. i want a script with squid that changes the default HTML on a page. someone has a solution? Best Regards, Carlos Silva, CSilva Web: http://www.csilva.org/ Scott Ullrich escreveu: > On 8/24/06, Carlos Silva wrote: >> Hi, >> >> Is that possible to manipulate a page that squid proxies? >> For example, in that page, there is an javascript alert(); function and >> i want to discard that so the browser doesn't see that. >> Basically, I want that squid change the HTML source codes from the pages >> that i download, with matching criterias. > > Yes, this should be possible. While this is not exactly what your > looking for it does modify the images mid-stream so it should be > possible to do the same for the HTML mid-flight. Take a look at > http://www.ex-parrot.com/~pete/upside-down-ternet.html which is an > interesting idea. > > Scott From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 01:05:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F69216A4DF for ; Fri, 25 Aug 2006 01:05:25 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D4EE43D46 for ; Fri, 25 Aug 2006 01:05:24 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so730698uge for ; Thu, 24 Aug 2006 18:05:23 -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=DR6pN2W9FTtKdmBgaDhwhhg8/i+gug0mWd2HGLISn/7vzfVnW42JVIMdmWkKWSjmqEYAATDcR3BPAL5GZus/UcOkoMY9gI2iHDTxxRxCCD856MKTRrDM3K4iV/BuWuADKIsoMkcEyStuStsvKVMc5wR17CequZ51s7Jr/X8n+Z4= Received: by 10.67.93.6 with SMTP id v6mr1528964ugl; Thu, 24 Aug 2006 18:05:23 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Thu, 24 Aug 2006 18:05:23 -0700 (PDT) Message-ID: Date: Thu, 24 Aug 2006 21:05:23 -0400 From: "Scott Ullrich" To: "Carlos Silva" In-Reply-To: <44EE496E.8010603@yourdot-mail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44EDFAD7.6080503@yourdot-mail.com> <44EE496E.8010603@yourdot-mail.com> Cc: freebsd-current@freebsd.org Subject: Re: squid page manipulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 01:05:25 -0000 On 8/24/06, Carlos Silva wrote: > hi, > > that's not what i am looking for. > i want a script with squid that changes the default HTML on a page. > someone has a solution? > While that script was not what you where looking for exactly, it can be altered to do exactly what you want in 2-3 lines of code. If you are looking for a solution that requires writing no code then I apologize for wasting your time. Scott From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 03:12:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A2EC16A4DE; Fri, 25 Aug 2006 03:12:16 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4390A43D46; Fri, 25 Aug 2006 03:12:15 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Fri, 25 Aug 2006 11:12:10 +0800 id 00108807.44EE6A8A.00008655 From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 11:12:10 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 03:12:16 -0000 Debugging is somewhat MUCH MORE DIFFICULT than rewriting. Here is the minimum patch that can only unbreak Mozilla 1.7.12 (GTK 1), Firefox 1.0.7 and RealPlayer 10.0.7.785 (playing video) (sysctl compat.linux.osrelease=2.6.16). It doesn't mean problems of clone(2) have been fixed. Actually, clone(2), set_thread_area(2) and get_thread_area(2) are mis-interpreted. Adobe Reader 7.0.8 hasn't been completely unbroken yet. Problems around it seem to be more complicated. My patch (against /sys/i386/linux/linux_machdep.c of CVS revision 1.53): http://ftp.intron.ac/tmp/linux_machdep.c.1.53.diff ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 06:15:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CAC816A4DA for ; Fri, 25 Aug 2006 06:15:52 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEB5043D46 for ; Fri, 25 Aug 2006 06:15:51 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from carrera ([82.179.80.87]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7P6EwKY062662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Aug 2006 10:15:02 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <002001c6c80d$cedcba60$9800a8c0@carrera> From: "Michael Bushkov" To: "Tom McLaughlin" , "Brooks Davis" References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> <20060823144347.GB24652@lor.one-eyed-alien.net> <1156464193.1394.14.camel@localhost> Date: Fri, 25 Aug 2006 10:14:55 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Cc: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org, LI Xin , Alexander Leidinger Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch andmore (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 06:15:52 -0000 Tom McLaughlin wrote: > Will it also be possible to build openldap in base with SASL support? > My understanding is Windows AD environments by default require all > connections to be authenticated via kerberos. (It's also a requirement > for the samba+openldap+krb5 setup I'm doing for work. ;) I saw a > comment about adding support for krb5_ccname in the config file. That's > a very useful option in the PADL version so I'm guessing this was > written with supporting SASL in mind? Thanks. > > tom Hi, sasl in OpenLDAP (and in nss_ldap) is supported in the way similar to Sendmail: CFLAGS+= ${OPENLDAP_CFLAGS} LDFLAGS+= ${OPENLDAP_LDFLAGS} LDADD+= ${OPENLDAP_LDADD} By defining, OPENLDAP_CFLAGS=-I/usr/local/include -DSASL OPENLDAP_LDFLAGS=-L/usr/local/lib OPENLDAP_LDADD=-lsasl you'll enable sasl support both for OpenLDAP and nss_ldap. BTW, I'll be able to implement and properly test krb5-ccname during the beginning of September. With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 06:23:02 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3208216A4DA; Fri, 25 Aug 2006 06:23:02 +0000 (UTC) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 413EF43D5F; Fri, 25 Aug 2006 06:22:40 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from carrera ([82.179.80.87]) (authenticated bits=0) by mail.r61.net (8.13.7/8.13.6) with ESMTP id k7P6MVQt063703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Aug 2006 10:22:34 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <002501c6c80e$db6fea80$9800a8c0@carrera> From: "Michael Bushkov" To: "Doug Barton" References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <002e01c6c744$97bc9560$9800a8c0@carrera> <44EE2260.80409@FreeBSD.org> Date: Fri, 25 Aug 2006 10:22:32 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 06:23:02 -0000 Doug Barton wrote: > Michael Bushkov wrote: > >> Well, maybe more compromise solution will be to have OpenLDAP and >> nss_ldap in the base, but to have them turned off by default, so the user >> would need to specify WITH_LDAP and WITH_NSS_LDAP in the make.conf to >> build them. > > It isn't requiring the user to build it that I'm worried about. However, I > refuse to continue tilting against this windmill. Given that I'm the only > one who seems to object to this, I withdraw my objection, and > correspondingly reserve the right to wave the "I told you this was a bad > idea" sign if it all blows up down the road. Ok - If it all blows up down the road, I'll stick the "he warned me" sign to my forehead :) > > Meanwhile, I agree with Brooks, if it's in the base, it needs to be on by > default. I agree too. >> And we should also have rewritten nss_ldap in ports (call it >> nss_ldap_bsd, for example). > > Why? Why not? It will be useful for somebody who'll want to use our nss_ldap instead of the PADL's one (I hope these times to come :) and will want to maintain it only via ports. With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 07:37:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32C2A16A4E1 for ; Fri, 25 Aug 2006 07:37:50 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1F3643D49 for ; Fri, 25 Aug 2006 07:37:49 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGWGA-000C6D-7d for freebsd-current@freebsd.org; Fri, 25 Aug 2006 09:37:46 +0200 To: freebsd-current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Fri, 25 Aug 2006 09:37:46 +0200 Message-Id: Subject: 802.1Q vlan performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 07:37:50 -0000 Hi While doing some experimentation and work on ipfw to see where I could improve performance for our virtualised firewall I came across the following comment in sys/net/if_vlan.c: * The VLAN_ARRAY substitutes the dynamic hash with a static array * with 4096 entries. In theory this can give a boots(sic) in processing, * however on practice it does not. Probably this is because array * is too big to fit into CPU cache. Being curious and having determined the main throughput bottleneck to be the vlan driver, I thought that I'd test the assertion. I have have 506 vlans on this machine. With VLAN_ARRAY unset, ipfw disabled, fastforwarding enabled, vlanhwtag enabled on the interface, the fastest forwarding rate I could get was 278kpps (This was a steady decrease from 440kpps with 24 vlans linearly proportional to the number of vlans). With exactly the same configuration, but the vlan driver compiled with VLAN_ARRAY defined, the forwarding rate of the system is back at 440kpps. The testbed looks like this: |pkt gen | | router | | pkt rec | | host |vlan2 vlan2 | |vlan1002 vlan1002 | host | |netperf |----------->| |------------------->| netserver| | |em0 em0 | |em1 em0 | | The router has vlan2 to vlan264 and vlan1002 through vlan1264 in 22 blocks of 23 vlan groups (a consequence of 24 port switches to to tag/untag for customers). The pkt gen and recieve host both have 253 vlans. Can anyone suggest a good reason not to turn this option on by default. It looks to me like it dramatically improves performance. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 08:41:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0A4716A4DD for ; Fri, 25 Aug 2006 08:41:29 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt3.ihug.co.nz (grunt3.ihug.co.nz [203.109.254.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ACF543D4C for ; Fri, 25 Aug 2006 08:41:29 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt3.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GGXFm-0006Uz-00; Fri, 25 Aug 2006 20:41:26 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 503AF1CC23; Fri, 25 Aug 2006 20:41:26 +1200 (NZST) Date: Fri, 25 Aug 2006 20:41:26 +1200 From: Andrew Thompson To: Ian FREISLICH Message-ID: <20060825084126.GA80099@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Ian FREISLICH , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: 802.1Q vlan performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 08:41:29 -0000 On Fri, Aug 25, 2006 at 09:37:46AM +0200, Ian FREISLICH wrote: > Hi > > While doing some experimentation and work on ipfw to see where I > could improve performance for our virtualised firewall I came across > the following comment in sys/net/if_vlan.c: > > * The VLAN_ARRAY substitutes the dynamic hash with a static array > * with 4096 entries. In theory this can give a boots(sic) in processing, > * however on practice it does not. Probably this is because array > * is too big to fit into CPU cache. > > Can anyone suggest a good reason not to turn this option on by > default. It looks to me like it dramatically improves performance. Its because of the amount of memory it uses, 16k doesnt sound like much but its valuable kernel memory. It was discussed a bit here, http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008716.html cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 08:48:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB49916A4DA; Fri, 25 Aug 2006 08:48:08 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63AC443D58; Fri, 25 Aug 2006 08:48:02 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7P8ltxl093729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 25 Aug 2006 10:47:55 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7P8ltt1093728; Fri, 25 Aug 2006 10:47:55 +0200 (CEST) Date: Fri, 25 Aug 2006 10:47:55 +0200 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20060825084755.GA93151@stud.fit.vutbr.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 08:48:08 -0000 On Fri, Aug 25, 2006 at 11:12:10AM +0800, Intron is my alias on the Internet wrote: > Debugging is somewhat MUCH MORE DIFFICULT than rewriting. > > Here is the minimum patch that can only unbreak Mozilla 1.7.12 (GTK 1), > Firefox 1.0.7 and RealPlayer 10.0.7.785 (playing video) > (sysctl compat.linux.osrelease=2.6.16). > > It doesn't mean problems of clone(2) have been fixed. Actually, clone(2), > set_thread_area(2) and get_thread_area(2) are mis-interpreted. > > Adobe Reader 7.0.8 hasn't been completely unbroken yet. Problems around > it seem to be more complicated. > > My patch (against /sys/i386/linux/linux_machdep.c of CVS revision 1.53): > > http://ftp.intron.ac/tmp/linux_machdep.c.1.53.diff + p2->p_pptr = td->td_proc->p_pptr; I already did this but differently: if (args->flags & (CLONE_PARENT|CLONE_THREAD)) { struct linux_getppid_args gpa; struct proc *pp; (void) linux_getppid(td, &gpa); pp = pfind(td->td_retval[0]); if (pp == NULL) { printf("shit\n"); return 0; } PROC_LOCK(p2); p2->p_pptr = pp; PROC_UNLOCK(p2); PROC_UNLOCK(pp); } also, linux also sets pgrp with CLONE_THREAD. can you pls explain me the set_thread_area() changes? also.. dont forget to update both instances of setting up TLS (ie. in CLONE_SETTLS and in set_thread_area() syscall) I have some more fixes uncommited which might fix the acroread. thnx for the work! roman From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 09:51:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A7E16A53E; Fri, 25 Aug 2006 09:51:59 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B67AD43D45; Fri, 25 Aug 2006 09:51:58 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGYM0-000CVd-1K; Fri, 25 Aug 2006 11:51:56 +0200 To: Andrew Thompson , freebsd-current@freebsd.org From: Ian FREISLICH In-Reply-To: Message from Andrew Thompson of "Fri, 25 Aug 2006 20:41:26 +1200." <20060825084126.GA80099@heff.fud.org.nz> X-Attribution: BOFH Date: Fri, 25 Aug 2006 11:51:56 +0200 Message-Id: Cc: Subject: Re: 802.1Q vlan performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 09:51:59 -0000 Andrew Thompson wrote: > On Fri, Aug 25, 2006 at 09:37:46AM +0200, Ian FREISLICH wrote: > > Hi > > > > While doing some experimentation and work on ipfw to see where I > > could improve performance for our virtualised firewall I came across > > the following comment in sys/net/if_vlan.c: > > > > * The VLAN_ARRAY substitutes the dynamic hash with a static array > > * with 4096 entries. In theory this can give a boots(sic) in processing, > > * however on practice it does not. Probably this is because array > > * is too big to fit into CPU cache. Just so that performance is not ignored, this option yields ~8% improvement on packet rate (consistent with the thread posted below) and CPU utilisation down from 75% to 3% in interrupt time. I'm not convinced that this should be sniffed at. > > Can anyone suggest a good reason not to turn this option on by > > default. It looks to me like it dramatically improves performance. > > Its because of the amount of memory it uses, 16k doesnt sound like much Wow, and I just added a 256k lookup table to ipfw (uncommitted) to boost performance. > but its valuable kernel memory. It was discussed a bit here, > http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008716.html So, it seems that the main cause for concern is embedded devices with little memory. As far as I know (from what little gets posted here about embedded applications) quite a lot of of stuff gets stripped out and stripped down. I think it's a small ask to have the embedded ports unset this option to get a little memory and kill performance, although it's unlikely that El Tiny Embed is going to be running thousands of vlans. Alternatively is there an objection to making this a kernel configuration file option as opposed to leaving it as an undocumented buried treasure? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 10:04:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECA9016A4DE; Fri, 25 Aug 2006 10:04:28 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB8A43D46; Fri, 25 Aug 2006 10:04:28 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGYY5-000CYz-Ow; Fri, 25 Aug 2006 12:04:25 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Fri, 25 Aug 2006 11:51:56 +0200." X-Attribution: BOFH Date: Fri, 25 Aug 2006 12:04:25 +0200 Message-Id: Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 10:04:29 -0000 Ian FREISLICH wrote: > Alternatively is there an objection to making this a kernel > configuration file option as opposed to leaving it as an undocumented > buried treasure? I see it is an option, just undocumented. Whitespace mangled: RCS file: /home/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1378 diff -u -d -r1.1378 NOTES --- /usr/src/sys/conf/NOTES 17 Aug 2006 00:37:03 -0000 1.1378 +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 @@ -646,6 +646,7 @@ # device ether #Generic Ethernet device vlan #VLAN support (needs miibus) +options VLAN_ARRAY #Lookup table for trunk interface device wlan #802.11 support device wlan_wep #802.11 WEP support device wlan_ccmp #802.11 CCMP support -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 10:11:00 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E734B16A4DD; Fri, 25 Aug 2006 10:10:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D53243D5E; Fri, 25 Aug 2006 10:10:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7PAArxK090483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 14:10:53 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7PAArkU090482; Fri, 25 Aug 2006 14:10:53 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 25 Aug 2006 14:10:53 +0400 From: Gleb Smirnoff To: Ian FREISLICH Message-ID: <20060825101053.GU76666@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: yar@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: 802.1Q vlan performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 10:11:00 -0000 Ian, big thanks for your testing and feedback made. When I made this option, I have tested it on a small number for VLANs and expected it to be a nop. However, it was a regression. That's why I decided that on moderate number of vlans it would be a regression. Probably on modern hardware with bigger CPU caches it isn't. I do most of my performance testing on quad PIII. On Fri, Aug 25, 2006 at 09:37:46AM +0200, Ian FREISLICH wrote: I> While doing some experimentation and work on ipfw to see where I I> could improve performance for our virtualised firewall I came across I> the following comment in sys/net/if_vlan.c: I> I> * The VLAN_ARRAY substitutes the dynamic hash with a static array I> * with 4096 entries. In theory this can give a boots(sic) in processing, I> * however on practice it does not. Probably this is because array I> * is too big to fit into CPU cache. I> I> Being curious and having determined the main throughput bottleneck I> to be the vlan driver, I thought that I'd test the assertion. I I> have have 506 vlans on this machine. I> I> With VLAN_ARRAY unset, ipfw disabled, fastforwarding enabled, I> vlanhwtag enabled on the interface, the fastest forwarding rate I I> could get was 278kpps (This was a steady decrease from 440kpps with I> 24 vlans linearly proportional to the number of vlans). I> I> With exactly the same configuration, but the vlan driver compiled I> with VLAN_ARRAY defined, the forwarding rate of the system is back I> at 440kpps. I> The testbed looks like this: I> I> |pkt gen | | router | | pkt rec | I> | host |vlan2 vlan2 | |vlan1002 vlan1002 | host | I> |netperf |----------->| |------------------->| netserver| I> | |em0 em0 | |em1 em0 | | I> I> The router has vlan2 to vlan264 and vlan1002 through vlan1264 in I> 22 blocks of 23 vlan groups (a consequence of 24 port switches to I> to tag/untag for customers). The pkt gen and recieve host both I> have 253 vlans. I> I> Can anyone suggest a good reason not to turn this option on by I> default. It looks to me like it dramatically improves performance. As said before by Andrew. It consumes memory. And looks like a regression on a system with small number of vlans. However, after your email I see that we need to document this option in vlan(4) and encourage people to try it, when they are building a system with a huge number of vlans. And here are some more performance thoughts on vlan(4) driver. When we are processing an incoming VLAN tagged frame, we need either hash or the array to determine which VLAN does this frame belong to. When we are sending a VLAN frame outwards, we don't need this lookup. I've made some tests and it looks like that the performance decrease that is observed between bare Ethernet interface and vlan(4) interface, is mostly caused by the transmit part. The packet is put twice on interface queues. I hope, this will be optimized after Robert Watson finishes his if_start_mbuf work. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 10:12:25 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD0D16A4DD; Fri, 25 Aug 2006 10:12:25 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA5AE43D66; Fri, 25 Aug 2006 10:11:41 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7PABe0g090502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 14:11:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7PABebG090501; Fri, 25 Aug 2006 14:11:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 25 Aug 2006 14:11:40 +0400 From: Gleb Smirnoff To: Ian FREISLICH Message-ID: <20060825101140.GV76666@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org, Andrew Thompson Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 10:12:25 -0000 On Fri, Aug 25, 2006 at 12:04:25PM +0200, Ian FREISLICH wrote: I> > Alternatively is there an objection to making this a kernel I> > configuration file option as opposed to leaving it as an undocumented I> > buried treasure? I> I> I see it is an option, just undocumented. I> I> Whitespace mangled: I> I> RCS file: /home/ncvs/src/sys/conf/NOTES,v I> retrieving revision 1.1378 I> diff -u -d -r1.1378 NOTES I> --- /usr/src/sys/conf/NOTES 17 Aug 2006 00:37:03 -0000 1.1378 I> +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 I> @@ -646,6 +646,7 @@ I> # I> device ether #Generic Ethernet I> device vlan #VLAN support (needs miibus) I> +options VLAN_ARRAY #Lookup table for trunk interface I> device wlan #802.11 support I> device wlan_wep #802.11 WEP support I> device wlan_ccmp #802.11 CCMP support I'd prefer not to put it into NOTES. When enabled, less code will be covered by LINT. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 10:38:20 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089C416A4DD; Fri, 25 Aug 2006 10:38:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9B743D45; Fri, 25 Aug 2006 10:38:19 +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 53CE146DED; Fri, 25 Aug 2006 06:38:19 -0400 (EDT) Date: Fri, 25 Aug 2006 11:38:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20060825101053.GU76666@FreeBSD.org> Message-ID: <20060825113658.D40887@fledge.watson.org> References: <20060825101053.GU76666@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ian FREISLICH , freebsd-current@FreeBSD.org, yar@FreeBSD.org Subject: Re: 802.1Q vlan performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 10:38:20 -0000 On Fri, 25 Aug 2006, Gleb Smirnoff wrote: > As said before by Andrew. It consumes memory. And looks like a regression on > a system with small number of vlans. > > However, after your email I see that we need to document this option in > vlan(4) and encourage people to try it, when they are building a system with > a huge number of vlans. > > And here are some more performance thoughts on vlan(4) driver. When we are > processing an incoming VLAN tagged frame, we need either hash or the array > to determine which VLAN does this frame belong to. When we are sending a > VLAN frame outwards, we don't need this lookup. I've made some tests and it > looks like that the performance decrease that is observed between bare > Ethernet interface and vlan(4) interface, is mostly caused by the transmit > part. The packet is put twice on interface queues. I hope, this will be > optimized after Robert Watson finishes his if_start_mbuf work. Ideally, it will also be possible to remove the m_tag allocation/free from the path once I'm done, which should help also. Is it possible to make the hash table decision a run-time decision? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 11:30:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BF8D16A4DD; Fri, 25 Aug 2006 11:30:35 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7116943D49; Fri, 25 Aug 2006 11:30:31 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5FD71.dip.t-dialin.net [84.165.253.113]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k7PBCGAW036532; Fri, 25 Aug 2006 13:12:17 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k7PBUZiA017400; Fri, 25 Aug 2006 13:30:35 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 25 Aug 2006 13:30:34 +0200 Message-ID: <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 25 Aug 2006 13:30:34 +0200 From: Alexander Leidinger To: Divacky Roman References: <20060825084755.GA93151@stud.fit.vutbr.cz> In-Reply-To: <20060825084755.GA93151@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Intron is my alias on the Internet Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 11:30:35 -0000 Quoting Divacky Roman (from Fri, 25 Aug 2006 10:47:55 +0200): > I have some more fixes uncommited which might fix the acroread. For the curious: http://www.leidinger.net/FreeBSD/linuxolator/013_linuxolator_final_uncommitted.diff Bye, Alexander. -- In any country there must be people who have to die. They are the sacrifices any nation has to make to achieve law and order. -- Idi Amin Dada http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 13:35:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 680DA16A4DA for ; Fri, 25 Aug 2006 13:35:13 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C738B43D81 for ; Fri, 25 Aug 2006 13:34:58 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 2532 invoked from network); 25 Aug 2006 13:34:55 -0000 Received: from unknown (HELO localhost) (775067@[217.50.133.150]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 25 Aug 2006 13:34:55 -0000 Date: Fri, 25 Aug 2006 15:34:33 +0200 From: Fabian Keil To: Carlos Silva Message-ID: <20060825153433.3a53a11f@localhost> In-Reply-To: <44EDFAD7.6080503@yourdot-mail.com> References: <44EDFAD7.6080503@yourdot-mail.com> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd6.1) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_XBvFmFySP+qPa1f=PBNtJsX"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: squid page manipulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 13:35:13 -0000 --Sig_XBvFmFySP+qPa1f=PBNtJsX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Carlos Silva wrote: > Is that possible to manipulate a page that squid proxies? > For example, in that page, there is an javascript alert(); function and=20 > i want to discard that so the browser doesn't see that. > Basically, I want that squid change the HTML source codes from the pages= =20 > that i download, with matching criterias. I don't know about squid, but Privoxy can be used to rewrite documents with regular expressions. You can chain it together with squid if you have to. =20 BTW, freebsd-questions or a squid mailing list would be better choices to ask this question. Fabian --=20 http://www.fabiankeil.de/ --Sig_XBvFmFySP+qPa1f=PBNtJsX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7vx7BYqIVf93VJ0RAof9AKCEwjKfU34b8P8lkFvpZyB1ps5ThgCeNmC+ jWz2a3iFIrZxs4yeCrqAFxY= =+Y4d -----END PGP SIGNATURE----- --Sig_XBvFmFySP+qPa1f=PBNtJsX-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 11:57:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CAF016A4E0 for ; Fri, 25 Aug 2006 11:57:58 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9429C43D49 for ; Fri, 25 Aug 2006 11:57:57 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1090200pye for ; Fri, 25 Aug 2006 04:57:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=ria5x6SJ5mi6TKvu52m2xy5ao4dD9KjfXwOcdup+MbarSQblyPdBLfVO6G48pHh2EKQxBZ1nljQF4TiYNqv+0yQzHe0GywTQBXHJl67IOOI4/EebKAac1TV8tCKRpLaUDEB19BKGeGddIitgOKcBl2Pe8OL4PYDJ61QzJ6oSN0Q= Received: by 10.35.9.15 with SMTP id m15mr4940805pyi; Fri, 25 Aug 2006 04:57:57 -0700 (PDT) Received: from ?222.48.99.49? ( [124.172.191.114]) by mx.gmail.com with ESMTP id n80sm2310428pye.2006.08.25.04.57.55; Fri, 25 Aug 2006 04:57:56 -0700 (PDT) From: "Yuan, Jue" Organization: Institute of Computing Technology, CAS, China To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 20:00:07 +0800 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608252000.07240.yuanjue02@gmail.com> X-Mailman-Approved-At: Fri, 25 Aug 2006 13:44:25 +0000 Subject: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 11:57:58 -0000 Hi all. Could I change the kernel version tag manually? say, I have a kernel which is 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. All I want is the change of tag. For example, if this works, then when I type "uname -a" in console, I would get "6.1-RELEASE ..." instead of "7.0-CURRENT ...". I guess some config files in src/sys/ could take care of this. But I cannot find it out. Anybody knows how to get this job done? Any ideas are really appreciated. :-) BTW: I am not in this list. So if you reply, please CC a copy to me. Thanks. -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:24:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3275616A4DD for ; Fri, 25 Aug 2006 14:24:46 +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 7CC9743D68 for ; Fri, 25 Aug 2006 14:24:39 +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 k7PEOXjY075845; Fri, 25 Aug 2006 10:24:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 10:03:27 -0400 User-Agent: KMail/1.9.1 References: <200608181445.k7IEjA9f020038@lurza.secnetix.de> In-Reply-To: <200608181445.k7IEjA9f020038@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251003.28528.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]); Fri, 25 Aug 2006 10:24:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Oliver Fromme , julian@elischer.org Subject: Re: suggested addition to 'date' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:24:46 -0000 On Friday 18 August 2006 10:45, Oliver Fromme wrote: > Julian Elischer wrote: > > BTW I chose 's' without any research.. Date only has the short getopt so > > '--' doesn't work, but > > there are lots of unsed letters.. a quick survey suggests maybe -p (pipe?) > > (suggestions welcome) my favourites of s and f are already used on one > > system or another. > > There's another possibility, which doesn't require a new > option letter at all. You could add a new escape sequence > to the format string, e.g. "%*". Whenever date(1) is > called with a format string containing that sequence, it > goes into filter mode and replaces the sequence with the > current line. That would also enable you to be more > flexible with the placement of the timestamps. > For example: > > $ printf 'foo\nbar\nbaz\n' | date +'%H:%M:%S %*' > 16:39:58 foo > 16:39:58 bar > 16:39:58 baz I prefer this of all the suggestions so far. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:24:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4810C16A5CC; Fri, 25 Aug 2006 14:24:51 +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 7EDF843D77; Fri, 25 Aug 2006 14:24:44 +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 k7PEOXja075845; Fri, 25 Aug 2006 10:24:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, pyunyh@gmail.com Date: Fri, 25 Aug 2006 10:22:45 -0400 User-Agent: KMail/1.9.1 References: <20060822042023.GC12848@cdnetworks.co.kr> <20060824004354.GC25876@lath.rinet.ru> <20060824010746.GC22634@cdnetworks.co.kr> In-Reply-To: <20060824010746.GC22634@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251022.46120.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]); Fri, 25 Aug 2006 10:24:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Oleg Bulyzhin Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:24:51 -0000 On Wednesday 23 August 2006 21:07, Pyun YongHyeon wrote: > On Thu, Aug 24, 2006 at 04:43:54AM +0400, Oleg Bulyzhin wrote: > > On Thu, Aug 24, 2006 at 09:30:35AM +0900, Pyun YongHyeon wrote: > > > On Wed, Aug 23, 2006 at 04:54:34PM +0400, Oleg Bulyzhin wrote: > > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > > > On Wed, Aug 23, 2006 at 09:55:54AM +0900, Pyun YongHyeon wrote: > > > > > > On Wed, Aug 23, 2006 at 12:43:42AM +0400, Oleg Bulyzhin wrote: > > > > > > > On Tue, Aug 22, 2006 at 02:44:34PM +0200, Michael Reifenberger wrote: > > > > > > > > On Tue, 22 Aug 2006, Pyun YongHyeon wrote: > > > > > > > > ... > > > > > > > > >I'm not familiar with vge(4) and don't have hardwares supported by > > > > > > > > >vge(4). Because vge(4) supports a kind of interrupt moderation, there > > > > > > > > >is a possiblity to have the same issue seen on em(4). > > > > > > > > >If you want my blind patch I can send a patch for you. > > > > > > > > > > > > > > > > > Yes, please! > > > > > > > > I can test it (on RELENG_6 though). > > > > > > > > > > > > > > I have an idea why those timeouts can happen. Could you please test > > > > > > > attached patch? It may help (or may not). Anyway would be fine > > > > > > > to know results. > > > > > > > > > > > > > > > > > > > Since vge(4) uses MTX_RECURSE mutex and miibus(4) handler is > > > > > > protected with the mutex I guess it wouldn't help much. > > > > > > I guess it needs a seperate mutex to protect miibus(4) handler > > > > > > and should remove the use of MTX_RECURSE. > > > > > > > > > > Hmm. > > > > > 1) _ifmedia_upd() & _ifmedia_sts() functions are not called from mii layer. > > > > > 2) As i can see MII layer is not protected by anything, unless you > > > > > specially acquire driver lock prior to calling mii_ function. > > > > > Locking ifmedia callbacks should be done (though, it may not help > > > > > with watchdogs timeout), otherwise we have race on accessing PHY registers. > > > > > (kern/98738). > > > > > > > > > > As i can see, random watchdog timeouts was reported for em, bge, vge, sk > > > > > (and maybe others, those ones which i remember) drivers. > > > > > All of them has unlocked _ifmedia_ functions. > > > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > > lead to hardware deadlock. > > > > > > > > > > > > > > > > vge(4) also has a bug > > > > > > if mbuf chain is too long(7 or higher) and defragmentation with > > > > > > m_defrag(9) fails it would access an invalid mbuf chain. > > > > > > All these requires lots of work and need a real hardware. > > > > > > Oleg, if you have hardware, would you fix it? > > > > > > > > > > Unfortunately i don't have vge hardware. > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Pyun YongHyeon > > > > > > > > > > -- > > > > > Oleg. > > > > > > > > > > > > > Forgot one thing: i think we need no dedicated mutex for mii layer if we lock > > > > ifmedia callbacks. > > > > > > > > > > If we use the diver mutex in MII access it would require MTX_RECURSE > > > mutex. I want simple MTX_DEF mutex. > > > > Could you please explain why MTX_RECURSE is required? > > > > I can't remember what caused this. Need more coffee. :-( > If my memory serve me right it's related with ioctls. > I guess you can easily experiment with removing MTX_RECURSE flag > in the driver. The fix for that is to not hold the driver lock in the ioctl routine when you call the mii function for media changes, but to only hold the lock in the ifmedia callouts. This is what I did in the several device drivers I locked or fixed the locking in. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:24:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ACA016A531 for ; Fri, 25 Aug 2006 14:24:53 +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 AA62143D6E for ; Fri, 25 Aug 2006 14:24:41 +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 k7PEOXjZ075845; Fri, 25 Aug 2006 10:24:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 10:12:42 -0400 User-Agent: KMail/1.9.1 References: <20060819211853.GA1016@tin.it> In-Reply-To: <20060819211853.GA1016@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251012.42642.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]); Fri, 25 Aug 2006 10:24:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Subject: Re: Fatal trap 30 when loading if_xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:24:53 -0000 On Saturday 19 August 2006 17:18, Paolo Pisati wrote: > Today's CURRENT panic my box everytime i load > if_xl: > > [flag@newluxor NEWLUXOR]$ sudo kgdb kernel.debug /var/crash/vmcore.0 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". 30 (unknown trap) can mean that you got a device interrupt to an IDT entry you haven't installed a handler for yet. If you want to figure out exactly which IDT entry, you'll need to install a unique custom dummy handler in each IDT entry so you can tell which one fired. > Unread portion of the kernel message buffer: > <118>. > <118>. > <118>Aug 19 22:38:31 newluxor syslogd: exiting on signal 15 > <118>Enter full pathname of shell or RETURN for /bin/sh: > <118># > <118>/dev/ad4s1a on / (ufs, local) > <118>devfs on /dev (devfs, local) > <118>/dev/ad4s1d on /usr (ufs, local, soft-updates) > <118>/dev/ad4s5 on /storage (msdosfs, local) > <118>procfs on /proc (procfs, local) > <118>linprocfs on /usr/compat/linux/proc (linprocfs, local) > <118># > <118># > <118># > <118>/dev/ad4s1a on / (ufs, local) > <118>devfs on /dev (devfs, local) > <118>/dev/ad4s1d on /usr (ufs, local, soft-updates) > <118>/dev/ad4s5 on /storage (msdosfs, local) > <118># > <118># > <118>/dev/ad4s1a on / (ufs, local) > <118>devfs on /dev (devfs, local) > <118>/dev/ad4s1d on /usr (ufs, local, soft-updates) > <118># > <118># > <118>umount: > <118>unmount of /dev failed > <118>: > <118>Device busy > <118># > <118>.cshrc cdrom home media storage > <118>.profile compat lib mnt sys > <118>.snap dev libexec proc tmp > <118>COPYRIGHT dist linc_data rescue usr > <118>bin entropy linc_storage root var > <118>boot etc lost+found sbin > <118># > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f mem 0xff8ffc00-0xff8ffc7f irq 18 at device 2.0 on pci1 > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc04ef25b > stack pointer = 0x28:0xe3491c34 > frame pointer = 0x28:0xe3491c50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 12 (swi4: clock sio) > panic: from debugger > cpuid = 0 > Uptime: 2m36s > Physical memory: 2031 MB > Dumping 61 MB: 46 30 14 > > #0 doadump () at pcpu.h:166 > 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc04f9cd4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04fa0b3 in panic (fmt=0xc06976c3 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc0451b47 in db_panic (addr=-1068567973, have_addr=0, count=-1, > modif=0xe3491a1c "") at /usr/src/sys/ddb/db_command.c:428 > #4 0xc0451ada in db_command (last_cmdp=0xc06ef7c4, cmd_table=0x0) > at /usr/src/sys/ddb/db_command.c:396 > #5 0xc0451ba1 in db_command_loop () at /usr/src/sys/ddb/db_command.c:448 > #6 0xc0453ae9 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_main.c:221 > #7 0xc051bcde in kdb_trap (type=0, code=0, tf=0xe3491bf4) > at /usr/src/sys/kern/subr_kdb.c:502 > #8 0xc066f602 in trap_fatal (frame=0xe3491bf4, eva=0) > at /usr/src/sys/i386/i386/trap.c:858 > #9 0xc066f04d in trap (frame= > {tf_fs = -1066467320, tf_es = -481755096, tf_ds = 40, tf_edi = -997181328, tf_esi = -996104080, tf_ebp = -481747888, tf_isp = -481747936, tf_ebx = -1066453624, tf_edx = 4, tf_ecx = -996104080, tf_eax = 582, tf_trapno = 30, tf_err = 0, tf_eip = -1068567973, tf_cs = 32, tf_eflags = 582, tf_esp = -1066453624, tf_ss = -1066446508}) at /usr/src/sys/i386/i386/trap.c:658 > #10 0xc065766a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #11 0xc04ef25b in _mtx_lock_sleep (m=0xc06f3588, tid=3297785968, opts=0, > file=0x0, line=0) at cpufunc.h:317 > #12 0xc050c028 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:240 > #13 0xc04dfbbf in ithread_execute_handlers (p=0xc49028d0, ie=0xc4957180) > at /usr/src/sys/kern/kern_intr.c:662 > #14 0xc04dfd05 in ithread_loop (arg=0xc48c68f0) > at /usr/src/sys/kern/kern_intr.c:745 > #15 0xc04de558 in fork_exit (callout=0xc04dfca1 , arg=0x246, > frame=0x246) at /usr/src/sys/kern/kern_fork.c:818 > #16 0xc06576cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 > (kgdb) frame 12 > #12 0xc050c028 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:240 > 240 mtx_lock(c_mtx); > (kgdb) p c_mtx > $1 = (struct mtx *) 0xc06f3588 > (kgdb) p *c_mtx > $2 = {mtx_object = {lo_name = 0xc06a1779 "Giant", > lo_type = 0xc06a1779 "Giant", lo_flags = 17498112, lo_witness_data = { > lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, > mtx_lock = 3298863219, mtx_recurse = 1} > (kgdb) > > bye -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:24:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAFC716A66A; Fri, 25 Aug 2006 14:24:54 +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 F008843D78; Fri, 25 Aug 2006 14:24:44 +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 k7PEOXjb075845; Fri, 25 Aug 2006 10:24:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 10:23:59 -0400 User-Agent: KMail/1.9.1 References: <20060822073201.GI12848@cdnetworks.co.kr> <20060824014121.GE22634@cdnetworks.co.kr> <20060824192621.GB39797@lath.rinet.ru> In-Reply-To: <20060824192621.GB39797@lath.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251024.00401.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]); Fri, 25 Aug 2006 10:24:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Pyun YongHyeon , Oleg Bulyzhin Subject: Re: call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:24:55 -0000 On Thursday 24 August 2006 15:26, Oleg Bulyzhin wrote: > On Thu, Aug 24, 2006 at 10:41:21AM +0900, Pyun YongHyeon wrote: > > On Thu, Aug 24, 2006 at 05:24:50AM +0400, Oleg Bulyzhin wrote: > > > On Thu, Aug 24, 2006 at 10:11:16AM +0900, Pyun YongHyeon wrote: > > > > On Thu, Aug 24, 2006 at 04:42:25AM +0400, Oleg Bulyzhin wrote: > > > > > On Thu, Aug 24, 2006 at 09:26:32AM +0900, Pyun YongHyeon wrote: > > > > > > On Wed, Aug 23, 2006 at 04:40:35PM +0400, Oleg Bulyzhin wrote: > > > > > > > > [...] > > > > > > > > > > > > > > > > > My idea was: perhaps, under certain condition, concurrent access to PHY could > > > > > > > lead to hardware deadlock. > > > > > > > > > > > > > > > > > > > Yes. Because MII bus access needs several steps to access PHY > > > > > > registers its operation shouldn't be interrupted until all pending > > > > > > requests are served. > > > > > > > > > > > > I can't sure you remember my mail for MII lock which modifies > > > > > > mii_phy_probe API to take an additional mutex. The driver mutex > > > > > > could be used with MII bus access/callbacks. > > > > > > > > > > Yes, i remember that mail but i didnt had time to dig code deep enough > > > > > to give an answer. I did it recently, while working on PR. > > > > > > > > > > > > > Glad to hear that. :-) > > > > > > > > > > If interface is up/running and auto negotiation is in progress MII > > > > > > layer would inspect BMSR register periodically to know the state > > > > > > of link. During the time if you run ifconfig(8) to know the state > > > > > > of the link or to change media type/duplex it will access PHY > > > > > > registers. Normally it would end up with "link states coalesced" > > > > > > messages. > > > > > > > > > > > > As you know the two callbacks(vge_ifmedia_upd/vge_ifmedia_sts) will > > > > > > end up with calling mii_mediachg() or mii_pollstat() which in turn > > > > > > access PHY registers. So if MII access is properly serialized we > > > > > > wouldn't get stale data. I guess your fix solves it by protecting > > > > > > callbacks with driver mutex but it wouldn't fix other cases. > > > > > > For example see vge_miibus_statchg MII interface. > > > > > > > > > > MII layer does not have it's own callouts, i.e. those autonegotiation > > > > > checks of BMSR are triggered by driver's _tick() function, which are locked. > > > > > So if we have locked _tick() & _ifmedia_(upd|sts) functions, concurrent > > > > > access to PHY is impossible. > > > > > (If we are talking about vge_miibus_statchg(), it would be: > > > > > vge_tick (here we obtain lock) -> mii_tick -> ciphy_service -> > > > > > mii_phy_update -> vge_miibus_statchg). > > > > > > > > > > > > > If we set media type manually while autonegotiation is in progress, > > > > wouldn't it access PHY registers without driver lock? > > > > > > No (if we have _tick() & ifmedia callbacks locked): > > > ioctl -> netioctl -> ifhwioctl -> vge_ioctl(SIOCSIFMEDIA) -> ifmedia_ioctl -> > > > vge_ifmedia_upd (here we obtain lock) -> mii_mediachg -> > > > ciphy_service(MII_MEDIACHG) -> mii_phy_update -> vge_miibus_statchg > > > > > > > Ah...I've missed the your assumption ifmedia callbacks were locked. > > As you said, several drivers don't have locks for ifmedia callback > > handlers. These drivers would access PHY registers without locks. > > I believe all such drivers should be fixed. Agreed. This is much more sane than trying to pass the locks around. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:27:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E15B16A4DA for ; Fri, 25 Aug 2006 14:27:57 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id B95C843DC4 for ; Fri, 25 Aug 2006 14:27:37 +0000 (GMT) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 6F21610E759; Fri, 25 Aug 2006 16:27:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBof9I8-jyF7; Fri, 25 Aug 2006 16:27:22 +0200 (CEST) Received: from danger.mcrn.sk (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id 9192610E75E; Fri, 25 Aug 2006 16:27:22 +0200 (CEST) Date: Fri, 25 Aug 2006 16:27:35 +0200 From: Daniel Gerzo Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1792789242.20060825162735@rulez.sk> To: "Yuan, Jue" In-Reply-To: <200608252000.07240.yuanjue02@gmail.com> References: <200608252000.07240.yuanjue02@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:27:57 -0000 Hello Jue, Friday, August 25, 2006, 2:00:07 PM, you wrote: > Hi all. > Could I change the kernel version tag manually? say, I have a kernel which is > 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELEASE, > while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. All I > want is the change of tag. For example, if this works, then when I > type "uname -a" in console, I would get "6.1-RELEASE ..." instead > of "7.0-CURRENT ...". > I guess some config files in src/sys/ could take care of this. But I cannot > find it out. Anybody knows how to get this job done? It's src/sys/conf/newvers.sh But I don't think it's a good idea to fake it ;-) > Any ideas are really appreciated. :-) > BTW: I am not in this list. So if you reply, please CC a copy to me. Thanks. -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:48:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F11E616A4E0; Fri, 25 Aug 2006 14:48:32 +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 38B0D43D6D; Fri, 25 Aug 2006 14:48:25 +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 k7PEmJ7K076037; Fri, 25 Aug 2006 10:48:19 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 10:28:55 -0400 User-Agent: KMail/1.9.1 References: <20060825084755.GA93151@stud.fit.vutbr.cz> In-Reply-To: <20060825084755.GA93151@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251028.55915.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]); Fri, 25 Aug 2006 10:48:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Divacky Roman , freebsd-emulation@freebsd.org, Intron is my alias on the Internet Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:48:33 -0000 On Friday 25 August 2006 04:47, Divacky Roman wrote: > On Fri, Aug 25, 2006 at 11:12:10AM +0800, Intron is my alias on the Internet wrote: > > Debugging is somewhat MUCH MORE DIFFICULT than rewriting. > > > > Here is the minimum patch that can only unbreak Mozilla 1.7.12 (GTK 1), > > Firefox 1.0.7 and RealPlayer 10.0.7.785 (playing video) > > (sysctl compat.linux.osrelease=2.6.16). > > > > It doesn't mean problems of clone(2) have been fixed. Actually, clone(2), > > set_thread_area(2) and get_thread_area(2) are mis-interpreted. > > > > Adobe Reader 7.0.8 hasn't been completely unbroken yet. Problems around > > it seem to be more complicated. > > > > My patch (against /sys/i386/linux/linux_machdep.c of CVS revision 1.53): > > > > http://ftp.intron.ac/tmp/linux_machdep.c.1.53.diff > > + p2->p_pptr = td->td_proc->p_pptr; > > I already did this but differently: > > if (args->flags & (CLONE_PARENT|CLONE_THREAD)) { > struct linux_getppid_args gpa; > struct proc *pp; > > (void) linux_getppid(td, &gpa); > pp = pfind(td->td_retval[0]); > if (pp == NULL) { > printf("shit\n"); > return 0; > } > PROC_LOCK(p2); > p2->p_pptr = pp; > PROC_UNLOCK(p2); > PROC_UNLOCK(pp); > } > > also, linux also sets pgrp with CLONE_THREAD. Umm, if you want to reparent a proc you should use the proc_reparent() function instead of just hacking on p_pptr. You also need to hold the proctree_lock when modifying p_pptr anyway. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:48:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F6D816A4DA; Fri, 25 Aug 2006 14:48:36 +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 4045B43D77; Fri, 25 Aug 2006 14:48:27 +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 k7PEmJ7L076037; Fri, 25 Aug 2006 10:48:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 10:31:33 -0400 User-Agent: KMail/1.9.1 References: <20060825101140.GV76666@FreeBSD.org> In-Reply-To: <20060825101140.GV76666@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251031.34081.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]); Fri, 25 Aug 2006 10:48:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Ian FREISLICH , Gleb Smirnoff , Andrew Thompson Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:48:36 -0000 On Friday 25 August 2006 06:11, Gleb Smirnoff wrote: > On Fri, Aug 25, 2006 at 12:04:25PM +0200, Ian FREISLICH wrote: > I> > Alternatively is there an objection to making this a kernel > I> > configuration file option as opposed to leaving it as an undocumented > I> > buried treasure? > I> > I> I see it is an option, just undocumented. > I> > I> Whitespace mangled: > I> > I> RCS file: /home/ncvs/src/sys/conf/NOTES,v > I> retrieving revision 1.1378 > I> diff -u -d -r1.1378 NOTES > I> --- /usr/src/sys/conf/NOTES 17 Aug 2006 00:37:03 -0000 1.1378 > I> +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 > I> @@ -646,6 +646,7 @@ > I> # > I> device ether #Generic Ethernet > I> device vlan #VLAN support (needs miibus) > I> +options VLAN_ARRAY #Lookup table for trunk interface > I> device wlan #802.11 support > I> device wlan_wep #802.11 WEP support > I> device wlan_ccmp #802.11 CCMP support > > I'd prefer not to put it into NOTES. When enabled, less code will > be covered by LINT. Bah, GENERIC will cover it then. All options should be in NOTES. If an option removes code and it's enabled in GENERIC, then you should put it in NOTES but comment it out. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:56:35 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C59A216A4DD; Fri, 25 Aug 2006 14:56:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13B2D43D45; Fri, 25 Aug 2006 14:56:34 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7PEuW77092191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 18:56:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7PEuWFX092190; Fri, 25 Aug 2006 18:56:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 25 Aug 2006 18:56:32 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20060825145632.GY76666@cell.sick.ru> References: <20060825101140.GV76666@FreeBSD.org> <200608251031.34081.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200608251031.34081.jhb@freebsd.org> User-Agent: Mutt/1.5.6i Cc: Ian FREISLICH , freebsd-current@FreeBSD.org, Andrew Thompson Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:56:35 -0000 On Fri, Aug 25, 2006 at 10:31:33AM -0400, John Baldwin wrote: J> > I> +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 J> > I> @@ -646,6 +646,7 @@ J> > I> # J> > I> device ether #Generic Ethernet J> > I> device vlan #VLAN support (needs miibus) J> > I> +options VLAN_ARRAY #Lookup table for trunk interface J> > I> device wlan #802.11 support J> > I> device wlan_wep #802.11 WEP support J> > I> device wlan_ccmp #802.11 CCMP support J> > J> > I'd prefer not to put it into NOTES. When enabled, less code will J> > be covered by LINT. J> J> Bah, GENERIC will cover it then. All options should be in NOTES. If J> an option removes code and it's enabled in GENERIC, then you should put J> it in NOTES but comment it out. But "device vlan" isn't in GENERIC. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 15:11:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0392916A4DD; Fri, 25 Aug 2006 15:11:20 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from palunko.srce.hr (palunko.srce.hr [161.53.2.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D44743D76; Fri, 25 Aug 2006 15:11:18 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [193.198.133.216] (cmung1486.cmu.carnet.hr [193.198.133.216]) by palunko.srce.hr (8.13.7/8.13.6) with ESMTP id k7PF6MNf014455; Fri, 25 Aug 2006 17:06:23 +0200 (CEST) Message-ID: <44EF12F6.3000806@fer.hr> Date: Fri, 25 Aug 2006 17:10:46 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: current@freebsd.org, geom@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7780AB464B2A72DC0BAEE3D7" X-Scanned-By: MIMEDefang 2.55 on 161.53.2.67 Cc: Subject: Announcing: gvirstor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 15:11:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7780AB464B2A72DC0BAEE3D7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm glad to announce availability of GEOM virtual storage class, (currently) named "gvirstor". The purpose of this class is to enable creation of huge virtual providers (for example: many terabytes) backed by limited physical storage, with the expectation that more physical storage will be added later. This is a part of a logical volume manager, and provides functionality up to now not available as a native GEOM class. gvirstor is currently available either from Perforce (under the name \\gvirstor) or at http://wiki.freebsd.org/gvirstor in a convenient tbz archive with appropriate Makefile. Please read the README file packaged in the archive for instructions on how to build and run gvirstor. Here are some usage examples from the man page: The following example shows how to create a virtual device of default size (2 TiB), of default chunk (extent) size (4 MiB), with two physical devices for backing storage. gvirstor label -v mydata /dev/ad4 /dev/ad6 newfs /dev/virstor/mydata From now on, the virtual device will be available via the /dev/virstor/mydata device entry. To add a new physical device / provider to an active virstor device: gvirstor add mydata ad8 This will add physical storage (from ad8) to /dev/virstor/mydata device.= To see device status information (including how much physical storage is= still available for the virtual device), use: gvirstor list The latest version of gvirstor is called "beta3" because it has not received much testing, especially on non-i386 architectures. Please help by testing both stability and performance of gvirstor if you have equipment and time. This work was sponsored by Google with its "Summer of Code 2006" project, the (very helpful :) ) mentor was Pawel Jakub Dawidek (pjd). --------------enig7780AB464B2A72DC0BAEE3D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7xMEldnAQVacBcgRAqwVAKD07bWbaT3+r1YYqFFhus/05K3hdwCgv6He kklw+zYkDd3YlhY3KRmOMsI= =JFP2 -----END PGP SIGNATURE----- --------------enig7780AB464B2A72DC0BAEE3D7-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 15:14:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9991516A4DD for ; Fri, 25 Aug 2006 15:14:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81AA243D55 for ; Fri, 25 Aug 2006 15:14:29 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 9BD7FEB0EC1; Fri, 25 Aug 2006 23:14:26 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id fCQY8yP8TeUo; Fri, 25 Aug 2006 23:14:25 +0800 (CST) Received: from [192.168.1.32] (unknown [221.222.204.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 12170EB0909; Fri, 25 Aug 2006 23:14:24 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=edkzM4d5dlek/Rz02SW2h2JgOKfR2RMAjLnVAhBVQGjAV1wC7rQO5bKDIF6MIQeId J6Sq9yZuJIv9+3OiosHmg== Message-ID: <44EF13CA.2070003@delphij.net> Date: Fri, 25 Aug 2006 23:14:18 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "Yuan, Jue" References: <200608252000.07240.yuanjue02@gmail.com> In-Reply-To: <200608252000.07240.yuanjue02@gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig5EDA70A59F901C56798E3931" Cc: freebsd-current@freebsd.org Subject: Re: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 15:14:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EDA70A59F901C56798E3931 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yuan, Jue wrote: > Hi all. >=20 > Could I change the kernel version tag manually? say, I have a kernel wh= ich is=20 > 7.0-CUREENT, but for some reasons I wanna it be something like 6.1-RELE= ASE,=20 > while the kernel itself does't change from 7.0-CURRENT to 6.1-RELEASE. = All I=20 > want is the change of tag. For example, if this works, then when I=20 > type "uname -a" in console, I would get "6.1-RELEASE ..." instead=20 > of "7.0-CURRENT ...". >=20 > I guess some config files in src/sys/ could take care of this. But I ca= nnot=20 > find it out. Anybody knows how to get this job done? >=20 > Any ideas are really appreciated. :-) >=20 > BTW: I am not in this list. So if you reply, please CC a copy to me. Th= anks. Changing the represented release name is not a generally wise idea. You may also want to modify sys/sys/param.h, consult the FreeBSD Porters' Handbook for more details. If you just want to cheat uname(1) and/or sysctl(8), perhaps renaming them to _uname and _sysctl and use some sort of _uname $@ | sed -e s/`_uname -r`/6.1-RELEASE/g trick will do. This also applies to the rc.d motd script, which uses uname(1) to determine the current FreeBSD version. This trick is less intrusive, but have no effect if your application read the version themselves, e.g. the build process of python, etc. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig5EDA70A59F901C56798E3931 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7xPKOfuToMruuMARAzNfAJ9latjmFkDaK8u28GCV/88m1+etPwCeOitk 2Le59Evlpxwx1Au639aLNJA= =ciO7 -----END PGP SIGNATURE----- --------------enig5EDA70A59F901C56798E3931-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 15:14:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05D2A16A4ED; Fri, 25 Aug 2006 15:14:47 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6404A43D49; Fri, 25 Aug 2006 15:14:46 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Fri, 25 Aug 2006 23:14:45 +0800 id 00108800.44EF13E5.0000AA1D References: <20060825084755.GA93151@stud.fit.vutbr.cz> <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> In-Reply-To: <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 23:14:44 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: Problems of New Linuxulator I Have Known X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 15:14:47 -0000 1. Many options of clone(2) are not correctly implemented, some of which may cause application crash when it wants to clone memory-independent process. 2. TLS (Thread Local Storage) support in clone(2), set_thread_area(2) and get_thread_area(2) doesn't conform to Linux 2.6.x, which can damage stack of Linux application using NPTL (Native POSIX Threads Library). Of course, to obtain the conformation, FreeBSD native GDT must be rearranged. But Linux NPTL is quite essential for modern Linux applications. 3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to wake up a single sleeping thread. 4. Some options of clock_gettime(2) actually can be implemented, though FreeBSD native implementation is different from Linux's. 5. Code style problems: member naming of structure, macro naming, function naming, encapsulation for queue(3) and so on. In a word, may ORACLE 10g for Linux be able to run under FreeBSD soon. ------------------------------------------------------------------------ From Beijing, China Alexander Leidinger wrote: > Quoting Divacky Roman (from Fri, 25 Aug 2006 > 10:47:55 +0200): > >> I have some more fixes uncommited which might fix the acroread. > > For the curious: > http://www.leidinger.net/FreeBSD/linuxolator/013_linuxolator_final_uncommi > tted.diff > > Bye, > Alexander. > > -- > In any country there must be people who have to die. They are the > sacrifices any nation has to make to achieve law and order. > -- Idi Amin Dada > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 14:30:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8A2A16A4DF for ; Fri, 25 Aug 2006 14:30:23 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 370E343D70 for ; Fri, 25 Aug 2006 14:30:18 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1139499pye for ; Fri, 25 Aug 2006 07:30:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=UWOvTdVaVySh+ET2l+/0d6B5EH5Hk+t87R6Do2tbV9u3HU58p+VbC7aOD25x46orzHbJC/27L8hakTaJ97ORLPPZpLEutKE9M6eqLr/rLdcozaQAR26nkB/D2jl0FNmYhXJupqSgD6JGlnbBVlJ732NR287Z7GE1ykgFLvV4ZHc= Received: by 10.35.78.13 with SMTP id f13mr5208460pyl; Fri, 25 Aug 2006 07:30:17 -0700 (PDT) Received: from ?222.48.99.94? ( [124.172.191.97]) by mx.gmail.com with ESMTP id w28sm2924317pyc.2006.08.25.07.30.15; Fri, 25 Aug 2006 07:30:17 -0700 (PDT) From: "Yuan, Jue" Organization: Institute of Computing Technology, CAS, China To: Daniel Gerzo Date: Fri, 25 Aug 2006 22:32:37 +0800 User-Agent: KMail/1.9.3 References: <200608252000.07240.yuanjue02@gmail.com> <1792789242.20060825162735@rulez.sk> In-Reply-To: <1792789242.20060825162735@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608252232.37347.yuanjue02@gmail.com> X-Mailman-Approved-At: Fri, 25 Aug 2006 16:30:57 +0000 Cc: freebsd-current@freebsd.org Subject: Re: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 14:30:23 -0000 On Friday 25 August 2006 22:27, Daniel Gerzo wrote: > Hello Jue, > > Friday, August 25, 2006, 2:00:07 PM, you wrote: > > Hi all. > > > > Could I change the kernel version tag manually? say, I have a kernel > > which is 7.0-CUREENT, but for some reasons I wanna it be something like > > 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to > > 6.1-RELEASE. All I want is the change of tag. For example, if this works, > > then when I type "uname -a" in console, I would get "6.1-RELEASE ..." > > instead of "7.0-CURRENT ...". > > > > I guess some config files in src/sys/ could take care of this. But I > > cannot find it out. Anybody knows how to get this job done? > > It's src/sys/conf/newvers.sh > > But I don't think it's a good idea to fake it ;-) > Thanks very much. Someone has told me this just now. And I also have found a better way to deal with my problem. Thanks again. :-) -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 15:18:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA00316A4DE for ; Fri, 25 Aug 2006 15:18:31 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D49743D5C for ; Fri, 25 Aug 2006 15:18:31 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1155853pye for ; Fri, 25 Aug 2006 08:18:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=l3qR9vgemUy4nrjevRoGSXVf+8DSRmUFG6UwKcoNqynAeaSwR6+39Giz76+mRl34j900Hwv887AZOwMnT+i2OaPdUV9cVUc0bdsuVODspFHQp8EgEWd8e2UynyW22vdwpGNM0gsULYIaluZzGpVQp1w9dDWHJlenEfuc0ckUS7I= Received: by 10.35.93.15 with SMTP id v15mr5255816pyl; Fri, 25 Aug 2006 08:18:29 -0700 (PDT) Received: from ?222.48.99.94? ( [124.172.191.97]) by mx.gmail.com with ESMTP id w25sm2980120pyw.2006.08.25.08.18.27; Fri, 25 Aug 2006 08:18:28 -0700 (PDT) From: "Yuan, Jue" Organization: Institute of Computing Technology, CAS, China To: LI Xin Date: Fri, 25 Aug 2006 23:20:50 +0800 User-Agent: KMail/1.9.3 References: <200608252000.07240.yuanjue02@gmail.com> <44EF13CA.2070003@delphij.net> In-Reply-To: <44EF13CA.2070003@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608252320.50363.yuanjue02@gmail.com> X-Mailman-Approved-At: Fri, 25 Aug 2006 16:31:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 15:18:32 -0000 On Friday 25 August 2006 23:14, LI Xin wrote: > Yuan, Jue wrote: > > Hi all. > > > > Could I change the kernel version tag manually? say, I have a kernel > > which is 7.0-CUREENT, but for some reasons I wanna it be something like > > 6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to > > 6.1-RELEASE. All I want is the change of tag. For example, if this works, > > then when I type "uname -a" in console, I would get "6.1-RELEASE ..." > > instead of "7.0-CURRENT ...". > > > > I guess some config files in src/sys/ could take care of this. But I > > cannot find it out. Anybody knows how to get this job done? > > > > Any ideas are really appreciated. :-) > > > > BTW: I am not in this list. So if you reply, please CC a copy to me. > > Thanks. > > Changing the represented release name is not a generally wise idea. You > may also want to modify sys/sys/param.h, consult the FreeBSD Porters' > Handbook for more details. > > If you just want to cheat uname(1) and/or sysctl(8), perhaps renaming > them to _uname and _sysctl and use some sort of _uname $@ | sed -e > s/`_uname -r`/6.1-RELEASE/g trick will do. This also applies to the > rc.d motd script, which uses uname(1) to determine the current FreeBSD > version. This trick is less intrusive, but have no effect if your > application read the version themselves, e.g. the build process of > python, etc. > Thanks for this enlightment. Very helpful :-) -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 17:57:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E42CC16A4DA; Fri, 25 Aug 2006 17:57:17 +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 D9FAA43D70; Fri, 25 Aug 2006 17:57:16 +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 k7PHv7Nc077177; Fri, 25 Aug 2006 13:57:07 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2006 13:05:30 -0400 User-Agent: KMail/1.9.1 References: <200608251031.34081.jhb@freebsd.org> <20060825145632.GY76666@cell.sick.ru> In-Reply-To: <20060825145632.GY76666@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608251305.31259.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]); Fri, 25 Aug 2006 13:57:11 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 01:55:58 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: Ian FREISLICH , Gleb Smirnoff , Andrew Thompson Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 17:57:18 -0000 On Friday 25 August 2006 10:56, Gleb Smirnoff wrote: > On Fri, Aug 25, 2006 at 10:31:33AM -0400, John Baldwin wrote: > J> > I> +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 > J> > I> @@ -646,6 +646,7 @@ > J> > I> # > J> > I> device ether #Generic Ethernet > J> > I> device vlan #VLAN support (needs miibus) > J> > I> +options VLAN_ARRAY #Lookup table for trunk interface > J> > I> device wlan #802.11 support > J> > I> device wlan_wep #802.11 WEP support > J> > I> device wlan_ccmp #802.11 CCMP support > J> > > J> > I'd prefer not to put it into NOTES. When enabled, less code will > J> > be covered by LINT. > J> > J> Bah, GENERIC will cover it then. All options should be in NOTES. If > J> an option removes code and it's enabled in GENERIC, then you should put > J> it in NOTES but comment it out. > > But "device vlan" isn't in GENERIC. Then put the option in and comment it out. NOTES serves 2 purposes: 1 is to provide the basis for LINT, the second is to document the various options and devices. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 18:10:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01E0916A4E0; Fri, 25 Aug 2006 18:10:38 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 522A943D53; Fri, 25 Aug 2006 18:10:36 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7PIAUSn015345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 25 Aug 2006 20:10:30 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7PIAUek015344; Fri, 25 Aug 2006 20:10:30 +0200 (CEST) Date: Fri, 25 Aug 2006 20:10:29 +0200 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20060825181029.GA15247@stud.fit.vutbr.cz> References: <20060825084755.GA93151@stud.fit.vutbr.cz> <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems of New Linuxulator I Have Known X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 18:10:38 -0000 On Fri, Aug 25, 2006 at 11:14:44PM +0800, Intron is my alias on the Internet wrote: > 1. Many options of clone(2) are not correctly implemented, some of > which may cause application crash when it wants to clone > memory-independent process. like? > 2. TLS (Thread Local Storage) support in clone(2), set_thread_area(2) > and get_thread_area(2) doesn't conform to Linux 2.6.x, which can > damage stack of Linux application using NPTL (Native POSIX Threads > Library). > > Of course, to obtain the conformation, FreeBSD native GDT must be > rearranged. But Linux NPTL is quite essential for modern Linux > applications. what do you mean that doesnt conform? TLS in linux is implemented using GDT. the only difference between fbsd and linux I can think of is that linux supports 3 gdt entries while fbsd just one. > 3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to > wake up a single sleeping thread. yes... I agree > 4. Some options of clock_gettime(2) actually can be implemented, though > FreeBSD native implementation is different from Linux's. I might look at it > 5. Code style problems: member naming of structure, macro naming, > function naming, encapsulation for queue(3) and so on. in my code or in the imported code? > In a word, may ORACLE 10g for Linux be able to run under FreeBSD soon. nice :) From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 19:00:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94C9116A511 for ; Fri, 25 Aug 2006 19:00:36 +0000 (UTC) (envelope-from prvs=julian=38535a252@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DE543D8D for ; Fri, 25 Aug 2006 18:59:47 +0000 (GMT) (envelope-from prvs=julian=38535a252@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.50]) by a50.ironport.com with ESMTP; 25 Aug 2006 11:59:46 -0700 Message-ID: <44EF48A2.3020600@elischer.org> Date: Fri, 25 Aug 2006 11:59:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yuan, Jue" References: <200608252000.07240.yuanjue02@gmail.com> <44EF13CA.2070003@delphij.net> <200608252320.50363.yuanjue02@gmail.com> In-Reply-To: <200608252320.50363.yuanjue02@gmail.com> Content-Type: text/plain; charset=x-gbk; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: How to change kernel version? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 19:00:36 -0000 Yuan, Jue wrote: >On Friday 25 August 2006 23:14, LI Xin wrote: > > >>Yuan, Jue wrote: >> >> >>>Hi all. >>> >>>Could I change the kernel version tag manually? say, I have a kernel >>>which is 7.0-CUREENT, but for some reasons I wanna it be something like >>>6.1-RELEASE, while the kernel itself does't change from 7.0-CURRENT to >>>6.1-RELEASE. All I want is the change of tag. For example, if this works, >>>then when I type "uname -a" in console, I would get "6.1-RELEASE ..." >>>instead of "7.0-CURRENT ...". >>> >>>I guess some config files in src/sys/ could take care of this. But I >>>cannot find it out. Anybody knows how to get this job done? >>> >>>Any ideas are really appreciated. :-) >>> >>>BTW: I am not in this list. So if you reply, please CC a copy to me. >>>Thanks. >>> >>> >>Changing the represented release name is not a generally wise idea. You >>may also want to modify sys/sys/param.h, consult the FreeBSD Porters' >>Handbook for more details. >> >>If you just want to cheat uname(1) and/or sysctl(8), perhaps renaming >>them to _uname and _sysctl and use some sort of _uname $@ | sed -e >>s/`_uname -r`/6.1-RELEASE/g trick will do. This also applies to the >>rc.d motd script, which uses uname(1) to determine the current FreeBSD >>version. This trick is less intrusive, but have no effect if your >>application read the version themselves, e.g. the build process of >>python, etc. >> >> >> >Thanks for this enlightment. Very helpful :-) > > ENVIRONMENT An environment variable composed of the string UNAME_ followed by any flag to the uname utility (except for -a) will allow the corresponding data to be set to the contents of the environment variable. From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 19:17:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46A9916A4DA; Fri, 25 Aug 2006 19:17:35 +0000 (UTC) (envelope-from prvs=julian=38535a252@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E137243D49; Fri, 25 Aug 2006 19:17:34 +0000 (GMT) (envelope-from prvs=julian=38535a252@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.50]) by a50.ironport.com with ESMTP; 25 Aug 2006 12:17:29 -0700 Message-ID: <44EF4CC9.7020909@elischer.org> Date: Fri, 25 Aug 2006 12:17:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200608181445.k7IEjA9f020038@lurza.secnetix.de> <200608251003.28528.jhb@freebsd.org> In-Reply-To: <200608251003.28528.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: suggested addition to 'date' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 19:17:35 -0000 John Baldwin wrote: >On Friday 18 August 2006 10:45, Oliver Fromme wrote: > > >>Julian Elischer wrote: >> > BTW I chose 's' without any research.. Date only has the short getopt so >> > '--' doesn't work, but >> > there are lots of unsed letters.. a quick survey suggests maybe -p (pipe?) >> > (suggestions welcome) my favourites of s and f are already used on one >> > system or another. >> >>There's another possibility, which doesn't require a new >>option letter at all. You could add a new escape sequence >>to the format string, e.g. "%*". Whenever date(1) is >>called with a format string containing that sequence, it >>goes into filter mode and replaces the sequence with the >>current line. That would also enable you to be more >>flexible with the placement of the timestamps. >>For example: >> >>$ printf 'foo\nbar\nbaz\n' | date +'%H:%M:%S %*' >>16:39:58 foo >>16:39:58 bar >>16:39:58 baz >> >> > >I prefer this of all the suggestions so far. > > The trouble wih this is that the format string is interpretted by strftime() and not by date, so you would have to pre-parse the string which would be quite a bit of work. The size of the patch wold blow out from the current 20 lines (or less) to many more. From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 22:00:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1AE16A4DD for ; Fri, 25 Aug 2006 22:00:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F5F5441DF for ; Fri, 25 Aug 2006 22:00:40 +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 mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k7PM0bkk027034 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Aug 2006 08:00:38 +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 k7PM0b74017053; Sat, 26 Aug 2006 08:00:37 +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 k7PM0Yl4017052; Sat, 26 Aug 2006 08:00:34 +1000 (EST) (envelope-from peter) Date: Sat, 26 Aug 2006 08:00:33 +1000 From: Peter Jeremy To: Brooks Davis Message-ID: <20060825220033.GC16768@turion.vk2pj.dyndns.org> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <20060823205523.GB27961@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s9fJI615cBHmzTOP" Content-Disposition: inline In-Reply-To: <20060823205523.GB27961@lor.one-eyed-alien.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 22:00:42 -0000 --s9fJI615cBHmzTOP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Aug-23 15:55:23 -0500, Brooks Davis wrote: > Having authentication functions outside the base makes them >more vulnerable to configuration problems and general library cross >threading. Can you explain what you mean here. Having a single OpenLDAP, nss_ldap etc in ports would seem to have less scope for misconfiguration than having one version in the base system and a slightly different version in ports. There are already a number of authentication modules in ports that don't seem to cause serious problems. > It also means they can't work out of the box. I disagree. X11 and perl are both ports that work out-of-the-box. There's no reason why OpenLDAP can't be a port on CD1 - which makes it fairly transparent to users. > I think the >costs are likely fairly small (no worse than those associated with >OpenSSL) and the benefits are substantial. As one of the majority who don't need LDAP authentication, I don't see any benefits to me. IMHO, FreeBSD should move towards a more modular system - a minimal base with most of the functionality in optional packages (or ports). Removing uucp, games and perl are steps in this direction. I believe there should be a very high bar on the import of functionality that is already available in ports. All the above said, I agree that if OpenLDAP is imported, it should be built by default. --=20 Peter Jeremy --s9fJI615cBHmzTOP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE73MB/opHv/APuIcRAoRQAJ4hJH6zxbOxfMg3UAuqHhQPNGH0HQCgkFta Pc3cMaMCGwiJETw2baEts2A= =xCFx -----END PGP SIGNATURE----- --s9fJI615cBHmzTOP-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 22:52:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A4CE16A5A6 for ; Fri, 25 Aug 2006 22:52:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 289084423A for ; Fri, 25 Aug 2006 22:27:47 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060825222745m92002shdre>; Fri, 25 Aug 2006 22:27:45 +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 k7PMRbBB051796; Fri, 25 Aug 2006 17:27:39 -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 k7PMRXsB051795; Fri, 25 Aug 2006 17:27:33 -0500 (CDT) (envelope-from brooks) Date: Fri, 25 Aug 2006 17:27:32 -0500 From: Brooks Davis To: Peter Jeremy Message-ID: <20060825222732.GA51559@lor.one-eyed-alien.net> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <20060823205523.GB27961@lor.one-eyed-alien.net> <20060825220033.GC16768@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20060825220033.GC16768@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 22:52:14 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 26, 2006 at 08:00:33AM +1000, Peter Jeremy wrote: > On Wed, 2006-Aug-23 15:55:23 -0500, Brooks Davis wrote: > > Having authentication functions outside the base makes them > >more vulnerable to configuration problems and general library cross > >threading. >=20 > Can you explain what you mean here. Having a single OpenLDAP, > nss_ldap etc in ports would seem to have less scope for > misconfiguration than having one version in the base system and a > slightly different version in ports. >=20 > There are already a number of authentication modules in ports > that don't seem to cause serious problems. If it's in the base you always know exactly what version is there and we generally limit the number of build options available so it's fairly easy to be sure you've built a set of things that actually work. There's also no supported way to upgrade your libraries out from under a dependency piece as happens fairly regularly in ports (yes there are ways to avoid it, but we're talking about your login system here. Breaking that is really bad). > > It also means they can't work out of the box. >=20 > I disagree. X11 and perl are both ports that work out-of-the-box. > There's no reason why OpenLDAP can't be a port on CD1 - which makes > it fairly transparent to users. I think authentication and authorization is in a different class of things from X and perl, but the line is certainly blurry. > > I think the > >costs are likely fairly small (no worse than those associated with > >OpenSSL) and the benefits are substantial. >=20 > As one of the majority who don't need LDAP authentication, I don't > see any benefits to me. > > IMHO, FreeBSD should move towards a more modular system - a minimal > base with most of the functionality in optional packages (or ports). > Removing uucp, games and perl are steps in this direction. I believe > there should be a very high bar on the import of functionality that > is already available in ports. I'm fairly confident that less than 1% of user use anything close to half the programs in the base system, but we still ship all of them because they are part of a complete system. I think that LDAP auth has moved (or is moving) into the category of things that should be in that complete system and that we would benefit from tighter integration than the ports collection can give us. There are also undoubtedly things in the base that longer contribute sufficiently to that system. I think there's room for more modularity, but I'd prefer not to rip out everything you could conceivable get from ports. -- Brooks --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE73lTXY6L6fI4GtQRAqc7AKCk+yiGsGgKkSxrtWm7dzMLZ+VNVwCfQllS Ntn64gHod8HqWK0j3W08aW0= =Wlid -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 25 23:22:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D52C16A4DE for ; Fri, 25 Aug 2006 23:22:15 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D00C43D45 for ; Fri, 25 Aug 2006 23:22:14 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from bofh.straycat.dhs.org (bofh.straycat.dhs.org [192.168.2.68]) by straycat.dhs.org (8.13.4/8.13.4) with ESMTP id k7PNMCAx013508; Fri, 25 Aug 2006 19:22:12 -0400 (EDT) From: Tom McLaughlin To: Michael Bushkov In-Reply-To: <002001c6c80d$cedcba60$9800a8c0@carrera> References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> <20060823144347.GB24652@lor.one-eyed-alien.net> <1156464193.1394.14.camel@localhost> <002001c6c80d$cedcba60$9800a8c0@carrera> Content-Type: text/plain Date: Fri, 25 Aug 2006 19:21:17 -0400 Message-Id: <1156548077.1119.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch andmore (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 23:22:15 -0000 On Fri, 2006-08-25 at 10:14 +0400, Michael Bushkov wrote: > Tom McLaughlin wrote: > > Will it also be possible to build openldap in base with SASL support? > > My understanding is Windows AD environments by default require all > > connections to be authenticated via kerberos. (It's also a requirement > > for the samba+openldap+krb5 setup I'm doing for work. ;) I saw a > > comment about adding support for krb5_ccname in the config file. That's > > a very useful option in the PADL version so I'm guessing this was > > written with supporting SASL in mind? Thanks. > > > > tom > > Hi, > sasl in OpenLDAP (and in nss_ldap) is supported in the way similar to > Sendmail: > CFLAGS+= ${OPENLDAP_CFLAGS} > LDFLAGS+= ${OPENLDAP_LDFLAGS} > LDADD+= ${OPENLDAP_LDADD} > > By defining, > OPENLDAP_CFLAGS=-I/usr/local/include -DSASL > OPENLDAP_LDFLAGS=-L/usr/local/lib > OPENLDAP_LDADD=-lsasl > you'll enable sasl support both for OpenLDAP and nss_ldap. > > > BTW, I'll be able to implement and properly test krb5-ccname during the > beginning of September. > > With best regards, > Michael Bushkov Sweet! Thanks a bunch for keeping this in mind and the good job. I can now stop fretting about this on IRC. :) tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | | BSD# http://www.mono-project.com/Mono:FreeBSD | From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 00:49:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59DFA16A4E1 for ; Sat, 26 Aug 2006 00:49:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F52643D4C for ; Sat, 26 Aug 2006 00:49:04 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1322657pye for ; Fri, 25 Aug 2006 17:49:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=OLPjVouk5iVn1RGr/h40aGzJsbr3TplvbhS4Cp7kyhLXDn+tfa3QgcSLvy9xkscpe+6+D+5CD18H7bTTWqYwqt7E1dcogkVej2NIh8x60hwnhIeaDOejBdWF4ep1Q1uk3jOuZwTRRGDa1hxPBndCxUeNUA9+3DshwHrwUr4DJLQ= Received: by 10.35.61.14 with SMTP id o14mr6264354pyk; Fri, 25 Aug 2006 17:49:03 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 16sm217818nzo.2006.08.25.17.49.02; Fri, 25 Aug 2006 17:49:03 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7Q0nbVc031505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Aug 2006 09:49:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7Q0nacq031504; Sat, 26 Aug 2006 09:49:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 26 Aug 2006 09:49:36 +0900 From: Pyun YongHyeon To: John Baldwin Message-ID: <20060826004936.GA31324@cdnetworks.co.kr> References: <20060819211853.GA1016@tin.it> <200608251012.42642.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608251012.42642.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 30 when loading if_xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 00:49:05 -0000 On Fri, Aug 25, 2006 at 10:12:42AM -0400, John Baldwin wrote: > On Saturday 19 August 2006 17:18, Paolo Pisati wrote: > > Today's CURRENT panic my box everytime i load > > if_xl: > > > > [flag@newluxor NEWLUXOR]$ sudo kgdb kernel.debug /var/crash/vmcore.0 > > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-marcel-freebsd". > > 30 (unknown trap) can mean that you got a device interrupt to an IDT > entry you haven't installed a handler for yet. If you want to figure > out exactly which IDT entry, you'll need to install a unique custom > dummy handler in each IDT entry so you can tell which one fired. > After bring up to date CURRENT I see this panic too while loading if_em which used to work flawlessly. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 02:07:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8304F16A4DE; Sat, 26 Aug 2006 02:07:20 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87FD243D45; Sat, 26 Aug 2006 02:07:19 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Sat, 26 Aug 2006 10:07:18 +0800 id 00108800.44EFACD6.0000C97F References: <20060825084755.GA93151@stud.fit.vutbr.cz> <200608251028.55915.jhb@freebsd.org> In-Reply-To: <200608251028.55915.jhb@freebsd.org> From: "Intron is my alias on the Internet" To: John Baldwin Date: Sat, 26 Aug 2006 10:07:17 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 02:07:20 -0000 John Baldwin wrote: > On Friday 25 August 2006 04:47, Divacky Roman wrote: > > Umm, if you want to reparent a proc you should use the proc_reparent() > function instead of just hacking on p_pptr. You also need to hold > the proctree_lock when modifying p_pptr anyway. > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Thank you for your reminder. I have updated my patch: http://ftp.intron.ac/tmp/linux_machdep.c.1.53-2.diff ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 03:16:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22F8516A4DA; Sat, 26 Aug 2006 03:16:26 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D571243D46; Sat, 26 Aug 2006 03:16:24 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Sat, 26 Aug 2006 11:16:23 +0800 id 00108801.44EFBD07.0000CCD4 References: <20060825084755.GA93151@stud.fit.vutbr.cz> <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> <20060825181029.GA15247@stud.fit.vutbr.cz> In-Reply-To: <20060825181029.GA15247@stud.fit.vutbr.cz> From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Date: Sat, 26 Aug 2006 11:16:23 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: Re: Problems of New Linuxulator I Have Known X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 03:16:26 -0000 Divacky Roman wrote: > On Fri, Aug 25, 2006 at 11:14:44PM +0800, Intron is my alias on the Internet wrote: >> 1. Many options of clone(2) are not correctly implemented, some of >> which may cause application crash when it wants to clone >> memory-independent process. > > like? CLONE_FS CLONE_STOPPED CLONE_VFORK CLONE_SYSVSEM Implementation of CLONE_PTRACE and CLONE_UNTRACED can be delayed, though they are useful, too. > >> 2. TLS (Thread Local Storage) support in clone(2), set_thread_area(2) >> and get_thread_area(2) doesn't conform to Linux 2.6.x, which can >> damage stack of Linux application using NPTL (Native POSIX Threads >> Library). >> >> Of course, to obtain the conformation, FreeBSD native GDT must be >> rearranged. But Linux NPTL is quite essential for modern Linux >> applications. > > what do you mean that doesnt conform? TLS in linux is implemented using > GDT. the only difference between fbsd and linux I can think of is that > linux supports 3 gdt entries while fbsd just one. > Linux hardcodes TLS entry number ranging from 6 to 8 for i386, or from 12 to 14 for amd64. But FreeBSD allows only entry number 3. I'm afraid Linux application checks entry number by macros GDT_ENTRY_TLS_MIN and GDT_ENTRY_TLS_MAX to judge whether the calling is successful. In GNU/Linux distribution, these two macros are defined in /usr/include/asm/segment.h, and in Linux kernel source the file is linux-2.6.17.11/include/asm-i386/segment.h or linux-2.6.17.11/include/asm-x86_64/segment.h >> 3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to >> wake up a single sleeping thread. > > yes... I agree > >> 4. Some options of clock_gettime(2) actually can be implemented, though >> FreeBSD native implementation is different from Linux's. > > I might look at it > >> 5. Code style problems: member naming of structure, macro naming, >> function naming, encapsulation for queue(3) and so on. > > in my code or in the imported code? Most of them are in NetBSD code. > >> In a word, may ORACLE 10g for Linux be able to run under FreeBSD soon. > > nice :) So far, Linuxulator is quite undependable. Kernel panic arises from time to time. In this case, shaky running of ORACLE 10g is meaningless. We have to continue our effects. Can you publicize your testing programs for those Linux system calls? ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 04:52:18 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2867216A4DA; Sat, 26 Aug 2006 04:52:18 +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 8B48143D46; Sat, 26 Aug 2006 04:52:17 +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 1EAF646C3B; Sat, 26 Aug 2006 00:52:17 -0400 (EDT) Date: Sat, 26 Aug 2006 05:52:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20060825145632.GY76666@cell.sick.ru> Message-ID: <20060826055028.A43127@fledge.watson.org> References: <20060825101140.GV76666@FreeBSD.org> <200608251031.34081.jhb@freebsd.org> <20060825145632.GY76666@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ian FREISLICH , freebsd-current@FreeBSD.org, Andrew Thompson , John Baldwin Subject: Re: 802.1Q vlan performance. [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 04:52:18 -0000 On Fri, 25 Aug 2006, Gleb Smirnoff wrote: > On Fri, Aug 25, 2006 at 10:31:33AM -0400, John Baldwin wrote: > J> > I> +++ /usr/src/sys/conf/NOTES 25 Aug 2006 10:03:18 -0000 > J> > I> @@ -646,6 +646,7 @@ > J> > I> # > J> > I> device ether #Generic Ethernet > J> > I> device vlan #VLAN support (needs miibus) > J> > I> +options VLAN_ARRAY #Lookup table for trunk interface > J> > I> device wlan #802.11 support > J> > I> device wlan_wep #802.11 WEP support > J> > I> device wlan_ccmp #802.11 CCMP support > J> > > J> > I'd prefer not to put it into NOTES. When enabled, less code will > J> > be covered by LINT. > J> > J> Bah, GENERIC will cover it then. All options should be in NOTES. If > J> an option removes code and it's enabled in GENERIC, then you should put > J> it in NOTES but comment it out. > > But "device vlan" isn't in GENERIC. Only for historical reasons -- at the recent devsummit, I argued that if_vlan should, in fact, be part of our generic ethernet support code, as vlans have become an expected ethernet link layer feature. I also argued that tigher integration of vlan support into ethernet would help avoid some of the trickier issues in keeping vlan interfaces synchronized to the set of ethernet interfaces, as well as avoiding the mbuf tag overhead, etc. I have some hope of looking into this once if_startmbuf is off the ground. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 05:00:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2054B16A4E0 for ; Sat, 26 Aug 2006 05:00:03 +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 1B35543D4C for ; Sat, 26 Aug 2006 05:00:03 +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 5A24946D01; Sat, 26 Aug 2006 01:00:02 -0400 (EDT) Date: Sat, 26 Aug 2006 06:00:02 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20060825220033.GC16768@turion.vk2pj.dyndns.org> Message-ID: <20060826055402.W43127@fledge.watson.org> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <20060823205523.GB27961@lor.one-eyed-alien.net> <20060825220033.GC16768@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Michael Bushkov Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 05:00:04 -0000 On Sat, 26 Aug 2006, Peter Jeremy wrote: > IMHO, FreeBSD should move towards a more modular system - a minimal base > with most of the functionality in optional packages (or ports). Removing > uucp, games and perl are steps in this direction. I believe there should be > a very high bar on the import of functionality that is already available in > ports. One of the strongest historical arguments for using *BSD as the base for development of an embedded/appliance-style system has been that this is precisely what FreeBSD is not: by keeping a useful base set of applications in revision control, tested together, and integrated together, we provide an excellent starting point for building network appliances, storage appliances, ISP systems, etc. It's when you start having to deal with big piles of applications that aren't tested together, managed in a single revision control tree, and so on, that maintainability and complexity become problems for these users. I can tell you that if we ripped out BIND, sendmail, and a dozen other highly useful base system components out into ports, I would be using another system, because it is precisely this integration that makes FreeBSD most useful as a starting point :-). This isn't an argument for endless growth (or even significant growth) of the base system, rather, an argument for not abandoning integrated revision control and building of the current system. Sure, we can make the build-time construction of the system modular in a cleaner and more comprehensive way, and provide better binary delivery mechanisms that offer more of the build-time flexibility we already have to the end-user. But an argument to dismember the current system is a non-starter. If I wanted to try to build a complete and integrated system from scratch, without any guarantees that the versions of the components had been tested together, without an integrated build system, etc, I could always use one of a thousand Linux distributions. A self-standing buildworld out of a single CVS checkout is one of our greatest strengths. (I realize that you weren't arguing for that end goal exactly, but I want to make sure that if we embark on the further modularization approach, we do so with an understanding that it needs to be an improvement on what we have, not an elimination of one of our most important features!) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 07:27:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AB5C16A4DD; Sat, 26 Aug 2006 07:27:20 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BABE43D45; Sat, 26 Aug 2006 07:27:18 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7Q7RCoL055366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Aug 2006 09:27:12 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7Q7R9Eh055363; Sat, 26 Aug 2006 09:27:09 +0200 (CEST) Date: Sat, 26 Aug 2006 09:27:09 +0200 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20060826072709.GA55105@stud.fit.vutbr.cz> References: <20060825084755.GA93151@stud.fit.vutbr.cz> <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> <20060825181029.GA15247@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems of New Linuxulator I Have Known X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 07:27:20 -0000 On Sat, Aug 26, 2006 at 11:16:23AM +0800, Intron is my alias on the Internet wrote: > Divacky Roman wrote: > > >On Fri, Aug 25, 2006 at 11:14:44PM +0800, Intron is my alias on the > >Internet wrote: > >>1. Many options of clone(2) are not correctly implemented, some of > >> which may cause application crash when it wants to clone > >> memory-independent process. > > > >like? > > CLONE_FS this one is only for kernel threads. I doubt we will ever support linux kernel threads :) > CLONE_STOPPED this should be very easy to add, I didnt see any use of that so I didnt implement that so far, but it should be very easy > CLONE_VFORK I tend to believe this is used only for vfork() implementation but if not this is also quite trivial to implement (take a look at my linux_vfork() implementation) > CLONE_SYSVSEM this might be a bit trickier because I know nothing about sysvsem, but judging from the code its not a big thing > Implementation of CLONE_PTRACE and CLONE_UNTRACED can be delayed, > though they are useful, too. I am getting panics when trying to use linux-strace, this is worth investigating > > > >>2. TLS (Thread Local Storage) support in clone(2), set_thread_area(2) > >> and get_thread_area(2) doesn't conform to Linux 2.6.x, which can > >> damage stack of Linux application using NPTL (Native POSIX Threads > >> Library). > >> > >> Of course, to obtain the conformation, FreeBSD native GDT must be > >> rearranged. But Linux NPTL is quite essential for modern Linux > >> applications. > > > >what do you mean that doesnt conform? TLS in linux is implemented using > >GDT. the only difference between fbsd and linux I can think of is that > >linux supports 3 gdt entries while fbsd just one. > > > > Linux hardcodes TLS entry number ranging from 6 to 8 for i386, or from > 12 to 14 for amd64. But FreeBSD allows only entry number 3. I'm afraid > Linux application checks entry number by macros GDT_ENTRY_TLS_MIN and > GDT_ENTRY_TLS_MAX to judge whether the calling is successful. > In GNU/Linux distribution, these two macros are defined in > /usr/include/asm/segment.h, and in Linux kernel source the file is > linux-2.6.17.11/include/asm-i386/segment.h or > linux-2.6.17.11/include/asm-x86_64/segment.h I've never seen an app that would check this. Also this thing should be setup by threading library and we can easily check it there. I dont think this is a real problem. The glibc doesnt check this (it just uses whatever we supply it) and there should be no other user. > >>3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to > >> wake up a single sleeping thread. > > > >yes... I agree I plan to do this once everything else is resolved because I really want to shrink the gap between my p4/uncommited linuxolator and what is in src. > >>5. Code style problems: member naming of structure, macro naming, > >> function naming, encapsulation for queue(3) and so on. > > > >in my code or in the imported code? > > Most of them are in NetBSD code. this is imported code and we want it to stay the same to easy possible future imports. if you found something bad in my code pls tell me (I'd prefer icq) > So far, Linuxulator is quite undependable. Kernel panic arises from time > to time. In this case, shaky running of ORACLE 10g is meaningless. > We have to continue our effects. pls, can you share the panics with me? > Can you publicize your testing programs for those Linux system calls? I am sure this is of your interest: www.stud.fit.vutbr.cz/~xdivac02/futex.c we dont pass this even with your patches thnx for your work! roman From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 08:04:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D53AE16A4DA; Sat, 26 Aug 2006 08:04:17 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0020B43D46; Sat, 26 Aug 2006 08:04:16 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7Q84BTg056787 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Aug 2006 10:04:11 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7Q84BpL056786; Sat, 26 Aug 2006 10:04:11 +0200 (CEST) Date: Sat, 26 Aug 2006 10:04:11 +0200 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20060826080410.GA56721@stud.fit.vutbr.cz> References: <20060825084755.GA93151@stud.fit.vutbr.cz> <200608251028.55915.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 08:04:18 -0000 On Sat, Aug 26, 2006 at 10:07:17AM +0800, Intron is my alias on the Internet wrote: > John Baldwin wrote: > > >On Friday 25 August 2006 04:47, Divacky Roman wrote: > > > >Umm, if you want to reparent a proc you should use the proc_reparent() > >function instead of just hacking on p_pptr. You also need to hold > >the proctree_lock when modifying p_pptr anyway. > > > >-- > >John Baldwin > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Thank you for your reminder. I have updated my patch: > > http://ftp.intron.ac/tmp/linux_machdep.c.1.53-2.diff this is wrong 1) you dont PROC_LOCK(p2) 2) you have to lock proctree_lock instead of allproc_lock are you satisfied with this patch? www.stud.fit.vutbr.cz/~xdivac02/linux-fix.patch From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 08:25:04 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 790A116A4DA; Sat, 26 Aug 2006 08:25:04 +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 B5E3F43D45; Sat, 26 Aug 2006 08:25:03 +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 3C83846D3E; Sat, 26 Aug 2006 04:25:03 -0400 (EDT) Date: Sat, 26 Aug 2006 09:25:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-current@FreeBSD.org Message-ID: <20060826092027.C54235@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org Subject: HEADS UP: TrustedBSD OpenBSM 1.0 alpha 9 imported X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 08:25:04 -0000 I've imported the most recent release of OpenBSM, which includes a renumbering of audit events and a chance in the BSM version. Old audit trail files will be readable by the new implementation, but older /etc/security/audit_event files are not able to translate the new event numbers to strings (etc). Make sure to run mergemaster if using audit. These changes are to avoid potential future event number conflicts with Solaris, and to assign our implementation a unique version number so it can be distinguished from existing Solaris and Darwin versions. OpenBSM is now about at the point where it's ready for import into the RELENG_6 tree, which I hope to do in the next couple of days in preparation for inclusion in FreeBSD 6.2. (Post import builds are now running locally to confirm it all committed properly.) Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 26 Aug 2006 08:04:17 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/contrib/openbsm - Imported sources rwatson 2006-08-26 08:04:17 UTC FreeBSD src repository src/contrib/openbsm - Imported sources Update of /home/ncvs/src/contrib/openbsm In directory repoman.freebsd.org:/tmp/cvs-serv19917 Log Message: Vendor import of OpenBSM 1.0 alpha 9, with the following change history notes since the last import: OpenBSM 1.0 alpha 9 - Rename many OpenBSM-specific constants and API elements containing the strings "BSM" and "bsm" to "AUDIT" and "audit", observing that this is true for almost all existing constants and APIs. - Instead of passing a per-instance cookie directly into all audit filter APIs, pass in the audit filter daemon state pointer, which is then used by the module using an audit_filter_{get,set}cookie() API. This will allow future service APIs provided by the filter daemon to maintain their own state -- for example, per-module preselection state. OpenBSM 1.0 alpha 8 - Correct typo in definition of AUR_INT. - Adopt OpenSolaris constant values for AUDIT_* configuration flags. - Arguments to au_to_exec_args() and au_to_exec_env() no longer const. - Add kernel versions of au_to_exec_args() and au_to_exec_env(). - Fix exec argument type that is printed for env strings from 'arg' to 'env'. - New OpenBSM token version number assigned, constants added for other commonly seen version numbers. - OpenBSM-specific events assigned numbers in the 43xxx range to avoid future collisions with Solaris. Darwin events renamed to AUE_DARWIN_foo, as they are now deprecated numberings. - autoconf now detects clock_gettime(), which is not available on Darwin. - praudit output fixes relating to arg32 and arg64 tokens. - Maximum record size updated to 64k-1 to match Solaris record size limit. - Various style and comment cleanups in include files. This is an MFC candidate to RELENG_6. Obtained from: TrustedBSD Project Status: Vendor Tag: TrustedBSD Release Tags: OPENBSM_1_0_ALPHA_9 U src/contrib/openbsm/HISTORY U src/contrib/openbsm/LICENSE U src/contrib/openbsm/Makefile.am U src/contrib/openbsm/Makefile.in U src/contrib/openbsm/README U src/contrib/openbsm/TODO U src/contrib/openbsm/VERSION U src/contrib/openbsm/aclocal.m4 U src/contrib/openbsm/autogen.sh U src/contrib/openbsm/configure U src/contrib/openbsm/configure.ac U src/contrib/openbsm/bin/Makefile.am U src/contrib/openbsm/bin/Makefile.in U src/contrib/openbsm/bin/audit/Makefile.am U src/contrib/openbsm/bin/audit/Makefile.in U src/contrib/openbsm/bin/audit/audit.8 U src/contrib/openbsm/bin/audit/audit.c U src/contrib/openbsm/bin/auditd/Makefile.am U src/contrib/openbsm/bin/auditd/Makefile.in U src/contrib/openbsm/bin/auditd/audit_warn.c U src/contrib/openbsm/bin/auditd/auditd.8 U src/contrib/openbsm/bin/auditd/auditd.c U src/contrib/openbsm/bin/auditd/auditd.h U src/contrib/openbsm/bin/auditfilterd/Makefile.am U src/contrib/openbsm/bin/auditfilterd/Makefile.in U src/contrib/openbsm/bin/auditfilterd/auditfilterd.8 U src/contrib/openbsm/bin/auditfilterd/auditfilterd.c U src/contrib/openbsm/bin/auditfilterd/auditfilterd.h U src/contrib/openbsm/bin/auditfilterd/auditfilterd_conf.c U src/contrib/openbsm/bin/auditreduce/Makefile.am U src/contrib/openbsm/bin/auditreduce/Makefile.in U src/contrib/openbsm/bin/auditreduce/auditreduce.1 U src/contrib/openbsm/bin/auditreduce/auditreduce.c U src/contrib/openbsm/bin/auditreduce/auditreduce.h U src/contrib/openbsm/bin/praudit/Makefile.am U src/contrib/openbsm/bin/praudit/Makefile.in U src/contrib/openbsm/bin/praudit/praudit.1 U src/contrib/openbsm/bin/praudit/praudit.c U src/contrib/openbsm/bsm/Makefile.am U src/contrib/openbsm/bsm/Makefile.in U src/contrib/openbsm/bsm/audit.h U src/contrib/openbsm/bsm/audit_filter.h U src/contrib/openbsm/bsm/audit_internal.h U src/contrib/openbsm/bsm/audit_kevents.h U src/contrib/openbsm/bsm/audit_record.h U src/contrib/openbsm/bsm/audit_uevents.h U src/contrib/openbsm/bsm/libbsm.h U src/contrib/openbsm/compat/endian.h U src/contrib/openbsm/compat/queue.h U src/contrib/openbsm/config/config.guess U src/contrib/openbsm/config/config.h.in U src/contrib/openbsm/config/config.sub U src/contrib/openbsm/config/depcomp U src/contrib/openbsm/config/install-sh U src/contrib/openbsm/config/ltmain.sh U src/contrib/openbsm/config/missing U src/contrib/openbsm/etc/audit_class U src/contrib/openbsm/etc/audit_control C src/contrib/openbsm/etc/audit_event U src/contrib/openbsm/etc/audit_filter U src/contrib/openbsm/etc/audit_user U src/contrib/openbsm/etc/audit_warn U src/contrib/openbsm/libbsm/Makefile.am U src/contrib/openbsm/libbsm/Makefile.in U src/contrib/openbsm/libbsm/au_class.3 U src/contrib/openbsm/libbsm/au_control.3 U src/contrib/openbsm/libbsm/au_event.3 U src/contrib/openbsm/libbsm/au_free_token.3 U src/contrib/openbsm/libbsm/au_io.3 U src/contrib/openbsm/libbsm/au_mask.3 U src/contrib/openbsm/libbsm/au_open.3 U src/contrib/openbsm/libbsm/au_token.3 U src/contrib/openbsm/libbsm/au_user.3 U src/contrib/openbsm/libbsm/audit_submit.3 U src/contrib/openbsm/libbsm/bsm_audit.c U src/contrib/openbsm/libbsm/bsm_class.c U src/contrib/openbsm/libbsm/bsm_control.c U src/contrib/openbsm/libbsm/bsm_event.c U src/contrib/openbsm/libbsm/bsm_flags.c U src/contrib/openbsm/libbsm/bsm_io.c U src/contrib/openbsm/libbsm/bsm_mask.c U src/contrib/openbsm/libbsm/bsm_notify.c U src/contrib/openbsm/libbsm/bsm_token.c U src/contrib/openbsm/libbsm/bsm_user.c U src/contrib/openbsm/libbsm/libbsm.3 U src/contrib/openbsm/libbsm/bsm_wrappers.c U src/contrib/openbsm/man/Makefile.am U src/contrib/openbsm/man/Makefile.in U src/contrib/openbsm/man/audit.2 U src/contrib/openbsm/man/audit.log.5 U src/contrib/openbsm/man/audit_class.5 U src/contrib/openbsm/man/audit_control.5 U src/contrib/openbsm/man/audit_event.5 U src/contrib/openbsm/man/audit_user.5 U src/contrib/openbsm/man/audit_warn.5 U src/contrib/openbsm/man/auditctl.2 U src/contrib/openbsm/man/auditon.2 U src/contrib/openbsm/man/getaudit.2 U src/contrib/openbsm/man/getauid.2 U src/contrib/openbsm/man/setaudit.2 U src/contrib/openbsm/man/setauid.2 U src/contrib/openbsm/modules/Makefile.am U src/contrib/openbsm/modules/Makefile.in U src/contrib/openbsm/modules/auditfilter_noop/Makefile.am U src/contrib/openbsm/modules/auditfilter_noop/Makefile.in U src/contrib/openbsm/modules/auditfilter_noop/auditfilter_noop.c U src/contrib/openbsm/test/Makefile.am U src/contrib/openbsm/test/Makefile.in U src/contrib/openbsm/test/bsm/Makefile.am U src/contrib/openbsm/test/bsm/Makefile.in U src/contrib/openbsm/test/bsm/generate.c U src/contrib/openbsm/tools/Makefile.am U src/contrib/openbsm/tools/Makefile.in U src/contrib/openbsm/tools/audump.c 1 conflicts created by this import. Use the following command to help the merge: cvs checkout -jTrustedBSD:yesterday -jTrustedBSD src/contrib/openbsm From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 08:37:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9732216A4DA; Sat, 26 Aug 2006 08:37:21 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F66C43D45; Sat, 26 Aug 2006 08:37:20 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Sat, 26 Aug 2006 16:37:19 +0800 id 00108801.44F0083F.0000DC13 References: <20060825084755.GA93151@stud.fit.vutbr.cz> <200608251028.55915.jhb@freebsd.org> <20060826080410.GA56721@stud.fit.vutbr.cz> In-Reply-To: <20060826080410.GA56721@stud.fit.vutbr.cz> From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Date: Sat, 26 Aug 2006 16:37:19 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 08:37:21 -0000 Divacky Roman wrote: > On Sat, Aug 26, 2006 at 10:07:17AM +0800, Intron is my alias on the Internet wrote: >> John Baldwin wrote: >> >> >On Friday 25 August 2006 04:47, Divacky Roman wrote: >> > >> >Umm, if you want to reparent a proc you should use the proc_reparent() >> >function instead of just hacking on p_pptr. You also need to hold >> >the proctree_lock when modifying p_pptr anyway. >> > >> >-- >> >John Baldwin >> >_______________________________________________ >> >freebsd-current@freebsd.org mailing list >> >http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> Thank you for your reminder. I have updated my patch: >> >> http://ftp.intron.ac/tmp/linux_machdep.c.1.53-2.diff > > this is wrong > > 1) you dont PROC_LOCK(p2) > > 2) you have to lock proctree_lock instead of allproc_lock > > are you satisfied with this patch? > > www.stud.fit.vutbr.cz/~xdivac02/linux-fix.patch This problem has confused me for a long time. The lock allproc_lock is more conservative than either p2->p_mtx or proctree_lock. It is the real protector of process tree. Actually, p2 should be protected from its birth to leaving the function linux_clone(). You may commit your patch to test. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 08:56:52 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B9D16A4DD; Sat, 26 Aug 2006 08:56:52 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10AE043D49; Sat, 26 Aug 2006 08:56:51 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k7Q8uofx062889; Sat, 26 Aug 2006 17:56:50 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 26 Aug 2006 17:56:50 +0900 From: Norikatsu Shigemura To: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Message-Id: <20060826175650.c6897fa1.nork@FreeBSD.org> In-Reply-To: <20060820172435.26c4cc2a.nork@FreeBSD.org> References: <20060820172435.26c4cc2a.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__26_Aug_2006_17_56_50_+0900_B3LIhfNEWJ2tmbRO" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sat, 26 Aug 2006 17:56:51 +0900 (JST) Cc: imp@FreeBSD.org Subject: Re: [RFC] prototype of top(1)'s CPU current frequency display X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 08:56:52 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__26_Aug_2006_17_56_50_+0900_B3LIhfNEWJ2tmbRO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 20 Aug 2006 17:24:35 +0900 Norikatsu Shigemura wrote: > 1. assume only 1 CPU. > 2. assume dev.cpu.0.freq is always exists. > 3. display position is good? I modified 1 and 2. Please check attached diff. I couldn't fix 3 issue. So I assumed support max 2CPUs. I confirmed following environments. - - PentiumIII-S dual - - - - - - - - - - - - - dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 - - PentiumIII-S dual - - - - - - - - - - - - - - - Pentium-M Dothan - - - - - - - - - - - - - - dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 - - Pentium-M Dothan - - - - - - - - - - - - - - - - Xeon 2.8GHz - - - - - - - - - - - - - - - - dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2807 dev.cpu.0.freq_levels: 2807/-1 2456/-1 2105/-1 1754/-1 1403/-1 1052/-1 701/-1 350/-1 - - Xeon 2.8GHz - - - - - - - - - - - - - - - - --Multipart=_Sat__26_Aug_2006_17_56_50_+0900_B3LIhfNEWJ2tmbRO Content-Type: text/plain; name="6-stable.usr-bin.top.machine.c.diff" Content-Disposition: attachment; filename="6-stable.usr-bin.top.machine.c.diff" Content-Transfer-Encoding: 7bit Index: machine.c =================================================================== RCS file: /home/ncvs/src/usr.bin/top/machine.c,v retrieving revision 1.74 diff -u -r1.74 machine.c --- machine.c 18 May 2005 13:42:51 -0000 1.74 +++ machine.c 26 Aug 2006 08:41:50 -0000 @@ -61,6 +61,8 @@ extern char* printable(char *); int swapmode(int *retavail, int *retfree); static int smpmode; +static int ncpu; +#define NCPU 2 /* support max 2cpu to display frequency */ enum displaymodes displaymode; static int namelength = 8; static int cmdlengthdelta; @@ -153,10 +155,10 @@ /* these are for detailing the process states */ -int process_states[8]; +int process_states[8+NCPU]; char *procstatenames[] = { "", " starting, ", " running, ", " sleeping, ", " stopped, ", - " zombie, ", " waiting, ", " lock, ", + " zombie, ", " waiting, ", " lock, ", " MHz, ", " MHz, ", NULL }; @@ -235,6 +237,13 @@ modelen != sizeof(smpmode)) smpmode = 0; + for (ncpu = -1; ncpu < NCPU; ncpu++) { + char buf[32]; + snprintf(buf, sizeof buf-1, "dev.cpu.%d.freq", ncpu+1); + if (sysctlbyname(buf, NULL, NULL, NULL, 0) < 0) + break; + } + while ((pw = getpwent()) != NULL) { if (strlen(pw->pw_name) > namelength) namelength = strlen(pw->pw_name); @@ -629,6 +638,16 @@ } } + /* CPU current frequency */ + if (ncpu != -1) { + int j; + for(j = 0; j <= ncpu; j++) { + char buf[32]; + snprintf(buf, sizeof buf-1, "dev.cpu.%d.freq", j); + GETSYSCTL(buf, process_states[j+8]); + } + } + /* if requested, sort the "interesting" processes */ if (compare != NULL) qsort(pref, active_procs, sizeof(*pref), compare); --Multipart=_Sat__26_Aug_2006_17_56_50_+0900_B3LIhfNEWJ2tmbRO Content-Type: text/plain; name="7-current.usr-bin.top.machine.c.diff" Content-Disposition: attachment; filename="7-current.usr-bin.top.machine.c.diff" Content-Transfer-Encoding: 7bit Index: machine.c =================================================================== RCS file: /home/ncvs/src/usr.bin/top/machine.c,v retrieving revision 1.77 diff -u -r1.77 machine.c --- machine.c 11 Jun 2006 19:18:39 -0000 1.77 +++ machine.c 26 Aug 2006 08:41:29 -0000 @@ -58,6 +58,8 @@ extern struct process_select ps; extern char* printable(char *); static int smpmode; +static int ncpu; +#define NCPU 2 /* support max 2cpu to display frequency */ enum displaymodes displaymode; static int namelength = 8; static int cmdlengthdelta; @@ -147,10 +149,10 @@ /* these are for detailing the process states */ -int process_states[8]; +int process_states[8+NCPU]; char *procstatenames[] = { "", " starting, ", " running, ", " sleeping, ", " stopped, ", - " zombie, ", " waiting, ", " lock, ", + " zombie, ", " waiting, ", " lock, ", " MHz, ", " MHz, ", NULL }; @@ -234,6 +236,13 @@ modelen != sizeof(smpmode)) smpmode = 0; + for (ncpu = -1; ncpu < NCPU; ncpu++) { + char buf[32]; + snprintf(buf, sizeof buf-1, "dev.cpu.%d.freq", ncpu+1); + if (sysctlbyname(buf, NULL, NULL, NULL, 0) < 0) + break; + } + while ((pw = getpwent()) != NULL) { if (strlen(pw->pw_name) > namelength) namelength = strlen(pw->pw_name); @@ -632,6 +641,16 @@ } } + /* CPU current frequency */ + if (ncpu != -1) { + int j; + for(j = 0; j <= ncpu; j++) { + char buf[32]; + snprintf(buf, sizeof buf-1, "dev.cpu.%d.freq", j); + GETSYSCTL(buf, process_states[j+8]); + } + } + /* if requested, sort the "interesting" processes */ if (compare != NULL) qsort(pref, active_procs, sizeof(*pref), compare); --Multipart=_Sat__26_Aug_2006_17_56_50_+0900_B3LIhfNEWJ2tmbRO-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 10:26:35 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA6116A4DA; Sat, 26 Aug 2006 10:26:35 +0000 (UTC) (envelope-from massimo@cedoc.mo.it) Received: from aa001msr.fastwebnet.it (aa001msr.fastwebnet.it [85.18.95.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C00445E4; Sat, 26 Aug 2006 10:26:31 +0000 (GMT) (envelope-from massimo@cedoc.mo.it) Received: from intanto.datacode.it (37.254.91.189) by aa001msr.fastwebnet.it (7.2.070.1) id 44AD3F5B016DC5B6; Sat, 26 Aug 2006 12:26:30 +0200 Date: Sat, 26 Aug 2006 12:26:34 +0200 From: Massimo Lusetti To: Robert Watson Message-Id: <20060826122634.f85f8671.massimo@cedoc.mo.it> In-Reply-To: <20060826055402.W43127@fledge.watson.org> References: <44E9582C.2010400@rsu.ru> <44ECBB7D.4090905@FreeBSD.org> <20060823205523.GB27961@lor.one-eyed-alien.net> <20060825220033.GC16768@turion.vk2pj.dyndns.org> <20060826055402.W43127@fledge.watson.org> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: peterjeremy@optushome.com.au, freebsd-current@freebsd.org, bushman@rsu.ru Subject: Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 10:26:35 -0000 On Sat, 26 Aug 2006 06:00:02 +0100 (BST) Robert Watson wrote: > One of the strongest historical arguments for using *BSD as the base for [..] > abandoning integrated revision control and building of the current system. FWIW I would like to second this comment, and would extend that saying that i feel lack of a DHCP server in the base. > Sure, we can make the build-time construction of the system modular in a > cleaner and more comprehensive way, and provide better binary delivery > mechanisms that offer more of the build-time flexibility we already have to > the end-user. But an argument to dismember the current system is a > non-starter. If I wanted to try to build a complete and integrated system > from scratch, without any guarantees that the versions of the components had > been tested together, without an integrated build system, etc, I could always > use one of a thousand Linux distributions. A self-standing buildworld out of > a single CVS checkout is one of our greatest strengths. That's the first main reason why i moved to FreeBSD, six years ago. Holy words! Regards, Massimo From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 10:28:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DBFC16A4E2; Sat, 26 Aug 2006 10:28:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7463B44616; Sat, 26 Aug 2006 10:28:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k7QASRI1040830; Sat, 26 Aug 2006 06:28:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k7QASRU0081150; Sat, 26 Aug 2006 06:28:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1B7407302F; Sat, 26 Aug 2006 06:28:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060826102827.1B7407302F@freebsd-current.sentex.ca> Date: Sat, 26 Aug 2006 06:28:26 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 10:28:29 -0000 TB --- 2006-08-26 08:35:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-08-26 08:35:32 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-08-26 08:35:32 - cleaning the object tree TB --- 2006-08-26 08:36:28 - checking out the source tree TB --- 2006-08-26 08:36:28 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-08-26 08:36:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-08-26 08:56:41 - building world (CFLAGS=-O2 -pipe) TB --- 2006-08-26 08:56:41 - cd /src TB --- 2006-08-26 08:56:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries [...] /src/lib/libbsm/../../contrib/openbsm/libbsm/bsm_token.c:1059: error: conflicting types for 'au_to_exec_args' /obj/amd64/src/lib32/usr/include/bsm/audit_record.h:322: error: previous declaration of 'au_to_exec_args' was here /src/lib/libbsm/../../contrib/openbsm/libbsm/bsm_token.c:1059: error: conflicting types for 'au_to_exec_args' /obj/amd64/src/lib32/usr/include/bsm/audit_record.h:322: error: previous declaration of 'au_to_exec_args' was here /src/lib/libbsm/../../contrib/openbsm/libbsm/bsm_token.c:1100: error: conflicting types for 'au_to_exec_env' /obj/amd64/src/lib32/usr/include/bsm/audit_record.h:323: error: previous declaration of 'au_to_exec_env' was here /src/lib/libbsm/../../contrib/openbsm/libbsm/bsm_token.c:1100: error: conflicting types for 'au_to_exec_env' /obj/amd64/src/lib32/usr/include/bsm/audit_record.h:323: error: previous declaration of 'au_to_exec_env' was here *** Error code 1 Stop in /src/lib/libbsm. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-08-26 10:28:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-08-26 10:28:26 - ERROR: failed to build world TB --- 2006-08-26 10:28:26 - tinderbox aborted TB --- 1.31 user 7.39 system 6773.96 real From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 10:32:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16B7216A4DA; Sat, 26 Aug 2006 10:32:43 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67642442D7; Sat, 26 Aug 2006 10:06:49 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Sat, 26 Aug 2006 18:06:47 +0800 id 0010880D.44F01D37.0000E216 References: <20060825084755.GA93151@stud.fit.vutbr.cz> <200608251028.55915.jhb@freebsd.org> <20060826072759.GB55105@stud.fit.vutbr.cz> In-Reply-To: <20060826072759.GB55105@stud.fit.vutbr.cz> From: "Intron is my alias on the Internet" To: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Date: Sat, 26 Aug 2006 18:06:47 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: Subject: Re: Linuxulator: Unbreak Mozilla, Firefox and RealPlayer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 10:32:43 -0000 Divacky Roman wrote: > On Sat, Aug 26, 2006 at 10:07:17AM +0800, Intron is my alias on the Internet wrote: >> John Baldwin wrote: >> >> >On Friday 25 August 2006 04:47, Divacky Roman wrote: >> > >> >Umm, if you want to reparent a proc you should use the proc_reparent() >> >function instead of just hacking on p_pptr. You also need to hold >> >the proctree_lock when modifying p_pptr anyway. >> > >> >-- >> >John Baldwin >> >_______________________________________________ >> >freebsd-current@freebsd.org mailing list >> >http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> Thank you for your reminder. I have updated my patch: >> >> http://ftp.intron.ac/tmp/linux_machdep.c.1.53-2.diff > > pls can you explain me this change: > - /* this is taken from i386 version of cpu_set_user_tls() */ > - critical_enter(); > - /* set %gs */ > + /* Set %gs of child */ > td2->td_pcb->pcb_gsd = sd; > - PCPU_GET(fsgs_gdt)[1] = sd; > - load_gs(GSEL(GUGS_SEL, SEL_UPL)); > - critical_exit(); > + td2->td_pcb->pcb_gs = GSEL(GUGS_SEL, SEL_UPL); > > > thnx! > > roman > The new descriptor of new TLS should be handed to new thread, and it shouldn't override current thread's TLS descriptor. When you commit the patch, please remove the line: td2->td_pcb->pcb_gs = GSEL(GUGS_SEL, SEL_UPL); This kernel directive ensures %gs pointing to TLS in new thread. But in fact, genuine Linux kernel doesn't meddle register value of userland thread/process. Let userland GNU LIBC be. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 15:47:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 999E216A4E1; Sat, 26 Aug 2006 15:47:21 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E7D743D46; Sat, 26 Aug 2006 15:47:20 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 03B2320A6; Sat, 26 Aug 2006 17:47:17 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 7E1B62084; Sat, 26 Aug 2006 17:47:16 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 5BEF4B80E; Sat, 26 Aug 2006 17:47:16 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Simon L. Nielsen" References: <44E9582C.2010400@rsu.ru> <44EAA213.6010507@delphij.net> <002901c6c5ba$628b67d0$9800a8c0@carrera> <86hd0423zk.fsf@xps.des.no> <44EB302A.7010106@rsu.ru> <20060823121157.yawh6f8e844w4osc@netchild.homeip.net> <86u043znbz.fsf@xps.des.no> <20060824120745.GE1077@zaphod.nitro.dk> Date: Sat, 26 Aug 2006 17:47:16 +0200 In-Reply-To: <20060824120745.GE1077@zaphod.nitro.dk> (Simon L. Nielsen's message of "Thu, 24 Aug 2006 14:07:47 +0200") Message-ID: <868xlbpkhn.fsf@dwp.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: OpenSSL ports/base magic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 15:47:21 -0000 "Simon L. Nielsen" writes: > I know there are some magic in ports/ to use the ports version of > OpenSSL, but I don't think there is anything done to support this in > the base system, or have I missed that? ISTR there used to be a knob to use the OpenSSL port when building world as well. I don't know if it still exists. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 19:19:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1941016A4DA; Sat, 26 Aug 2006 19:19:11 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.logital.it (85-18-201-99.ip.fastwebnet.it [85.18.201.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B10343D46; Sat, 26 Aug 2006 19:19:09 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from [192.168.44.2] (adsl-253-10.38-151.net24.it [151.38.10.253]) (authenticated bits=0) by mail.logital.it (8.13.7/8.13.7) with ESMTP id k7QJIsmO066348; Sat, 26 Aug 2006 21:19:03 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <44F09E9B.5090303@commit.it> Date: Sat, 26 Aug 2006 21:18:51 +0200 From: Angelo Turetta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org References: <200608200300.k7K30eH5092848@freefall.freebsd.org> In-Reply-To: <200608200300.k7K30eH5092848@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_60,FU_FREE,TW_FX, TW_KB,TW_TK autolearn=no version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on mail.logital.it X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on mail.logital.it X-Virus-Status: Clean Cc: Frank Reppin Subject: Interrupt storm on ASUS M2N-E (was: amd64/101873: Freebsd amd64 hangs on booting sata drive?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 19:19:11 -0000 Frank Reppin wrote: > From: Frank Reppin > To: bug-followup@FreeBSD.org, habeeb@cfl.rr.com > Cc: > Subject: Re: amd64/101873: Freebsd amd64 hangs on booting sata drive? > > I've had the same experience with my brand new and shiny > amd64 equipmnent...: > > Mainboard -> ASUS M2N-E (nforce 570 - *no* SLI) > RAM -> DDR2 800 CL5 made by MDT (1.8V ... 2x512) > CPU -> AMD64 4200+ AM2 EE > GPU -> ASUS Top Silent 7600GS > HD -> 2x SATA2 Seagate 160GB drives > > ... it won't boot the official 6.1 REL but booting/installing from: > > 7.0-CURRENT-200608-amd64-disc1.iso > > fixed this issue for me. Lucky man :-) I got to the same (temporary) conclusion before realizing that, as soon as the SATA disks are probed, the system is plagued by an interrupt storm that render it almost unusable: #vmstat -i interrupt total rate irq1: atkbd0 6 0 irq6: fdc0 1 0 irq14: ata0 47 0 irq16: fwohci0 1 0 irq17: fxp0 1809 0 irq21: ohci0+ 2 0 irq22: ehci0 1 0 irq23: atapci1 716308228 159605 cpu0: timer 8974123 1999 Total 725284218 161605 Booting amd64 or i386 gives the same results. On a different boot atapci1 was on irq20 (but I cannot remember if it was amd64 or i386), but the storm was unchanged. Now the PC has a i386 minimal installation. I also tried kldload-ing if_nfe (the on-board ethernet is a Marvell): the driver attaches, but the responsiveness of the system deteriorates visibly, and I ended up with a corrupted root partition trying to build world with both /usr/src and /usr/obj mounted from NFS. How could I solve/work around this issue? I put on my home server the ACPI dump files, boot messages (verbose) and pciconf -lv, just in case some good soul can shed some light... http://stable.commit.it/m2n-e/ TIA Angelo Turetta Modena - Italy From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 22:12:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 558E116A4EF for ; Sat, 26 Aug 2006 22:12:11 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93252444CF for ; Sat, 26 Aug 2006 21:21:20 +0000 (GMT) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7QLLKF0067456 for ; Sat, 26 Aug 2006 21:21:20 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7QLLK7s067455 for current@freebsd.org; Sat, 26 Aug 2006 21:21:20 GMT (envelope-from kan) Date: Sat, 26 Aug 2006 21:21:20 +0000 From: Alexander Kabaev To: current@freebsd.org Message-ID: <20060826212120.GA66604@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: HEADS UP: GCC 3.4.6 update in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 22:12:11 -0000 In order to pave the way for an upcoming GCC 4.1 import, we decided to update GCC 3.4 in the tree to the latest version available in FSF SVN repository. After a short period in -current this version will be MFC-ed to RELENG6, which will then be able to take advantage of all the fixes that went info FSF sources since we did last compiler update. The update will happen over next hour or so. I will post 'all clear' message once the system is back to consistent state. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 22:36:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 952) id C3F5C16A4DF; Sat, 26 Aug 2006 22:36:08 +0000 (UTC) Date: Sat, 26 Aug 2006 22:36:08 +0000 From: Alexander Kabaev To: current@freebsd.org Message-ID: <20060826223608.GA5436@hub.freebsd.org> References: <20060826212120.GA66604@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060826212120.GA66604@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: HEADS UP: GCC 3.4.6 update complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 22:36:08 -0000 All is clear. This update should be pretty uneventful and nothing should break because of it. I am very interested in being notified of anything that contradicts with an above statement. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 23:00:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 306B016A4E0; Sat, 26 Aug 2006 23:00:10 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFE343D97; Sat, 26 Aug 2006 23:00:08 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.6/8.13.6) with ESMTP id k7QN08Bg060484; Sat, 26 Aug 2006 19:00:08 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.6/8.13.6/Submit) with ESMTP id k7QN08AS060481; Sat, 26 Aug 2006 19:00:08 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sat, 26 Aug 2006 19:00:08 -0400 (EDT) From: "Andrew R. Reiter" To: Alexander Kabaev In-Reply-To: <20060826223608.GA5436@hub.freebsd.org> Message-ID: <20060826185936.C60397@fledge.watson.org> References: <20060826212120.GA66604@freefall.freebsd.org> <20060826223608.GA5436@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@freebsd.org Subject: Re: HEADS UP: GCC 3.4.6 update complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 23:00:10 -0000 On Sat, 26 Aug 2006, Alexander Kabaev wrote: :All is clear. This update should be pretty uneventful and nothing should :break because of it. I am very interested in being notified of anything :that contradicts with an above statement. : Any specific benefits from the move minus just "the latest & greatest"? Jsut curious. peace, andrew :-- :Alexander Kabaev :_______________________________________________ :freebsd-current@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-current :To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" : : -- arr@watson.org From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 23:08:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EAE116A4DE; Sat, 26 Aug 2006 23:08:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6BE143D93; Sat, 26 Aug 2006 23:08:24 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k7QN7ZTX047722; Sat, 26 Aug 2006 16:07:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k7QN7ZWh047721; Sat, 26 Aug 2006 16:07:35 -0700 (PDT) (envelope-from sgk) Date: Sat, 26 Aug 2006 16:07:35 -0700 From: Steve Kargl To: "Andrew R. Reiter" Message-ID: <20060826230735.GA47659@troutmask.apl.washington.edu> References: <20060826212120.GA66604@freefall.freebsd.org> <20060826223608.GA5436@hub.freebsd.org> <20060826185936.C60397@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060826185936.C60397@fledge.watson.org> User-Agent: Mutt/1.4.2.2i Cc: Alexander Kabaev , current@freebsd.org Subject: Re: HEADS UP: GCC 3.4.6 update complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 23:08:25 -0000 On Sat, Aug 26, 2006 at 07:00:08PM -0400, Andrew R. Reiter wrote: > > On Sat, 26 Aug 2006, Alexander Kabaev wrote: > > :All is clear. This update should be pretty uneventful and nothing should > :break because of it. I am very interested in being notified of anything > :that contradicts with an above statement. > : > > Any specific benefits from the move minus just "the latest & greatest"? > Jsut curious. > http://gcc.gnu.org/gcc-3.4/ -- Steve