From owner-freebsd-current Sun Jun 9 1:20:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 16E9637B400 for ; Sun, 9 Jun 2002 01:20:35 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g598KQJ03469; Sun, 9 Jun 2002 01:20:26 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3) with ESMTP id g598KUAi048153; Sun, 9 Jun 2002 01:20:30 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g598KTK8048152; Sun, 9 Jun 2002 01:20:29 -0700 (PDT) (envelope-from marcel) Date: Sun, 9 Jun 2002 01:20:29 -0700 From: Marcel Moolenaar To: Yamada Ken Takeshi Cc: freebsd-current@FreeBSD.ORG Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries Message-ID: <20020609082029.GA48045@dhcp01.pn.xcllnt.net> References: <20020608.221113.730550684.ken@tydfam.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020608.221113.730550684.ken@tydfam.jp> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 08, 2002 at 10:11:13PM +0900, Yamada Ken Takeshi wrote: > Thank you! Your patch-z32 made me happy a little. >=20 > When can I compile XFree86-4-Server-4.2.0_2 with -current? =20 > It gives me "internal compiler error", too as below. I had > thought it uses XFree86-4-libraries port which was wrong. The build in XFree86-Server has "-O -pipe" on the commandline, which I presume you have in /etc/make.conf. The one in XFree86-Libraries didn't (as demonstrated by your earlier mail). Hence the first didn't hit the compiler bug and this one does. The work-around: build this file without -O. > : : : (snip) > rm -f translate.o > LD_LIBRARY_PATH=3D../../../../exports/lib cc -c -O -pipe -ansi -pedant= ic -Dasm=3D__asm -Wall -Wpointer-arith -I../../../../exports/include -I..= /../../../exports/include/X11 -I../../../../include/extensions -I../../..= /../extras/Mesa/src -I../../../../lib/GL/dri -I../../../.. -I../../../../e= xports/include -DCSRG_BASED -DFUNCPROTO=3D15 -DNARROWPROTO -DXTHREADS = -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL -DGLXEXT -= DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DUSE_X= 86_ASM -DUSE_MMX_ASM -ansi -pedantic -Dasm=3D__asm -Wall -Wpointer-ar= ith -I../../../../exports/include -I../../../../exports/include/X11 -I../.= ./../../include/extensions -I../../../../extras/Mesa/src -I../../../../li= b/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BASED -DFUN= CPROTO=3D15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAP= I -DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGL= X_USE_DLOPEN -DGLX_USE_MES! > A -DUSE_X86_ASM -DUSE_MMX_ASM -fPIC translate.c > In file included from translate.c:779: > ../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1u= b_elt': > ../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill regis= ter > (insn 96 94 97 (set (subreg:SF (reg:QI 75) 0) > (plus:SF (reg:SF 8 st(0) [76]) > (reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 8= 7 (nil)) > (expr_list:REG_DEAD (reg:SF 8 st(0) [76]) > (nil))) > ../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in f= ailed_reload, at reload1.c:5050 > Please submit a full bug report, > with preprocessed source if appropriate. --=20 Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 2:39:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 195B937B407 for ; Sun, 9 Jun 2002 02:39:46 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id B6BAE8B5B0 for ; Sun, 9 Jun 2002 02:39:45 -0700 (PDT) Message-ID: <3D032261.8CB94725@FreeBSD.org> Date: Sun, 09 Jun 2002 02:39:45 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Head's up: NO_PERL -> NO_PERL_WRAPPER Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Per discussion with various folks, including Mark, I've moved the NO_PERL knob over to NO_PERL_WRAPPER, and documented same. Given that this is a fundamentally different thing than the old perl knobs, my opinion is that we don't need to provide compatibility, but I won't argue that point too strongly. I'm currently working on a patch to ports/lang/perl5/files/use.perl to deal with this, and a few of the other outstanding issues. Doug -------- Original Message -------- Subject: cvs commit: src/share/examples/etc make.conf src/share/man/man5make.conf.5 src/usr.bin Makefile Date: Sun, 9 Jun 2002 02:28:02 -0700 (PDT) From: Doug Barton To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org dougb 2002/06/09 02:28:02 PDT Modified files: share/examples/etc make.conf share/man/man5 make.conf.5 usr.bin Makefile Log: Per previous discussion, and with Mark's blessing, update the value of this knob to reflect (-)current reality. Revision Changes Path 1.191 +1 -0 src/share/examples/etc/make.conf 1.51 +4 -0 src/share/man/man5/make.conf.5 1.210 +1 -1 src/usr.bin/Makefile http://www.FreeBSD.org/cgi/cvsweb.cgi/src/share/examples/etc/make.conf.diff?&r1=1.190&r2=1.191&f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/share/man/man5/make.conf.5.diff?&r1=1.50&r2=1.51&f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.bin/Makefile.diff?&r1=1.209&r2=1.210&f=h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 3:49: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 8086537B40C for ; Sun, 9 Jun 2002 03:49:00 -0700 (PDT) Received: by heechee.tobez.org (Postfix, from userid 1001) id DEEDAAC05; Sun, 9 Jun 2002 12:48:50 +0200 (CEST) Date: Sun, 9 Jun 2002 12:48:50 +0200 From: Anton Berezin To: Trish Lynch Cc: current@FreeBSD.ORG, John Hay , Szilveszter Adam Subject: Re: perl wrapper and PATH Message-ID: <20020609104850.GC25520@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Trish Lynch , current@FreeBSD.ORG, John Hay , Szilveszter Adam References: <20020608110834.A25686@dragon.nuxi.com> <20020608141128.D403-100000@femme.listmistress.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020608141128.D403-100000@femme.listmistress.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 08, 2002 at 02:14:09PM -0400, Trish Lynch wrote: > Anton, if you don;t get around to it this weekend, mind if I take a > stab at it? No, I don't mind at all. If only we can agree who does what. :-( Cheers, \Anton. -- | Anton Berezin | FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | tobez@catpipe.net (_(_|| | tobez@FreeBSD.org | | +45 7021 0050 | Private: tobez@tobez.org | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 3:54: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 4067637B401; Sun, 9 Jun 2002 03:53:57 -0700 (PDT) Received: by heechee.tobez.org (Postfix, from userid 1001) id 42611AC09; Sun, 9 Jun 2002 12:53:53 +0200 (CEST) Date: Sun, 9 Jun 2002 12:53:53 +0200 From: Anton Berezin To: Doug Barton Cc: freebsd-current@FreeBSD.org Subject: Re: Head's up: NO_PERL -> NO_PERL_WRAPPER Message-ID: <20020609105353.GD25520@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Doug Barton , freebsd-current@FreeBSD.org References: <3D032261.8CB94725@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D032261.8CB94725@FreeBSD.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002 at 02:39:45AM -0700, Doug Barton wrote: > Per discussion with various folks, including Mark, I've moved the > NO_PERL knob over to NO_PERL_WRAPPER, and documented same. Given that > this is a fundamentally different thing than the old perl knobs, my > opinion is that we don't need to provide compatibility, but I won't > argue that point too strongly. The compatibility is a moot point either way, since there was no NO_PERL knob - it used to be called NOPERL. > I'm currently working on a patch to ports/lang/perl5/files/use.perl to > deal with this, and a few of the other outstanding issues. That's fine, but I am still trying to understand why do we need a wrapper at all. As was indicated (on IRC, not sure it was mentioned in the mail threads), the ability to launch /usr/bin/perl with no perl in the system is different from the inability to launch anything at all. =Anton. -- | Anton Berezin | FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | tobez@catpipe.net (_(_|| | tobez@FreeBSD.org | | +45 7021 0050 | Private: tobez@tobez.org | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 3:57:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 375C337B408 for ; Sun, 9 Jun 2002 03:57:06 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id ED3A98B5C1; Sun, 9 Jun 2002 03:57:05 -0700 (PDT) Message-ID: <3D033481.AE78818C@FreeBSD.org> Date: Sun, 09 Jun 2002 03:57:05 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner Cc: current@FreeBSD.ORG Subject: Re: perl wrapper and PATH References: <200206080626.XAA22903@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fenner wrote: > > I know that the specific mergemaster issues have been addressed, but I > thought this experience pointed out something subtly astonishing, so I > figured I'd point it out. > > I ran mergemaster, and the perl wrapper started complaining that I > needed to install perl, so I did "pkg_add -r perl". The port talked > all about "use.perl port" or "use.perl system", but I figured > "system" was "wrapper" so I didn't bother running use.perl . I tried > "perl -de 0", and voila, I had perl. So I ran mergemaster again, > and the wrapper started complaining again that I needed to install > perl. > > Turns out that mergemaster sets a restrictive PATH, and the wrapper > (apparently) looks for the "real" perl in the PATH. This can be > awfully confusing -- "/usr/bin/perl" works, but "env PATH=/usr/bin perl" > doesn't work. Actually in the case of the old mergemaster, I don't think even /usr/bin/perl would have worked, since PATH would still exclude /usr/local/bin, therefore the wrapper wouldn't have found it. > I ran "use.perl port", and that gave me a working perl for mergemaster. > Interestingly, "use.perl system" didn't give me back the perl wrapper; > I'm not sure what I got. Sigh. I think I have a new version of use.perl that will handle this problem. I'm fixin' to post the patch. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 4: 7:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id A160137B40C; Sun, 9 Jun 2002 04:07:43 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 7014B8B5CF; Sun, 9 Jun 2002 04:07:43 -0700 (PDT) Message-ID: <3D0336FF.5A0D4F0@FreeBSD.org> Date: Sun, 09 Jun 2002 04:07:43 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, tobez@FreeBSD.org Subject: use.perl patch for the new -current world Content-Type: multipart/mixed; boundary="------------9755D75EAEB4D5D7F08EC1D3" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9755D75EAEB4D5D7F08EC1D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is a patch that I think sufficiently updates use.perl to handle the state of the world in -current, without boning things for -stable. It also moves some duplicate code up out of the functions. There are certainly other possible ways to solve this problem, but I've tested the attached patch, moving back and forth between system and port, and it works fine. The other alternative I considered is to rely on something like: if (-f /usr/bin/perl-wrapper) { blah } but decided against it because the current script uses the concept of leaving /usr/bin/perl5 as whatever is installed on the system, so I figured that staying with that would be less of a pola violation. Comments/suggestions welcome. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? --------------9755D75EAEB4D5D7F08EC1D3 Content-Type: text/plain; charset=us-ascii; name="use.perl.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="use.perl.diff" Index: use.perl =================================================================== RCS file: /home/ncvs/ports/lang/perl5/files/use.perl,v retrieving revision 1.2 diff -u -r1.2 use.perl --- use.perl 20 May 2002 00:03:07 -0000 1.2 +++ use.perl 9 Jun 2002 10:58:05 -0000 @@ -14,6 +14,11 @@ exit 2; } +my $port_perl = '%%PREFIX%%/bin/perl'; +$port_perl =~ tr|/|/|s; + +my $ident = `/usr/bin/ident /usr/bin/perl5`; + @ARGV == 1 or usage(); if ($ARGV[0] eq 'port') { switch_to_port(); @@ -24,18 +29,25 @@ } exit 0; +# Both functions depend on the idea that switch_to_port leaves +# perl5 alone. If the wrapper is installed on a -current system, +# /usr/bin/perl5 will also be the wrapper. + sub switch_to_system { - my $port_perl = '%%PREFIX%%/bin/perl'; - $port_perl =~ tr|/|/|s; - # protect against cases where people use PREFIX=/usr if ($port_perl ne '/usr/bin/perl') { unlink '/usr/bin/perl', '/usr/bin/suidperl', '/usr/bin/perl%%PERL_VERSION%%'; link '/usr/bin/perl5', '/usr/bin/perl'; - link '/usr/bin/sperl5', '/usr/bin/suidperl'; + link '/usr/bin/perl5', '/usr/bin/perl%%PERL_VERSION%%'; + + if ($ident =~ m#src/usr.bin/perl/perl.c#) { + link '/usr/bin/perl5', '/usr/bin/suidperl'; + } else { + link '/usr/bin/sperl5', '/usr/bin/suidperl'; + } } open MK, ">> /etc/make.conf" or die "/etc/make.conf: $!"; @@ -47,6 +59,7 @@ .undef PERL_VERSION .undef PERL_ARCH .undef NOPERL +.undef NO_PERL EOF close MK; @@ -54,13 +67,15 @@ sub switch_to_port { - my $port_perl = '%%PREFIX%%/bin/perl'; - $port_perl =~ tr|/|/|s; - # protect against cases where people use PREFIX=/usr if ($port_perl ne '/usr/bin/perl') { - unlink '/usr/bin/perl', '/usr/bin/suidperl', - '/usr/bin/perl%%PERL_VERSION%%'; + if ($ident =~ m#src/usr.bin/perl/perl.c#) { + rename '/usr/bin/perl', '/usr/bin/perl-wrapper'; + } else { + unlink '/usr/bin/perl'; + } + + unlink '/usr/bin/suidperl', '/usr/bin/perl%%PERL_VERSION%%'; symlink '%%PREFIX%%/bin/perl', '/usr/bin/perl'; symlink '%%PREFIX%%/bin/suidperl', '/usr/bin/suidperl'; @@ -76,6 +91,8 @@ PERL_VERSION=%%PERL_VERSION%% PERL_ARCH=%%PERL_ARCH%% NOPERL=yo +NO_PERL=yo +NO_PERL_WRAPPER=yo EOF close MK; --------------9755D75EAEB4D5D7F08EC1D3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 4:12:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id BFE7137B403 for ; Sun, 9 Jun 2002 04:12:37 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 6B95D8B5AD; Sun, 9 Jun 2002 04:12:37 -0700 (PDT) Message-ID: <3D033825.C024679E@FreeBSD.org> Date: Sun, 09 Jun 2002 04:12:37 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Anton Berezin Cc: freebsd-current@FreeBSD.org Subject: Re: Head's up: NO_PERL -> NO_PERL_WRAPPER References: <3D032261.8CB94725@FreeBSD.org> <20020609105353.GD25520@heechee.tobez.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Anton Berezin wrote: > > On Sun, Jun 09, 2002 at 02:39:45AM -0700, Doug Barton wrote: > > Per discussion with various folks, including Mark, I've moved the > > NO_PERL knob over to NO_PERL_WRAPPER, and documented same. Given that > > this is a fundamentally different thing than the old perl knobs, my > > opinion is that we don't need to provide compatibility, but I won't > > argue that point too strongly. > > The compatibility is a moot point either way, since there was no NO_PERL > knob - it used to be called NOPERL. It's NOPERL in -stable, but it was NO_PERL in -current when I changed it to NO_PERL_WRAPPER. > > I'm currently working on a patch to ports/lang/perl5/files/use.perl to > > deal with this, and a few of the other outstanding issues. > > That's fine, but I am still trying to understand why do we need a > wrapper at all. As was indicated (on IRC, not sure it was mentioned in > the mail threads), the ability to launch /usr/bin/perl with no perl in > the system is different from the inability to launch anything at all. Personally, I don't think we need a wrapper, as long as the use.perl script knows how to DTRT. However, given that currently we have a wrapper I thought fixing use.perl to handle it was reasonable. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 4:24: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id F1DA037B401; Sun, 9 Jun 2002 04:23:57 -0700 (PDT) Received: by heechee.tobez.org (Postfix, from userid 1001) id C2550AC08; Sun, 9 Jun 2002 13:23:53 +0200 (CEST) Date: Sun, 9 Jun 2002 13:23:53 +0200 From: Anton Berezin To: Doug Barton Cc: freebsd-current@FreeBSD.org Subject: Re: Head's up: NO_PERL -> NO_PERL_WRAPPER Message-ID: <20020609112353.GE25520@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Doug Barton , freebsd-current@FreeBSD.org References: <3D032261.8CB94725@FreeBSD.org> <20020609105353.GD25520@heechee.tobez.org> <3D033825.C024679E@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D033825.C024679E@FreeBSD.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002 at 04:12:37AM -0700, Doug Barton wrote: > Anton Berezin wrote: > > The compatibility is a moot point either way, since there was no NO_PERL > > knob - it used to be called NOPERL. > > It's NOPERL in -stable, but it was NO_PERL in -current when I changed it > to NO_PERL_WRAPPER. My point was that it *was* NOPERL in -current before the removal of perl. But I see you handle this case in your patch to use.perl, so no argument here. > > That's fine, but I am still trying to understand why do we need a > > wrapper at all. As was indicated (on IRC, not sure it was mentioned in > > the mail threads), the ability to launch /usr/bin/perl with no perl in > > the system is different from the inability to launch anything at all. > Personally, I don't think we need a wrapper, as long as the use.perl > script knows how to DTRT. My point exactly. > However, given that currently we have a wrapper I thought fixing > use.perl to handle it was reasonable. The keyword here is `currently'. :-) Cheers, \Anton. -- | Anton Berezin | FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | tobez@catpipe.net (_(_|| | tobez@FreeBSD.org | | +45 7021 0050 | Private: tobez@tobez.org | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 4:25:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id 50A3B37B40C; Sun, 9 Jun 2002 04:24:57 -0700 (PDT) Received: by heechee.tobez.org (Postfix, from userid 1001) id 544D7AC08; Sun, 9 Jun 2002 13:24:53 +0200 (CEST) Date: Sun, 9 Jun 2002 13:24:53 +0200 From: Anton Berezin To: Doug Barton Cc: freebsd-current@FreeBSD.org Subject: Re: use.perl patch for the new -current world Message-ID: <20020609112453.GF25520@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Doug Barton , freebsd-current@FreeBSD.org References: <3D0336FF.5A0D4F0@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0336FF.5A0D4F0@FreeBSD.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002 at 04:07:43AM -0700, Doug Barton wrote: > Attached is a patch that I think sufficiently updates use.perl to handle > the state of the world in -current, without boning things for -stable. > It also moves some duplicate code up out of the functions. > Comments/suggestions welcome. Looks good. =Anton. -- | Anton Berezin | FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | tobez@catpipe.net (_(_|| | tobez@FreeBSD.org | | +45 7021 0050 | Private: tobez@tobez.org | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 5:13:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from femme.listmistress.org (bgp01560565bgs.gambrl01.md.comcast.net [68.50.32.109]) by hub.freebsd.org (Postfix) with ESMTP id E42AA37B407; Sun, 9 Jun 2002 05:13:26 -0700 (PDT) Received: from femme.listmistress.org (trish@localhost [127.0.0.1]) by femme.listmistress.org (8.12.3/8.12.1) with ESMTP id g59CDKMO029319; Sun, 9 Jun 2002 08:13:22 -0400 (EDT) Received: from localhost (trish@localhost) by femme.listmistress.org (8.12.3/8.12.3/Submit) with ESMTP id g59CDInN029316; Sun, 9 Jun 2002 08:13:19 -0400 (EDT) X-Authentication-Warning: femme.listmistress.org: trish owned process doing -bs Date: Sun, 9 Jun 2002 08:13:18 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Anton Berezin Cc: Doug Barton , Subject: Re: use.perl patch for the new -current world In-Reply-To: <20020609112453.GF25520@heechee.tobez.org> Message-ID: <20020609081122.K31340-100000@femme.listmistress.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Jun 2002, Anton Berezin wrote: > On Sun, Jun 09, 2002 at 04:07:43AM -0700, Doug Barton wrote: > > Attached is a patch that I think sufficiently updates use.perl to handle > > the state of the world in -current, without boning things for -stable. > > It also moves some duplicate code up out of the functions. > > > Comments/suggestions welcome. > > Looks good. > > =Anton. Now if we can agree upon behaviour of the perl "wrapper" I think, that if use use.perl, all the "wrapper" has to do is: perl is not installed: please install /usr/ports/lang/perl5 or pkg_add -r perl -Trish (who is amazed at what just happened while she slept *grr*) -- Trish Lynch trish@bsdunix.net FreeBSD The Power to Serve Ecartis Core Team trish@listmistress.org http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 5:33:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7ABF937B404; Sun, 9 Jun 2002 05:33:16 -0700 (PDT) Received: from pool0011.cvx22-bradley.dialup.earthlink.net ([209.179.198.11] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17H1sT-0003Ip-00; Sun, 09 Jun 2002 05:33:01 -0700 Message-ID: <3D034AD8.F5EA3DDD@mindspring.com> Date: Sun, 09 Jun 2002 05:32:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Barton Cc: Anton Berezin , freebsd-current@FreeBSD.org Subject: Re: Head's up: NO_PERL -> NO_PERL_WRAPPER References: <3D032261.8CB94725@FreeBSD.org> <20020609105353.GD25520@heechee.tobez.org> <3D033825.C024679E@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Barton wrote: > Anton Berezin wrote: > > On Sun, Jun 09, 2002 at 02:39:45AM -0700, Doug Barton wrote: > > > Per discussion with various folks, including Mark, I've moved the > > > NO_PERL knob over to NO_PERL_WRAPPER, and documented same. Given that > > > this is a fundamentally different thing than the old perl knobs, my > > > opinion is that we don't need to provide compatibility, but I won't > > > argue that point too strongly. > > > > The compatibility is a moot point either way, since there was no NO_PERL > > knob - it used to be called NOPERL. > > It's NOPERL in -stable, but it was NO_PERL in -current when I changed it > to NO_PERL_WRAPPER. If we are expressing preferences, I prefer that it be called: NO_WE_CHANGE_THE_NAME_SO_YOU_GET_PERL_ANYWAY_`date "+%Y%m%d%H%M%S"` Just so that the name matches it's *real* function, which is apparently to make sure that whatever variable you set to avoid getting perl last time is totally ineffective in preventing you getting perl this time. I personally just consider it an unsubtle means of perl advocacy... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 6:42:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 3B87037B403 for ; Sun, 9 Jun 2002 06:42:15 -0700 (PDT) Received: (qmail 19077 invoked from network); 9 Jun 2002 13:42:05 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 9 Jun 2002 13:42:05 -0000 Received: from trudy.torrini.home (localhost.torrini.home [127.0.0.1]) by torrini.org (8.12.3/8.12.3) with ESMTP id g59Dg72G000486 for ; Sun, 9 Jun 2002 15:42:07 +0200 (CEST) (envelope-from riccardo@trudy.torrini.home) Received: (from riccardo@localhost) by trudy.torrini.home (8.12.3/8.12.3/Submit) id g59Dg5n2000485 for freebsd-current@FreeBSD.ORG; Sun, 9 Jun 2002 15:42:05 +0200 (CEST) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 09 Jun 2002 15:42:05 +0200 (CEST) From: Riccardo Torrini To: freebsd-current@FreeBSD.ORG Subject: usbd.core Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This block crashes usbd with: ...(usbd), uid 0: exited on signal 11 (core dumped) I have a pre-GCC_3.1: (FreeBSD 5.0-CURRENT #34: Wed May 8 02:31:46 CEST 2002) -----8<-----[ /etc/usbd.conf ]-----8<----- device "Scanner Epson Perfection 1240U (photo)" # Perfection1240(0x010b), EPSON(0x04b8), rev 0x0114 product 0x010b vendor 0x04b8 release 0x0114 devname "uscanner[0-9]+" attach "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker" ## attach "/bin/chmod 666 /dev/uscanner0 && echo L16cce > /dev/speaker" detach "echo L16eec > /dev/speaker" -----8<----- (gdb) bt #0 0x280e7dd6 in strncpy () from /usr/lib/libc.so.5 #1 0x80494d4 in sigprocmask () #2 0x804a6c7 in sigprocmask () #3 0x8048cc3 in sigprocmask () Adding a comment before 'device' solves the problem: -----8<----- # device [...] -----8<----- Riccardo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 6:45:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail2.dada.it [195.110.96.69]) by hub.freebsd.org (Postfix) with SMTP id B2CC837B409 for ; Sun, 9 Jun 2002 06:45:54 -0700 (PDT) Received: (qmail 12364 invoked from network); 9 Jun 2002 13:45:49 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 9 Jun 2002 13:45:49 -0000 Received: from trudy.torrini.home (localhost.torrini.home [127.0.0.1]) by torrini.org (8.12.3/8.12.3) with ESMTP id g59Djq2G000506 for ; Sun, 9 Jun 2002 15:45:52 +0200 (CEST) (envelope-from riccardo@trudy.torrini.home) Received: (from riccardo@localhost) by trudy.torrini.home (8.12.3/8.12.3/Submit) id g59DjqHJ000505 for freebsd-current@FreeBSD.ORG; Sun, 9 Jun 2002 15:45:52 +0200 (CEST) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 09 Jun 2002 15:45:52 +0200 (CEST) From: Riccardo Torrini To: freebsd-current@FreeBSD.ORG Subject: I need USB and DEVFS info Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a USB scanner (Epson Perfection 1240U) and a digital camera (Agfa CL18). The first is identified as uscanner0 and work really well, the second show up as ugen{0,0.1,0.2,0.3} With -CURRENT and DEVFS both come up with read/write enable only for root, so I added this line for scanner to etc/usbd.conf: attach "/bin/chmod 666 /dev/${DEVNAME} && echo L16cce > /dev/speaker" This enable my user to use scanner. I tryed the same with digital camera but (I think) DEVFS reset protections to read only. # chmod go+w /dev/ugen0* riccardo@trudy[0]: ll /dev/ugen* crw-rw-rw- 1 root operator 114, 0 Jun 9 14:37 /dev/ugen0 crw-rw-rw- 1 root operator 114, 1 Jun 9 14:37 /dev/ugen0.1 crw-rw-rw- 1 root operator 114, 2 Jun 9 14:43 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 3 Jun 9 14:37 /dev/ugen0.3 riccardo@trudy[0]: gphoto2 --camera "Agfa CL18" --list-files *** Error *** An error occurred in the io-library ('Error writing to the port'): No error description available *** Error ('Error writing to the port') *** [...] riccardo@trudy[1]: ll /dev/ugen* crw-rw-rw- 1 root operator 114, 0 Jun 9 14:37 /dev/ugen0 crw-r--r-- 1 root operator 114, 1 Jun 9 14:37 /dev/ugen0.1 crw-r--r-- 1 root operator 114, 2 Jun 9 14:43 /dev/ugen0.2 crw-r--r-- 1 root operator 114, 3 Jun 9 14:37 /dev/ugen0.3 Trying the list/download photo command from root works. After some command gphoto2 lockup and mark itself as a 'D' process (D = process in disk (or other short term, uninterruptible) wait) and I must reboot to remove it :\ Is a status=D process really unbreakable? And why it become 'D'? And why procections reset to 644 after accessing /dev/ugen* device? Any other hint ? (no, I cannot buy a more expensive camera). TIA, Riccardo. PS: I'd like to buy an USB (cheaper) printer: Epson C40UX. Under linuxprinting.org seems well supported using a ghostscript driver, so I choose this one. The only obscure point is FreeBSD USB driver that is different from Linux one. Is this printer working? Any -CURRENT or -STABLE user with this (or other cheaper) USB printers? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 6:50:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 4A3E437B406 for ; Sun, 9 Jun 2002 06:50:08 -0700 (PDT) Received: (qmail 24604 invoked from network); 9 Jun 2002 13:50:00 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 9 Jun 2002 13:50:00 -0000 Received: from trudy.torrini.home (localhost.torrini.home [127.0.0.1]) by torrini.org (8.12.3/8.12.3) with ESMTP id g59Do32G000515 for ; Sun, 9 Jun 2002 15:50:03 +0200 (CEST) (envelope-from riccardo@trudy.torrini.home) Received: (from riccardo@localhost) by trudy.torrini.home (8.12.3/8.12.3/Submit) id g59Do3dV000514 for freebsd-current@FreeBSD.ORG; Sun, 9 Jun 2002 15:50:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Date: Sun, 09 Jun 2002 15:50:03 +0200 (CEST) From: Riccardo Torrini To: freebsd-current@FreeBSD.ORG Subject: sendmail Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm unable to hide: > X-Authentication-Warning: ...goofy set sender to foobar using -f neither using this m4 macros: define(`confTRUSTED_USERS', ``goofy'') FEATURE(`use_ct_file') nor editing sendmail.cf adding T class. Tgoofy I'm using sendmail 8.12.3 on 4.6-PRERELEASE and 5.0-CURRENT but no difference. Just ignore it :\ Any hint will be appreciated. TIA, Riccardo. PS: I'm not sure where to ask, here, on -STABLE or on -QUESTIONS, if this is the wrong list sorry for wasting your time, feel free to forward to the right list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 6:55:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from zardoc.esmtp.org (adsl-63-195-85-27.dsl.snfc21.pacbell.net [63.195.85.27]) by hub.freebsd.org (Postfix) with ESMTP id C8A8937B408 for ; Sun, 9 Jun 2002 06:55:52 -0700 (PDT) Received: from zardoc.esmtp.org (localhost [127.0.0.1]) by zardoc.esmtp.org (8.12.4/8.12.4) with ESMTP id g59Ds2Jx007975 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Jun 2002 06:54:02 -0700 (PDT) Received: (from ca@localhost) by zardoc.esmtp.org (8.12.4/8.12.3/Submit) id g59Ds27S013501; Sun, 9 Jun 2002 06:54:02 -0700 (PDT) Date: Sun, 9 Jun 2002 06:54:01 -0700 From: Claus Assmann To: Riccardo Torrini Cc: freebsd-current@FreeBSD.ORG Subject: Re: sendmail Message-ID: <20020609065401.A3332@zardoc.esmtp.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from riccardo@torrini.org on Sun, Jun 09, 2002 at 03:50:03PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002, Riccardo Torrini wrote: > I'm unable to hide: > > X-Authentication-Warning: ...goofy set sender to foobar using -f > > neither using this m4 macros: > define(`confTRUSTED_USERS', ``goofy'') > FEATURE(`use_ct_file') Did you add this to submit.mc? Please see cf/README: +----------------------------+ | MESSAGE SUBMISSION PROGRAM | +----------------------------+ .... Notice: do not add options/features to submit.mc unless you are absolutely sure you need them. Options you may want to change include: - confTRUSTED_USERS, FEATURE(`use_ct_file'), and confCT_FILE for avoiding X-Authentication warnings. ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 7: 7:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (port757.uc1-esp.isdn-lan.cybercity.dk [212.242.98.245]) by hub.freebsd.org (Postfix) with ESMTP id F120B37B406 for ; Sun, 9 Jun 2002 07:07:48 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g59E6I0e010980; Sun, 9 Jun 2002 16:06:19 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Riccardo Torrini Cc: freebsd-current@FreeBSD.ORG Subject: Re: I need USB and DEVFS info In-Reply-To: Your message of "Sun, 09 Jun 2002 15:45:52 +0200." Date: Sun, 09 Jun 2002 16:06:18 +0200 Message-ID: <10979.1023631578@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Riccardo Torrini write s: >This enable my user to use scanner. I tryed the same with digital >camera but (I think) DEVFS reset protections to read only. DEVFS certainly doesn't. The device driver might. Dima Dorfman has code in the pipeline which will allow you to instruct DEVFS what to do and what permissions to use when devices come and go. I'm hoping he will commit it RSN so people an start to tell us if it is a totally bogus concept. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 7:37:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from tydfam.jp (ns.tydfam.jp [61.194.211.50]) by hub.freebsd.org (Postfix) with ESMTP id 24CB537B40C for ; Sun, 9 Jun 2002 07:37:48 -0700 (PDT) Received: from localhost (tyd3.sub.tydfam.jp [192.168.0.3]) by tydfam.jp (8.11.6/8.11.6) with ESMTP id g59EbjI07610; Sun, 9 Jun 2002 23:37:46 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sun, 09 Jun 2002 23:37:03 +0900 (JST) Message-Id: <20020609.233703.730560602.ken@tydfam.jp> To: freebsd-current@FreeBSD.ORG Cc: marcel@xcllnt.net Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries From: Yamada Ken Takeshi In-Reply-To: <20020609082029.GA48045@dhcp01.pn.xcllnt.net> X-Mailer: Mew version 2.2 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank you! By eliminating "-O" option, I could make XFree86-4-Server which works. "-O -pipe" was in /usr/share/mk/sys.mk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 8:43:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id E9E8C37B40A for ; Sun, 9 Jun 2002 08:43:09 -0700 (PDT) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.3/8.12.3) with ESMTP id g59FgxHc096654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 9 Jun 2002 17:43:01 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g59Fh5SA057430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Jun 2002 17:43:05 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g59Fh5js057429; Sun, 9 Jun 2002 17:43:05 +0200 (CEST)?g (envelope-from ticso) Date: Sun, 9 Jun 2002 17:43:04 +0200 From: Bernd Walter To: Riccardo Torrini Cc: freebsd-current@FreeBSD.ORG Subject: Re: sendmail Message-ID: <20020609154304.GC39774@cicely5.cicely.de> Reply-To: ticso@cicely.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002 at 03:50:03PM +0200, Riccardo Torrini wrote: > I'm unable to hide: > > X-Authentication-Warning: ...goofy set sender to foobar using -f > > neither using this m4 macros: > define(`confTRUSTED_USERS', ``goofy'') > FEATURE(`use_ct_file') > > nor editing sendmail.cf adding T class. > Tgoofy You need to do it for submit.cf/submit.mc -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 11:31: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from sharma-home.net (cpe-66-1-147-119.ca.sprintbbd.net [66.1.147.119]) by hub.freebsd.org (Postfix) with ESMTP id 7A1C837B406 for ; Sun, 9 Jun 2002 11:30:25 -0700 (PDT) Received: by sharma-home.net (Postfix, from userid 500) id 14E3A157; Sun, 9 Jun 2002 11:25:31 -0700 (PDT) Date: Sun, 9 Jun 2002 11:25:31 -0700 From: Arun Sharma To: freebsd-current@freebsd.org Subject: Lock order reversal with a recent SMP kernel Message-ID: <20020609112531.A1482@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG lock order reversal 1st 0xc9c48d98 sis0 (network driver) @ /usr.current/src/sys/pci/if_sis.c:804 2nd 0xc0328600 allproc (allproc) @ /usr.current/src/sys/kern/kern_fork.c:309 Is this a problem ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 12:34:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from web13302.mail.yahoo.com (web13302.mail.yahoo.com [216.136.175.38]) by hub.freebsd.org (Postfix) with SMTP id 10A6E37B406 for ; Sun, 9 Jun 2002 12:34:14 -0700 (PDT) Message-ID: <20020609193410.63290.qmail@web13302.mail.yahoo.com> Received: from [207.175.241.198] by web13302.mail.yahoo.com via HTTP; Sun, 09 Jun 2002 12:34:10 PDT Date: Sun, 9 Jun 2002 12:34:10 -0700 (PDT) From: Maksim Yevmenkin Subject: -current (DP1) and USB transfers To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1531940720-1023651250=:62906" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --0-1531940720-1023651250=:62906 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hackers, I'm a USB newbie and have a couple stupid questions about USB transfers. System: -current DP1 Laptop: Toshiba Tecra 8100 (docked/undocked) Device: 3COM Bluetooth USB dongle (see attached dump) Device presents three interfaces: Interface 0 - Control, bulk and interrupt transfers Interface 1 - Isochronous transfers Interface 2 - Frimware upgrade Interface 1 has 5 different configurations (they all the same, except wMaxPacketSize). Now, everything is working just fine i can talk to the device send/receive data - no problem. The problem is that as soon as i open isochronous pipe and start incoming isochronous transfer, the isochronous callback gets called over and over again. Both isoc. pipe and isoc. transfer have USBD_NO_SHORT_XFER flag set. I also set configuration #5 for interface 1. The funny part that device says that it got zero bytes from the pipe. It does not affect (or so it seems) the other transfers and everything still works. I also tried ugen driver with the same results. What is up with that? Also, is it safe to assume that USB transfers callbacks are not re-enterable? Here is what i mean: 1) USB transfer callback is called 2) driver starts processing (but does not complete yet) 3) usbd_abort_pipe() called which triggers call to callback again I can only see splusb() calls in the code. Also is it safe to replace interrupt transfers with bulk transfers, given the fact that spec requires 1ms interrupt polling period. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --0-1531940720-1023651250=:62906 Content-Type: text/plain; name="dump.txt" Content-Description: dump.txt Content-Disposition: inline; filename="dump.txt" uhci0: ---------------------------------------------------------------------------- /dev/ugen0 Opened Product: product 0x00a0 Vendor: 3Com address 3 Dumping all descriptors DEVICE descriptor: bLength=18 bDescriptorType=1 bcdUSB=1.10 bDeviceClass=224 bDeviceSubClass=1 bDeviceProtocol=1 bMaxPacketSize=64 idVendor=0x0506 idProduct=0x00a0 bcdDevice=115 iManufacturer=0 iProduct=0 iSerialNumber=0 bNumConfigurations=1 Current configuration is number 1 CONFIGURATION descriptor index 0: bLength=9 bDescriptorType=2 wTotalLength=193 bNumInterface=3 bConfigurationValue=1 iConfiguration=0 bmAttributes=80 bMaxPower=120 mA INTERFACE descriptor index 0, alt index 0: bLength=9 bDescriptorType=4 bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=3 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=1-in bmAttributes=3 wMaxPacketSize=16 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=2-out bmAttributes=2 wMaxPacketSize=64 bInterval=1 ENDPOINT descriptor index 2: bLength=7 bDescriptorType=5 bEndpointAddress=2-in bmAttributes=2 wMaxPacketSize=64 bInterval=1 INTERFACE descriptor index 1, alt index 0: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=0 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=0 bInterval=1 INTERFACE descriptor index 1, alt index 1: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=1 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=9 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=9 bInterval=1 INTERFACE descriptor index 1, alt index 2: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=2 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=17 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=17 bInterval=1 INTERFACE descriptor index 1, alt index 3: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=3 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=25 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=25 bInterval=1 INTERFACE descriptor index 1, alt index 4: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=4 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=33 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=33 bInterval=1 INTERFACE descriptor index 1, alt index 5: bLength=9 bDescriptorType=4 bInterfaceNumber=1 bAlternateSetting=5 bNumEndpoints=2 bInterfaceClass=224 bInterfaceSubClass=1 bInterfaceProtocol=1 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=3-out bmAttributes=1 wMaxPacketSize=49 bInterval=1 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=3-in bmAttributes=1 wMaxPacketSize=49 bInterval=1 INTERFACE descriptor index 2, alt index 0: bLength=9 bDescriptorType=4 bInterfaceNumber=2 bAlternateSetting=0 bNumEndpoints=0 bInterfaceClass=254 bInterfaceSubClass=1 bInterfaceProtocol=0 iInterface=0 --0-1531940720-1023651250=:62906-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 13:59:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 1FDC337B40A for ; Sun, 9 Jun 2002 13:59:31 -0700 (PDT) Received: from pool0102.cvx22-bradley.dialup.earthlink.net ([209.179.198.102] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17H9mW-0003fY-00; Sun, 09 Jun 2002 13:59:25 -0700 Message-ID: <3D03C187.2E6FD56@mindspring.com> Date: Sun, 09 Jun 2002 13:58:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maksim Yevmenkin Cc: current@freebsd.org Subject: Re: -current (DP1) and USB transfers References: <20020609193410.63290.qmail@web13302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maksim Yevmenkin wrote: > The problem is that as soon as i open isochronous pipe and > start incoming isochronous transfer, the isochronous callback > gets called over and over again. Both isoc. pipe and isoc. > transfer have USBD_NO_SHORT_XFER flag set. I also set > configuration #5 for interface 1. The funny part that device > says that it got zero bytes from the pipe. It does not affect > (or so it seems) the other transfers and everything still works. > I also tried ugen driver with the same results. What is up with > that? Pipes are known to be broken. There's a patch floating around that works around the problem, but does not fix it. The place to get it is the IP telephony USB dongle thing for FreeBSD, from ports. You will need to look for it, since I don't have an exact location for it, sorry. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 14:36: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from sharmas.dhs.org (cpe-66-1-147-119.ca.sprintbbd.net [66.1.147.119]) by hub.freebsd.org (Postfix) with ESMTP id 6A20437B401; Sun, 9 Jun 2002 14:35:54 -0700 (PDT) Received: by sharmas.dhs.org (Postfix, from userid 500) id 939965E003; Sun, 9 Jun 2002 14:36:51 -0700 (PDT) Date: Sun, 9 Jun 2002 14:36:51 -0700 From: Arun Sharma To: freebsd-current@freebsd.org Cc: freebsd-smp@freebsd.org Subject: Page faults in kernel mode Message-ID: <20020609213651.GA5956@sharma-home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Running on a dual celeron box. CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 201326592 (196608K bytes) avail memory = 191365120 (186880K bytes) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 1. While running background fsck alone: fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 01000000 fault virtual address = 0xc9d65e90 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01aee6c stack pointer = 0x10:0xcaafe9a4 frame pointer = 0x10:0xcaafe9b0 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 = 155 (syslogd) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x3e: lock cmpxchgl %edx,0x1c(%ebx) db> trace _mtx_lock_flags(c9d65e74,0,c02f31e0,6da,cabb5034) at _mtx_lock_flags+0x3e vref(c9d65e00,cabb5034,0,c02f2f40,98) at vref+0x1d namei(caafec10) at namei+0x17d vn_open_cred(caafec10,caafeb64,1a4,c98fe100,caafecec) at vn_open_cred+0x238 vn_open(caafec10,caafeb64,1a4,c01aeef3,cac6dac8) at vn_open+0x1b open(caadea54,caafed14,3,59,296) at open+0x155 syscall(2f,bfbf002f,bfbf002f,4,2811afa0) at syscall+0x1db syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (5, FreeBSD ELF, open), eip = 0x280a8c73, esp = 0xbfbfe78c, ebp = 0- 2. background fsck + two processes running find / panic: blockable sleep lock (sleep mutex) process lock @ /usr.current/src/sys/i1 cpuid = 0; lapic.id = 00000000 Debugger("panic") Couldn't get any more information on the exact filename from ddb. 3. Running two copies of find / alone: Debugger(c02ea41a) at Debugger+0x46 panic(c02edc20,c02e9380,c02e7400,c030e420,2c7) at panic+0xd1 witness_lock(cb081818,8,c030e420,2c7,1) at witness_lock+0x7f _mtx_lock_flags(cb081818,0,c030e420,2c7,cb081738) at _mtx_lock_flags+0x6a trap_pfault(cb0bb8fc,0,64) at trap_pfault+0x92 trap(c02e0018,cb0b0010,c01a0010,c9d65b74,6a9) at trap+0x32b calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc01af1bf, esp = 0xcb0bb93c, ebp = 0xcb0bb950 --- _mtx_lock_sleep(c9d65b74,0,c02f31e0,6a9) at _mtx_lock_sleep+0x121 _mtx_lock_flags(c9d65b74,0,c02f31e0,6a9) at _mtx_lock_flags+0x58 vget(c9d65b00,2,cb081738,0,cb081738) at vget+0x28 vfs_cache_lookup(cb0bba74,cb0bbaa0,c01efc94,cb0bba74,cb081738) at vfs_cache_loo9 ufs_vnoperate(cb0bba74) at ufs_vnoperate+0x13 lookup(cb0bbc90,cb081738,cada5400,0,cb081738) at lookup+0x2b2 namei(cb0bbc90,0,cb0bbb20,c01af023,c0327ea0) at namei+0x1df execve(cb081738,cb0bbd14,3,1,297) at execve+0x19a syscall(2f,2f,2f,812e0b6,812e050) at syscall+0x1db syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (59, FreeBSD ELF, execve), eip = 0x80a6e80, esp = 0xbfbff9c8, ebp =- This sounds like a variant of (1). 4. More page faults in kernel mode: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 01000000 fault virtual address = 0xc9d65014 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f32d3 stack pointer = 0x10:0xc9d54c68 frame pointer = 0x10:0xc9d54c9c 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 = 7 (syncer) Also, in ddb, show map /f prints a never ending list of map objects. Is that normal or is my list corrupted somehow ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 15:45:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id 2AF1037B405; Sun, 9 Jun 2002 15:45:11 -0700 (PDT) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g59Mj6X49748; Sun, 9 Jun 2002 18:45:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 9 Jun 2002 18:45:06 -0400 (EDT) From: Jeff Roberson To: Ian Dowse Cc: jeff@freebsd.org, Subject: Re: Typo in uma_core.c causing panics after uma_zdestroy() In-Reply-To: <200206050224.aa96889@salmon.maths.tcd.ie> Message-ID: <20020609184443.N85064-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Jun 2002, Ian Dowse wrote: > > The logic for testing UMA_ZFLAG_INTERNAL in zone_dtor() is reversed. > I was able to reliably reproduce crashes with: > > mdconfig -a -t malloc -s 10m > mdconfig -d -u 0 > mdconfig -a -t malloc -s 10m > mdconfig -d -u 0 > > Ian > > Index: uma_core.c > =================================================================== > RCS file: /FreeBSD/FreeBSD-CVS/src/sys/vm/uma_core.c,v > retrieving revision 1.26 > diff -u -r1.26 uma_core.c > --- uma_core.c 3 Jun 2002 22:59:19 -0000 1.26 > +++ uma_core.c 5 Jun 2002 01:17:27 -0000 > @@ -1132,7 +1132,7 @@ > printf("Zone %s was not empty. Lost %d pages of memory.\n", > zone->uz_name, zone->uz_pages); > > - if ((zone->uz_flags & UMA_ZFLAG_INTERNAL) != 0) > + if ((zone->uz_flags & UMA_ZFLAG_INTERNAL) == 0) > for (cpu = 0; cpu < maxcpu; cpu++) > CPU_LOCK_FINI(zone, cpu); > > Looks great to me. Commit it? Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 16:19:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 47B4837B409; Sun, 9 Jun 2002 16:19:26 -0700 (PDT) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.3/8.12.3) with ESMTP id g59NJKHc001233 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 10 Jun 2002 01:19:23 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g59NJKSA059774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jun 2002 01:19:20 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g59NJJ7Q059773; Mon, 10 Jun 2002 01:19:19 +0200 (CEST)?g (envelope-from ticso) Date: Mon, 10 Jun 2002 01:19:19 +0200 From: Bernd Walter To: Poul-Henning Kamp Cc: alpha@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: alpha boot1 UFS support: HELP NEEDED! Message-ID: <20020609231919.GF39774@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <49229.1023279349@critter.freebsd.dk> <20020605122552.GJ66505@cicely5.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020605122552.GJ66505@cicely5.cicely.de> User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 05, 2002 at 02:25:53PM +0200, Bernd Walter wrote: > On Wed, Jun 05, 2002 at 02:15:49PM +0200, Poul-Henning Kamp wrote: > > > > Somebody who has an alpha at hand needs to make the alpha boot1 code > > use sys/boot/common/ufsread.c before June 19th where the UFS2 patch > > is scheduled to be committed. > > I'll take a look into this during the next WE. Not much success so far. ufsread.c triggers several size limitations on alpha. I'll let you know when I have it booting. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 18:15:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4CD2737B40A; Sun, 9 Jun 2002 18:15:25 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g5A1F4x7092968; Sun, 9 Jun 2002 21:15:04 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020609104850.GC25520@heechee.tobez.org> References: <20020608110834.A25686@dragon.nuxi.com> <20020608141128.D403-100000@femme.listmistress.org> <20020609104850.GC25520@heechee.tobez.org> Date: Sun, 9 Jun 2002 21:15:03 -0400 To: Anton Berezin , Trish Lynch From: Garance A Drosihn Subject: Re: perl wrapper and PATH Cc: current@FreeBSD.ORG, John Hay , Szilveszter Adam Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:48 PM +0200 6/9/02, Anton Berezin wrote: >On Sat, Jun 08, 2002 at 02:14:09PM -0400, Trish Lynch wrote: > > > Anton, if you don;t get around to it this weekend, mind > > if I take a stab at it? > >No, I don't mind at all. If only we can agree who does what. :-( RPI has been running with something like the perl wrapper on our systems for many years. It can be very useful, if it's done right. My fear is that everyone is hoping for some quick fix (something as quick as creating a symlink), and does not want to really think about what we want from this wrapper. I would argue we need to stop a minute and think of what we're doing, why we're doing it, and what result we want. We don't have to paint a lot of bikesheds, but we should think it through a bit more than we have so far. We (developers) have decided to make the incompatible system change of removing perl from the base system (a change that I completely agree with). This is an incompatible change, no matter how much we try to lessen the disruption from it. If we want to make this incompatible change on relatively short notice, then we must have a wrapper in /usr/bin/perl which works exactly as /usr/bin/perl worked when it was part of the base OS. We do not want a solution that starts out "users will just have to edit all the perl scripts they've ever done, and change...". That is not user-friendly. We (developers) are making this change, it is our responsibility to make it go smoothly. The perl wrapper should not depend on the setting of PATH. When perl was part of the base OS, then what you got by specifying /usr/bin/perl did not depend on the setting of PATH. The new wrapper should not. We do not know all the environments that all the user-written perl scripts will be running in. I do completely agree that it would be very useful if whatever we did for a wrapper did make it easier to have multiple versions of perl available. In fact, at RPI this is the *main* reason we have a wrapper for perl (and for several other interpretters). I have thoughts on how that version-selection could work, but that debate can wait. The main point I want to make right now is that the initial version of the wrapper should not depend on PATH. It should "just work" when the port is installed, and work in all situations. If 'use.perl port' is required for the wrapper to work in all situations, then the wrapper should say 'Run use.perl port' in addition to saying 'pkg_add -r perl'. I think it would be better if the use.perl step was not required, although obviously that script does need to be smarter in case someone does run it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 18:58:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 409EA37B410 for ; Sun, 9 Jun 2002 18:58:55 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id E0B358B5B5; Sun, 9 Jun 2002 18:58:53 -0700 (PDT) Message-ID: <3D0407DD.9FC040F9@FreeBSD.org> Date: Sun, 09 Jun 2002 18:58:53 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Anton Berezin , freebsd-current@FreeBSD.org Subject: Re: Head's up: NO_PERL -> NO_PERL_WRAPPER References: <3D032261.8CB94725@FreeBSD.org> <20020609105353.GD25520@heechee.tobez.org> <3D033825.C024679E@FreeBSD.org> <3D034AD8.F5EA3DDD@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > If we are expressing preferences, I prefer that it be called: > > NO_WE_CHANGE_THE_NAME_SO_YOU_GET_PERL_ANYWAY_`date "+%Y%m%d%H%M%S"` If we're expressing preferences, I think we should eliminate the wrapper altogether. > Just so that the name matches it's *real* function, which is apparently > to make sure that whatever variable you set to avoid getting perl last > time is totally ineffective in preventing you getting perl this time. But you're not getting perl, you're just getting the basically harmless wrapper. I had two choices with this change, I could either change the variable back to NOPERL which both A) Doesn't match the current pseudo-standard, and B) doesn't describe what it's actually doing. > I personally just consider it an unsubtle means of perl advocacy... I tend to agree with this. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 19:32:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 106DE37B401; Sun, 9 Jun 2002 19:32:08 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 753A48B5D1; Sun, 9 Jun 2002 19:32:07 -0700 (PDT) Message-ID: <3D040FA7.9D688E74@FreeBSD.org> Date: Sun, 09 Jun 2002 19:32:07 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Anton Berezin , current@FreeBSD.ORG, John Hay , Szilveszter Adam Subject: Re: perl wrapper and PATH References: <20020608110834.A25686@dragon.nuxi.com> <20020608141128.D403-100000@femme.listmistress.org> <20020609104850.GC25520@heechee.tobez.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > At 12:48 PM +0200 6/9/02, Anton Berezin wrote: > >On Sat, Jun 08, 2002 at 02:14:09PM -0400, Trish Lynch wrote: > > > > > Anton, if you don;t get around to it this weekend, mind > > > if I take a stab at it? > > > >No, I don't mind at all. If only we can agree who does what. :-( > > RPI has been running with something like the perl wrapper on our > systems for many years. It can be very useful, if it's done > right. My fear is that everyone is hoping for some quick fix > (something as quick as creating a symlink), and does not want > to really think about what we want from this wrapper. And yet, with the use.perl script installed as part of the port, we can provide a solution that IS, "as quick as creating a symlink." tobez and I were discussing it some last night, and we have an idea for just automatically doing the right thing for -current systems that have no perl installed. I agree that for users who want perl, we should have a /usr/bin/perl that "just works." I also agree that more thought needs to go into what form that takes. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 20:54:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from 141.com (mail1.141.com [65.168.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 77EE137B400 for ; Sun, 9 Jun 2002 20:54:22 -0700 (PDT) Received: from 141.com [151.200.58.53] by 141.com with ESMTP (SMTPD32-7.10) id A3333380010C; Sun, 09 Jun 2002 21:55:31 -0600 To: freebsd-current@freebsd.org Subject: one or two errors in installworld Date: Sun, 09 Jun 2002 23:54:22 -0400 From: Andrew Lankford Message-Id: <200206092155296.SM02244@141.com> X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [4000020e]. X-Note: This E-mail was scanned for spam. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the file /usr/src/share/sendmail/Makefile: copies:: .for dir in ${CFDIRS} ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 755 -d ${DDIR}/${dir} .endfor ...according to the fine man page, the -d option should appear before both the target directory and all the other options. Also, it appears that INSTALL is defined as "install -C", which I don't think is appropriate for use with the -d option either. I think I noticed a few "install -C -C ... " 's flash by before the last attempted installworld ground to a halt. Andrew Lankford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 20:57:32 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 4032037B404; Sun, 9 Jun 2002 20:57:13 -0700 (PDT) Date: Sun, 9 Jun 2002 20:57:13 -0700 From: "J. Mallett" To: Andrew Lankford Cc: freebsd-current@freebsd.org Subject: Re: one or two errors in installworld Message-ID: <20020609205713.A47754@FreeBSD.ORG> References: <200206092155296.SM02244@141.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206092155296.SM02244@141.com>; from arlankfo@141.com on Sun, Jun 09, 2002 at 11:54:22PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * From Andrew Lankford > > In the file /usr/src/share/sendmail/Makefile: > > copies:: > .for dir in ${CFDIRS} > ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 755 -d ${DDIR}/${dir} > .endfor > > ...according to the fine man page, the -d option should appear before both the > target directory and all the other options. > > Also, it appears that INSTALL is defined as "install -C", which I > don't think is appropriate for use with the -d option either. I > think I noticed a few "install -C -C ... " 's flash by before the > last attempted installworld ground to a halt. Change the override of INSTALL in /etc/make.conf. > Andrew Lankford > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- J. Mallett FreeBSD: The Power To Serve "I've coined new words, like, misunderstanding and Hispanically." -- George W. Bush, Radio-Television Correspondents Association dinner, Washington, D.C., March 29, 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 21:23:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from bgsv5505.tk.mesh.ad.jp (bgsv5504.tk.mesh.ad.jp [210.147.2.4]) by hub.freebsd.org (Postfix) with ESMTP id 1074F37B405 for ; Sun, 9 Jun 2002 21:23:08 -0700 (PDT) Received: from yyamada2 (ntoska031095.ftth2.ppp.infoweb.ne.jp) by bgsv5505.tk.mesh.ad.jp (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0GXH0092J2UHX3@bgsv5505.tk.mesh.ad.jp> for FreeBSD-current@FreeBSD.ORG; Mon, 10 Jun 2002 13:23:06 +0900 (JST) Date: Mon, 10 Jun 2002 13:23:17 +0900 From: yamada yositaka Subject: To: FreeBSD-current@FreeBSD.ORG Message-id: <001b01c21036$8b59c5f0$270b000a@yyamada2> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="----=_NextPart_000_0017_01C21081.FB2A8A90" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Priority: 3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C21081.FB2A8A90 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0017_01C21081.FB2A8A90 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0017_01C21081.FB2A8A90-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 21:28:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id C45DB37B406; Sun, 9 Jun 2002 21:28:26 -0700 (PDT) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.3/8.12.3) with ESMTP id g5A4SPQ9081844; Sun, 9 Jun 2002 21:28:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.3/8.12.3/Submit) id g5A4SPjF081843; Sun, 9 Jun 2002 21:28:25 -0700 (PDT) Date: Sun, 9 Jun 2002 21:28:25 -0700 From: Steve Kargl To: "J. Mallett" Cc: Andrew Lankford , freebsd-current@FreeBSD.ORG Subject: Re: one or two errors in installworld Message-ID: <20020609212825.A81804@troutmask.apl.washington.edu> References: <200206092155296.SM02244@141.com> <20020609205713.A47754@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020609205713.A47754@FreeBSD.ORG>; from jmallett@FreeBSD.ORG on Sun, Jun 09, 2002 at 08:57:13PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 09, 2002 at 08:57:13PM -0700, J. Mallett wrote: > * From Andrew Lankford > > > > In the file /usr/src/share/sendmail/Makefile: > > > > copies:: > > .for dir in ${CFDIRS} > > ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 755 -d ${DDIR}/${dir} > > .endfor > > > > ...according to the fine man page, the -d option should appear before both the > > target directory and all the other options. > > > > Also, it appears that INSTALL is defined as "install -C", which I > > don't think is appropriate for use with the -d option either. I > > think I noticed a few "install -C -C ... " 's flash by before the > > last attempted installworld ground to a halt. > > Change the override of INSTALL in /etc/make.conf. > This is bogus. [x]install should ignore options that conflict with -d. If you don't think it's bogus, then fix the documentation of make.conf and commit an UPDATING entry to warn everyone who set INSTALL several years ago. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 9 21:41:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 77C5937B400; Sun, 9 Jun 2002 21:40:50 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5A4ebj21169; Sun, 9 Jun 2002 22:40:37 -0600 (MDT) (envelope-from ken) Date: Sun, 9 Jun 2002 22:40:37 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020609224036.A21143@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have released a new zero copy sockets snapshot, the code and a brief update on what has been fixed is here: http://people.FreeBSD.org/~ken/zero_copy In short, I fixed the following things, which were found by Alfred Perlstein: - fix a race in the vm object allocation in jumbo_vm_init() - use a sysinit to initialize the jumbo_mutex, since there is really no other way to avoid a race between checking the mutex to see if it has been initialized and actually initializing it. - use SLIST_FIRST instead of directly accessing the first element in the inuse list. - don't call malloc(9) with M_WAITOK while holding a mutex. Between the last snapshot and this one, jhb (or someone else, can't remember who) turned on the WITNESS logging that flags when there is a potential sleep while a mutex is held. That has uncovered a whole slew of warnings in the zero copy code. Some of the warnings are present in the ti(4) driver without my patches, some of them are only triggered by the zero copy patches. Below is an abbreviated list of places where I found problems. Most of these problems are in areas where I could use some help to figure out what the best course of action to take is. So any comments on how to get these things fixed up (or better yet, code!) would be welcome! 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls ends up calling vm_map_entry_create(). vm_map_entry_create() calls uma_zalloc() with M_WAITOK. 2. sf_buf_init() calls malloc() *with* M_NOWAIT, but the VM code ends up calling vm_map_entry_create(), so you have the same problem as above. 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls ends up calling vm_map_entry_create(), same problem as above. 4. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls malloc() with M_WAITOK. 5. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls kthread_create(), which calls fork1(), which calls uma_zalloc() with M_WAITOK. 6. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls kthread_create(), which calls fork1(), which calls MALLOC() with M_WAITOK in various places. 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() with M_WAITOK. 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls vm_map_find(), which through several calls calls vm_map_entry_create(). 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), which does a uma_zalloc() with M_WAITOK. 11. ti_attach() calls bus_setup_intr(), which ends up calling ithread_add_handler() through several layers of indirection. ithread_add_handler() calls malloc with M_WAITOK. 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() calls vm_map_insert(), which calls vm_map_entry_create(), which calls uma_zalloc with M_WAITOK. 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization function), which calls kmem_alloc_pageable(). See number 1 above, same problem here with vm_map_entry_create(). 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() gets called, which calls vm_map_entry_create(), which calls uma_zalloc() with M_WAITOK. 15. several more instances, the same as 14, but vm_map_entry_create() gets called through a slightly different path from the same root malloc() call in jumbo_vm_init(). 16. ti_newbuf_std() calls MCLGET(), *with* M_DONTWAIT set, but m_clget() calls mb_alloc(), which calls mb_pop_cont(), which calls kmem_malloc(), which calls vm_map_insert(), which calls vm_map_entry_create(), which calls uma_zalloc() with M_WAITOK. I could keep going almost indefinitely, but I'm getting kinda tired of going through stack traces, and this is enough to talk about for the moment. There seem to be two general problems here: - the M_WAITOK call to uma_zalloc in vm_map_entry_create() is the cause of the problems in entries 1, 2, 3, 12, 13, 14, 15 and 16 - the bus_setup_intr(), or rather the kthread code in general apparantly isn't safe to be called while holding a mutex. This is the cause of the problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. Several of the interfaces, most notably malloc(), contigmalloc(), and MCLGET(), offer "don't wait" interfaces, but the functions that they call don't necessarily respect or know about those flags. There are a lot more problems I ran into, some similar to the ones above. This is enough to get started with. If anyone wants to see the full console log, it is available at: http://people.FreeBSD.org/~ken/zero_copy/session.log.20020609 There was one other problem I ran into that wasn't related to sleeping while holding a mutex: db> c lock order reversal 1st 0xe7920bc0 ti0 (network driver) @ /usr/home/ken/perforce/FreeBSD-zero/src/sys/pci/if_ti.c:2126 2nd 0xc036c7c0 allproc (allproc) @ /usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/kern_fork.c:309 Debugger("witness_lock") Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db> trace Debugger(c0318067) at Debugger+0x46 witness_lock(c036c7c0,8,c0311480,135,c04fcae8) at witness_lock+0x533 _sx_xlock(c036c7c0,c0311480,135,c01dc94b,c03cae10) at _sx_xlock+0x7d fork1(c0367d00,60034,c04fcabc) at fork1+0x1a0 kthread_create(c01d59c0,d8364400,c04fcae8,60000,c0311841) at kthread_create+0x37 ithread_create(c04fcb1c,10,0,c02e197a,c02e192c,c03381fd,10) at ithread_create+0x96 inthand_add(e7929480,10,c027aec4,e791e000,4) at inthand_add+0x6e nexus_setup_intr(e5dc4a00,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at nexus_setup_intr+0x61 bus_generic_setup_intr(e5dc4600,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at bus_generic_setup_intr+0x77 bus_generic_setup_intr(e7938700,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at bus_generic_setup_intr+0x77 bus_setup_intr(e7938600,e78f37c0,4,c027aec4,e791e000) at bus_setup_intr+0x79 ti_attach(e7938600) at ti_attach+0x226 device_probe_and_attach(e7938600) at device_probe_and_attach+0x9c bus_generic_attach(e7938700) at bus_generic_attach+0x14 device_probe_and_attach(e7938700) at device_probe_and_attach+0x9c bus_generic_attach(e5dc4600,e5dc4600,c03398b8,2,e5dc4600) at bus_generic_attach+0x14 nexus_pcib_attach(e5dc4600) at nexus_pcib_attach+0x21 device_probe_and_attach(e5dc4600) at device_probe_and_attach+0x9c bus_generic_attach(e5dc4a00,e5dc4a00,e788f090,e5dc4a00,c04fcd60) at bus_generic_attach+0x14 nexus_attach(e5dc4a00) at nexus_attach+0xf device_probe_and_attach(e5dc4a00) at device_probe_and_attach+0x9c root_bus_configure(e5dc4c80,c0331000,0) at root_bus_configure+0x16 configure(0,4f9c00,4f9000,0,c012a1cc) at configure+0x20 mi_startup() at mi_startup+0x93 begin() at begin+0x43 db> c As I said above, any comments would be welcome! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 1:47:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 15DCF37B407; Mon, 10 Jun 2002 01:47:47 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17HKpx-0000ql-00; Mon, 10 Jun 2002 12:47:41 +0400 Subject: Re: New ipfw code available From: "Vladimir B. " Grebenschikov To: Luigi Rizzo Cc: ipfw@freebsd.org, "current@freebsd.org" In-Reply-To: <20020608201909.A41807@iguana.icir.org> References: <20020608201909.A41807@iguana.icir.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:47:40 +0400 Message-Id: <1023698860.576.29.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =F7 Sun, 09.06.2002, =D7 07:19, Luigi Rizzo =CE=C1=D0=C9=D3=C1=CC: Hi > over the past 2-3 weeks I have done an extensive rewrite of the > ipfw code (userland + kernel) in an attempt to make it faster and > more flexible. >=20 > The idea (which I discussed a few times on the mailing lists) was > to replace the current ipfw rules (macroinstructions) with a set > of microinstructions, each of them performing a single operation > such as matching an address, or a port range, or a protocol flag, > etc. -- much in the spirit of BPF and derivatives -- and to let > the userland front-end compile ipfw(8) commands into an appropriate > set of microinstructions. Really COOL!=20 And what about radix-tree-based ip-list matching ? like this: ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30} or cat mylist | ipfw list add mylist - ipfw add 1 allow ip from @mylist or something like=20 If you deal with large access-lists ipfw becomes not best tool due to linear comparison. > translates to a couple of microinstructions (whose complete > implementation is below the instructions themselves): >=20 > O_IP_DST=20 > if (((ipfw_insn_ip *)cmd)->addr.s_addr =3D=3D > (dst_ip.s_addr & ((ipfw_insn_ip *)cmd)->mask.s_addr)) > goto cmd_match; > goto cmd_fail; >=20 > O_ACCEPT: > retval =3D 0; /* accept */ > goto accept; >=20 >=20 > But there is a lot more -- the instruction set is easily extensible, > and without backward compatibility problems. Furthermore, you can > build (and I have already implemented them) more complex rules by > assembling microinstructions with OR and NOT operands. I.e. you can write > something like: >=20 > pipe 10 tcp from 1.2.3.4 or 1.2.3.7 or not 1.2.3.0/28 21-25,1024-4095 \ > to any in recv ed0 or recv fxp1 or recv dc0 uid 35 or uid 50 >=20 > You get the idea...=20 >=20 > I have a fairly complete version of the above code at the moment, > which is only missing a small set of functionalities > (ip/tcp flags matching, "log" and fixing hooks to the stateful > code). However the glue to implement all the missing pieces is > already there, it is just a matter of adding a few lines of code > and testing things. > Other than that, the code is meant to be fully compatible with the > old syntax so you will not have to rewrite your existing rulesets. >=20 > I have put a preliminary snapshot of this code (for CURRENT) at >=20 > http://info.iet.unipi.it/~luigi/ipfw5.20020609.tgz >=20 > It replaces the following files from a recent (2002/05/14) version of -cu= rrent. >=20 > sys/netinet/ip_dummynet.c > sys/netinet/ip_fw.c > sys/netinet/ip_fw.h > sbin/ipfw/ipfw.c >=20 > I would be very grateful if someone could have a look at the > code, maybe give it a try, and see e.g. how it compiles your > typical ruleset and whether the new extensions can make your > ipfw rulesets simpler. >=20 > Feedback welcome, both on the architecture and on the implementation. >=20 > NOTE: if people wonder why I did not use BPF and reinvented the wheel: > the keyword is "backward compatiblity" -- i thought it was a bit too > complex to compile the existent ipfw syntax into BPF, especially because > BPF at least as far as i know does not handle UIDs, and GIDs and > interface matches and different "actions" than match or not match, > so i would have had to extend the code anyways, at which point i > thought I could as well write my own microinstruction set... >=20 > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > to=20 >=20 > thanks > luigi >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 2:27:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 9D24E37B409; Mon, 10 Jun 2002 02:27:13 -0700 (PDT) Received: from kokeb.ambesa.net ([64.173.9.235]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXH008XSGXDSG@mta6.snfc21.pbi.net>; Mon, 10 Jun 2002 02:27:13 -0700 (PDT) Received: from kokeb.ambesa.net (dev1ant@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5A9WTVF008407; Mon, 10 Jun 2002 02:32:29 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5A9WPe1008406; Mon, 10 Jun 2002 02:32:25 -0700 (PDT envelope-from mikem) Date: Mon, 10 Jun 2002 02:32:24 -0700 From: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 In-reply-to: To: John Baldwin Cc: freebsd-current@FreeBSD.ORG, jrh@lab.it.uc3m.es, hiten@uk.FreeBSD.org Message-id: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200206081214.g58CEYmq006939@kokeb.ambesa.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 08 Jun 2002 10:57:32 -0400 (EDT) John Baldwin wrote: > > > > Is the solution to this to use M_NOWAIT and continue re-trying untill it> > succeeds? Is there on-going smp work in locking down struct proc that> > will eliminate this problem? > > Well, the real solution probably involves changing where we dink with > uidinfo structs so we bump the reference count on teh new one before we> grab the proc lock, change over to the new one while holding the proc lock,> then release the reference to the old one after we are done. > Well... this is basically what happens setuid - creates a new ucred - locks p - calls change_ruid() change_ruid - calls uifind() uifind - does MALLOC w/ M_WAITOK After thinking about it for a while, this is the solution I came up with: Each new struct ucred will carry an array of pointers to struct uidinfo. This will be an array of 3 elements (a spare for cr_ruidinfo, cr_uidinfo, null). Obviously, it gets added after ->cr_endcopy. When crget() is called it calls a function whose job it is to create an array of pointers to struct uidinfo and allocate the memory for them. When uifind() is called it will be given an array of pointers to uidinfo structs (the ones from ucred), in addition to the uid it is to lookup. If it already has a uidinfo for that uid, then it returns that to the calling function. If it can't find the uid, then it unhooks (copies the address, and deletes it from the array) the last struct uidinfo from the array, initializes it, inserts it into the hashtable and returns it to the caller. When crfree is called it calls a function that deallocates the spare structs uidinfo. This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 2:47:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C65CC37B408; Mon, 10 Jun 2002 02:47:30 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5A9lQ455217; Mon, 10 Jun 2002 02:47:26 -0700 (PDT) (envelope-from rizzo) Date: Mon, 10 Jun 2002 02:47:26 -0700 From: Luigi Rizzo To: "Vladimir B. Grebenschikov" Cc: ipfw@freebsd.org, "current@freebsd.org" Subject: Re: New ipfw code available Message-ID: <20020610024726.A54631@iguana.icir.org> References: <20020608201909.A41807@iguana.icir.org> <1023698860.576.29.camel@vbook.express.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1023698860.576.29.camel@vbook.express.ru>; from vova@sw.ru on Mon, Jun 10, 2002 at 12:47:40PM +0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 12:47:40PM +0400, Vladimir B. Grebenschikov wrote: ... > And what about radix-tree-based ip-list matching ? yes, it is planned. cheers luigi > > ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30} > or > cat mylist | ipfw list add mylist - > ipfw add 1 allow ip from @mylist > > or something like > > If you deal with large access-lists ipfw becomes not best tool due to > linear comparison. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 2:52: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11403.mail.yahoo.com (web11403.mail.yahoo.com [216.136.131.233]) by hub.freebsd.org (Postfix) with SMTP id 1C8E137B401 for ; Mon, 10 Jun 2002 02:52:02 -0700 (PDT) Message-ID: <20020610095202.95307.qmail@web11403.mail.yahoo.com> Received: from [202.167.61.228] by web11403.mail.yahoo.com via HTTP; Mon, 10 Jun 2002 02:52:02 PDT Date: Mon, 10 Jun 2002 02:52:02 -0700 (PDT) From: Shizuka Kudo Subject: Re: My postgresql7 not working for new gcc To: aaron g , freebsd-current@freebsd.org Cc: shizukakudo_99@yahoo.com In-Reply-To: <20020606202609.31716.qmail@operamail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- aaron g wrote: > I do beleive the OpenSSL library has moved to a new > default > location. I could be wrong. > > - aarong > -- I don't think it has been moved as of yestersday. Regards, shizuka# ls -al /usr/include/openssl/ssl.h -r--r--r-- 1 root wheel 60914 Jun 9 02:30 /usr/include/openssl/ssl.h __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 3: 1:29 2002 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-56.dsl.lsan03.pacbell.net [63.207.60.56]) by hub.freebsd.org (Postfix) with ESMTP id 5E3CD37B403 for ; Mon, 10 Jun 2002 03:01:24 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 03D4E66D83; Mon, 10 Jun 2002 03:01:21 -0700 (PDT) Date: Mon, 10 Jun 2002 03:01:21 -0700 From: Kris Kennaway To: Shizuka Kudo Cc: aaron g , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc Message-ID: <20020610030121.A25480@xor.obsecurity.org> References: <20020606202609.31716.qmail@operamail.com> <20020610095202.95307.qmail@web11403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020610095202.95307.qmail@web11403.mail.yahoo.com>; from shizukakudo_99@yahoo.com on Mon, Jun 10, 2002 at 02:52:02AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2002 at 02:52:02AM -0700, Shizuka Kudo wrote: >=20 > --- aaron g wrote: > > I do beleive the OpenSSL library has moved to a new > > default > > location. I could be wrong. > >=20 > > - aarong > > --=20 >=20 > I don't think it has been moved as of yestersday. OpenSSL has not moved (and is not expected to be moved). Kris --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9BHjwWry0BWjoQKURAsxCAJ916AVGCP8XJoah6pL0vMWXcX903gCg1hWM v79coEUh5bYNderEwa2Wv3I= =XU+f -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 4:46:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from daemonz.org (TK212017094177.teleweb.at [212.17.94.177]) by hub.freebsd.org (Postfix) with SMTP id BA26437B413 for ; Mon, 10 Jun 2002 04:45:56 -0700 (PDT) Received: (qmail 91991 invoked by uid 1001); 10 Jun 2002 11:51:50 -0000 Date: Mon, 10 Jun 2002 13:51:50 +0200 From: Stanislav Grozev To: Shizuka Kudo Cc: freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc Message-ID: <20020610115150.GA91765@meerkat.dungeon> References: <20020601195008.GJ17045@elvis.mu.org> <20020605113540.62177.qmail@web11402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020605113540.62177.qmail@web11402.mail.yahoo.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 05, 2002 at 04:35:40AM -0700, Shizuka Kudo wrote: > checking for readline/readline.h... no > checking for readline.h... no > checking for readline/history.h... no > checking for history.h... no > checking for openssl/ssl.h... no > configure: error: header file is > required for OpenSSL > actually that is a problem with the autoconf version used by postgresql. the new gcc 3.1 gives out a warning if one of the system include directories is also given as a -I argument (in this case -I/usr/include). the autoconf, when compiling the test program, mistakenly interprets this warning as an error, and decides that the feature is not present, thus giving that openssl/ssl.h is not present, and in fact it is. one messy and temporary solution is to compile with make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w which tells gcc to pass -w to the preprocessor, and -w means inhibit all warnings. with this, postgresql compiles and works fine. for 'correct' solution - the configure script for postgresql must be regenerated from configure.in, using the newer autoconf, but I am not sure whether that would be successfull, as there were (AFAIK), some incompatibilities between the two - but i may be wrong. anyway, HTH -tacho -- [a lie is my shield] | [http://daemonz.org/ || tacho@daemonz.org] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 4:48:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mercury.gennex.com.au (CPE-144-132-60-7.vic.bigpond.net.au [144.132.60.7]) by hub.freebsd.org (Postfix) with ESMTP id CF5CB37B406 for ; Mon, 10 Jun 2002 04:48:33 -0700 (PDT) Received: from mercury.gennex.com.au (localhost [127.0.0.1]) by mercury.gennex.com.au (8.12.3/8.11.6) with ESMTP id g5ABmUXs015847 for ; Mon, 10 Jun 2002 21:48:31 +1000 (EST) (envelope-from spenno01@mercury.gennex.com.au) Received: (from spenno01@localhost) by mercury.gennex.com.au (8.12.3/8.12.3/Submit) id g5ABmT2i015846 for current@freebsd.org; Mon, 10 Jun 2002 21:48:29 +1000 (EST) Date: Mon, 10 Jun 2002 21:48:29 +1000 (EST) From: Scott Penno Message-Id: <200206101148.g5ABmT2i015846@mercury.gennex.com.au> To: current@freebsd.org Subject: Problems building world in kdump Reply-To: scott.penno@gennex.com.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there, I've been attempting to build current on and off over the past few weeks with little success. Problems occur when making dependencies within kdump as shown below. Sources last update June 9, 2002 at 12:30 GMT. I've been through UPDATING, README and mailling lists to no avail. Any assistance appreciated. Regards, Scott. ===> usr.bin/kdump sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include > ioctl.c cpp0: warning: changing search order for system directory "/usr/obj/usr/src/i386/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/obj/usr/src/i386/usr/include" cpp0: warning: as it has already been specified as a non-system directory In file included from /usr/obj/usr/src/i386/usr/include/sys/param.h:107, from /usr/obj/usr/src/i386/usr/include/security/lomac/lomacio.h:42, from :49: /usr/obj/usr/src/i386/usr/include/machine/limits.h:71:1: warning: "INT_MAX" redefined In file included from :23: /usr/obj/usr/src/i386/usr/include/machine/if_wl_wavelan.h:149:1: warning: this is the location of the previous definition In file included from :70: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:19:1: warning: "MDF_ACTIVE" redefined In file included from :47: /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:115:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:860:1: warning: "EATAUSRCMD" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:265:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:861:1: warning: "DPT_SIGNATURE" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:269:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:862:1: warning: "DPT_NUMCTRLS" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:274:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:863:1: warning: "DPT_CTRLINFO" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:276:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:864:1: warning: "DPT_SYSINFO" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:282:1: warning: this is the location of the previous definition In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:865:1: warning: "DPT_BLINKLED" redefined In file included from :97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:288:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:379:1: warning: "LUN_MASK" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:138:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:380:1: warning: "TARGET_MASK" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:135:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:381:1: warning: "BUS_MASK" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:136:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:382:1: warning: "HBA_MASK" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:137:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:384:1: warning: "minor2lun" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:143:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:385:1: warning: "minor2target" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:140:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:386:1: warning: "minor2bus" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:141:1: warning: this is the location of the previous definition In file included from :101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:387:1: warning: "minor2hba" redefined In file included from :100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:142:1: warning: this is the location of the previous definition In file included from :123: /usr/obj/usr/src/i386/usr/include/vm/i386/ibcs2/ibcs2_socksys.h:33:36: i386/ibcs2/ibcs2_types.h: No such file or directory In file included from :147: /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:51:22: opt_pcvt.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:79:28: dev/kbd/kbdreg.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:80:31: dev/kbd/atkbdcreg.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:82:37: i386/isa/pcvt/pcvt_conf.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:103:1: warning: "KB_OTHER" redefined In file included from :68: /usr/obj/usr/src/i386/usr/include/sys/kbio.h:47:1: warning: this is the location of the previous definition In file included from :147: /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:135:2: #error "Supported keyboard scancode sets are 1 and 2 only (for now)!!!" In file included from :163: /usr/obj/usr/src/i386/usr/include/vm/pc98/pc98/wormio.h:102:1: warning: "CDRIOCBLANK" redefined In file included from :54: /usr/obj/usr/src/i386/usr/include/sys/cdrio.h:88:1: warning: this is the location of the previous definition rm -f .depend mkdep -f .depend -a -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. /usr/src/usr.bin/kdump/kdump.c ioctl.c /usr/src/usr.bin/kdump/../ktrace/subr.c In file included from ioctl.c:149: /usr/obj/usr/src/i386/usr/include/vm/i386/ibcs2/ibcs2_socksys.h:33:36: i386/ibcs2/ibcs2_types.h: No such file or directory In file included from ioctl.c:173: /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:51:22: opt_pcvt.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:79:28: dev/kbd/kbdreg.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:80:31: dev/kbd/atkbdcreg.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:82:37: i386/isa/pcvt/pcvt_conf.h: No such file or directory /usr/obj/usr/src/i386/usr/include/vm/i386/isa/pcvt/pcvt_hdr.h:135:2: #error "Supported keyboard scancode sets are 1 and 2 only (for now)!!!" ioctl.c:2576:21: macro "_IOR" requires 3 arguments, but only 2 given mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 7: 4: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id B428A37B40A for ; Mon, 10 Jun 2002 07:03:56 -0700 (PDT) Received: from pool0033.cvx22-bradley.dialup.earthlink.net ([209.179.198.33] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HPlx-0001zp-00; Mon, 10 Jun 2002 07:03:54 -0700 Message-ID: <3D04B166.950171E2@mindspring.com> Date: Mon, 10 Jun 2002 07:02:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stanislav Grozev Cc: Shizuka Kudo , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc References: <20020601195008.GJ17045@elvis.mu.org> <20020605113540.62177.qmail@web11402.mail.yahoo.com> <20020610115150.GA91765@meerkat.dungeon> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Stanislav Grozev wrote: > actually that is a problem with the autoconf version used by postgresql. > the new gcc 3.1 gives out a warning if one of the system include directories > is also given as a -I argument (in this case -I/usr/include). > the autoconf, when compiling the test program, mistakenly interprets > this warning as an error, and decides that the feature is not present, > thus giving that openssl/ssl.h is not present, and in fact it is. > one messy and temporary solution is to compile with > make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w > which tells gcc to pass -w to the preprocessor, and -w means inhibit > all warnings. with this, postgresql compiles and works fine. > for 'correct' solution - the configure script for postgresql must be > regenerated from configure.in, using the newer autoconf, but I am not > sure whether that would be successfull, as there were (AFAIK), some > incompatibilities between the two - but i may be wrong. > anyway, HTH That's ugly. Since it's jamming in includes anyway: By using both `-nostdinc' and `-I-', you can limit the include-file search file to only those directo- ries you specify explicitly. e.g.: you should be able to get it to work with warnings fully enabled, and explicit use of system include paths in the Makefile. This might be a more permanent fix... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 7: 6:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from pc-ugarte.research.att.com (H-135-207-23-230.research.att.com [135.207.23.230]) by hub.freebsd.org (Postfix) with ESMTP id 649D337B407 for ; Mon, 10 Jun 2002 07:06:45 -0700 (PDT) Received: (from cau@localhost) by pc-ugarte.research.att.com (8.11.0/8.11.0) id g5AE5v516323; Mon, 10 Jun 2002 10:05:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15620.45637.197810.405400@pc-ugarte.research.att.com> Date: Mon, 10 Jun 2002 10:05:57 -0400 From: Carlos Ugarte To: Maksim Yevmenkin Cc: current@FreeBSD.ORG Subject: Re: -current (DP1) and USB transfers In-Reply-To: <20020609193410.63290.qmail@web13302.mail.yahoo.com> References: <20020609193410.63290.qmail@web13302.mail.yahoo.com> X-Mailer: VM 6.99 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Homepage: http://www.cs.arizona.edu/~cau Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maksim Yevmenkin writes: > The problem is that as soon as i open isochronous pipe and > start incoming isochronous transfer, the isochronous callback > gets called over and over again. Both isoc. pipe and isoc. > transfer have USBD_NO_SHORT_XFER flag set. I also set > configuration #5 for interface 1. The funny part that device > says that it got zero bytes from the pipe. It does not affect > (or so it seems) the other transfers and everything still works. > I also tried ugen driver with the same results. What is up with > that? My experience with isochronous pipes is the same. I'm working with a couple of webcams and the isoc callback is invoked repeatedly, but always with a size of 0. This occurs in both -stable and -current, tested on two different UHCI chipsets. I also played around with ugen (stock ugen and a userland driver, as well as a "custom ugen") but the results were the same. While I have no other USB devices to try out under FreeBSD, my guess is that the problems are mainly with isoc transfers; there are plenty of supported devices using bulk and interrupt transfers but there is only one case I'm aware of that makes use of isoc transfers. Reportedly a different webcam works under 4.6-RC using ugen and a userland program (/usr/ports/graphics/vid). I'm also a USB newbie so I cannot answer your other questions. Carlos -- Carlos A. Ugarte cau@CS.Arizona.EDU To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 7:52:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from daemonz.org (TK212017094177.teleweb.at [212.17.94.177]) by hub.freebsd.org (Postfix) with SMTP id 51D8A37B405 for ; Mon, 10 Jun 2002 07:52:14 -0700 (PDT) Received: (qmail 53662 invoked by uid 1001); 10 Jun 2002 14:58:13 -0000 Date: Mon, 10 Jun 2002 16:58:13 +0200 From: Stanislav Grozev To: Terry Lambert Cc: freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc Message-ID: <20020610145813.GA50547@meerkat.dungeon> References: <20020601195008.GJ17045@elvis.mu.org> <20020605113540.62177.qmail@web11402.mail.yahoo.com> <20020610115150.GA91765@meerkat.dungeon> <3D04B166.950171E2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D04B166.950171E2@mindspring.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 07:02:14AM -0700, Terry Lambert wrote: > Stanislav Grozev wrote: > That's ugly. well, i _did_ mention that it's a messy and a temporary solution, but at least it gets postgresql (and many others) to compile and run fine. > > Since it's jamming in includes anyway: > > By using both `-nostdinc' and `-I-', you can limit > the include-file search file to only those directo- > ries you specify explicitly. > > e.g.: you should be able to get it to work with warnings fully > enabled, and explicit use of system include paths in the Makefile. > > This might be a more permanent fix... I agree... but still I don't see the point in that warning, which is useless (IMHO) in 99% of the cases (normal development) and in the 1% where it is usefull (gcc devel, libc, etc.) the people doing it already know their stuff and know what they're doing. but I digress... > > -- Terry > -tacho -- [a lie is my shield] | [http://daemonz.org/ || tacho@daemonz.org] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 8:39:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4C7A337B408 for ; Mon, 10 Jun 2002 08:39:24 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5AFdLJn037660; Mon, 10 Jun 2002 08:39:21 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g5AFdLYD037659; Mon, 10 Jun 2002 08:39:21 -0700 (PDT) Date: Mon, 10 Jun 2002 08:39:21 -0700 From: "David O'Brien" To: Terry Lambert Cc: Stanislav Grozev , Shizuka Kudo , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc Message-ID: <20020610083921.A37639@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020601195008.GJ17045@elvis.mu.org> <20020605113540.62177.qmail@web11402.mail.yahoo.com> <20020610115150.GA91765@meerkat.dungeon> <3D04B166.950171E2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D04B166.950171E2@mindspring.com>; from tlambert2@mindspring.com on Mon, Jun 10, 2002 at 07:02:14AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 07:02:14AM -0700, Terry Lambert wrote: > > one messy and temporary solution is to compile with > > make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w > > which tells gcc to pass -w to the preprocessor, and -w means inhibit > > all warnings. with this, postgresql compiles and works fine. > > for 'correct' solution - the configure script for postgresql must be > > regenerated from configure.in, using the newer autoconf, but I am not > > sure whether that would be successfull, as there were (AFAIK), some > > incompatibilities between the two - but i may be wrong. > > anyway, HTH > > That's ugly. > > Since it's jamming in includes anyway: > > By using both `-nostdinc' and `-I-', you can limit > the include-file search file to only those directo- > ries you specify explicitly. > > e.g.: you should be able to get it to work with warnings fully > enabled, and explicit use of system include paths in the Makefile. > > This might be a more permanent fix... *sigh*, why not a *real* fix? --- configure.in.orig Thu Sep 27 01:03:56 2001 +++ configure.in Mon Apr 29 13:20:27 2002 @@ -200,7 +200,9 @@ done if test "$ac_found_openssl_lib_dir" != "no"; then echo "found in $ac_found_openssl_lib_dir" - INCLUDES="-I$ac_found_openssl_inc_dir $INCLUDES" + if test "$ac_found_openssl_inc_dir" != "/usr/include"; then + INCLUDES="-I$ac_found_openssl_inc_dir $INCLUDES" + fi DEFINES="-DOPENSSL $DEFINES" else echo "not found." You'll note that they bother with this kind of check for other headers, but for some reason didn't consider it for openssl headers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 9:13: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from taz.sindrome.net (taz.sindrome.net [209.172.186.231]) by hub.freebsd.org (Postfix) with ESMTP id 940F237B409 for ; Mon, 10 Jun 2002 09:12:59 -0700 (PDT) Received: from taz.sindrome.net (taz.sindrome.net [209.172.186.231] (may be forged)) by taz.sindrome.net (8.12.3/8.12.3) with ESMTP id g5AGCw0N031339 for ; Mon, 10 Jun 2002 11:12:59 -0500 (CDT) (envelope-from sindrome@sindrome.net) Received: (from sindrome@localhost) by taz.sindrome.net (8.12.3/8.12.3/Submit) id g5AGCwKO031338 for freebsd-current@FreeBSD.ORG; Mon, 10 Jun 2002 11:12:58 -0500 (CDT) X-Authentication-Warning: taz.sindrome.net: sindrome set sender to sindrome@sindrome.net using -f Date: Mon, 10 Jun 2002 11:12:58 -0500 From: Troy To: freebsd-current@FreeBSD.ORG Subject: Kernel breakage in XE module Message-ID: <20020610111258.A31326@sindrome.net> Reply-To: sindrome@sindrome.net Mail-Followup-To: freebsd-current@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Been trying to buildkernel, and as of about 2 weeks ago something happened to the XE module. Anyone have some ideas? -Troy ===> xe @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend CC='/usr/bin/cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/mod ules/xe/../../dev/xe/if_xe.c /usr/src/sys/modules/xe/../../dev/xe/if_xe_pccard.c cd /usr/obj/usr/src/sys/SINDROME; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH= /usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/l ibexec make KERNEL=kernel all /usr/bin/cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winl ine -Wcast-qual -Wno-format -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src /sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/us r/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding /usr/src/sys/i386/i386/locore.s {standard input}: Assembler messages: {standard input}:1684: Warning: rest of line ignored; first ignored character is `t' {standard input}:1686: Error: unknown pseudo-op: `.' {standard input}:1801: Error: missing ')' {standard input}:1801: Error: missing ')' {standard input}:1801: Error: junk `tmpstk)- 0xc0000000)' after expression *** Error code 1 Stop in /usr/obj/usr/src/sys/SINDROME. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 9:21:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 0050637B40A for ; Mon, 10 Jun 2002 09:21:38 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.12.3/8.12.3) id g5AGLb0F055658; Mon, 10 Jun 2002 11:21:37 -0500 (CDT) (envelope-from dan) Date: Mon, 10 Jun 2002 11:21:36 -0500 From: Dan Nelson To: Troy Cc: freebsd-current@FreeBSD.ORG Subject: Re: Kernel breakage in XE module Message-ID: <20020610162136.GA54696@dan.emsphone.com> References: <20020610111258.A31326@sindrome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020610111258.A31326@sindrome.net> User-Agent: Mutt/1.3.99i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Jun 10), Troy said: > Been trying to buildkernel, and as of about 2 weeks ago something > happened to the XE module. Anyone have some ideas? Upgrade your gcc in the base system. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 10: 5: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id 3438B37B481 for ; Mon, 10 Jun 2002 10:02:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mharnois.mdharnois.net (Postfix) with ESMTP id D31DC3C9E for ; Mon, 10 Jun 2002 12:02:41 -0500 (CDT) Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries From: "Michael D. Harnois" To: freebsd-current@FreeBSD.ORG In-Reply-To: <20020609.233703.730560602.ken@tydfam.jp> References: <20020609.233703.730560602.ken@tydfam.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:02:41 -0500 Message-Id: <1023728561.7633.31.camel@mharnois.mdharnois.net> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 2L, UST School of Law Minneapolis, Minnesota If you want to follow Jesus, you better look good on wood. --Daniel Berrigan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 10:16:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 138E937B493 for ; Mon, 10 Jun 2002 10:13:53 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5AHDpJn068553; Mon, 10 Jun 2002 10:13:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g5AHDoHn068549; Mon, 10 Jun 2002 10:13:50 -0700 (PDT) Date: Mon, 10 Jun 2002 10:13:50 -0700 From: "David O'Brien" To: "Michael D. Harnois" Cc: freebsd-current@FreeBSD.ORG Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries Message-ID: <20020610101350.A68466@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020609.233703.730560602.ken@tydfam.jp> <1023728561.7633.31.camel@mharnois.mdharnois.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023728561.7633.31.camel@mharnois.mdharnois.net>; from mharnois@cpinternet.com on Mon, Jun 10, 2002 at 12:02:41PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: > The libraries build for me without incident. However, anything which > tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 10:18:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id 38C0C37B98B; Mon, 10 Jun 2002 10:15:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mharnois.mdharnois.net (Postfix) with ESMTP id 958553C9E; Mon, 10 Jun 2002 12:15:40 -0500 (CDT) Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries From: "Michael D. Harnois" To: obrien@FreeBSD.ORG Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <20020610101350.A68466@dragon.nuxi.com> References: <20020609.233703.730560602.ken@tydfam.jp> <1023728561.7633.31.camel@mharnois.mdharnois.net> <20020610101350.A68466@dragon.nuxi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:15:40 -0500 Message-Id: <1023729340.7633.37.camel@mharnois.mdharnois.net> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2002-06-10 at 12:13, David O'Brien wrote: > On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: > > The libraries build for me without incident. However, anything which > > tries to link against libGLU generates this error for me: > > Your current is too old. Please do a fresh build. Since 6:30 last night? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 2L, UST School of Law Minneapolis, Minnesota Wise men talk because they have something to say; fools, because they have to say something. -- Plato To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 10:26:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id C2D5337B43A for ; Mon, 10 Jun 2002 10:26:37 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5AHQaJn081356; Mon, 10 Jun 2002 10:26:36 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g5AHQaXu081355; Mon, 10 Jun 2002 10:26:36 -0700 (PDT) Date: Mon, 10 Jun 2002 10:26:36 -0700 From: "David O'Brien" To: "Michael D. Harnois" Cc: freebsd-current@FreeBSD.ORG Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries Message-ID: <20020610102635.A79571@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020609.233703.730560602.ken@tydfam.jp> <1023728561.7633.31.camel@mharnois.mdharnois.net> <20020610101350.A68466@dragon.nuxi.com> <1023729340.7633.37.camel@mharnois.mdharnois.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023729340.7633.37.camel@mharnois.mdharnois.net>; from mharnois@cpinternet.com on Mon, Jun 10, 2002 at 12:15:40PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 12:15:40PM -0500, Michael D. Harnois wrote: > On Mon, 2002-06-10 at 12:13, David O'Brien wrote: > > On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: > > > The libraries build for me without incident. However, anything which > > > tries to link against libGLU generates this error for me: > > > > Your current is too old. Please do a fresh build. > > Since 6:30 last night? You must have NO_CXX or something -- you aren't linking with the C++ support libs for some reason. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 11: 5:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id A9E5C37B4A7; Mon, 10 Jun 2002 11:03:01 -0700 (PDT) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXI0002E4T1I2@mta6.snfc21.pbi.net>; Mon, 10 Jun 2002 11:03:01 -0700 (PDT) Date: Mon, 10 Jun 2002 11:03:09 -0700 From: Jeffrey Hsu Subject: Re: new zero copy sockets snapshot, WITNESS problems In-reply-to: "Message from Kenneth D. Merry" "of Sun, 09 Jun 2002 22:40:37 MDT." <20020609224036.A21143@panzer.kdm.org> To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Message-id: <0GXI0002F4T1I2@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls > ends up calling vm_map_entry_create(). vm_map_entry_create() calls > uma_zalloc() with M_WAITOK. Alan Cox and Tor Egge just fixed this in -current in rev 1.247 of vm_map.c. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 11:10:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11405.mail.yahoo.com (web11405.mail.yahoo.com [216.136.131.235]) by hub.freebsd.org (Postfix) with SMTP id EB15837B66F for ; Mon, 10 Jun 2002 11:09:39 -0700 (PDT) Message-ID: <20020610180939.94228.qmail@web11405.mail.yahoo.com> Received: from [203.198.23.169] by web11405.mail.yahoo.com via HTTP; Mon, 10 Jun 2002 11:09:39 PDT Date: Mon, 10 Jun 2002 11:09:39 -0700 (PDT) From: Shizuka Kudo Subject: Re: My postgresql7 not working for new gcc To: obrien@freebsd.org, Terry Lambert Cc: Stanislav Grozev , Shizuka Kudo , freebsd-current@freebsd.org In-Reply-To: <20020610083921.A37639@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- David O'Brien wrote: > > *sigh*, why not a *real* fix? > > --- configure.in.orig Thu Sep 27 01:03:56 2001 > +++ configure.in Mon Apr 29 13:20:27 2002 > @@ -200,7 +200,9 @@ > done > if test "$ac_found_openssl_lib_dir" != "no"; then > echo "found in $ac_found_openssl_lib_dir" > - INCLUDES="-I$ac_found_openssl_inc_dir $INCLUDES" > + if test "$ac_found_openssl_inc_dir" != > "/usr/include"; then > + INCLUDES="-I$ac_found_openssl_inc_dir > $INCLUDES" > + fi > DEFINES="-DOPENSSL $DEFINES" > else > echo "not found." > > > You'll note that they bother with this kind of check > for other headers, > but for some reason didn't consider it for openssl > headers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of > the message Hi David, Which version of postgresql that you are using? I have cvsupped the postgresql7 ports and didn't find what you referred here. However, I didn't manage to patch "configure" not to include "/usr/include" based on your advice. Here's the patch if anyone is interested. Thanks --- configure.orig Mon Mar 18 23:04:09 2002 +++ configure Mon Jun 10 18:06:57 2002 @@ -1697,7 +1697,9 @@ # SRCH_INC comes from the template file for dir in $with_includes $SRCH_INC; do if test -d "$dir"; then - INCLUDES="$INCLUDES -I$dir" + if test "$dir" != "/usr/include"; then + INCLUDES="$INCLUDES -I$dir" + fi else echo "configure: warning: *** Include directory $dir does not exist." 1>&2 fi @@ -2008,7 +2010,9 @@ if test -d "$krb4_prefix/include"; then - INCLUDES="$INCLUDES -I$krb4_prefix/include" + if test "$krb4_prefix/include" != "/usr/include"; then + INCLUDES="$INCLUDES -I$krb4_prefix/include" + fi fi if test -d "$krb4_prefix/lib"; then LIBDIRS="$LIBDIRS -L$krb4_prefix/lib" @@ -2053,7 +2057,9 @@ if test -d "$krb5_prefix/include"; then - INCLUDES="$INCLUDES -I$krb5_prefix/include" + if test "$krb5_prefix/include" != "/usr/include"; then + INCLUDES="$INCLUDES -I$krb5_prefix/include" + fi fi if test -d "$krb5_prefix/lib"; then LIBDIRS="$LIBDIRS -L$krb5_prefix/lib" @@ -2158,7 +2164,9 @@ if test -d "${openssl_prefix}/include" ; then - INCLUDES="$INCLUDES -I${openssl_prefix}/include" + if test "${openssl_prefix}/include" != "/usr/include"; then + INCLUDES="$INCLUDES -I${openssl_prefix}/include" + fi fi if test -d "${openssl_prefix}/lib" ; then LIBDIRS="$LIBDIRS -L${openssl_prefix}/lib" __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 11:20:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 0DE0B37B405 for ; Mon, 10 Jun 2002 11:20:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020610182009.LJKI975.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 10 Jun 2002 18:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA79703; Mon, 10 Jun 2002 11:07:18 -0700 (PDT) Date: Mon, 10 Jun 2002 11:07:18 -0700 (PDT) From: Julian Elischer To: Troy Cc: freebsd-current@FreeBSD.ORG Subject: Re: Kernel breakage in XE module In-Reply-To: <20020610111258.A31326@sindrome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG the HIDENAME() macro was changed to work with Gcc3.1 (the new compiler) but broke it for the old compiler/assembler. back out the definition in i386/include/asmacros.h to what it was before (it used to use the CONCAT() macro) OR bite the bullet and upgrade to a new -current and get the new compiler. On Mon, 10 Jun 2002, Troy wrote: > Been trying to buildkernel, and as of about 2 weeks ago something > happened to the XE module. Anyone have some ideas? > > -Troy > > ===> xe > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > rm -f .depend > CC='/usr/bin/cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. > -I@ -I@/dev -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/mod > ules/xe/../../dev/xe/if_xe.c /usr/src/sys/modules/xe/../../dev/xe/if_xe_pccard.c > > cd /usr/obj/usr/src/sys/SINDROME; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 > MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH= > /usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/l > ibexec make KERNEL=kernel all > /usr/bin/cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winl > ine -Wcast-qual -Wno-format -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src > /sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/us > r/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common > -mpreferred-stack-boundary=2 -ffreestanding /usr/src/sys/i386/i386/locore.s > {standard input}: Assembler messages: > {standard input}:1684: Warning: rest of line ignored; first ignored character is > `t' > {standard input}:1686: Error: unknown pseudo-op: `.' > {standard input}:1801: Error: missing ')' > {standard input}:1801: Error: missing ')' > {standard input}:1801: Error: junk `tmpstk)- 0xc0000000)' after expression > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/SINDROME. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 11:23:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 10F0037B40D for ; Mon, 10 Jun 2002 11:23:30 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.12.3/8.12.3) id g5AINTab065430; Mon, 10 Jun 2002 13:23:29 -0500 (CDT) (envelope-from dan) Date: Mon, 10 Jun 2002 13:23:29 -0500 From: Dan Nelson To: Troy Cc: freebsd-current@FreeBSD.ORG Subject: Re: Kernel breakage in XE module Message-ID: <20020610182329.GB54696@dan.emsphone.com> References: <20020610111258.A31326@sindrome.net> <20020610162136.GA54696@dan.emsphone.com> <20020610130341.A35221@sindrome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020610130341.A35221@sindrome.net> User-Agent: Mutt/1.3.99i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Jun 10), Troy said: > Dan, > > Thanks for your response. I just built the gcc31 package, but it doesn't > appear to replace the 2.95. Can you be a bit more specific on what I > should do to upgrade the GCC in your last note. Basically, buildworld. If you're lucky, just building and installing /usr/src/gnu/usr.bin/cc might work. I guess another question would be "should you be able to build a -current kernel with 2.95.3 anymore"? It might make upgrades from 4.* a bit difficult. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 11:37: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mile.nevermind.kiev.ua (office.netstyle.com.ua [213.186.199.26]) by hub.freebsd.org (Postfix) with ESMTP id D071437B406 for ; Mon, 10 Jun 2002 11:36:59 -0700 (PDT) Received: from mile.nevermind.kiev.ua (never@localhost [127.0.0.1]) by mile.nevermind.kiev.ua (8.12.3/8.12.3) with ESMTP id g5AIausQ054368; Mon, 10 Jun 2002 21:36:56 +0300 (EEST) (envelope-from never@mile.nevermind.kiev.ua) Received: (from never@localhost) by mile.nevermind.kiev.ua (8.12.3/8.12.3/Submit) id g5AIajcx054367; Mon, 10 Jun 2002 21:36:45 +0300 (EEST) Date: Mon, 10 Jun 2002 21:36:45 +0300 From: Alexandr Kovalenko To: Kris Kennaway Cc: Joe Marcus Clarke , Jun Kuriyama , current@FreeBSD.ORG Subject: Re: Mozilla 1.0 error Message-ID: <20020610183645.GB49295@nevermind.kiev.ua> References: <3D00AA4F.8080604@veidit.net> <7m1ybj2lau.wl@black.imgsrc.co.jp> <1023483405.326.26.camel@gyros.marcuscom.com> <20020607140252.A67949@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020607140252.A67949@xor.obsecurity.org> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Kris Kennaway! On Fri, Jun 07, 2002 at 02:02:52PM -0700, you wrote: > On Fri, Jun 07, 2002 at 04:56:45PM -0400, Joe Marcus Clarke wrote: > > On Fri, 2002-06-07 at 10:52, Jun Kuriyama wrote: > > > At Fri, 7 Jun 2002 12:43:27 +0000 (UTC), > > > John Angelmo wrote: > > > > (cd /usr/ports/www/mozilla/work/mozilla/dist/bin; /usr/bin/env > > > > LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom; echo > > > > skin,install,select,classic/1.0 >> chrome/installed-chrome.txt; echo > > > > locale,install,select,en-US >> chrome/installed-chrome.txt; > > > > /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome) > > > > [1] Segmentation fault (core dumped) > > > > *** Error code 139 > > > > > > > > Stop in /usr/ports/www/mozilla. > > > I got same result, too. > > This problem seems to happen on -CURRENT and alpha -stable. > And i386 -stable. Worked fine for me: [never@mile ~]$ cat /usr/ports/www/mozilla/Makefile | grep \$FreeBSD # $FreeBSD: ports/www/mozilla/Makefile,v 1.107 2002/06/06 18:52:31 sobomax Exp $ [never@mile ~]$ uname -a FreeBSD mile.nevermind.kiev.ua 4.6-RC FreeBSD 4.6-RC #0: Wed Jun 5 21:12:35 EEST 2002 root@mile.nevermind.kiev.ua:/usr/obj/usr/src/sys/mile i386 [never@mile ~]$ gcc -v Using builtin specs. gcc version 2.95.3 20010315 (release) [FreeBSD] -- NEVE-RIPE Ukrainian FreeBSD User Group http://uafug.org.ua/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 12:17:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx2.datanet.hu (mx2.datanet.hu [194.149.13.163]) by hub.freebsd.org (Postfix) with ESMTP id 374E537B40D for ; Mon, 10 Jun 2002 12:17:35 -0700 (PDT) Received: from fonix.adamsfamily.xx (nilus-139.adsl.datanet.hu [195.56.48.139]) by mx2.datanet.hu (DataNet) with ESMTP id F0D3C5672 for ; Mon, 10 Jun 2002 21:17:28 +0200 (CEST) Received: from fonix.adamsfamily.xx (localhost [127.0.0.1]) by fonix.adamsfamily.xx (8.12.3/8.12.3) with ESMTP id g5AJIXZn000823 for ; Mon, 10 Jun 2002 21:18:33 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from cc@localhost) by fonix.adamsfamily.xx (8.12.3/8.12.3/Submit) id g5AJIWIw000822 for freebsd-current@FreeBSD.ORG; Mon, 10 Jun 2002 21:18:32 +0200 (CEST) X-Authentication-Warning: fonix.adamsfamily.xx: cc set sender to sziszi@bsd.hu using -f Date: Mon, 10 Jun 2002 21:18:32 +0200 From: Szilveszter Adam To: freebsd-current@FreeBSD.ORG Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries Message-ID: <20020610191832.GA711@fonix.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , freebsd-current@FreeBSD.ORG References: <20020609.233703.730560602.ken@tydfam.jp> <1023728561.7633.31.camel@mharnois.mdharnois.net> <20020610101350.A68466@dragon.nuxi.com> <1023729340.7633.37.camel@mharnois.mdharnois.net> <20020610102635.A79571@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020610102635.A79571@dragon.nuxi.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 10:26:36AM -0700, David O'Brien wrote: > On Mon, Jun 10, 2002 at 12:15:40PM -0500, Michael D. Harnois wrote: > > On Mon, 2002-06-10 at 12:13, David O'Brien wrote: > > > On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: > > > > The libraries build for me without incident. However, anything which > > > > tries to link against libGLU generates this error for me: > > > > > > Your current is too old. Please do a fresh build. > > > > Since 6:30 last night? > > You must have NO_CXX or something -- you aren't linking with the C++ > support libs for some reason. Sorry David, but I experienced the same thing. No matter if I used the base system c++ compiler, or the latest gcc31 port. The problem is all the more interesting, because X worked for me fine, no matter what compiler I used to build it (with a few patches from the XFree86-4-libraries port) and libGLU is the only part of XFree that is wirtten in C++. If I specify -lstdc++ on the link line of any programs that use libGLU, it works (see xc/programs/glxinfo). My -CURRENT is from Saturday (8th), NO_CXX is *not* set. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 13: 7:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from femme.listmistress.org (bgp01560565bgs.gambrl01.md.comcast.net [68.50.32.109]) by hub.freebsd.org (Postfix) with ESMTP id D821437B401; Mon, 10 Jun 2002 13:07:08 -0700 (PDT) Received: from femme.listmistress.org (trish@localhost [127.0.0.1]) by femme.listmistress.org (8.12.3/8.12.1) with ESMTP id g5AK71cC000620; Mon, 10 Jun 2002 16:07:07 -0400 (EDT) Received: from localhost (trish@localhost) by femme.listmistress.org (8.12.3/8.12.3/Submit) with ESMTP id g5AK6wmw000617; Mon, 10 Jun 2002 16:07:00 -0400 (EDT) X-Authentication-Warning: femme.listmistress.org: trish owned process doing -bs Date: Mon, 10 Jun 2002 16:06:53 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Luigi Rizzo Cc: "Vladimir B. Grebenschikov" , , "current@freebsd.org" Subject: Re: New ipfw code available In-Reply-To: <20020610024726.A54631@iguana.icir.org> Message-ID: <20020610160123.B450-100000@femme.listmistress.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Jun 2002, Luigi Rizzo wrote: > On Mon, Jun 10, 2002 at 12:47:40PM +0400, Vladimir B. Grebenschikov wrote: > ... > > And what about radix-tree-based ip-list matching ? > > yes, it is planned. > > cheers > luigi > > > > ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30} > > or > > cat mylist | ipfw list add mylist - > > ipfw add 1 allow ip from @mylist > > > > or something like > > > > If you deal with large access-lists ipfw becomes not best tool due to > > linear comparison. Luigi, gave this a try, and dummynet and my current rulesets except for one worked fine... I tried to add a divert rule, and it kept telling me it was an invalid port for divert/tee. I went back to the original code... just because I happen to be using natd :) After this is fixed, I'll install again and play with the new features :) -Trish -- Trish Lynch trish@bsdunix.net FreeBSD The Power to Serve Ecartis Core Team trish@listmistress.org http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 14:14: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id 1A28637B40B for ; Mon, 10 Jun 2002 14:13:48 -0700 (PDT) Message-ID: <20020610211347.71117.qmail@web13305.mail.yahoo.com> Received: from [206.220.224.4] by web13305.mail.yahoo.com via HTTP; Mon, 10 Jun 2002 14:13:47 PDT Date: Mon, 10 Jun 2002 14:13:47 -0700 (PDT) From: Maksim Yevmenkin Subject: Device cloning To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Device driver will create new instance, every time open() called. It will use D_TRACKCLOSE flag and destroy instances in close(). What kind of information should i store to identify each instance? Is/Will it be possible to identify a single thread within a process? Is there any problems with fork()? The support for the threads is optional. I can live with single instance per process. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 14:16:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 56D2737B408 for ; Mon, 10 Jun 2002 14:16:47 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5ALFJV7029347; Mon, 10 Jun 2002 23:15:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Maksim Yevmenkin Cc: current@FreeBSD.ORG Subject: Re: Device cloning In-Reply-To: Your message of "Mon, 10 Jun 2002 14:13:47 PDT." <20020610211347.71117.qmail@web13305.mail.yahoo.com> Date: Mon, 10 Jun 2002 23:15:19 +0200 Message-ID: <29346.1023743719@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020610211347.71117.qmail@web13305.mail.yahoo.com>, Maksim Yevmenk in writes: >Hackers, > >The project i'm working on might require some sort of >device cloning. The current way of cloning, i.e. use >DEVFS and allocate unique minor numbers, is not very >good for my purpose. > >The idea is simple: the same device(major,minor) can >be opened several times by different processes (or >possibly threads within the same process) and each >process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 15:32:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by hub.freebsd.org (Postfix) with ESMTP id B95FA37B401 for ; Mon, 10 Jun 2002 15:32:19 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17HXhn-0000Tz-00; Tue, 11 Jun 2002 02:32:07 +0400 Subject: Re: Device cloning From: "Vladimir B. " Grebenschikov To: Poul-Henning Kamp Cc: Maksim Yevmenkin , "current@freebsd.org" In-Reply-To: <29346.1023743719@critter.freebsd.dk> References: <29346.1023743719@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 02:32:06 +0400 Message-Id: <1023748326.595.69.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =F7 Tue, 11.06.2002, =D7 01:15, Poul-Henning Kamp =CE=C1=D0=C9=D3=C1=CC: > In message <20020610211347.71117.qmail@web13305.mail.yahoo.com>, Maksim Y= evmenk > in writes: > >Hackers, > > > >The project i'm working on might require some sort of > >device cloning. The current way of cloning, i.e. use > >DEVFS and allocate unique minor numbers, is not very > >good for my purpose. > > > >The idea is simple: the same device(major,minor) can > >be opened several times by different processes (or > >possibly threads within the same process) and each > >process (thread) will have unique device instance.=20 >=20 > Sorry, but this wont work for a large number of reasons. >=20 > For one thing none of the dup(2) or fork(2) like systemcalls > report what happens to the filedescriptors down to the > device drivers so you have no way to correctly track which > process or which instance you are working on. As far as I understand _key_ word is "open", each new instance appears on open(), but fork() and dup() only do regular work. dup'ed or fork'ed descriptors will be same from driver's point of view, but each new open() will create new instance. > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe =20 > Never attribute to malice what can adequately be explained by incompetenc= e. =20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 17: 6:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from rumba.clave.gr.jp (rumba.clave.gr.jp [202.248.115.186]) by hub.freebsd.org (Postfix) with ESMTP id 5DA6A37B400 for ; Mon, 10 Jun 2002 17:06:19 -0700 (PDT) Received: from localhost (rumba.clave.gr.jp [202.248.115.186]) by rumba.clave.gr.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA70784; Tue, 11 Jun 2002 09:06:17 +0900 (JST) Date: Mon, 10 Jun 2002 22:49:24 +0900 (JST) Message-Id: <20020610.224924.74752528.mac@clave.gr.jp> To: current@FreeBSD.org Subject: about beforeinstall target in /usr/share/mk/*.mk From: Masahide -mac- NODA X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi. In /usr/share/mk/bsd.*.mk, 'beforeinstall' target execute after install on current. You found it to doing below in current: % cd /usr/src/share/mk % make install -n install -c -o root -g wheel -m 444 bsd.README bsd.cpu.mk bsd.dep.mk bsd.doc.mk bsd.files.mk bsd.info.mk bsd.incs.mk bsd.init.mk bsd.kern.mk bsd.kmod.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.mk bsd.port.post.mk bsd.port.pre.mk bsd.port.subdir.mk bsd.prog.mk bsd.subdir.mk bsd.sys.mk sys.mk /usr/share/mk date '+%Y%m%d' > /var/db/port.mkversion % but, in makefile, beforeinstall: date '+%Y%m%d' > ${DESTDIR}/var/db/port.mkversion beforeinstall target execute after install. ### I found it at installing portupgrade from ports. :-) -- mac@clave.gr.jp/mac@jp.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 17:16: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id 67E0537B409; Mon, 10 Jun 2002 17:16:02 -0700 (PDT) Received: from pool0444.cvx22-bradley.dialup.earthlink.net ([209.179.199.189] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HZKJ-0003UY-00; Mon, 10 Jun 2002 17:16:00 -0700 Message-ID: <3D05411C.9CD7D59C@mindspring.com> Date: Mon, 10 Jun 2002 17:15:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: Stanislav Grozev , Shizuka Kudo , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc References: <20020601195008.GJ17045@elvis.mu.org> <20020605113540.62177.qmail@web11402.mail.yahoo.com> <20020610115150.GA91765@meerkat.dungeon> <3D04B166.950171E2@mindspring.com> <20020610083921.A37639@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > *sigh*, why not a *real* fix? Feel free to submit this to the Postgres project... they may even incorporate it. > You'll note that they bother with this kind of check for other headers, > but for some reason didn't consider it for openssl headers. Mostly the reason that this fix was not being bandied about is that the Postgres source code is largely under third party control. If the change can be made to the Makefile, etc., which is under direct control of FreeBSD, then the code will compile unmodified. That means if there are future changes, we won't end up with a local patch to third party code, which doesn't apply cleanly. Locally maintaining patches against large projects is a very big headache; in fact, this headache is one of the primary things people rely upon in order to ensure that people donate tactical fixes back to the FreeBSD project itself. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 17:42:44 2002 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.theblackmoor.net (theblackmoor.net [63.170.133.254]) by hub.freebsd.org (Postfix) with ESMTP id CC3E137B40A for ; Mon, 10 Jun 2002 17:42:37 -0700 (PDT) Received: from sentinel (dsl3.wk.net [208.137.160.6]) by cygnus.theblackmoor.net (8.12.1/8.12.1) with SMTP id g5B0gTVI005875 for ; Mon, 10 Jun 2002 20:42:31 -0400 Date: Mon, 10 Jun 2002 19:42:26 -0500 From: drogoh To: current@FreeBSD.org Subject: buildworld problem Message-Id: <20020610194226.63c5b52b.drogoh@necessary-evil.org> Organization: there is no organization when the world is chaos X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG how do I resolve this? ===> gnu/usr.bin/groff/src/libs/libgroff c++ -O -pipe -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -c /usr/src/contrib/groff/src/libs/libgroff/assert.cc -o assert.o ld: unrecognized option `-o' Use `ld --help' for a complete list of options. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 17:46: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 23F8437B40B for ; Mon, 10 Jun 2002 17:45:43 -0700 (PDT) Received: from pool0444.cvx22-bradley.dialup.earthlink.net ([209.179.199.189] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HZmp-0004Ey-00; Mon, 10 Jun 2002 17:45:27 -0700 Message-ID: <3D054803.F3A0D76E@mindspring.com> Date: Mon, 10 Jun 2002 17:44:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir B. Grebenschikov" Cc: Poul-Henning Kamp , Maksim Yevmenkin , "current@freebsd.org" Subject: Re: Device cloning References: <29346.1023743719@critter.freebsd.dk> <1023748326.595.69.camel@vbook.express.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Vladimir B. Grebenschikov" wrote: > As far as I understand _key_ word is "open", each new instance appears > on open(), but fork() and dup() only do regular work. dup'ed or fork'ed > descriptors will be same from driver's point of view, but each new > open() will create new instance. No. The problem is that if you open the same thing N times, you will get N references to the single vnode of the thing. For devices, it's possible to kludge this, so that the device gives you a different vnode for each instance; however, the close is not sufficiently tracked unless you also give back a different minor number for each open instance. The problem is that there is no per reference instance information that is stored with the vnode and given to the device, as a context, with each operation, other tha the device context itself. So the only way to do this is a different minor number, so that the device is capable of maintaining its own per open instance information. It's also really questionable what the correct course of action for the fork/dup/dup2 code is. Consider the case of a program that intentionally forks, so that one process can read from the /etc/tty and write to the device, while the other can do the opposite (this is how the original "cu" program worked). On top of this, add descriptor passing. This breaks down to: are you creating a new open instance, or are you manipulating a reference to an existing open instance? Pushing this information over the "struct fileops" barrier is not a very easy thing to do. It would require reorganization of a lot of code. While this code is in *dire* need of reorganization, when you are done, if you can't answer the question about whether you are doing a "dup" or passing a reference to a single instance when you pass an FD between processes... well... you're in a bit of a jam. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 18:14:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id A6E6F37B404; Mon, 10 Jun 2002 18:14:38 -0700 (PDT) Received: from pool0444.cvx22-bradley.dialup.earthlink.net ([209.179.199.189] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HaF2-00039D-00; Mon, 10 Jun 2002 18:14:37 -0700 Message-ID: <3D054ED9.8DF80B4@mindspring.com> Date: Mon, 10 Jun 2002 18:14:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shizuka Kudo Cc: obrien@freebsd.org, Stanislav Grozev , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc References: <20020610180939.94228.qmail@web11405.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Shizuka Kudo wrote: > > --- David O'Brien wrote: > > > > *sigh*, why not a *real* fix? [ ... ] > Which version of postgresql that you are using? I have > cvsupped the postgresql7 ports and didn't find what > you referred here. However, I didn't manage to patch > "configure" not to include "/usr/include" based on > your advice. Here's the patch if anyone is interested. David's fix is more correct. The "configure" program you are patching is actually created from the "configure.in" file that David was patching. Since it's machine generated, it's a bad idea to patch it directly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 20: 4:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11406.mail.yahoo.com (web11406.mail.yahoo.com [216.136.131.236]) by hub.freebsd.org (Postfix) with SMTP id E12F337B40A for ; Mon, 10 Jun 2002 20:04:45 -0700 (PDT) Message-ID: <20020611030445.20140.qmail@web11406.mail.yahoo.com> Received: from [202.167.61.228] by web11406.mail.yahoo.com via HTTP; Mon, 10 Jun 2002 20:04:45 PDT Date: Mon, 10 Jun 2002 20:04:45 -0700 (PDT) From: Shizuka Kudo Subject: Re: My postgresql7 not working for new gcc To: Terry Lambert Cc: obrien@freebsd.org, Stanislav Grozev , freebsd-current@freebsd.org In-Reply-To: <3D054ED9.8DF80B4@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- Terry Lambert wrote: > Shizuka Kudo wrote: > > > > --- David O'Brien wrote: > > > > > > *sigh*, why not a *real* fix? > > [ ... ] > > > Which version of postgresql that you are using? I > have > > cvsupped the postgresql7 ports and didn't find > what > > you referred here. However, I didn't manage to > patch > > "configure" not to include "/usr/include" based on > > your advice. Here's the patch if anyone is > interested. > > David's fix is more correct. The "configure" > program you are > patching is actually created from the "configure.in" > file that > David was patching. Since it's machine generated, > it's a bad > idea to patch it directly. > > -- Terry I don't think autoconf was called in postgresql7 port, and patching configure is necessary. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 21: 9:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from 141.com (mail1.141.com [65.168.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 623EC37B40B for ; Mon, 10 Jun 2002 21:09:21 -0700 (PDT) Received: from 141.com [151.200.149.107] by 141.com with ESMTP (SMTPD32-7.10) id A8367C9E00EE; Mon, 10 Jun 2002 22:10:30 -0600 To: freebsd-current@freebsd.org Cc: Steve Kargl Subject: Re: one or two errors in installworld In-Reply-To: Your message of "Sun, 09 Jun 2002 21:28:25 PDT." <20020609212825.A81804@troutmask.apl.washington.edu> Date: Tue, 11 Jun 2002 00:09:23 -0400 From: Andrew Lankford Message-Id: <20020610221078.SM02244@141.com> X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [4000020e]. X-Note: This E-mail was scanned for spam. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020609212825.A81804@troutmask.apl.washington.edu>, Steve Kargl wr ites: > >If you don't think it's bogus, then fix the >documentation of make.conf and commit an UPDATING >entry to warn everyone who set INSTALL several years >ago. Check out the next to last few entries in: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/sendmail/Makefile?sortby=log or http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/xinstall/xinstall.c So, on to a new topic. Which is better, ^? or ^H ? Andrew Lankford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 21:56:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id D725637B40B; Mon, 10 Jun 2002 21:56:08 -0700 (PDT) Received: from pool0454.cvx22-bradley.dialup.earthlink.net ([209.179.199.199] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hdgt-0000Ct-00; Mon, 10 Jun 2002 21:55:37 -0700 Message-ID: <3D05824A.4261352B@mindspring.com> Date: Mon, 10 Jun 2002 21:53:30 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shizuka Kudo Cc: obrien@freebsd.org, Stanislav Grozev , freebsd-current@freebsd.org Subject: Re: My postgresql7 not working for new gcc References: <20020611030445.20140.qmail@web11406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Shizuka Kudo wrote: > I don't think autoconf was called in postgresql7 port, > and patching configure is necessary. It's derived data, and the patches will likely not remain valid after the next release/upgrade. That basically means that the way to correct your complaint about autoconf not being run is to make the port Makefile run autoconf. A patch to a derived file is not one that will make it back into the project source tree. If the patch isn't one that the Postgres people will accept, it's probably a bad patch. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 22:38:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3199137B409; Mon, 10 Jun 2002 22:38:41 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA14312; Tue, 11 Jun 2002 15:38:18 +1000 Date: Tue, 11 Jun 2002 15:39:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Troy , , Subject: Re: Kernel breakage in XE module In-Reply-To: Message-ID: <20020611145357.F3970-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Jun 2002, Julian Elischer wrote: > the HIDENAME() macro was changed to work with Gcc3.1 (the new compiler) > but broke it for the old compiler/assembler. Ugh. I was surprised that this change worked for any gcc. The change is from: #define HIDENAME(asmsym) __CONCAT(.,asmsym) to: #define HIDENAME(asmsym) .asmsym Note that the change isn't for use of CONCAT with "," and "word" lke its commit message says. It is for use of __CONCAT with "." and "word". Here the quotes are to mark up identifiers -- there are no strings involved. The problem is that the ISO C concatenation operator "##" is less useful than might first appear. It is only required to work if the result could be a preprocessing token, and the rules for when the result could be a preprocessing token are quite complicated. E.g., ".foo" is not a preprocessing token but ".1" is. The result of concatenating "." with "foo" is undefined, and gcc now detects this error. Since ".foo" is lexed as separate tokens, there is no need for the preprocessor to keep the "." and the "foo" separate. In practice, previous versions of the preprocessor inserted a space between the tokens and the current version doesn't. The current HIDENAME() macro depends on this implementation detail in the current preprocessor and is just broken in general. > back out the definition in i386/include/asmacros.h to what it was before > (it used to use the CONCAT() macro) > > OR > > bite the bullet and upgrade to a new -current and get the new compiler. OR for a quick fix, fixing one of the following related bogons: (1) For non-profiling kernels, HIDENAME is only used for the tmpstk variable in locore.s, but there is no need for this variable to be hidden. Hiding it mainly broke examining it using ddb before ddb was fixed to recognize symbols with a "." in their name. (2) For non-profiling kernels, HIDENAME is only used for the tmpstk variable in locore.s, but the old macro still works for cpp'ing assembler sources. This is why committing gcc-3 didn't break building of all kernels. Fixing the following related bogon would have no significant affect: (3) HIDENAME still has its old definition in at least the i386 . This is harmless at least on i386's because that definition is not actually used. This leaves the problem of fixing the use of HIDENAME in profiling kernels. Unfortunately, the standard name for "mcount" requires a "." in it for the ELF case (the ELF case is more broken than the aout case here). This problem is avoided for userland profiling using a magic asm in . The i386 prof_machdep.c uses HIDENAME to get slightly less magic asm. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 22:55:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 50C3D37B400 for ; Mon, 10 Jun 2002 22:55:11 -0700 (PDT) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.3/8.12.3) with ESMTP id g5B5tAQ9024810; Mon, 10 Jun 2002 22:55:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.3/8.12.3/Submit) id g5B5tASd024809; Mon, 10 Jun 2002 22:55:10 -0700 (PDT) Date: Mon, 10 Jun 2002 22:55:10 -0700 From: Steve Kargl To: Andrew Lankford Cc: freebsd-current@freebsd.org Subject: Re: one or two errors in installworld Message-ID: <20020610225510.A24733@troutmask.apl.washington.edu> References: <20020609212825.A81804@troutmask.apl.washington.edu> <20020610221078.SM02244@141.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020610221078.SM02244@141.com>; from arlankfo@141.com on Tue, Jun 11, 2002 at 12:09:23AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 11, 2002 at 12:09:23AM -0400, Andrew Lankford wrote: > In message <20020609212825.A81804@troutmask.apl.washington.edu>, Steve Kargl wr > ites: > > > >If you don't think it's bogus, then fix the > >documentation of make.conf and commit an UPDATING > >entry to warn everyone who set INSTALL several years > >ago. > > Check out the next to last few entries in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/share/sendmail/Makefile?sortby=log > > or > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/xinstall/xinstall.c > > So, on to a new topic. Which is better, ^? or ^H ? > What's your point? Greg kludged share/sendmail/Makefile to work around Ruslan's broken implementation in xinstall. Either fix xinstall so options that conflict with -d are ignored (I've already posted a patch, twice), or fix the documentation of make.conf (I've already posted a patch for this, too) and fix the example make.conf under share/example/etc and add an entry to UPDATING. There is also an open problem report bin/37795, which Ruslan knew existed, and he has not closed it (his kludge invalidates the PR). At one time, setting INSTALL to "install -C" in make.conf could be a BIG time saver during a "make world"? One can no longer set INSTALL. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 23:19:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 7576F37B401 for ; Mon, 10 Jun 2002 23:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.4/8.12.3) with ESMTP id g5B6JSxw008638; Tue, 11 Jun 2002 15:49:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Device cloning From: "Daniel O'Connor" To: Poul-Henning Kamp Cc: Maksim Yevmenkin , current@FreeBSD.ORG In-Reply-To: <29346.1023743719@critter.freebsd.dk> References: <29346.1023743719@critter.freebsd.dk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 15:49:28 +0930 Message-Id: <1023776371.2412.455.camel@chowder.gsoft.com.au> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 2002-06-11 at 06:45, Poul-Henning Kamp wrote: > >The idea is simple: the same device(major,minor) can > >be opened several times by different processes (or > >possibly threads within the same process) and each > >process (thread) will have unique device instance. > > Sorry, but this wont work for a large number of reasons. > > For one thing none of the dup(2) or fork(2) like systemcalls > report what happens to the filedescriptors down to the > device drivers so you have no way to correctly track which > process or which instance you are working on. Can't you kludge this by creating /dev/foo0 and when it is opened replacing it with a different minor number? Or perhaps /dev/foo0 as a symlink to /dev/foo0.0 and when it is opened create /dev/foo0.1 and change the symlink. This is obviously a different major,minor pair but those are the constraints in the system :) -- 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 - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 10 23:52:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 81C6F37B413 for ; Mon, 10 Jun 2002 23:52:36 -0700 (PDT) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5B6qXh06392; Tue, 11 Jun 2002 08:52:33 +0200 (MEST) Date: Tue, 11 Jun 2002 08:52:33 +0200 (CEST) From: Harti Brandt To: Maksim Yevmenkin Cc: current@FreeBSD.ORG Subject: Re: Device cloning In-Reply-To: <20020610211347.71117.qmail@web13305.mail.yahoo.com> Message-ID: <20020611085001.G33171-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Jun 2002, Maksim Yevmenkin wrote: MY>Hackers, MY> MY>The project i'm working on might require some sort of MY>device cloning. The current way of cloning, i.e. use MY>DEVFS and allocate unique minor numbers, is not very MY>good for my purpose. MY> MY>The idea is simple: the same device(major,minor) can MY>be opened several times by different processes (or MY>possibly threads within the same process) and each MY>process (thread) will have unique device instance. MY>Device driver will create new instance, every time MY>open() called. It will use D_TRACKCLOSE flag and MY>destroy instances in close(). MY> MY>What kind of information should i store to identify MY>each instance? Is/Will it be possible to identify a MY>single thread within a process? Is there any problems MY>with fork()? The support for the threads is optional. MY>I can live with single instance per process. In MHO this idea is based on a fundamental misunderstanding of what a device is under unix. If you need such a behaviour you should put another abstraction on top of you devices (as the filesystem is put on top of disks and sockets on top of network devices), that handle multiple contexts for multiple processes. A device is just a device... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 0:53: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A560A37B400; Tue, 11 Jun 2002 00:53:03 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA00694; Tue, 11 Jun 2002 17:52:43 +1000 Date: Tue, 11 Jun 2002 17:57:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Masahide -mac- NODA Cc: current@FreeBSD.ORG, Subject: Re: about beforeinstall target in /usr/share/mk/*.mk In-Reply-To: <20020610.224924.74752528.mac@clave.gr.jp> Message-ID: <20020611174927.H4349-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Jun 2002, Masahide -mac- NODA wrote: > In /usr/share/mk/bsd.*.mk, 'beforeinstall' target execute after install > on current. > > You found it to doing below in current: > > % cd /usr/src/share/mk > % make install -n > install -c -o root -g wheel -m 444 bsd.README ... > date '+%Y%m%d' > /var/db/port.mkversion > % > > but, in makefile, > > beforeinstall: > date '+%Y%m%d' > ${DESTDIR}/var/db/port.mkversion > > > beforeinstall target execute after install. > > ### I found it at installing portupgrade from ports. :-) This bug seems to be mainly in bsd.file.mk. realinstall depends on both installfiles and beforeinstall, but there is no dependency of installfiles on beforeinstall. This can probably be fixed by adding the dependency (in bsd.files.mk). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 0:58:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 8649A37B405 for ; Tue, 11 Jun 2002 00:58:13 -0700 (PDT) Received: from pool0011.cvx22-bradley.dialup.earthlink.net ([209.179.198.11] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HgXK-0004uB-00; Tue, 11 Jun 2002 00:57:55 -0700 Message-ID: <3D05ACE9.ED09D57E@mindspring.com> Date: Tue, 11 Jun 2002 00:55:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harti Brandt Cc: Maksim Yevmenkin , current@FreeBSD.ORG Subject: Re: Device cloning References: <20020611085001.G33171-100000@beagle.fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harti Brandt wrote: > In MHO this idea is based on a fundamental misunderstanding of what a > device is under unix. If you need such a behaviour you should put another > abstraction on top of you devices (as the filesystem is put on top of > disks and sockets on top of network devices), that handle multiple > contexts for multiple processes. A device is just a device... I really disagree with this. SVR4 and AIX have supported clone devices for a very long time now, starting with support for pty's. Cloning eliminates several things: o The search requirement for allocating an instance of a device type; this is generally a linear search, through an O(n^2) interface, e.g. looking up the next pty in the space defined by /dev/pty* o The normal limit on the number of devices that's imposed because of both the namespace limits, and on static declaration of things that should be allocated on a per instance bases, up to the limits of system resources o The system dependence on naming that goes into building code that it portable between systems. For pty's, in particular, instance is identified via minor number; the need to actually try to open and obtain exclusive use of the master pty, up to the first unallocated one, and the fact that when you run out of names, you run out of pty's, are both enough, each on their own, to justify cloning devices. FreeBSD today can not run more than one VMWare seassion at a time because it lacks the ability to distinguish open instances to the device that exports the VMWare kernel context information to the user space application: because FreeBSD lacks device cloning. Rather than trying to say what someone should do, it'd be nice, at least in the case of commercial code that can't be demanded to be rewritten, and which runs under a non-native ABI on FreeBSD, to be able to support all of the functionality of the OS whose ABI is being emulated, and thus, if for no other reason, to support device cloning. It's not like third parties are going to be willing to port their code to FreeBSD, particularly after the last 6 years or so of being told *by FreeBSD people* to target the Linux ABI. So trying to change people wanting cloning in the first place is not really a winable fight. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 1:36:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id 6F83337B407 for ; Tue, 11 Jun 2002 01:36:51 -0700 (PDT) Received: (qmail 25296 invoked from network); 11 Jun 2002 08:36:50 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2002 08:36:50 -0000 Received: from laptop.baldwin.cx ([206.187.69.211]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g5B8amQ81393; Tue, 11 Jun 2002 04:36:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> Date: Tue, 11 Jun 2002 04:36:41 -0400 (EDT) From: John Baldwin To: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 Cc: hiten@uk.FreeBSD.org, jrh@lab.it.uc3m.es, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Jun-2002 Mike Makonnen wrote: >> Well, the real solution probably involves changing where we dink with >> uidinfo structs so we bump the reference count on teh new one before > we> grab the proc lock, change over to the new one while holding the > proc lock,> then release the reference to the old one after we are done. >> > > Well... this is basically what happens > > setuid - creates a new ucred > - locks p > - calls change_ruid() > > change_ruid - calls uifind() > > uifind - does MALLOC w/ M_WAITOK > > After thinking about it for a while, this is the solution I came up > with: > > Each new struct ucred will carry an array of pointers to struct uidinfo. > This will be an array of 3 elements (a spare for cr_ruidinfo, > cr_uidinfo, null). Obviously, it gets added after ->cr_endcopy. > > When crget() is called it calls a function whose job it is to create an > array of pointers to struct uidinfo and allocate the memory for them. > > When uifind() is called it will be given an array of pointers to uidinfo > structs (the ones from ucred), in addition to the uid it is to lookup. > If it already has a uidinfo for that uid, then it returns that to the > calling function. If it can't find the uid, then it unhooks (copies the > address, and deletes it from the array) the last struct uidinfo from > the array, initializes it, inserts it into the hashtable and returns it > to the caller. > > When crfree is called it calls a function that deallocates the spare > structs uidinfo. > > This solution has the advantage that the only code that has to change is > the ucred and setuid/gid helper functions that already know about the > struct uidinfo functions. In fact only three functions not related to > uidinfo(9) need to be touched: proc0_init(), change_ruid(), > change_uid(). The disadvantage is the memory bloat and a small amount of > code complexity (but as I said, this is localized, and not very complex > either). > > Do you like it? > Should I go ahead and implement a patch? > Anything I overlooked? It won't work if you have to change a uidinfo more than once. I still prefer just doing the uifind() at the beginning of the function, passing in the uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's in case of failure. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 1:37:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id 5A33337B40B for ; Tue, 11 Jun 2002 01:37:14 -0700 (PDT) Received: (qmail 9855 invoked from network); 11 Jun 2002 08:37:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2002 08:37:12 -0000 Received: from laptop.baldwin.cx ([206.187.69.211]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g5B8bAQ81411; Tue, 11 Jun 2002 04:37:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020609224036.A21143@panzer.kdm.org> Date: Tue, 11 Jun 2002 04:37:04 -0400 (EDT) From: John Baldwin To: "Kenneth D. Merry" Subject: RE: new zero copy sockets snapshot, WITNESS problems Cc: net@FreeBSD.org, current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Jun-2002 Kenneth D. Merry wrote: > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > ends up calling vm_map_entry_create(), same problem as above. > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls malloc() with M_WAITOK. > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls uma_zalloc() with M_WAITOK. > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls MALLOC() with M_WAITOK in various places. > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > with M_WAITOK. > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > vm_map_find(), which through several calls calls vm_map_entry_create(). > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > which does a uma_zalloc() with M_WAITOK. > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > ithread_add_handler() through several layers of indirection. > ithread_add_handler() calls malloc with M_WAITOK. ti_attach() doesn't need to hold its lock while doing these things. Don't actually enable the logical network device until all the setup for it is done. > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > uma_zalloc with M_WAITOK. > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > function), which calls kmem_alloc_pageable(). See number 1 above, same > problem here with vm_map_entry_create(). > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > gets called, which calls vm_map_entry_create(), which calls > uma_zalloc() with M_WAITOK. > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > called through a slightly different path from the same root malloc() > call in jumbo_vm_init(). Same as above with regards to ti_attach(). > - the bus_setup_intr(), or rather the kthread code in general apparantly > isn't safe to be called while holding a mutex. This is the cause of the > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. Yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 1:43:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 24F4F37B403 for ; Tue, 11 Jun 2002 01:43:13 -0700 (PDT) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5B8h7h19851; Tue, 11 Jun 2002 10:43:08 +0200 (MEST) Date: Tue, 11 Jun 2002 10:43:07 +0200 (CEST) From: Harti Brandt To: Terry Lambert Cc: Maksim Yevmenkin , Subject: Re: Device cloning In-Reply-To: <3D05ACE9.ED09D57E@mindspring.com> Message-ID: <20020611103826.W35132-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002, Terry Lambert wrote: TL>Harti Brandt wrote: TL>> In MHO this idea is based on a fundamental misunderstanding of what a TL>> device is under unix. If you need such a behaviour you should put another TL>> abstraction on top of you devices (as the filesystem is put on top of TL>> disks and sockets on top of network devices), that handle multiple TL>> contexts for multiple processes. A device is just a device... TL> TL>I really disagree with this. SVR4 and AIX have supported clone TL>devices for a very long time now, starting with support for pty's. TL> TL>Cloning eliminates several things: TL> TL>o The search requirement for allocating an instance of a TL> device type; this is generally a linear search, through TL> an O(n^2) interface, e.g. looking up the next pty in the TL> space defined by /dev/pty* TL> TL>o The normal limit on the number of devices that's imposed TL> because of both the namespace limits, and on static TL> declaration of things that should be allocated on a per TL> instance bases, up to the limits of system resources TL> TL>o The system dependence on naming that goes into building TL> code that it portable between systems. TL> TL>For pty's, in particular, instance is identified via minor number; TL>the need to actually try to open and obtain exclusive use of the TL>master pty, up to the first unallocated one, and the fact that TL>when you run out of names, you run out of pty's, are both enough, TL>each on their own, to justify cloning devices. TL> TL>FreeBSD today can not run more than one VMWare seassion at a time TL>because it lacks the ability to distinguish open instances to the TL>device that exports the VMWare kernel context information to the TL>user space application: because FreeBSD lacks device cloning. TL> TL>Rather than trying to say what someone should do, it'd be nice, TL>at least in the case of commercial code that can't be demanded to TL>be rewritten, and which runs under a non-native ABI on FreeBSD, TL>to be able to support all of the functionality of the OS whose TL>ABI is being emulated, and thus, if for no other reason, to TL>support device cloning. TL> TL>It's not like third parties are going to be willing to port their TL>code to FreeBSD, particularly after the last 6 years or so of TL>being told *by FreeBSD people* to target the Linux ABI. TL> TL>So trying to change people wanting cloning in the first place is TL>not really a winable fight. Terry, I was talking about real devices, not pseudo devices that you can get out of thin air. Device driver for real devices should be just what they are: device drivers. If you take a disk driver, then there is no code there that tries to present multiple contexts to multiple openers - supporting this is the task of the file system. If you take a sound card, the multiplexing stuff, that handles multiple processes open the soundcard should not be in the driver, but in the abstraction above. The same holds for the network devices. The situation is different for pseudo devices which you can create on demand. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 2:37:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 8DABE37B407 for ; Tue, 11 Jun 2002 02:37:35 -0700 (PDT) Received: from pool0011.cvx22-bradley.dialup.earthlink.net ([209.179.198.11] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hi5d-0004rE-00; Tue, 11 Jun 2002 02:37:26 -0700 Message-ID: <3D05C414.D3B5F0C0@mindspring.com> Date: Tue, 11 Jun 2002 02:34:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harti Brandt Cc: Maksim Yevmenkin , current@FreeBSD.ORG Subject: Re: Device cloning References: <20020611103826.W35132-100000@beagle.fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harti Brandt wrote: > I was talking about real devices, not pseudo devices that you can get out > of thin air. Device driver for real devices should be just what they are: > device drivers. If you take a disk driver, then there is no code there > that tries to present multiple contexts to multiple openers - supporting > this is the task of the file system. If you take a sound card, the > multiplexing stuff, that handles multiple processes open the soundcard > should not be in the driver, but in the abstraction above. The same holds > for the network devices. The situation is different for pseudo devices > which you can create on demand. This is true for most real devices, but not all of them. For a disk device, it would be nice if I could ioctl() it to change it's instance to that of a parent, e.g. for "slice management". For a sound device, it would be nice if multiple instances to the devices were mux'ed. I've had cases where the program I was using was using a smaller number that the total available channels, and it would have been nice if the next open instance got the remaining channels, rather than a "device in use" error. You'd have to manage this by giving all remaining available channels to an opener, and then having them ioctl() the unused ones back (e.g. "allocate N" when there are M available, means "give M-N back"). For a DVD, it would be nice if you could select the instance of the device you were going to get for seperation of the ISO9660 and UDF FS's (e.g. which record boundary the device actually used). The way that OS X supports this is by doing DVD mounts on both the character and block device seperately. For FreeBSD, UDF support, which has to have access to the ISO9660 FS for the purposes of index access, is much more messy. You could also make an argument for multiple input devices and the management of which one you get when you open /dev/mouse. Finally, there's a long history on SCO Xenix and UNIX, starting with "Computone" multiport serial cards, of multiplexing access to the device seperately for printing vs. terminal I/O. Yes, Digiboard and other vendors handle this by having two device nodes for a single pgysical device, and maintaining a state machine for the escape sequences. But this is really a matter of preference, not necessity. Writing to one instance, you talk to the terminal, and writing to the other, you talk to the "aux" port. I don't think the original poster wanted cloning for support on physical devices for which there was a 1:1 relationship anyway (8^)), but there *are* cases where it could be useful. Actually, I think the original poster never really disclosed *what* they wanted to use the feature for... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 2:48:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id AD3E937B400 for ; Tue, 11 Jun 2002 02:48:36 -0700 (PDT) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g5B9mRh01548; Tue, 11 Jun 2002 11:48:28 +0200 (MEST) Date: Tue, 11 Jun 2002 11:48:27 +0200 (CEST) From: Harti Brandt To: Terry Lambert Cc: Maksim Yevmenkin , Subject: Re: Device cloning In-Reply-To: <3D05C414.D3B5F0C0@mindspring.com> Message-ID: <20020611114039.L35453-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002, Terry Lambert wrote: TL>Harti Brandt wrote: TL>> I was talking about real devices, not pseudo devices that you can get out TL>> of thin air. Device driver for real devices should be just what they are: TL>> device drivers. If you take a disk driver, then there is no code there TL>> that tries to present multiple contexts to multiple openers - supporting TL>> this is the task of the file system. If you take a sound card, the TL>> multiplexing stuff, that handles multiple processes open the soundcard TL>> should not be in the driver, but in the abstraction above. The same holds TL>> for the network devices. The situation is different for pseudo devices TL>> which you can create on demand. TL> TL>This is true for most real devices, but not all of them. TL> TL>For a disk device, it would be nice if I could ioctl() it to change TL>it's instance to that of a parent, e.g. for "slice management". Can't see any 'cloning' here. TL>For a sound device, it would be nice if multiple instances to the TL>devices were mux'ed. I've had cases where the program I was using TL>was using a smaller number that the total available channels, and TL>it would have been nice if the next open instance got the remaining TL>channels, rather than a "device in use" error. You'd have to manage TL>this by giving all remaining available channels to an opener, and TL>then having them ioctl() the unused ones back (e.g. "allocate N" TL>when there are M available, means "give M-N back"). That has also nothing to do with cloning. Look at the current pcm driver - it just has a device entry per channel. Where cloning could come into the play is when more than one process tries to open a 1-channel device and you want to mix the audio. As I said this would be a task of a layer above the sound driver (just as X 'multiplexes' N processes onto one display device). Unfortunately there is no good sound API up to now. TL>For a DVD, it would be nice if you could select the instance of the TL>device you were going to get for seperation of the ISO9660 and UDF TL>FS's (e.g. which record boundary the device actually used). The way TL>that OS X supports this is by doing DVD mounts on both the character TL>and block device seperately. For FreeBSD, UDF support, which has to TL>have access to the ISO9660 FS for the purposes of index access, is TL>much more messy. No cloning here. TL>You could also make an argument for multiple input devices and the TL>management of which one you get when you open /dev/mouse. Again you just get it the wrong way around. You need per process/open context if you try to put the multiplexing of ONE mouse between MULTIPLE processes into the hardware mouse driver. Again this would be plain wrong. TL>Finally, there's a long history on SCO Xenix and UNIX, starting with TL>"Computone" multiport serial cards, of multiplexing access to the TL>device seperately for printing vs. terminal I/O. Yes, Digiboard and TL>other vendors handle this by having two device nodes for a single TL>pgysical device, and maintaining a state machine for the escape TL>sequences. But this is really a matter of preference, not necessity. TL>Writing to one instance, you talk to the terminal, and writing to the TL>other, you talk to the "aux" port. Again this is not about 'cloning a physical' device. TL>I don't think the original poster wanted cloning for support on TL>physical devices for which there was a 1:1 relationship anyway TL>(8^)), but there *are* cases where it could be useful. TL> TL>Actually, I think the original poster never really disclosed *what* TL>they wanted to use the feature for... That's true... From reading the original post I was under the impression that this is again a 'hey, I write a device driver and I need to track the number of opens and to tack a context onto each open' that periodically comes up. If I'm wrong, well, sorry then... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 2:50: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from daemonz.org (TK212017094177.teleweb.at [212.17.94.177]) by hub.freebsd.org (Postfix) with SMTP id 1A59937B408 for ; Tue, 11 Jun 2002 02:49:59 -0700 (PDT) Received: (qmail 84282 invoked by uid 1001); 11 Jun 2002 09:55:57 -0000 Date: Tue, 11 Jun 2002 11:55:57 +0200 From: Stanislav Grozev To: Szilveszter Adam Cc: freebsd-current@freebsd.org Subject: Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries Message-ID: <20020611095557.GA83982@meerkat.dungeon> References: <20020609.233703.730560602.ken@tydfam.jp> <1023728561.7633.31.camel@mharnois.mdharnois.net> <20020610101350.A68466@dragon.nuxi.com> <1023729340.7633.37.camel@mharnois.mdharnois.net> <20020610102635.A79571@dragon.nuxi.com> <20020610191832.GA711@fonix.adamsfamily.xx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020610191832.GA711@fonix.adamsfamily.xx> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 10, 2002 at 09:18:32PM +0200, Szilveszter Adam wrote: > Sorry David, but I experienced the same thing. No matter if I used the > base system c++ compiler, or the latest gcc31 port. The problem is all > the more interesting, because X worked for me fine, no matter what > compiler I used to build it (with a few patches from the > XFree86-4-libraries port) and libGLU is the only part of XFree that is > wirtten in C++. If I specify -lstdc++ on the link line of any programs > that use libGLU, it works (see xc/programs/glxinfo). > > My -CURRENT is from Saturday (8th), NO_CXX is *not* set. > me too. current from sunday, and i had to link libstdc++ manually to it, for it to work. after that - no probs -tacho To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 2:55:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 2012C37B401; Tue, 11 Jun 2002 02:55:43 -0700 (PDT) Received: from kokeb.ambesa.net ([64.173.11.74]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXJ00AO3CWVXR@mta6.snfc21.pbi.net>; Tue, 11 Jun 2002 02:55:43 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5BA14OZ002287; Tue, 11 Jun 2002 03:01:04 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5BA13L3002278; Tue, 11 Jun 2002 03:01:03 -0700 (PDT envelope-from mikem) Date: Tue, 11 Jun 2002 03:01:02 -0700 From: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 In-reply-to: To: John Baldwin Cc: hiten@uk.FreeBSD.org, jrh@lab.it.uc3m.es, freebsd-current@FreeBSD.ORG Message-id: <200206111001.g5BA13L3002278@kokeb.ambesa.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200206100932.g5A9WPe1008406@kokeb.ambesa.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin wrote: > > This solution has the advantage that the only code that has to change is > > the ucred and setuid/gid helper functions that already know about the > > struct uidinfo functions. In fact only three functions not related to > > uidinfo(9) need to be touched: proc0_init(), change_ruid(), > > change_uid(). The disadvantage is the memory bloat and a small amount of > > code complexity (but as I said, this is localized, and not very complex > > either). > > > > Do you like it? > > Should I go ahead and implement a patch? > > Anything I overlooked? > > It won't work if you have to change a uidinfo more than once. I still prefer > just doing the uifind() at the beginning of the function, passing in the > uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's > in case of failure. Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. With that assumption in mind I wanted to compartmentalize the allocation of struct uidinfo. It seemed cleaner to me to have only uifind() and its immediate callers have intimate knowledge struct uidinfo creation and destruction, but I suppose if setuid() (for example) knows enough to compare cr_ruid et al, its knowledge of one more member isn't that bad. Basically, I wanted to avoid having to touch every function that changes the r/e uid, and touch just those that already dealt with the uidinfo. In any case, I'll submit a patch to you doing it the way you suggested. Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 3:25:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 0BB1D37B40A; Tue, 11 Jun 2002 03:25:14 -0700 (PDT) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.3/8.12.3) with ESMTP id g5BAOfaR067440; Tue, 11 Jun 2002 14:24:53 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.3/8.12.3/Submit) id g5BAObPV067439; Tue, 11 Jun 2002 14:24:37 +0400 (MSD) Date: Tue, 11 Jun 2002 14:24:35 +0400 From: "Andrey A. Chernov" To: peter@freebsd.org, Shizuka Kudo Cc: freebsd-current@freebsd.org Subject: Re: libncurses cannot show the first column on the screen Message-ID: <20020611102432.GA67341@nagual.pp.ru> References: <20020605112835.61101.qmail@web11402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020605112835.61101.qmail@web11402.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 05, 2002 at 04:28:35 -0700, Shizuka Kudo wrote: > > The libncurses commit on May 21 seems not working > properly. I cvsupped latest current & ports, build a > typical ncurses app (lynx) and find that the first > column is not shown correctly. Bascially it is blank This bug reason now is known (thanx to Thomas). Peter, please upgrade to newer version to fix it. ------------------------------------------------------------------- That was a blunder which was fixed (in the 20020525 patch): 20020523 + correct and simplify logic for lib_pad.c change in 20020518 (reported by Mike Castle). 20020518 + fix lib_pad.c for case of drawing a double-width character which falls off the left margin of the pad (patch by Kriang Lerdsuwanakij ) -------------------------------------------------------------------------- -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 4:58:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from sdns.kv.ukrtel.net (sdns.kv.ukrtel.net [195.5.27.246]) by hub.freebsd.org (Postfix) with ESMTP id A1A6037B40B; Tue, 11 Jun 2002 04:58:21 -0700 (PDT) Received: from vega.vega.com (195.5.51.243 [195.5.51.243]) by sdns.kv.ukrtel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M2L7DVHW; Tue, 11 Jun 2002 15:00:18 +0300 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id g5BBw5342464; Tue, 11 Jun 2002 14:58:05 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D05E5DE.7797B7EE@FreeBSD.org> Date: Tue, 11 Jun 2002 14:58:22 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Ruslan Ermilov Cc: current@FreeBSD.ORG Subject: Re: World is broken References: <3CF2185A.635D3709@FreeBSD.org> <20020527132254.GA85117@sunbay.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > On Mon, May 27, 2002 at 02:28:26PM +0300, Maxim Sobolev wrote: > > Finally I have decided to give post gcc-3.1 perless world a > > try, but found that world doesn't build. :(( The system in > > question is 5-CURRENT makeworlded about a month ago. > > > > Any ideas? > > > Your /usr/include is hosed, well, actually your machine/stdarg.h > is the broken version (rev. 1.12). Please manually install the > revision 1.14 under /usr/include/machine/ and try again. Still broken. :(( Following is piece of log (sources cvsup'ed today). Any ideas are appreciated. -Maxim root@notebook# make buildworld -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/i386 [...] -------------------------------------------------------------- >>> stage 4: building libraries -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; cd /usr/src/gnu/lib/csu; make DIRPRFX=gnu/lib/csu/ depend; make DIRPRFX=gnu/lib/csu/ all; make DIRPRFX=gnu/lib/csu/ install make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc tconfig.h echo 'struct rtx_def;' > tconfig.h echo 'typedef struct rtx_def *rtx;' >> tconfig.h echo 'struct rtvec_def;' >> tconfig.h echo 'typedef struct rtvec_def *rtvec;' >> tconfig.h echo 'union tree_node;' >> tconfig.h echo 'typedef union tree_node *tree;' >> tconfig.h echo '' >> tconfig.h echo '#include "ansidecl.h"' >> tconfig.h echo '#include "i386/i386.h"' >> tconfig.h echo '#include "i386/att.h"' >> tconfig.h echo '#include "dbxelf.h"' >> tconfig.h echo '#include "elfos.h"' >> tconfig.h echo '#include ' >> tconfig.h echo '#include "freebsd-spec.h"' >> tconfig.h echo '#include "freebsd.h"' >> tconfig.h echo '#include "i386/freebsd.h"' >> tconfig.h echo '#include "defaults.h"' >> tconfig.h echo '#ifndef POSIX' >> tconfig.h echo '# define POSIX' >> tconfig.h echo '#endif' >> tconfig.h echo '#define CONFIG_SJLJ_EXCEPTIONS 0' >> tconfig.h rm -f .depend CC="cc" MKDEP_CPP_OPTS="-M -DCRT_BEGIN" mkdep -f .depend -a -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:0: malformed option `-A system=unix' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:0: malformed option `-A system=bsd' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:0: malformed option `-A system=FreeBSD' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:0: malformed option `-A cpu=i386' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:0: malformed option `-A machine=i386' mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:15:21 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id B956937B40F; Tue, 11 Jun 2002 05:15:17 -0700 (PDT) Date: Tue, 11 Jun 2002 05:15:17 -0700 From: Juli Mallett To: current@FreeBSD.ORG Subject: Looking for comments on a new utility... Message-ID: <20020611051517.A87966@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hej, As some of you may have noticed, I've done some poking of ps(1) lately, and this has brought attention of people who have ideas for things that they would like to see done to ps(1) :) The most notable request was for a feature I've missed having in our ps(1) for a while, the ability to get a tree of processes printed so you can tell who is whose child, etc. ps(1)'s internals, however, didn't seem quite right to me, but after about 10 minutes reading kvm(3) manpages and recalling some tricks with recursive programming to produce an N-level tree with as many as N-1 elements, I had come up with a simple utility to print out a "process tree". You can find the code here: http://people.freebsd.org/~jmallett/.proctree/proctree.c And some example output from a cluster machine here: http://people.freebsd.org/~jmallett/.proctree/proctree.out Lots of people have given feedback that they don't care much for the \_ formatting of the tree, and I'm willing to look at patches that provide noticably more readable output. I'd actually like to hear what information otherwise could better be included along with associated login, pid, cpu, etc. And I'd really like to hear thoughts about inclusion of this into the tree. Does anyone hold the opinion that it absolutely cannot be included? Does anyone have any suggestions to make the code better? I'm asking you guys, the CURRENT userbase, since you are users who obviously seem to take more of an interest in FreeBSD's future, etc. :) Thanks, juli. -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:40:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id BE22A37B401; Tue, 11 Jun 2002 05:40:06 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id 205BC77C9; Tue, 11 Jun 2002 14:39:59 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id BFBB92C3D1; Tue, 11 Jun 2002 14:39:57 +0200 (CEST) Date: Tue, 11 Jun 2002 14:39:57 +0200 From: Thomas Quinot To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611143957.A17613@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <20020611051517.A87966@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020611051517.A87966@FreeBSD.ORG>; from jmallett@FreeBSD.org on Tue, Jun 11, 2002 at 05:15:17AM -0700 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Le 2002-06-11, Juli Mallett écrivait : > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. Yes, this would be an invaluable feature! Even nicer would be a user interface (command line, output style) consistent with the existing Linux pstree utility. This one also has a nice functionality: by default it will collapse all siblings with the same name, in order to limit display clutter, eg: |-omniNames---omniNames---3*[omniNames] with the following being printed if you ask for pids ('-p'): |-omniNames(313)---omniNames(335)-+-omniNames(336) | |-omniNames(338) | `-omniNames(345) (note: this is not the same as our sysutils/pstree port, which postprocesses the output of ps(1)). One version of the Linux pstree is available from the psmisc port. Another, more recent, has been ported to several platforms (including NetBSD), see http://www.chiark.greenend.org.uk/~bjharris/. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:40:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by hub.freebsd.org (Postfix) with ESMTP id 750AD37B414; Tue, 11 Jun 2002 05:40:16 -0700 (PDT) Received: from gpo.openet-telecom.lan (unverified) by mail.openet-telecom.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 11 Jun 2002 13:52:05 +0100 Received: from openet-telecom.com (10.0.0.40) by gpo.openet-telecom.lan (NPlex 6.5.007) id 3CF373520000B004; Tue, 11 Jun 2002 13:37:00 +0100 Message-ID: <3D05EFA8.6070805@openet-telecom.com> Date: Tue, 11 Jun 2002 13:40:08 +0100 From: Peter Edwards User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Solaris has something similar in /usr/proc/bin/ptree. One of the things it lets you do is specify _which_ user to use. Isn't the kvm_*() interface somewhat frowned upon? Is there anything missing from /proc that you need kvm_* for? -- Cheers, Peter. Juli Mallett wrote: > Hej, > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. > > ps(1)'s internals, however, didn't seem quite right to me, but after about > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > programming to produce an N-level tree with as many as N-1 elements, I had > come up with a simple utility to print out a "process tree". > > You can find the code here: > http://people.freebsd.org/~jmallett/.proctree/proctree.c > > And some example output from a cluster machine here: > http://people.freebsd.org/~jmallett/.proctree/proctree.out > > Lots of people have given feedback that they don't care much for the \_ > formatting of the tree, and I'm willing to look at patches that provide > noticably more readable output. > > I'd actually like to hear what information otherwise could better be > included along with associated login, pid, cpu, etc. > > And I'd really like to hear thoughts about inclusion of this into the tree. > Does anyone hold the opinion that it absolutely cannot be included? Does > anyone have any suggestions to make the code better? > > I'm asking you guys, the CURRENT userbase, since you are users who obviously > seem to take more of an interest in FreeBSD's future, etc. :) > > Thanks, > juli. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:40:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 8CAEE37B406; Tue, 11 Jun 2002 05:40:44 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17Hkxc-000CIl-00; Tue, 11 Jun 2002 14:41:20 +0200 From: Sheldon Hearn To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... In-reply-to: Your message of "Tue, 11 Jun 2002 05:15:17 MST." <20020611051517.A87966@FreeBSD.ORG> Date: Tue, 11 Jun 2002 14:41:20 +0200 Message-ID: <47290.1023799280@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote: > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. Like pstree in the ports tree? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:41: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id E846C37B408; Tue, 11 Jun 2002 05:41:00 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7E1B55361; Tue, 11 Jun 2002 14:40:55 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> From: Dag-Erling Smorgrav Date: 11 Jun 2002 14:40:54 +0200 In-Reply-To: <20020611051517.A87966@FreeBSD.ORG> Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett writes: > ps(1)'s internals, however, didn't seem quite right to me, but after about > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > programming to produce an N-level tree with as many as N-1 elements, I had > come up with a simple utility to print out a "process tree". Don't do anything in ps(1) that depends on libkvm. It has to be doable with sysctl as well. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 5:44:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id E26DB37B408; Tue, 11 Jun 2002 05:44:26 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 98B6F5362; Tue, 11 Jun 2002 14:44:25 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Edwards Cc: Juli Mallett , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> <3D05EFA8.6070805@openet-telecom.com> From: Dag-Erling Smorgrav Date: 11 Jun 2002 14:44:25 +0200 In-Reply-To: <3D05EFA8.6070805@openet-telecom.com> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Edwards writes: > Isn't the kvm_*() interface somewhat frowned upon? Is there anything > missing from /proc that you need kvm_* for? /proc is also frowned upon, use sysctl. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:33:54 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id A9DF837B40C; Tue, 11 Jun 2002 06:33:48 -0700 (PDT) Date: Tue, 11 Jun 2002 06:33:48 -0700 From: Juli Mallett To: Thomas Quinot Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611063348.A97611@FreeBSD.ORG> References: <20020611051517.A87966@FreeBSD.ORG> <20020611143957.A17613@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020611143957.A17613@melusine.cuivre.fr.eu.org>; from thomas@cuivre.fr.eu.org on Tue, Jun 11, 2002 at 02:39:57PM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Thomas Quinot escriurères > Le 2002-06-11, Juli Mallett écrivait : > > > feature I've missed having in our ps(1) for a while, the ability to get a > > tree of processes printed so you can tell who is whose child, etc. > > Yes, this would be an invaluable feature! > > Even nicer would be a user interface (command line, output style) > consistent with the existing Linux pstree utility. This one also has > a nice functionality: by default it will collapse all siblings with > the same name, in order to limit display clutter, eg: > > |-omniNames---omniNames---3*[omniNames] That seems frighteningly useless to me though. Seems a bit like a number of utilities I've seen from the Linux camp which take useful functionality and mask it behind something that looks good. What exactly can you get from that kind of output? > with the following being printed if you ask for pids ('-p'): > > |-omniNames(313)---omniNames(335)-+-omniNames(336) > | |-omniNames(338) > | `-omniNames(345) That output's pretty useful, on the other hand, but it seems overly difficult to do that sort of formatting without kludging everything with a lot of conditionals and rather than simple recursion, something more complex. > (note: this is not the same as our sysutils/pstree port, which > postprocesses the output of ps(1)). Yuck. > One version of the Linux pstree is available from the psmisc port. > Another, more recent, has been ported to several platforms (including > NetBSD), see http://www.chiark.greenend.org.uk/~bjharris/. Interesting. Thanks for the pointers. -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:35:13 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 1B43137B413; Tue, 11 Jun 2002 06:35:05 -0700 (PDT) Date: Tue, 11 Jun 2002 06:35:05 -0700 From: Juli Mallett To: Dag-Erling Smorgrav Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611063505.B97611@FreeBSD.ORG> References: <20020611051517.A87966@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from des@ofug.org on Tue, Jun 11, 2002 at 02:40:54PM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Dag-Erling Smorgrav escriurères > Juli Mallett writes: > > ps(1)'s internals, however, didn't seem quite right to me, but after about > > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > > programming to produce an N-level tree with as many as N-1 elements, I had > > come up with a simple utility to print out a "process tree". > > Don't do anything in ps(1) that depends on libkvm. It has to be > doable with sysctl as well. I believe I can get pid, ppid, username (or at least uid [yay user_from_uid]), etc., from sysctl(3) at least as easily as with kvm(3). -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:37:31 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 0F48337B41B; Tue, 11 Jun 2002 06:37:08 -0700 (PDT) Date: Tue, 11 Jun 2002 06:37:08 -0700 From: Juli Mallett To: Sheldon Hearn Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611063707.C97611@FreeBSD.ORG> References: <20020611051517.A87966@FreeBSD.ORG> <47290.1023799280@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <47290.1023799280@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Tue, Jun 11, 2002 at 02:41:20PM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Sheldon Hearn escriurères > On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote: > > > > As some of you may have noticed, I've done some poking of ps(1) lately, and > > this has brought attention of people who have ideas for things that they > > would like to see done to ps(1) :) The most notable request was for a > > feature I've missed having in our ps(1) for a while, the ability to get a > > tree of processes printed so you can tell who is whose child, etc. > > Like pstree in the ports tree? Wasn't really aware of that existing, but my understanding from another message in this thread is it just works with the output from ps(1)? That seems a bit icky to me. -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:41: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from theinternet.com.au (c16543.carlnfd1.nsw.optusnet.com.au [210.49.135.162]) by hub.freebsd.org (Postfix) with ESMTP id DD50B37B40B; Tue, 11 Jun 2002 06:40:56 -0700 (PDT) Received: (from akm@localhost) by theinternet.com.au (8.11.6/8.11.4) id g5BDetm38716; Tue, 11 Jun 2002 23:40:55 +1000 (EST) (envelope-from akm) Date: Tue, 11 Jun 2002 23:40:55 +1000 From: Andrew Kenneth Milton To: Juli Mallett Cc: Sheldon Hearn , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611234055.N91173@zeus.theinternet.com.au> References: <20020611051517.A87966@FreeBSD.ORG> <47290.1023799280@axl.seasidesoftware.co.za> <20020611063707.C97611@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020611063707.C97611@FreeBSD.ORG>; from jmallett@FreeBSD.ORG on Tue, Jun 11, 2002 at 06:37:08AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG +-------[ Juli Mallett ]---------------------- | | Wasn't really aware of that existing, but my understanding from another message | in this thread is it just works with the output from ps(1)? That seems a bit | icky to me. Piping commands through other commands seems icky? -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |akm@theinternet.com.au| Carpe Daemon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:41:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by hub.freebsd.org (Postfix) with ESMTP id B8FBD37B40C for ; Tue, 11 Jun 2002 06:41:37 -0700 (PDT) Received: from relayb.mw.cray.com (relayb.mw.cray.com [192.168.252.110]) by mail1.cray.com (8.12.3/8.12.3/gw-1.14) with ESMTP id g5BDfaem017035 for ; Tue, 11 Jun 2002 08:41:36 -0500 (CDT) Received: from saffron.mw.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.3/8.12.3/hub-1.14) with ESMTP id g5BDfZmc011134 for ; Tue, 11 Jun 2002 08:41:35 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-16-182 [172.31.16.182]) by saffron.mw.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id IAA1789034 for ; Tue, 11 Jun 2002 08:41:35 -0500 (CDT) Message-ID: <3D05FE0F.5060701@cray.com> Date: Tue, 11 Jun 2002 08:41:35 -0500 From: Jan Gustafson Organization: Cray Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: (no subject) References: <20020611051517.A87966@FreeBSD.ORG> <20020611143957.A17613@melusine.cuivre.fr.eu.org> <20020611063348.A97611@FreeBSD.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG unsubscribe freebsd-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:44:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id A300837B406; Tue, 11 Jun 2002 06:44:12 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id C10D877F5; Tue, 11 Jun 2002 15:44:10 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 718D22C3D1; Tue, 11 Jun 2002 15:44:09 +0200 (CEST) Date: Tue, 11 Jun 2002 15:44:09 +0200 From: Thomas Quinot To: Juli Mallett Cc: Thomas Quinot , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611154409.A31815@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <20020611051517.A87966@FreeBSD.ORG> <20020611143957.A17613@melusine.cuivre.fr.eu.org> <20020611063348.A97611@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020611063348.A97611@FreeBSD.ORG>; from jmallett@FreeBSD.org on Tue, Jun 11, 2002 at 06:33:48AM -0700 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Le 2002-06-11, Juli Mallett écrivait : > mask it behind something that looks good. What exactly can you get from > that kind of output? The overall organization of the tree. Useless if the information you are looking for is 'what is the PID of the father of X', but may be useful when you have some complex activity going on and want to grasp the overall structure of running processes. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:46:16 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 1A90E37B40D; Tue, 11 Jun 2002 06:46:13 -0700 (PDT) Date: Tue, 11 Jun 2002 06:46:13 -0700 From: Juli Mallett To: Andrew Kenneth Milton Cc: Sheldon Hearn , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611064612.A703@FreeBSD.ORG> References: <20020611051517.A87966@FreeBSD.ORG> <47290.1023799280@axl.seasidesoftware.co.za> <20020611063707.C97611@FreeBSD.ORG> <20020611234055.N91173@zeus.theinternet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020611234055.N91173@zeus.theinternet.com.au>; from akm@theinternet.com.au on Tue, Jun 11, 2002 at 11:40:55PM +1000 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Andrew Kenneth Milton escriurères > +-------[ Juli Mallett ]---------------------- > | > | Wasn't really aware of that existing, but my understanding from another message > | in this thread is it just works with the output from ps(1)? That seems a bit > | icky to me. > > Piping commands through other commands seems icky? Relying on reasonable output from ps(1) seems icky when you can extract the data yourself and not have to worry about formatting getting in the way of processing data properly. -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:48:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by hub.freebsd.org (Postfix) with ESMTP id 7EB0E37B403 for ; Tue, 11 Jun 2002 06:48:38 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5BDmbRY022918 for ; Tue, 11 Jun 2002 09:48:37 -0400 Received: from calvin.in.ibm.com (calvin.in.ibm.com [9.182.24.126]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BDmZs66450 for ; Tue, 11 Jun 2002 07:48:36 -0600 Received: by calvin.in.ibm.com (Postfix, from userid 1001) id DE96B3381; Tue, 11 Jun 2002 19:13:08 +0530 (IST) Date: Tue, 11 Jun 2002 19:13:08 +0530 From: Sid Carter To: freebsd-current@freebsd.org Subject: Kernel Panic and Automagic Reboots Message-ID: <20020611134308.GA346@calvin.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i X-Operating-System: FreeBSD calvin.in.ibm.com 5.0-CURRENT FreeBSD 5.0-CURRENT Organisation: Sid Carter Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Today my system rebooted twice automagically. This is what the message log shows. -------------------------------------------------- Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with "process lock" locked from /usr/src/sys/kern/kern_prot.c:511 Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with "process lock" locked from /usr/src/sys/kern/kern_prot.c:613 Jun 11 19:02:20 calvin kernel: Memory modified after free 0xd33f5900(252) Jun 11 19:02:20 calvin kernel: panic: Most recently used by kqueue Jun 11 19:02:20 calvin kernel: Jun 11 19:02:20 calvin kernel: Jun 11 19:02:20 calvin kernel: syncing disks... panic: bremfree: bp 0xc76431a0 n ot locked Jun 11 19:02:20 calvin kernel: Uptime: 6h1m9s Jun 11 19:02:20 calvin kernel: pfs_vncache_unload(): 1 entries remaining Jun 11 19:02:20 calvin kernel: Terminate ACPI Jun 11 19:02:20 calvin kernel: Automatic reboot in 15 seconds - press a key on t he console to abort Jun 11 19:02:20 calvin kernel: --> Press a key on the console to reboot, Jun 11 19:02:20 calvin kernel: --> or switch off the system now. Jun 11 19:02:20 calvin kernel: Rebooting... -------------------------------------------------- This has happened twice and more info about the compiled kernel is -------------------------------------------------- FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jun 10 13:55:43 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 Jun 11 19:02:20 calvin kernel: Timecounter "i8254" frequency 1193182 Hz Jun 11 19:02:20 calvin kernel: Timecounter "TSC" frequency 996769599 Hz Jun 11 19:02:20 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron (996.77 -MHz 686-class CPU) Jun 11 19:02:20 calvin kernel: Origin = "GenuineIntel" Id = 0x68a Stepping = 1 0 Jun 11 19:02:20 calvin kernel: Features=0x383fbff Jun 11 19:02:20 calvin kernel: real memory = 267255808 (260992K bytes) Jun 11 19:02:20 calvin kernel: avail memory = 253108224 (247176K bytes) -------------------------------------------------- Has anyone else encountered this ? Something wrong with my machine ? TIA Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 6:50:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by hub.freebsd.org (Postfix) with ESMTP id 12EF237B40A for ; Tue, 11 Jun 2002 06:50:41 -0700 (PDT) Received: from relayb.mw.cray.com (relayb.mw.cray.com [192.168.252.110]) by mail1.cray.com (8.12.3/8.12.3/gw-1.14) with ESMTP id g5BDobem017300 for ; Tue, 11 Jun 2002 08:50:38 -0500 (CDT) Received: from saffron.mw.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.3/8.12.3/hub-1.14) with ESMTP id g5BDobmc011483 for ; Tue, 11 Jun 2002 08:50:37 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-16-182 [172.31.16.182]) by saffron.mw.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id IAA1786718 for ; Tue, 11 Jun 2002 08:50:36 -0500 (CDT) Message-ID: <3D06002C.4050403@cray.com> Date: Tue, 11 Jun 2002 08:50:36 -0500 From: Jan Gustafson Organization: Cray Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: current Subject: [Fwd: (no subject)] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG unsubscribe freebsd-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:25: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 8CE5C37B405; Tue, 11 Jun 2002 07:25:01 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17HmaF-00009x-00; Tue, 11 Jun 2002 16:25:19 +0200 From: Sheldon Hearn To: Juli Mallett Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... In-reply-to: Your message of "Tue, 11 Jun 2002 06:46:13 MST." <20020611064612.A703@FreeBSD.ORG> Date: Tue, 11 Jun 2002 16:25:19 +0200 Message-ID: <616.1023805519@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote: > > Piping commands through other commands seems icky? > > Relying on reasonable output from ps(1) seems icky when you can extract the > data yourself and not have to worry about formatting getting in the way of > processing data properly. I don't think you should worry too much about _not_ getting reasonable output from POSIX-conformant utilities. :-) I didn't want to be the one to break the "pstree exists" news, because I know how frustrating it is to discover that you've just engineered a solution to a solved problem, but it's an unfortunate fact of life. I was very annoyed when I realized that my waitpid(1) program that I was so proud of already existed in several incarnations. :-) Still, you can be proud of the work you've done. You could even get it into the ports tree. It's always nice to have choices. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:26: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B229C37B401; Tue, 11 Jun 2002 07:26:02 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 5A4C05362; Tue, 11 Jun 2002 16:26:01 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> <20020611063505.B97611@FreeBSD.ORG> From: Dag-Erling Smorgrav Date: 11 Jun 2002 16:26:00 +0200 In-Reply-To: <20020611063505.B97611@FreeBSD.ORG> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett writes: > I believe I can get pid, ppid, username (or at least uid [yay > user_from_uid]), etc., from sysctl(3) at least as easily as with > kvm(3). You can get the full process table from sysctl (kern.proc.all) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:29:59 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 6669237B409; Tue, 11 Jun 2002 07:29:56 -0700 (PDT) Date: Tue, 11 Jun 2002 07:29:56 -0700 From: Juli Mallett To: Sheldon Hearn Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... Message-ID: <20020611072956.A6437@FreeBSD.ORG> References: <20020611064612.A703@FreeBSD.ORG> <616.1023805519@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <616.1023805519@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Tue, Jun 11, 2002 at 04:25:19PM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Sheldon Hearn escriurères > > > On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote: > > > > Piping commands through other commands seems icky? > > > > Relying on reasonable output from ps(1) seems icky when you can extract the > > data yourself and not have to worry about formatting getting in the way of > > processing data properly. > > I don't think you should worry too much about _not_ getting reasonable > output from POSIX-conformant utilities. :-) I'd read SUS's ps(1) escription a little closer. Very few guarantees with it. > I didn't want to be the one to break the "pstree exists" news, because I > know how frustrating it is to discover that you've just engineered a > solution to a solved problem, but it's an unfortunate fact of life. I > was very annoyed when I realized that my waitpid(1) program that I was > so proud of already existed in several incarnations. :-) It's fine :) > Still, you can be proud of the work you've done. You could even get it > into the ports tree. It's always nice to have choices. That's something to think about :) Thanks. -- Juli Mallett FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:37:35 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 6DC3337B40A; Tue, 11 Jun 2002 07:37:29 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17Hmmb-0000El-00; Tue, 11 Jun 2002 16:38:05 +0200 From: Sheldon Hearn To: Juli Mallett Cc: Andrew Kenneth Milton , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... In-reply-to: Your message of "Tue, 11 Jun 2002 07:29:56 MST." <20020611072956.A6437@FreeBSD.ORG> Date: Tue, 11 Jun 2002 16:38:05 +0200 Message-ID: <914.1023806285@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002 07:29:56 MST, Juli Mallett wrote: > > I don't think you should worry too much about _not_ getting > > reasonable output from POSIX-conformant utilities. :-) > > I'd read SUS's ps(1) escription a little closer. Very few guarantees > with it. My POSIX.2 (1993) suggests that you can get a sufficient level of regularity out of ps(1) to provide reliable input for a tree printer. I think the "5.23.6.1 Standard Output" section defines the impact of the format specified with the -o option "well enough". I haven't looked at what SUS has to say about the issue, but if it's more ambiguous, then it's a regression from POSIX.2 (1993) and should be corrected. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:43:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by hub.freebsd.org (Postfix) with ESMTP id 1A31B37B406 for ; Tue, 11 Jun 2002 07:43:21 -0700 (PDT) Received: from [62.64.208.29] (helo=cream.org) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 3.35 #1) id 17HmrG-000EB5-00; Tue, 11 Jun 2002 15:42:54 +0100 Message-ID: <3D060D08.7060500@cream.org> Date: Tue, 11 Jun 2002 15:45:28 +0100 From: Andrew Boothman User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Andrews Cc: Mark Murray , current@freebsd.org Subject: Re: The great perl rewrite - progress report References: <200206061631.g56GVDUE019782@grimreaper.grondar.org> <20020606201235.GB53809@squall.waterspout.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Will Andrews wrote: > On Thu, Jun 06, 2002 at 05:31:12PM +0100, Mark Murray wrote: > >>/usr/sbin/sysinstall * - fix - * > > > What part of this uses perl?? Perhaps it was just a general comment ;-) Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 7:58:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from nightmare.lothlorien.no (lothlorien.no [217.8.137.178]) by hub.freebsd.org (Postfix) with ESMTP id 0A8F937B408 for ; Tue, 11 Jun 2002 07:58:42 -0700 (PDT) Received: from vampire.lothlorien.no (vampire.lothlorien.no [192.168.1.1]) by nightmare.lothlorien.no (8.12.3/8.12.3) with ESMTP id g5BEwdL0042722 for ; Tue, 11 Jun 2002 16:58:39 +0200 (CEST) (envelope-from killer@lothlorien.no) Subject: Crash after world/kernel upgrade From: Thomas Ugland To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QXQYRZwTVSC8r1Sa0qAj" X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 16:58:39 +0200 Message-Id: <1023807519.376.46.camel@vampire.lothlorien.no> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-QXQYRZwTVSC8r1Sa0qAj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable System crashed after updating today. During the start of system services, in specific at the start of sendmail the system crashes with the new kernel. :/ uname -a: --------- FreeBSD vampire.lothlorien.no 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jun 11 15:41:09 CEST 2002 root@:/usr/src/sys/i386/compile/VAMPIRE=20 i386 gdb/bt: ------- GNU gdb 5.2 (FreeBSD) This GDB was configured as "i386-portbld-freebsd5.0"... IdlePTD at phsyical address 0x0050d000 initial pcb at physical address 0x003d9b80 panicstr: from debugger panic messages: --- panic: system call close returning with mutex(s) held panic: from debugger Uptime: 1m15s Dumping 255 MB ata0: resetting devices .. ad0: DMA limited to UDMA33, non-ATA66 cable or device done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0202024 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:346 #2 0xc0202201 in panic () at /usr/src/sys/kern/kern_shutdown.c:490 #3 0xc0143dd4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:449 #4 0xc0143d69 in db_command (last_cmdp=3D0xc03810a0, cmd_table=3D0xcdffeb10, aux_cmd_tablep=3D0xc0143dd4, aux_cmd_tablep_end=3D0xc0339bc8) at /usr/src/sys/ddb/db_command.c:345 #5 0xc0143e4c in db_command_loop () at /usr/src/sys/ddb/db_command.c:471 #6 0xc014656c in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_trap.c:72 #7 0xc030efeb in kdb_trap (type=3D3, code=3D0, regs=3D0xcdffec78) at /usr/src/sys/i386/i386/db_interface.c:161 #8 0xc031e231 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -838889472, tf_= esi =3D 256, tf_ebp =3D -838865724, tf_isp =3D -838865756, tf_ebx =3D 0, tf_edx =3D= 0, tf_ecx =3D 32, tf_eax =3D 18, tf_trapno =3D 3, tf_err =3D 0, tf_eip =3D -1070534051, tf_cs =3D 8, tf_eflags =3D 662, tf_esp =3D -1070127393, tf_ss = =3D -1070254436}) at /usr/src/sys/i386/i386/trap.c:585 #9 0xc030f25d in Debugger (msg=3D0x0) at cpufunc.h:68 #10 0xc02021ea in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:477 #11 0xc031ec5e in syscall (frame=3D {tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 135235593, tf_e= si =3D 420, tf_ebp =3D -1077943416, tf_isp =3D -838865548, tf_ebx =3D 673845760, tf_edx =3D 135217248, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err = =3D 2, tf_eip =3D 673441123, tf_cs =3D 31, tf_eflags =3D 518, tf_esp =3D -10779434= 60, tf_ss =3D 47}) at /usr/src/sys/i386/i386/trap.c:1081 #12 0xc031060d in syscall_with_err_pushed () at {standard input}:128 #13 0x0806c149 in ?? () #14 0x0804c08d in ?? () (kgdb)=20 --=20 Thomas Ugland -> If everything is coming your way then you're in the wrong lane. <- --=-QXQYRZwTVSC8r1Sa0qAj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9BhAftEcIL3Mpih4RAmZLAJwLVTwJYZZH3IFYf4KelSg0kRx6bwCdF6Wg d1ORto81Ht4fqdBsYCzPbTQ= =VEvQ -----END PGP SIGNATURE----- --=-QXQYRZwTVSC8r1Sa0qAj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 9:14: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from encontacto.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id DFA6F37B405 for ; Tue, 11 Jun 2002 09:13:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (uid 0) by encontacto.net with local; Tue, 11 Jun 2002 09:13:44 -0700 Received: from adsl-64-173-182-155.dsl.mtry01.pacbell.net (adsl-64-173-182-155.dsl.mtry01.pacbell.net [64.173.182.155]) as user eculp@encontacto.net@encontacto.net by Mail.EnContacto.Net with HTTP; Tue, 11 Jun 2002 09:13:44 -0700 Message-ID: <1023812024.3d0621b85f97b@Mail.EnContacto.Net> Date: Tue, 11 Jun 2002 09:13:44 -0700 From: Edwin Culp To: Sid Carter Cc: freebsd-current@freebsd.org Subject: Re: Kernel Panic and Automagic Reboots References: <20020611134308.GA346@calvin.in.ibm.com> In-Reply-To: <20020611134308.GA346@calvin.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Quoting Sid Carter : | Hi, | | Today my system rebooted twice automagically. This is what the message | log shows. | | -------------------------------------------------- | Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep | with | "process lock" locked from /usr/src/sys/kern/kern_prot.c:511 | Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep | with | "process lock" locked from /usr/src/sys/kern/kern_prot.c:613 | Jun 11 19:02:20 calvin kernel: Memory modified after free | 0xd33f5900(252) | Jun 11 19:02:20 calvin kernel: panic: Most recently used by kqueue | Jun 11 19:02:20 calvin kernel: | Jun 11 19:02:20 calvin kernel: | Jun 11 19:02:20 calvin kernel: syncing disks... panic: bremfree: bp | 0xc76431a0 n | ot locked | Jun 11 19:02:20 calvin kernel: Uptime: 6h1m9s | Jun 11 19:02:20 calvin kernel: pfs_vncache_unload(): 1 entries remaining | Jun 11 19:02:20 calvin kernel: Terminate ACPI | Jun 11 19:02:20 calvin kernel: Automatic reboot in 15 seconds - press a | key on t | he console to abort | Jun 11 19:02:20 calvin kernel: --> Press a key on the console to reboot, | Jun 11 19:02:20 calvin kernel: --> or switch off the system now. | Jun 11 19:02:20 calvin kernel: Rebooting... | -------------------------------------------------- | | This has happened twice and more info about the compiled kernel is | | -------------------------------------------------- | FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jun 10 13:55:43 IST | 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 | | Jun 11 19:02:20 calvin kernel: Timecounter "i8254" frequency 1193182 Hz | Jun 11 19:02:20 calvin kernel: Timecounter "TSC" frequency 996769599 Hz | Jun 11 19:02:20 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron | (996.77 | -MHz 686-class CPU) | Jun 11 19:02:20 calvin kernel: Origin = "GenuineIntel" Id = 0x68a | Stepping = 1 | 0 | Jun 11 19:02:20 calvin kernel: | Features=0x383fbff | Jun 11 19:02:20 calvin kernel: real memory = 267255808 (260992K bytes) | Jun 11 19:02:20 calvin kernel: avail memory = 253108224 (247176K bytes) | -------------------------------------------------- | | Has anyone else encountered this ? Something wrong with my machine ? | My laptop is rebooting with todays current/kernel in ifconfig. I just got it up with an old kernel and am checking now. It will run with the new kernel if I don't try to configure the network. I may have something wrong though. ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 9:27:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by hub.freebsd.org (Postfix) with ESMTP id 03EBF37B406; Tue, 11 Jun 2002 09:27:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.11.6/8.11.6) with ESMTP id g5BGRX378029; Tue, 11 Jun 2002 16:27:33 GMT (envelope-from tegge@cvsup.no.freebsd.org) To: killer@lothlorien.no, hsu@freebsd.org Cc: current@freebsd.org Subject: Re: Crash after world/kernel upgrade From: Tor.Egge@cvsup.no.freebsd.org In-Reply-To: <1023807519.376.46.camel@vampire.lothlorien.no> References: <1023807519.376.46.camel@vampire.lothlorien.no> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jun_11_16:26:55_2002_809)--" Content-Transfer-Encoding: 7bit Message-Id: <20020611162732B.tegge@cvsup.no.freebsd.org> Date: Tue, 11 Jun 2002 16:27:32 GMT X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Tue_Jun_11_16:26:55_2002_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > System crashed after updating today. > During the start of system services, in specific > at the start of sendmail the system crashes with > the new kernel. :/ There are some problems with the inpcb locking: - attempts to destroy held lock in in_pcbdetach. - typo in unlocking (causing recursive lock instead) - lack of inet6 support for inpcb locking, e.g. no handling of locks in in6_pcbdetach. I had to comment out INET6 from my kernel config file and apply the enclosed patch to get my machine to boot today. - Tor Egge ----Next_Part(Tue_Jun_11_16:26:55_2002_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=netinetfix Index: sys/netinet/in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.106 diff -u -r1.106 in_pcb.c --- sys/netinet/in_pcb.c 10 Jun 2002 20:05:36 -0000 1.106 +++ sys/netinet/in_pcb.c 11 Jun 2002 16:13:29 -0000 @@ -573,6 +573,11 @@ rtfree(inp->inp_route.ro_rt); ip_freemoptions(inp->inp_moptions); inp->inp_vflag = 0; + /* XXX: Kludge: Unlock inp before crashing */ + if (mtx_owned(&inp->inp_mtx)) { + printf("Warning: INP_LOCK held in in_pcbdetach\n"); + INP_UNLOCK(inp); + } INP_LOCK_DESTROY(inp); uma_zfree(ipi->ipi_zone, inp); } @@ -741,7 +746,7 @@ } INP_UNLOCK(inp); } - INP_INFO_RLOCK(pcbinfo); + INP_INFO_RUNLOCK(pcbinfo); } /* ----Next_Part(Tue_Jun_11_16:26:55_2002_809)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 9:36: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0E70C37B40F; Tue, 11 Jun 2002 09:36:00 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5BGZxQ33413; Tue, 11 Jun 2002 10:35:59 -0600 (MDT) (envelope-from ken) Date: Tue, 11 Jun 2002 10:35:59 -0600 From: "Kenneth D. Merry" To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org Subject: Re: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020611103559.A33391@panzer.kdm.org> References: <20020609224036.A21143@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Jun 11, 2002 at 04:37:04AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 11, 2002 at 04:37:04 -0400, John Baldwin wrote: > On 10-Jun-2002 Kenneth D. Merry wrote: > > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > > ends up calling vm_map_entry_create(), same problem as above. > > > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls malloc() with M_WAITOK. > > > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls uma_zalloc() with M_WAITOK. > > > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls MALLOC() with M_WAITOK in various places. > > > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > > with M_WAITOK. > > > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > > vm_map_find(), which through several calls calls vm_map_entry_create(). > > > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > > which does a uma_zalloc() with M_WAITOK. > > > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > > ithread_add_handler() through several layers of indirection. > > ithread_add_handler() calls malloc with M_WAITOK. > > ti_attach() doesn't need to hold its lock while doing these things. Don't > actually enable the logical network device until all the setup for it is done. Okay, will do. > > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > > uma_zalloc with M_WAITOK. > > > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > > function), which calls kmem_alloc_pageable(). See number 1 above, same > > problem here with vm_map_entry_create(). > > > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > > gets called, which calls vm_map_entry_create(), which calls > > uma_zalloc() with M_WAITOK. > > > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > > called through a slightly different path from the same root malloc() > > call in jumbo_vm_init(). > > Same as above with regards to ti_attach(). > > > - the bus_setup_intr(), or rather the kthread code in general apparantly > > isn't safe to be called while holding a mutex. This is the cause of the > > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. > > Yes. Thanks! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10: 9:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from valu.uninet.ee (valu.uninet.ee [194.204.34.51]) by hub.freebsd.org (Postfix) with ESMTP id 12EA737B401 for ; Tue, 11 Jun 2002 10:09:44 -0700 (PDT) Received: by valu.uninet.ee (Postfix, from userid 1002) id 8D75B36420; Tue, 11 Jun 2002 20:09:42 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by valu.uninet.ee (Postfix) with ESMTP id 8820432619 for ; Tue, 11 Jun 2002 20:09:42 +0300 (EEST) Date: Tue, 11 Jun 2002 20:09:42 +0300 (EEST) From: Taavi Talvik To: current@freebsd.org Subject: no /dev/apmctl ? Message-ID: <20020611200324.I93773-100000@valu.uninet.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have included apm in kernel (cvsupped yesterday) config file. However, it does not create /dev/apmctl >l /dev/apm* crw-rw-r-- 1 root operator 39, 0 Jun 11 19:31 /dev/apm How is this possible? Driver code /usr/src/sys/i386/apm/apm.c calls creation of both device nodes around line 1106 without any conditionals make_dev(&apm_cdevsw, 0, 0, 5, 0664, "apm"); make_dev(&apm_cdevsw, 8, 0, 5, 0660, "apmctl"); best regards, taavi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:15: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id 2BBD437B40B for ; Tue, 11 Jun 2002 10:14:54 -0700 (PDT) Message-ID: <20020611171448.77703.qmail@web13305.mail.yahoo.com> Received: from [206.220.224.4] by web13305.mail.yahoo.com via HTTP; Tue, 11 Jun 2002 10:14:48 PDT Date: Tue, 11 Jun 2002 10:14:48 -0700 (PDT) From: Maksim Yevmenkin Subject: Re: Device cloning To: Harti Brandt , Terry Lambert Cc: Maksim Yevmenkin , current@FreeBSD.ORG In-Reply-To: <20020611114039.L35453-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hackers, [...] > TL>I don't think the original poster wanted cloning for support on > TL>physical devices for which there was a 1:1 relationship anyway > TL>(8^)), but there *are* cases where it could be useful. > TL> > TL>Actually, I think the original poster never really disclosed *what* > TL>they wanted to use the feature for... > > That's true... > > From reading the original post I was under the impression that this is > again a 'hey, I write a device driver and I need to track the number of > opens and to tack a context onto each open' that periodically comes up. > If I'm wrong, well, sorry then... I'm sorry people :) I should have been more specific. Here is what i meant. I'm working on Bluetooth stack for FreeBSD. Everything is implemented in Netgraph. The real device driver nodes are connected to HCI layer. You can talk to any Bluetooth device via HCI layer. It does not really matter what kind of device you have, PC-CARD, serial or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) Currently there is a single "control" hook for every HCI node. Control application connects to the hook and sends HCI commands and receives HCI events. It does work, but once the hook is connected, nobody else can connect to the same hook. That is a limitation, IMO. It would really be nice to have several control applications. For example, - HCI dump (a-la tcpdump) - HCI link key/PIN manager (security) My choices were: 1) Create /dev/hci[0-9]+ for every HCI node and implement cloning pid 1 -> /dev/hci0 -+-> hci0 node -> device driver node pid 2 -> /dev/hci0(clone 0) -+ This will not work work. 2) Raw HCI sockets The problem here is how to identify device, i.e. what to put into sockaddr? Netgraph node name? May be not a good choice, because it can be changed at any time. Device BD_ADDR? Does not work also, because in order to get BD_ADDR you must send HCI command to the device. 3) Multiple "control/raw" Netgraph hooks I like it best for now. Each hook will have a filter and every message/data will be delivered to each hook if it has not been filtered. Anyway, i got answers i wanted. Thanks everyone. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:19:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id D2C4F37B40B for ; Tue, 11 Jun 2002 10:19:11 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5BHHZV7052546; Tue, 11 Jun 2002 19:17:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Maksim Yevmenkin Cc: Harti Brandt , Terry Lambert , current@FreeBSD.ORG Subject: Re: Device cloning In-Reply-To: Your message of "Tue, 11 Jun 2002 10:14:48 PDT." <20020611171448.77703.qmail@web13305.mail.yahoo.com> Date: Tue, 11 Jun 2002 19:17:35 +0200 Message-ID: <52544.1023815855@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020611171448.77703.qmail@web13305.mail.yahoo.com>, Maksim Yevmenk in writes: >I'm sorry people :) I should have been more specific. Here is >what i meant. I'm working on Bluetooth stack for FreeBSD. Everything >is implemented in Netgraph. The real device driver nodes are connected >to HCI layer. You can talk to any Bluetooth device via HCI layer. It >does not really matter what kind of device you have, PC-CARD, serial >or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort >of looks like /dev/tcp :) That's called a "protocol family" in BSD and you access it using sockets. Based on what little I know about "Blåtand" it will be much easier to work with as a socket than as a /dev/bla entry. >Currently there is a single "control" hook for every HCI node. Control >application connects to the hook and sends HCI commands and receives >HCI events. It does work, but once the hook is connected, nobody else >can connect to the same hook. That is a limitation, IMO. It would >really be nice to have several control applications. For example, This is exactly the kind of semantics sockets offer you. >2) Raw HCI sockets > > The problem here is how to identify device, i.e. what to put > into sockaddr? Netgraph node name? May be not a good choice, > because it can be changed at any time. Device BD_ADDR? Does not > work also, because in order to get BD_ADDR you must send HCI > command to the device. Well, many TCP clients don't care about the name, so they ask for INADDR_ANY and get whatever the kernel feels like giving them, you could do the same and have the kernel hand out random numbers. In fact, you don't actually have to call bind(2) at all, you can just call socket(2) and run with the result... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:22:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by hub.freebsd.org (Postfix) with ESMTP id 8889537B405 for ; Tue, 11 Jun 2002 10:22:11 -0700 (PDT) Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.192.101]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5BHLtg5063646; Tue, 11 Jun 2002 13:21:56 -0400 Received: from calvin.in.ibm.com (calvin.in.ibm.com [9.182.24.126]) by westrelay05.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BIQaj21794; Tue, 11 Jun 2002 12:26:37 -0600 Received: by calvin.in.ibm.com (Postfix, from userid 1001) id AEA1F33A1; Tue, 11 Jun 2002 22:51:25 +0530 (IST) Date: Tue, 11 Jun 2002 22:51:25 +0530 From: Sid Carter To: Thomas Ugland , freebsd-current@freebsd.org Subject: Re: Crash after world/kernel upgrade Message-ID: <20020611172125.GA1393@calvin.in.ibm.com> References: <1023807519.376.46.camel@vampire.lothlorien.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1023807519.376.46.camel@vampire.lothlorien.no> User-Agent: Mutt/1.3.99i X-Operating-System: FreeBSD calvin.in.ibm.com 5.0-CURRENT FreeBSD 5.0-CURRENT Organisation: Sid Carter Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG An Tue, Jun 11, 2002 at 04:58:39PM +0200, Thomas Ugland schreib : > System crashed after updating today. > During the start of system services, in specific > at the start of sendmail the system crashes with > the new kernel. :/ > uname -a: > --------- > FreeBSD vampire.lothlorien.no 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue > Jun 11 15:41:09 CEST 2002 root@:/usr/src/sys/i386/compile/VAMPIRE > i386 Hi, Just rebooted after a crash and am presently doing a cvsup for a rebuild. I got similar error messages and this is what my /var/log/messages shows. ---------------------------------------------- Jun 11 22:29:29 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with "process lock" locked from /usr/src/sys/kern/kern_prot.c:511 Jun 11 22:29:38 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with "inp" locked from /usr/src/sys/netinet/tcp_usrreq.c:650 Jun 11 22:29:38 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with "tcp" locked from /usr/src/sys/netinet/tcp_usrreq.c:633 Jun 11 22:29:38 calvin kernel: acquiring duplicate lock of same type: "inp" Jun 11 22:29:38 calvin kernel: 1st inp @ /usr/src/sys/netinet/tcp_input.c:631 Jun 11 22:29:38 calvin kernel: 2nd inp @ /usr/src/sys/netinet/tcp_usrreq.c:144 Jun 11 22:34:47 calvin syslogd: kernel boot file is /boot/kernel/kernel Jun 11 22:34:47 calvin kernel: lock order reversal Jun 11 22:34:47 calvin kernel: 1st 0xd311c2f8 inp (inp) @ /usr/src/sys/netinet/tcp_usrreq.c:581 Jun 11 22:34:47 calvin kernel: 2nd 0xc04a5340 Giant (Giant) @ /usr/src/sys/kern/subr_trap.c:76 Jun 11 22:34:47 calvin kernel: exclusive sleep mutex inp r = 0 (0xd311c2f8) locked @ /usr/src/sys/netinet/tcp_usrreq.c:581 Jun 11 22:34:47 calvin kernel: panic: system call shutdown returning with mutex(s) held ---------------------------------------------- uname -a -------- FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jun 11 21:20:29 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:28:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by hub.freebsd.org (Postfix) with ESMTP id 8B4B437B407 for ; Tue, 11 Jun 2002 10:28:53 -0700 (PDT) Received: from energistic.com (steve@localhost [127.0.0.1]) by energistic.com (8.12.3/8.12.3) with ESMTP id g5BHSpIf069584; Tue, 11 Jun 2002 12:28:51 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.12.3/8.12.3/Submit) id g5BHSmmC068777; Tue, 11 Jun 2002 12:28:48 -0500 (EST) Date: Tue, 11 Jun 2002 12:28:48 -0500 From: Steve Ames To: Sid Carter Cc: Thomas Ugland , freebsd-current@FreeBSD.ORG Subject: Re: Crash after world/kernel upgrade Message-ID: <20020611172848.GA56020@energistic.com> References: <1023807519.376.46.camel@vampire.lothlorien.no> <20020611172125.GA1393@calvin.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020611172125.GA1393@calvin.in.ibm.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 11, 2002 at 10:51:25PM +0530, Sid Carter wrote: > An Tue, Jun 11, 2002 at 04:58:39PM +0200, Thomas Ugland schreib : > > System crashed after updating today. > > During the start of system services, in specific > > at the start of sendmail the system crashes with > > the new kernel. :/ > > uname -a: > > --------- > > FreeBSD vampire.lothlorien.no 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue > > Jun 11 15:41:09 CEST 2002 root@:/usr/src/sys/i386/compile/VAMPIRE > > i386 > > Hi, > > Just rebooted after a crash and am presently doing a cvsup for a > rebuild. I got similar error messages and this is what my > /var/log/messages shows. > You got way more info than I did. With this mornings -CURRENT (around 9AM EDT): Jun 11 09:22:10 : Doing initial network setup: Jun 11 09:22:10 : host.conf Jun 11 09:22:10 : hostname Jun 11 09:22:10 : . Jun 11 09:22:10 : Jun 11 09:22:10 : Jun 11 09:22:10 : Fatal trap 12: page fault while in kernel mode Jun 11 09:22:10 : fault virtual address = 0x28 Jun 11 09:22:10 : fault code = supervisor read, page not present Jun 11 09:22:10 : instruction pointer = 0x8:0xc01851c1 Jun 11 09:22:10 : stack pointer = 0x10:0xd7865bdc Jun 11 09:22:10 : frame pointer = 0x10:0xd7865bec Jun 11 09:22:10 : code segment = base 0x0, limit 0xfffff, type 0x1b Jun 11 09:22:10 : = DPL 0, pres 1, def32 1, gran 1 Jun 11 09:22:10 : processor eflags = interrupt enabled, resume, IOPL = 0 Jun 11 09:22:10 : current process = 11 (swi1: net) Jun 11 09:22:10 : trap number = 12 Jun 11 09:22:10 : panic: page fault Jun 11 09:22:10 : Jun 11 09:22:10 : syncing disks... panic: bdwrite: buffer is not busy Jun 11 09:22:10 : Uptime: 3s Jun 11 09:22:10 : pfs_vncache_unload(): 1 entries remaining Jun 11 09:22:10 : Terminate ACPI Jun 11 09:22:10 : Automatic reboot in 15 seconds - press a key on the console to abort To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:39:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id CBA3237B407 for ; Tue, 11 Jun 2002 10:39:37 -0700 (PDT) Message-ID: <20020611173935.84573.qmail@web13305.mail.yahoo.com> Received: from [206.220.224.4] by web13305.mail.yahoo.com via HTTP; Tue, 11 Jun 2002 10:39:35 PDT Date: Tue, 11 Jun 2002 10:39:35 -0700 (PDT) From: Maksim Yevmenkin Subject: Re: Device cloning To: Poul-Henning Kamp Cc: Harti Brandt , Terry Lambert , current@FreeBSD.ORG In-Reply-To: <52544.1023815855@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >I'm sorry people :) I should have been more specific. Here is > >what i meant. I'm working on Bluetooth stack for FreeBSD. Everything > >is implemented in Netgraph. The real device driver nodes are connected > >to HCI layer. You can talk to any Bluetooth device via HCI layer. It > >does not really matter what kind of device you have, PC-CARD, serial > >or USB dongle. They all MUST talk via HCI. So HCI is not really a > device driver, and, IMO, it is not a pseudo device driver. It sort > >of looks like /dev/tcp :) > > That's called a "protocol family" in BSD and you access it using > sockets. Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a predefined set of control messages and events that user might send to the device. L2CAP which is runs over HCI _IS_ a network protocol and it is implemented in AF_BLUETOOTH protocol family. So application can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then bind(s) and connect(s). > Based on what little I know about "Blåtand" it will be much easier > to work with as a socket than as a /dev/bla entry. > > >Currently there is a single "control" hook for every HCI node. Control > >application connects to the hook and sends HCI commands and receives > >HCI events. It does work, but once the hook is connected, nobody else > >can connect to the same hook. That is a limitation, IMO. It would > >really be nice to have several control applications. For example, > > This is exactly the kind of semantics sockets offer you. > > >2) Raw HCI sockets > > > > The problem here is how to identify device, i.e. what to put > > into sockaddr? Netgraph node name? May be not a good choice, > > because it can be changed at any time. Device BD_ADDR? Does not > > work also, because in order to get BD_ADDR you must send HCI > > command to the device. > > Well, many TCP clients don't care about the name, so they ask > for INADDR_ANY and get whatever the kernel feels like giving them, > you could do the same and have the kernel hand out random numbers. Again, i have to ask specific device on _HCI_ layer. Here is an example. User plugged the card. Now HCI layer MUST query the card and ask - what is the BD_ADDR (MAC) ? - what are the capabilities of the device? - what is the size of the data buffer? - etc. HCI layer _has_ all this commands defined. In fact control application sends several HCI commands to the device to initialze it. After device is connected to the stack - no problem - you now can use BD_ADDR in sockaddr and do whatever you want to do. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 10:48:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11401.mail.yahoo.com (web11401.mail.yahoo.com [216.136.131.231]) by hub.freebsd.org (Postfix) with SMTP id 5234737B419 for ; Tue, 11 Jun 2002 10:47:53 -0700 (PDT) Message-ID: <20020611174753.32352.qmail@web11401.mail.yahoo.com> Received: from [203.198.2.7] by web11401.mail.yahoo.com via HTTP; Tue, 11 Jun 2002 10:47:53 PDT Date: Tue, 11 Jun 2002 10:47:53 -0700 (PDT) From: Shizuka Kudo Subject: Re: libncurses cannot show the first column on the screen To: "Andrey A. Chernov" , peter@freebsd.org Cc: freebsd-current@freebsd.org In-Reply-To: <20020611102432.GA67341@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- "Andrey A. Chernov" wrote: > ------------------------------------------------------------------- > > That was a blunder which was fixed (in the 20020525 > patch): > > 20020523 > + correct and simplify logic for lib_pad.c change > in 20020518 (reported > by Mike Castle). > > 20020518 > + fix lib_pad.c for case of drawing a double-width > character which > falls off the left margin of the pad (patch by > Kriang Lerdsuwanakij > ) > > -------------------------------------------------------------------------- > > > -- > Andrey A. Chernov > http://ache.pp.ru/ > Andrey, Yes, it works. Just compose this yahoo message from "lynx" and the first column is displayed correctly. Thanks. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11: 1:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by hub.freebsd.org (Postfix) with ESMTP id 6749237B40C for ; Tue, 11 Jun 2002 11:01:05 -0700 (PDT) Received: from localhost.axe-inc.co.jp (localhost.axe-inc.co.jp [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id DAA19975 for ; Wed, 12 Jun 2002 03:01:03 +0900 (JST) Message-Id: <200206111801.DAA19975@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost.axe-inc.co.jp [127.0.0.1] didn't use HELO protocol To: current@freebsd.org Subject: Re: no /dev/apmctl ? In-reply-to: Your message of "Tue, 11 Jun 2002 20:09:42 +0300." <20020611200324.I93773-100000@valu.uninet.ee> Date: Wed, 12 Jun 2002 03:01:03 +0900 From: Takanori Watanabe Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020611200324.I93773-100000@valu.uninet.ee>, Taavi Talvik wrote: > >I have included apm in kernel (cvsupped yesterday) config file. However, >it does not create /dev/apmctl > >>l /dev/apm* >crw-rw-r-- 1 root operator 39, 0 Jun 11 19:31 /dev/apm This can be fake apm device node made by ACPI driver. >How is this possible? Driver code /usr/src/sys/i386/apm/apm.c calls >creation of both device nodes around line 1106 without any conditionals > > make_dev(&apm_cdevsw, 0, 0, 5, 0664, "apm"); > make_dev(&apm_cdevsw, 8, 0, 5, 0660, "apmctl"); Are you surely using apm driver? You may have to disable acpi loading by typing 'unset acpi_load' in boot loader. ACPI makes apm node only, not apmctl node. Takanori Watanabe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11: 6:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from encontacto.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id C461737B406 for ; Tue, 11 Jun 2002 11:06:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (uid 0) by encontacto.net with local; Tue, 11 Jun 2002 11:06:44 -0700 Received: from adsl-64-173-182-155.dsl.mtry01.pacbell.net (adsl-64-173-182-155.dsl.mtry01.pacbell.net [64.173.182.155]) as user eculp@encontacto.net@encontacto.net by Mail.EnContacto.Net with HTTP; Tue, 11 Jun 2002 11:06:44 -0700 Message-ID: <1023818804.3d063c345cd26@Mail.EnContacto.Net> Date: Tue, 11 Jun 2002 11:06:44 -0700 From: Edwin Culp To: Steve Ames Cc: Sid Carter , Thomas Ugland , freebsd-current@FreeBSD.ORG Subject: Re: Crash after world/kernel upgrade References: <1023807519.376.46.camel@vampire.lothlorien.no> <20020611172125.GA1393@calvin.in.ibm.com> <20020611172848.GA56020@energistic.com> In-Reply-To: <20020611172848.GA56020@energistic.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Quoting Steve Ames : | On Tue, Jun 11, 2002 at 10:51:25PM +0530, Sid Carter wrote: | > An Tue, Jun 11, 2002 at 04:58:39PM +0200, Thomas Ugland schreib : | > > System crashed after updating today. | > > During the start of system services, in specific | > > at the start of sendmail the system crashes with | > > the new kernel. :/ | > > uname -a: | > > --------- | > > FreeBSD vampire.lothlorien.no 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue | > > Jun 11 15:41:09 CEST 2002 root@:/usr/src/sys/i386/compile/VAMPIRE | > > i386 | > | > Hi, | > | > Just rebooted after a crash and am presently doing a cvsup for a | > rebuild. I got similar error messages and this is what my | > /var/log/messages shows. | > | | You got way more info than I did. With this mornings -CURRENT (around 9AM | EDT): | I get blown away with network setup with a Fatal trap 12, too. I've cvsuped and rebuilt twice with no change. ed | Jun 11 09:22:10 : Doing initial network setup: | Jun 11 09:22:10 : host.conf | Jun 11 09:22:10 : hostname | Jun 11 09:22:10 : . | Jun 11 09:22:10 : | Jun 11 09:22:10 : | Jun 11 09:22:10 : Fatal trap 12: page fault while in kernel mode | Jun 11 09:22:10 : fault virtual address = 0x28 | Jun 11 09:22:10 : fault code = supervisor read, page not present | Jun 11 09:22:10 : instruction pointer = 0x8:0xc01851c1 | Jun 11 09:22:10 : stack pointer = 0x10:0xd7865bdc | Jun 11 09:22:10 : frame pointer = 0x10:0xd7865bec | Jun 11 09:22:10 : code segment = base 0x0, limit 0xfffff, type 0x1b | Jun 11 09:22:10 : = DPL 0, pres 1, def32 1, gran 1 | Jun 11 09:22:10 : processor eflags = interrupt enabled, resume, IOPL = 0 | Jun 11 09:22:10 : current process = 11 (swi1: net) | Jun 11 09:22:10 : trap number = 12 | Jun 11 09:22:10 : panic: page fault | Jun 11 09:22:10 : | Jun 11 09:22:10 : syncing disks... panic: bdwrite: buffer is not busy | Jun 11 09:22:10 : Uptime: 3s | Jun 11 09:22:10 : pfs_vncache_unload(): 1 entries remaining | Jun 11 09:22:10 : Terminate ACPI | Jun 11 09:22:10 : Automatic reboot in 15 seconds - press a key on the console | to abort | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-current" in the body of the message -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:12:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from valu.uninet.ee (valu.uninet.ee [194.204.34.51]) by hub.freebsd.org (Postfix) with ESMTP id E182B37B406 for ; Tue, 11 Jun 2002 11:12:09 -0700 (PDT) Received: by valu.uninet.ee (Postfix, from userid 1002) id A343C36420; Tue, 11 Jun 2002 21:12:05 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by valu.uninet.ee (Postfix) with ESMTP id A82A932619; Tue, 11 Jun 2002 21:12:05 +0300 (EEST) Date: Tue, 11 Jun 2002 21:12:03 +0300 (EEST) From: Taavi Talvik To: Takanori Watanabe Cc: current@freebsd.org Subject: Re: no /dev/apmctl ? In-Reply-To: <200206111801.DAA19975@axe-inc.co.jp> Message-ID: <20020611210939.P95887-100000@valu.uninet.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 12 Jun 2002, Takanori Watanabe wrote: > In message <20020611200324.I93773-100000@valu.uninet.ee>, Taavi Talvik wrote: Yes, acpi the case. Acpi tries to emulate apm, but seams that this emulation is incomplete. At least it does not provide support for apmd. Actually, i should have looked at acpi sources before asking from list. Again fingers are faster than brain:( best regards, taavi > >I have included apm in kernel (cvsupped yesterday) config file. However, > >it does not create /dev/apmctl > > > >>l /dev/apm* > >crw-rw-r-- 1 root operator 39, 0 Jun 11 19:31 /dev/apm > > This can be fake apm device node made by ACPI driver. > > >How is this possible? Driver code /usr/src/sys/i386/apm/apm.c calls > >creation of both device nodes around line 1106 without any conditionals > > > > make_dev(&apm_cdevsw, 0, 0, 5, 0664, "apm"); > > make_dev(&apm_cdevsw, 8, 0, 5, 0660, "apmctl"); > > Are you surely using apm driver? You may have to disable acpi loading > by typing 'unset acpi_load' in boot loader. > ACPI makes apm node only, not apmctl node. > > Takanori Watanabe > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ----------------------------------------------------------- Taavi Talvik | Internet: taavi@uninet.ee AS Uninet | phone: +372 6800013 Parnu mnt. 105 | fax: +372 6800001 Tallinn 11312, Estonia | gsm: +372 56569996 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:18: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from CPE0030ab0ef2bb.cpe.net.cable.rogers.com (CPE0030ab0ef2bb.cpe.net.cable.rogers.com [24.101.108.107]) by hub.freebsd.org (Postfix) with ESMTP id AB1B137B40A for ; Tue, 11 Jun 2002 11:17:58 -0700 (PDT) Received: by CPE0030ab0ef2bb.cpe.net.cable.rogers.com (Postfix, from userid 1001) id A0D64CE; Tue, 11 Jun 2002 14:19:46 -0400 (EDT) Date: Tue, 11 Jun 2002 14:19:46 -0400 From: Munish Chopra To: freebsd-current@FreeBSD.ORG Subject: Re: Kernel Panic and Automagic Reboots Message-ID: <20020611141946.A358@CPE0030ab0ef2bb.cpe.net.cable.rogers.com> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <20020611134308.GA346@calvin.in.ibm.com> <1023812024.3d0621b85f97b@Mail.EnContacto.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1023812024.3d0621b85f97b@Mail.EnContacto.Net>; from eculp@encontacto.net on Tue, Jun 11, 2002 at 09:13:44AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 11, 2002 at 09:13:44AM -0700, Edwin Culp wrote: > > My laptop is rebooting with todays current/kernel in ifconfig. I just > got it up with an old kernel and am checking now. It will run with the > new kernel if I don't try to configure the network. I may have something > wrong though. > Same thing happens to me, reboot during the startup process when ifoncfig tries to get iself an IP from the dhcp server. I didn't have the time to write down the entire thing, but I'll try to get to it tonight. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:21:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from CPE0030ab0ef2bb.cpe.net.cable.rogers.com (CPE0030ab0ef2bb.cpe.net.cable.rogers.com [24.101.108.107]) by hub.freebsd.org (Postfix) with ESMTP id 4186637B404 for ; Tue, 11 Jun 2002 11:21:16 -0700 (PDT) Received: by CPE0030ab0ef2bb.cpe.net.cable.rogers.com (Postfix, from userid 1001) id 6BD6FCE; Tue, 11 Jun 2002 14:23:04 -0400 (EDT) Date: Tue, 11 Jun 2002 14:23:04 -0400 From: Munish Chopra To: freebsd-current@FreeBSD.ORG Subject: Re: Crash after world/kernel upgrade Message-ID: <20020611142304.B358@CPE0030ab0ef2bb.cpe.net.cable.rogers.com> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <1023807519.376.46.camel@vampire.lothlorien.no> <20020611172125.GA1393@calvin.in.ibm.com> <20020611172848.GA56020@energistic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020611172848.GA56020@energistic.com>; from steve@energistic.com on Tue, Jun 11, 2002 at 12:28:48PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 11, 2002 at 12:28:48PM -0500, Steve Ames wrote: > > You got way more info than I did. With this mornings -CURRENT (around 9AM EDT): > > Jun 11 09:22:10 : Doing initial network setup: > Jun 11 09:22:10 : host.conf > Jun 11 09:22:10 : hostname > Jun 11 09:22:10 : . > Jun 11 09:22:10 : > Jun 11 09:22:10 : > Jun 11 09:22:10 : Fatal trap 12: page fault while in kernel mode > Jun 11 09:22:10 : fault virtual address = 0x28 > Jun 11 09:22:10 : fault code = supervisor read, page not present > Jun 11 09:22:10 : instruction pointer = 0x8:0xc01851c1 > Jun 11 09:22:10 : stack pointer = 0x10:0xd7865bdc > Jun 11 09:22:10 : frame pointer = 0x10:0xd7865bec > Jun 11 09:22:10 : code segment = base 0x0, limit 0xfffff, type 0x1b > Jun 11 09:22:10 : = DPL 0, pres 1, def32 1, gran 1 > Jun 11 09:22:10 : processor eflags = interrupt enabled, resume, IOPL = 0 > Jun 11 09:22:10 : current process = 11 (swi1: net) > Jun 11 09:22:10 : trap number = 12 > Jun 11 09:22:10 : panic: page fault > Jun 11 09:22:10 : > Jun 11 09:22:10 : syncing disks... panic: bdwrite: buffer is not busy > Jun 11 09:22:10 : Uptime: 3s > Jun 11 09:22:10 : pfs_vncache_unload(): 1 entries remaining > Jun 11 09:22:10 : Terminate ACPI > Jun 11 09:22:10 : Automatic reboot in 15 seconds - press a key on the console to abort > My bad, this is exactly what I was referring to in the other thread. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:37:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 2C7F337B403 for ; Tue, 11 Jun 2002 11:36:45 -0700 (PDT) Received: from pool0380.cvx21-bradley.dialup.earthlink.net ([209.179.193.125] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HqVO-00035h-00; Tue, 11 Jun 2002 11:36:34 -0700 Message-ID: <3D06430E.D58FF87A@mindspring.com> Date: Tue, 11 Jun 2002 11:35:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harti Brandt Cc: Maksim Yevmenkin , current@FreeBSD.ORG Subject: Re: Device cloning References: <20020611114039.L35453-100000@beagle.fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Harti Brandt wrote: > TL>For a sound device, it would be nice if multiple instances to the > TL>devices were mux'ed. I've had cases where the program I was using > TL>was using a smaller number that the total available channels, and > TL>it would have been nice if the next open instance got the remaining > TL>channels, rather than a "device in use" error. You'd have to manage > TL>this by giving all remaining available channels to an opener, and > TL>then having them ioctl() the unused ones back (e.g. "allocate N" > TL>when there are M available, means "give M-N back"). > > That has also nothing to do with cloning. Look at the current pcm driver - > it just has a device entry per channel. A device entry per channel is a stupid idea. It means that I can not write software to "open the sound device", I have gto write software to "open the *right* sound device out of N sound devices, so that I get the right channel". It's a lot easier to just open the thing, than it is to teach every single piece of software that uses sound to do the "right" thing, and know how to do that. If nothing else, it wil mean an incredible duplication of code in all sound using user space programs, and programs written by naieve programmers (yeah, I know -- like rattus giganticus, they don't exist, right) so that "if you want to run A and B, you have to run B first, because B doesn't know aboout anything but the first sound device". This is just a recipe for disaster. > Where cloning could come into the > play is when more than one process tries to open a 1-channel device and > you want to mix the audio. As I said this would be a task of a layer above > the sound driver (just as X 'multiplexes' N processes onto one display > device). Unfortunately there is no good sound API up to now. If only you could differentiate open instances of the same device from each other, so that mixing would just be implied, and "just work"... if only the sound device were a *cloning device*. 8-). > TL>For a DVD, it would be nice if you could select the instance of the > TL>device you were going to get for seperation of the ISO9660 and UDF > TL>FS's (e.g. which record boundary the device actually used). The way > TL>that OS X supports this is by doing DVD mounts on both the character > TL>and block device seperately. For FreeBSD, UDF support, which has to > TL>have access to the ISO9660 FS for the purposes of index access, is > TL>much more messy. > > No cloning here. ??? You are suggesting two devices? That's quite interesting. I suppose it's possible, if you absolutely insist on it. I guess pushing the complexity from a relatively trivial device driver operation into a much more complex file system operation would work. IMO, though, it would not really be a good idea. It's like laying carpet, and leaving a bubble in it. You can chase it all around your living room, but the bubble is going to be *somewhere*. > TL>You could also make an argument for multiple input devices and the > TL>management of which one you get when you open /dev/mouse. > > Again you just get it the wrong way around. You need per process/open > context if you try to put the multiplexing of ONE mouse between MULTIPLE > processes into the hardware mouse driver. Again this would be plain wrong. I'm not *talking* about multiple processes. For example, I have three mice on the machine from which I am currently typing: 1) A 3 button USB two axis optical mouse 2) A 2 buttom "glidepoint" two axis touchpad 3) A 1 button one axis "jogdial" All of these are devices to mux into a single program, the X server, and from there, into the Window Manager, so that I can make them behave as they do under Windows (e.g. my "jogdial" input needs to be routed to a popup utility that can launch programs). While my #1 and #2 need to be treated as synonyms (including treating the third button on the optical mouse the same as a chord of button 1&2 on the touchpad). I'd rather not have to go outside the normal operation of my X server input manager, in order to be able to achieve this. I'd rather just set it up so that the jogdial were reported as button events. > TL>Finally, there's a long history on SCO Xenix and UNIX, starting with > TL>"Computone" multiport serial cards, of multiplexing access to the > TL>device seperately for printing vs. terminal I/O. Yes, Digiboard and > TL>other vendors handle this by having two device nodes for a single > TL>pgysical device, and maintaining a state machine for the escape > TL>sequences. But this is really a matter of preference, not necessity. > TL>Writing to one instance, you talk to the terminal, and writing to the > TL>other, you talk to the "aux" port. > > Again this is not about 'cloning a physical' device. You're high. What happens when I have two programs, and one of them doesn't know to make it's write of escape sequences atomic, because it's not expecting a second program to be sending escape sequences to select and deselect output to the AUX port on the terminal?!? Someone, somewhere has to keep the interference management finite state automaton, so that the single real serial device driver underneath is able to prevent data corruption to the printer or the screen for simultaneously operating programs. Yeah, FreeBSD doesn't do this today, but then it's not a commercial grade OS that has to be able to deal with, for example, running the terminals and the little receipt printer at a video store. > TL>I don't think the original poster wanted cloning for support on > TL>physical devices for which there was a 1:1 relationship anyway > TL>(8^)), but there *are* cases where it could be useful. > TL> > TL>Actually, I think the original poster never really disclosed *what* > TL>they wanted to use the feature for... > > That's true... > > From reading the original post I was under the impression that this is > again a 'hey, I write a device driver and I need to track the number of > opens and to tack a context onto each open' that periodically comes up. > If I'm wrong, well, sorry then... No, I think this is what they wanted. I think that you can't say that they aren't building a clone of the pty code on Linux or SVR4, so that commercial programs run under the ABI will run properly under FreeBSD. So, no matter what, whether you think "it's the FreeBSD way" or not, it needs to be possible to support it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:42:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id BFB2D37B407; Tue, 11 Jun 2002 11:42:22 -0700 (PDT) Received: from pool0380.cvx21-bradley.dialup.earthlink.net ([209.179.193.125] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hqay-0004Pt-00; Tue, 11 Jun 2002 11:42:21 -0700 Message-ID: <3D064468.D1B1F2C6@mindspring.com> Date: Tue, 11 Jun 2002 11:41:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juli Mallett Cc: Thomas Quinot , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> <20020611143957.A17613@melusine.cuivre.fr.eu.org> <20020611063348.A97611@FreeBSD.ORG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett wrote: > > |-omniNames---omniNames---3*[omniNames] > > That seems frighteningly useless to me though. Seems a bit like a number of > utilities I've seen from the Linux camp which take useful functionality and > mask it behind something that looks good. What exactly can you get from > that kind of output? > > > with the following being printed if you ask for pids ('-p'): > > > > |-omniNames(313)---omniNames(335)-+-omniNames(336) > > | |-omniNames(338) > > | `-omniNames(345) > > That output's pretty useful, on the other hand, but it seems overly difficult > to do that sort of formatting without kludging everything with a lot of > conditionals and rather than simple recursion, something more complex. Theres a program in -ports. If you insist on doing it, though, look at the output of "w -d" (yeah, I have a vested interest in it, but it's still pretty cool). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:44:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 5CE3037B403; Tue, 11 Jun 2002 11:44:21 -0700 (PDT) Received: from pool0380.cvx21-bradley.dialup.earthlink.net ([209.179.193.125] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HqcR-0006oD-00; Tue, 11 Jun 2002 11:43:52 -0700 Message-ID: <3D0644C4.10A112E5@mindspring.com> Date: Tue, 11 Jun 2002 11:43:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juli Mallett Cc: Andrew Kenneth Milton , Sheldon Hearn , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... References: <20020611051517.A87966@FreeBSD.ORG> <47290.1023799280@axl.seasidesoftware.co.za> <20020611063707.C97611@FreeBSD.ORG> <20020611234055.N91173@zeus.theinternet.com.au> <20020611064612.A703@FreeBSD.ORG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett wrote: > > Piping commands through other commands seems icky? > > Relying on reasonable output from ps(1) seems icky when you can extract the > data yourself and not have to worry about formatting getting in the way of > processing data properly. This is just wrong on so many levels... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:52:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 1637937B407 for ; Tue, 11 Jun 2002 11:52:19 -0700 (PDT) Received: from pool0380.cvx21-bradley.dialup.earthlink.net ([209.179.193.125] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HqkZ-00053j-00; Tue, 11 Jun 2002 11:52:16 -0700 Message-ID: <3D0646BB.E427C4DB@mindspring.com> Date: Tue, 11 Jun 2002 11:51:39 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maksim Yevmenkin Cc: Harti Brandt , current@FreeBSD.ORG Subject: Re: Device cloning References: <20020611171448.77703.qmail@web13305.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maksim Yevmenkin wrote: > I'm sorry people :) I should have been more specific. Here is > what i meant. I'm working on Bluetooth stack for FreeBSD. Everything > is implemented in Netgraph. The real device driver nodes are connected > to HCI layer. You can talk to any Bluetooth device via HCI layer. It > does not really matter what kind of device you have, PC-CARD, serial > or USB dongle. They all MUST talk via HCI. So HCI is not really a > device driver, and, IMO, it is not a pseudo device driver. It sort > of looks like /dev/tcp :) Ah. You have a device which is an addressable bus. Yes, if cloning worked, it would be the best way to implement it. The typical BSD way of dealing with this would probably be to create a socket interface. The problem with a socket interface is that you woun't be able to run standard protocols over top of your HCI, unless you (re)implement them as netgraph nodes (e.g. like a "/dev/tcp" with a streams stack pushed on it). I think that your current Netgraph approach is probably the best one available to you, if you want to avoid additional plumbing work. Good luck on your work, it sounds interesting! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 11:58: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC937B40F for ; Tue, 11 Jun 2002 11:58:03 -0700 (PDT) Received: from pool0380.cvx21-bradley.dialup.earthlink.net ([209.179.193.125] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hqq4-0006Kk-00; Tue, 11 Jun 2002 11:57:57 -0700 Message-ID: <3D064811.D512445F@mindspring.com> Date: Tue, 11 Jun 2002 11:57:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maksim Yevmenkin Cc: Poul-Henning Kamp , Harti Brandt , current@FreeBSD.ORG Subject: Re: Device cloning References: <20020611173935.84573.qmail@web13305.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maksim Yevmenkin wrote: > Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a > predefined set of control messages and events that user might send > to the device. L2CAP which is runs over HCI _IS_ a network protocol > and it is implemented in AF_BLUETOOTH protocol family. So application > can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then > bind(s) and connect(s). You might want to look at how you issue raw SCSI commands on devices via CAM. You can start with "man cam". Your situation is exactly analogous (IMO) to a device interface to a raw bus. You will notice that most of it is section 3 (e.g. implemented in a set of user space library routines on top of the SCSI bus commands). If you look at how the CAM toys talk to the SCSI bus itself, though, you will see an interface for jamming known format SCSI commands down onto a SCSI bus, which is probably the level at which you want your interface. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 14:20:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id C803A37B40C; Tue, 11 Jun 2002 14:20:11 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020611212011.ZFKJ1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 11 Jun 2002 21:20:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA85705; Tue, 11 Jun 2002 14:19:59 -0700 (PDT) Date: Tue, 11 Jun 2002 14:19:57 -0700 (PDT) From: Julian Elischer To: Dag-Erling Smorgrav Cc: Juli Mallett , current@FreeBSD.ORG Subject: Re: Looking for comments on a new utility... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG we need to extend this to handle a full thread table per process.. anyone have any ideas on how to do this? Anyone rewriting ps should think about this twist... On 11 Jun 2002, Dag-Erling Smorgrav wrote: > Juli Mallett writes: > > I believe I can get pid, ppid, username (or at least uid [yay > > user_from_uid]), etc., from sysctl(3) at least as easily as with > > kvm(3). > > You can get the full process table from sysctl (kern.proc.all) > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 14:23: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from krusty.oanet.com (krusty.oanet.com [204.209.13.17]) by hub.freebsd.org (Postfix) with ESMTP id 3BE7F37B404 for ; Tue, 11 Jun 2002 14:22:55 -0700 (PDT) Received: from mail.oanet.com (mars.oanet.com [204.209.13.52]) by krusty.oanet.com (8.11.6/8.11.6) with ESMTP id g5BLMTu88951 for ; Tue, 11 Jun 2002 15:22:30 -0600 (MDT) (envelope-from pputh@oanet.com) Received: from PaulP.oanet.com (firewall.oanet.com [204.209.13.50]) by mail.oanet.com (8.11.5/8.11.5) with ESMTP id g5BLMs720633 for ; Tue, 11 Jun 2002 15:22:54 -0600 Message-Id: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> X-Sender: pputh@pop.oanet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Jun 2002 15:27:08 -0600 To: freebsd-current@freebsd.org From: "Paul S. Puth" Subject: looking for warn quota tools Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I am looking for a tool that will email to the user if his/her account (more specifically email box) is approaching quota limit. I've searched everywhere for such a tool but to no avail. On Linux, there is a tool called "warnquota" that fits my need but I am running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from searching on google, I've found a tool called "psntools" that has the warnquota feature but it doesn't work on a filesystem that has a mailspool. Can someone help me? Thanks, Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 14:31:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EB37F37B40D for ; Tue, 11 Jun 2002 14:31:50 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g5BLVPb5015554; Tue, 11 Jun 2002 17:31:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 11 Jun 2002 17:31:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Paul S. Puth" Cc: freebsd-current@freebsd.org Subject: Re: looking for warn quota tools In-Reply-To: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I always just used the following script in the /etc/csh.login: #if ("`quota | grep '\*'`" != "") then # echo Warning: Quota Exceeded: # quota #endif Given that the output of the quota command is fairly parseable, a little bit of scripting or perl should do the trick. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories On Tue, 11 Jun 2002, Paul S. Puth wrote: > Hi, > > I am looking for a tool that will email to the user if his/her account > (more specifically email box) is approaching quota limit. I've searched > everywhere for such a tool but to no avail. > > On Linux, there is a tool called "warnquota" that fits my need but I am > running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from > searching on google, I've found a tool called "psntools" that has the > warnquota feature but it doesn't work on a filesystem that has a mailspool. > > Can someone help me? > > Thanks, > > Paul > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 14:35:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from scan.ji-net.com (scan.ji-net.com [203.130.156.4]) by hub.freebsd.org (Postfix) with ESMTP id 9158E37B400 for ; Tue, 11 Jun 2002 14:35:24 -0700 (PDT) Received: from net1.ji-net.com ([203.156.15.120]) by scan.ji-net.com (8.11.2/8.11.2) with SMTP id g5BLZLQ06125 for ; Wed, 12 Jun 2002 04:35:22 +0700 Message-Id: <200206112135.g5BLZLQ06125@scan.ji-net.com> Date: Wed, 12 Jun 2002 04:37:26 To: freebsd-current@freebsd.org From: goodhealthgoodjob@yahoo.com (foodforhealth) Subject: Çѹ¹Õé¤Ø³´ÙáÅÊØ¢ÀÒ¾áÅéÇËÃ×ÍÂѧ X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG á¹Ð¹Óâ»Ãá¡ÃÁ¤Çº¤ØÁ¹éÓ˹ѡ à¾ÔèÁ¹éÓ˹ѡ ÃÑ¡ÉÒÊØ¢ÀÒ¾ ¤Ø³ËÃ×ͤ¹·Õè¤Ø³ÃÑ¡¡ÓÅѧÁͧËÒÇÔ¸Õ´ÙáÅÊØ¢ÀÒ¾·Õèà»ç¹¸ÃÃÁªÒµÔÍÂÙèãªèäËÁ? ËÒ¡¤Ø³àº×èÍ˹èÒ¡Ѻ¤ÇÒÁ¾ÂÒÂÒÁ·ÕèäÁè»ÃÐʺ¤ÇÒÁÊÓàÃ稤ÃÑé§áÅéǤÃÑé§àÅèÒ ã¹¡ÒôÙáÅÊØ¢ÀÒ¾à¾×èÍÃÙ»ÃèÒ§·Õè´Õ àÃÒÁÕâ»Ãá¡ÃÁâÀª¹Ò¡ÒÃà¾×èÍÊØ¢ÀÒ¾ ·ÕèªèǤسä´é ÊÓËÃѺ¼Ùé·ÕèÁջѭËÒ ¹éÓ˹ѡà¡Ô¹ËÃ×ÍÍéǹ, ¼ÍÁà¡Ô¹ä», ÁջѭËÒÊØ¢ÀÒ¾ (¼ÍÁáËé§áç¹éÍÂ, ¾Ø§ËéÍÂÍ×´ÍÒ´, ¢Ò´¤ÇÒÁÁÑè¹ã¨, âäÀѶÒÁËÒ,ãºË¹éÒà»ç¹ÊÔÇ, ¼ÔǾÃóàËÕèÂÇÂè¹, ¤¹àÅ蹡ÕÌÒ, ¤Ø³»éÒÇÑ·ͧ, ¤Ø³¹éÍ§æ ·ÕèÍÂÒ¡ÊÇÂ)à»ç¹¼ÅÔµÀѳ±ì¨Ò¡¸ÃÃÁªÒµÔ 100 % äÁèãªèÂÒ äÁèµéͧʹÍÒËÒà äÁèÁռŢéÒ§à¤Õ§ äÁèµéͧÍÍ¡¡ÓÅѧ¡Ò ¿Ñ§´ÙäÁè¹èÒàª×èÍáµè¡çµéͧàª×èÍà¾ÃÒмèÒ¹ ÍÂ.·Ø¡»ÃÐà·È·Õèà¢éÒ仢ÒÂâ´Â੾ÒлÃÐà·Èä·ÂáÅÐÍàÁÃÔ¡Ò ãËéÊÒÃÍÒËÒäú¶éǹ »ÃѺÊÁ´ØŢͧÃèÒ§¡ÒÂÅ´ä¢ÁѹÊèǹà¡Ô¹ ÃѺÃͧ¼ÅÀÒÂã¹30Çѹ´éÇÂÃкº¤×¹à§Ô¹100%(á¾·Âì¼Ùé¤Ô´¤é¹ÍÒËÒÃÊٵùÕé¤×ͤ¹·Õè¤Ô´¤é¹ÍÒËÒÃãËé¹Ñ¡ºÔ¹ÍÇ¡ÒÈͧ¤ì¡ÒùҫèÒ) ʹ㨠¢Í¤Óá¹Ð¹Óà¾ÔèÁàµÔÁä´é·Õè ¤Ø³ÊÔÃÔ 01-8901701¾º¤ÓµÍºÊØ´·éÒ¢ͧ¤Ø³ä´é·Õè¹Õè http://www.smartslender.com/foodforhealth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 14:41:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from krusty.oanet.com (krusty.oanet.com [204.209.13.17]) by hub.freebsd.org (Postfix) with ESMTP id 0366737B42F for ; Tue, 11 Jun 2002 14:40:56 -0700 (PDT) Received: from mail.oanet.com (mars.oanet.com [204.209.13.52]) by krusty.oanet.com (8.11.6/8.11.6) with ESMTP id g5BLeUu90050 for ; Tue, 11 Jun 2002 15:40:30 -0600 (MDT) (envelope-from pputh@oanet.com) Received: from PaulP.oanet.com (firewall.oanet.com [204.209.13.50]) by mail.oanet.com (8.11.5/8.11.5) with ESMTP id g5BLes726789 for ; Tue, 11 Jun 2002 15:40:54 -0600 Message-Id: <5.1.0.14.0.20020611154229.00a8e1e8@pop.oanet.com> X-Sender: pputh@pop.oanet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Jun 2002 15:45:08 -0600 To: freebsd-current@FreeBSD.ORG From: "Paul S. Puth" Subject: Re: looking for warn quota tools In-Reply-To: References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank for the quick response, Robert. I fail to mention that this machine is strictly a mail server with over 10K+ accounts. Users cannot log into their shell account and they check email via POP/IMAP only. At 05:31 PM 6/11/2002 -0400, Robert Watson wrote: >I always just used the following script in the /etc/csh.login: > >#if ("`quota | grep '\*'`" != "") then ># echo Warning: Quota Exceeded: ># quota >#endif > >Given that the output of the quota command is fairly parseable, a little >bit of scripting or perl should do the trick. > >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Network Associates Laboratories > >On Tue, 11 Jun 2002, Paul S. Puth wrote: > > > Hi, > > > > I am looking for a tool that will email to the user if his/her account > > (more specifically email box) is approaching quota limit. I've searched > > everywhere for such a tool but to no avail. > > > > On Linux, there is a tool called "warnquota" that fits my need but I am > > running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from > > searching on google, I've found a tool called "psntools" that has the > > warnquota feature but it doesn't work on a filesystem that has a mailspool. > > > > Can someone help me? > > > > Thanks, > > > > Paul > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 15:21:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 1794A37B407 for ; Tue, 11 Jun 2002 15:21:36 -0700 (PDT) Received: from pool0186.cvx40-bradley.dialup.earthlink.net ([216.244.42.186] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Hu13-0005AB-00; Tue, 11 Jun 2002 15:21:30 -0700 Message-ID: <3D0677C2.ED706536@mindspring.com> Date: Tue, 11 Jun 2002 15:20:50 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul S. Puth" Cc: freebsd-current@freebsd.org Subject: Re: looking for warn quota tools References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Paul S. Puth" wrote: > I am looking for a tool that will email to the user if his/her account > (more specifically email box) is approaching quota limit. I've searched > everywhere for such a tool but to no avail. > > On Linux, there is a tool called "warnquota" that fits my need but I am > running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from > searching on google, I've found a tool called "psntools" that has the > warnquota feature but it doesn't work on a filesystem that has a mailspool. > > Can someone help me? The "warnquota" program is a program that's based on you using Cyrus IMAP for you message store. We are not talking about disk quotas here. In fact, we can't, since disk quotas appear as write errors for the MDA (the "local" mailer), not accept errors for the MTA (the SMTP server). FWIW: It's kind of a dumb idea to send email warning about a condition which is caused by having too much email. We did this on the InterJet, and it was actually a pretty dumb thing to do; you end up with a recursive problem that's unsolvable -- you basically have to let certain cenders be "priviledged" for the delivery of the messages, which means hacking both the MDA ("deliver") and "warnquota". Another issue is that quota enforcement only occurs *after* you exceed the quota, not *when* you exceed the quota. This is because email messages must be treated as atomic units; so if you are within 3k of a 100k quota, and you get an 80k message, you can't not accept it. Further, quota enforcement involves a quota *on the mailbox*; an interesting side effect of this is that the following happens: 1) You receive a message to the local queue which, if it were delivered, would push the user over quota (or the user is already over quota) 2) You attempt to deliver it, and delivery fails because of the quota 3) You leave the message in the queue, to retry later, in hopes that the user has reduced the size of their mailbox So not matter how you look at it, if you deliver it don't deliver it, it's taking up your disk space, whether you have quotas on users or have no quotas on users. The way "HotMail" handles this condition is to drop email that it has accepted to delivery, if it can't be delivered to the user because of them being over quota. But since it has already accepted the email for delivery (by sending "250 OK" to the remote SMTP client or MTA, it has pledged to deliver the message, or give failure notification, so the message contents are not lost), the email is basically lost with no recourse. The inability to guarantee delivery is the basis for the liability disclaimer, and the terms of service not allowing business use of the service (i.e. to prevent legal liability problems). You really don't want to bet your business on this level of (dis)service. Basically, the only way to really handle this is to refuse delivery at the SMTP level. The problem with doing this is that you would have to do it on a per maildrop (locally hosted email address) basis. This, in turn, requires that your MTA have promiscuous knowledge of the quota information in a per maildrop basis. I.e. you must tightly, rather than loosely, couple the MTA and the maildrop storage management, not simply hand off the delivery to a "mailer" after it's been accepted. This means that you introduce a delivery latency into the "250 OK" response. In addition, message bodies are sent via the SMTP protocol *after* the addresses are accepted/rejected. This basically means that if the peer machine does not use the "SIZE extension" to indicate on the "MAIL FROM:" SMTP command the size of the message that will be sent -- OR it lies about it/gets it wrong (the SMTP SIZE extenson normally does *NOT* give an absolutely accurate representation because of transfer encoding and wire encoding differences, which tend to change the size), then you are still screwed, by having said that you will accept a message that you can't deliver. The only upside in this is that you can ignore the size, and only reject addresses that are actually *over* quota -- rather than addresses that would be pushed over quota by the current message. That leaves you with the requirement that you allow the mailbox to go over quota by one message, but that you claim 101% is the same as 150%. Otherwise, you are stuck with the message in the local queue, but locally undeliverable for an indefinite period of time. The obvious problem with this is that, no matter what your per account quota is, you can't prevent the delivery of any message which is less than the maximum size that the server is willing to accept from a peer via SMTP. So setting a maximum transfer size of 10M, with accounts with 1M quotas, means that each account can in fact end up with 10M - 1 byte over quota. Now... if you are going to go to all this trouble... then the "over quota" email should actually be metadata about the account; and then when someone goes to download, there are two bits: "over quota" and "over quota message sent". The message gets "sent" by generating it on the message download: in other words, it's not real. This keeps it from taking up quota space, itself. Personally, I think that the idea of quotas is pretty lame, relative to deliverability, unless you rewrite your SMTP server to tightly couple to the per maildrop message store (e.g. so you can say "421 Over quota" when they give you a "RCPT TO:"). Since one of the fundamental design issues in SMTP servers is reduced latency, don't expect to be able to do this easily with sendmail, qmail, postfix, or most other mail servers that you don't buy from a commercial mail server vendor without quota enforcement already on their feature list. And if you do buy a mail server to get the feature, be sure that it handles the quota enforcement at the "RCPT TO:", rather than after the "DATA", or you aren't actually saving any disk space by having the ability to set quotas. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 15:23: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id 5126437B403; Tue, 11 Jun 2002 15:22:38 -0700 (PDT) Received: from kokeb.ambesa.net ([66.122.213.222]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXK00MI8BHMDE@mta7.pltn13.pbi.net>; Tue, 11 Jun 2002 15:22:38 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5BMRtuj000799; Tue, 11 Jun 2002 15:27:55 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5BMRlBh000798; Tue, 11 Jun 2002 15:27:47 -0700 (PDT envelope-from mikem) Date: Tue, 11 Jun 2002 15:27:47 -0700 From: Mike Makonnen Subject: Re: Fixing "could sleeep..." was (Re: ../../../vm/uma_core.c:132 In-reply-to: To: John Baldwin Cc: freebsd-current@FreeBSD.ORG, jrh@lab.it.uc3m.es, hiten@uk.FreeBSD.org Message-id: <20020611152747.091c2377.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200206111001.g5BA13L3002278@kokeb.ambesa.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002 13:07:03 -0400 (EDT) John Baldwin wrote: > > Yes... if you don't go through the setuid/gid family of functions. Currently, > > the only place uifind() is called, besides change_[re]uid() is in proc0_init. My > > assumption was that you need to change the uidinfo only when changing > > ucreds (either an exec or specific seteuid,etc), and that when you change ucreds > > you always crget() a new one and not reuse the old one. So, in this case there > > could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo > > and one for cr_ruidinfo. > > Oh, duh, you are right, it should work then. You can implement whichever you please > then. I can see pros and cons cleanliness-wise of both. :) > Disregard my earlier patch. It has a bug. Is it possible to sleep when doing a FREE()? I had assumed not, but it seems I may be mistaken. On which way to go: I like your idea better, because it is less work and less bloat. Sometimes I have to keep reminding myself: "Choose the simplest design that works." Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 15:56:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from scan.ji-net.com (scan.ji-net.com [203.130.156.4]) by hub.freebsd.org (Postfix) with ESMTP id BEDC337B403 for ; Tue, 11 Jun 2002 15:56:11 -0700 (PDT) Received: from net1.ji-net.com ([203.156.15.120]) by scan.ji-net.com (8.11.2/8.11.2) with SMTP id g5BMu9Q23928 for ; Wed, 12 Jun 2002 05:56:09 +0700 Message-Id: <200206112256.g5BMu9Q23928@scan.ji-net.com> Date: Wed, 12 Jun 2002 05:58:12 To: current@FreeBSD.org From: goodhealthgoodjob@yahoo.com (foodforhealth) Subject: Çѹ¹Õé¤Ø³´ÙáÅÊØ¢ÀÒ¾áÅéÇËÃ×ÍÂѧ X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG á¹Ð¹Óâ»Ãá¡ÃÁ¤Çº¤ØÁ¹éÓ˹ѡ à¾ÔèÁ¹éÓ˹ѡ ÃÑ¡ÉÒÊØ¢ÀÒ¾ ¤Ø³ËÃ×ͤ¹·Õè¤Ø³ÃÑ¡¡ÓÅѧÁͧËÒÇÔ¸Õ´ÙáÅÊØ¢ÀÒ¾·Õèà»ç¹¸ÃÃÁªÒµÔÍÂÙèãªèäËÁ? ËÒ¡¤Ø³àº×èÍ˹èÒ¡Ѻ¤ÇÒÁ¾ÂÒÂÒÁ·ÕèäÁè»ÃÐʺ¤ÇÒÁÊÓàÃ稤ÃÑé§áÅéǤÃÑé§àÅèÒ ã¹¡ÒôÙáÅÊØ¢ÀÒ¾à¾×èÍÃÙ»ÃèÒ§·Õè´Õ àÃÒÁÕâ»Ãá¡ÃÁâÀª¹Ò¡ÒÃà¾×èÍÊØ¢ÀÒ¾ ·ÕèªèǤسä´é ÊÓËÃѺ¼Ùé·ÕèÁջѭËÒ ¹éÓ˹ѡà¡Ô¹ËÃ×ÍÍéǹ, ¼ÍÁà¡Ô¹ä», ÁջѭËÒÊØ¢ÀÒ¾ (¼ÍÁáËé§áç¹éÍÂ, ¾Ø§ËéÍÂÍ×´ÍÒ´, ¢Ò´¤ÇÒÁÁÑè¹ã¨, âäÀѶÒÁËÒ,ãºË¹éÒà»ç¹ÊÔÇ, ¼ÔǾÃóàËÕèÂÇÂè¹, ¤¹àÅ蹡ÕÌÒ, ¤Ø³»éÒÇÑ·ͧ, ¤Ø³¹éÍ§æ ·ÕèÍÂÒ¡ÊÇÂ)à»ç¹¼ÅÔµÀѳ±ì¨Ò¡¸ÃÃÁªÒµÔ 100 % äÁèãªèÂÒ äÁèµéͧʹÍÒËÒà äÁèÁռŢéÒ§à¤Õ§ äÁèµéͧÍÍ¡¡ÓÅѧ¡Ò ¿Ñ§´ÙäÁè¹èÒàª×èÍáµè¡çµéͧàª×èÍà¾ÃÒмèÒ¹ ÍÂ.·Ø¡»ÃÐà·È·Õèà¢éÒ仢ÒÂâ´Â੾ÒлÃÐà·Èä·ÂáÅÐÍàÁÃÔ¡Ò ãËéÊÒÃÍÒËÒäú¶éǹ »ÃѺÊÁ´ØŢͧÃèÒ§¡ÒÂÅ´ä¢ÁѹÊèǹà¡Ô¹ ÃѺÃͧ¼ÅÀÒÂã¹30Çѹ´éÇÂÃкº¤×¹à§Ô¹100%(á¾·Âì¼Ùé¤Ô´¤é¹ÍÒËÒÃÊٵùÕé¤×ͤ¹·Õè¤Ô´¤é¹ÍÒËÒÃãËé¹Ñ¡ºÔ¹ÍÇ¡ÒÈͧ¤ì¡ÒùҫèÒ) ʹ㨠¢Í¤Óá¹Ð¹Óà¾ÔèÁàµÔÁä´é·Õè ¤Ø³ÊÔÃÔ 01-8901701¾º¤ÓµÍºÊØ´·éÒ¢ͧ¤Ø³ä´é·Õè¹Õè http://www.smartslender.com/foodforhealth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 16: 9:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp.noos.fr (claudel.noos.net [212.198.2.83]) by hub.freebsd.org (Postfix) with ESMTP id 3184C37B40D for ; Tue, 11 Jun 2002 16:09:43 -0700 (PDT) Received: (qmail 11111959 invoked by uid 0); 11 Jun 2002 23:09:41 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.230.194]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with SMTP for ; 11 Jun 2002 23:09:41 -0000 Received: from gits.gits.dyndns.org (btzkpq2rhm5uvbke@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.3/8.12.3) with ESMTP id g5BN9ea6018711; Wed, 12 Jun 2002 01:09:40 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.3/8.12.3/Submit) id g5BN9dKt018686; Wed, 12 Jun 2002 01:09:39 +0200 (CEST) (envelope-from root) Date: Wed, 12 Jun 2002 01:09:38 +0200 From: Cyrille Lefevre To: Juli Mallett Cc: current@FreeBSD.org Subject: Re: Looking for comments on a new utility... Message-ID: <20020611230938.GA24547@gits.dyndns.org> References: <20020611051517.A87966@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20020611051517.A87966@FreeBSD.ORG> User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 11, 2002 at 05:15:17AM -0700, Juli Mallett wrote: > Hej, > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. > > ps(1)'s internals, however, didn't seem quite right to me, but after about > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > programming to produce an N-level tree with as many as N-1 elements, I had > come up with a simple utility to print out a "process tree". > > You can find the code here: > http://people.freebsd.org/~jmallett/.proctree/proctree.c > > And some example output from a cluster machine here: > http://people.freebsd.org/~jmallett/.proctree/proctree.out > Lots of people have given feedback that they don't care much for the \_ > formatting of the tree, and I'm willing to look at patches that provide > noticably more readable output. how about this one ? 1 ? 0 \_ init 2814 ttyp0 0 \_ sh 2816 ttyp0 0 | \_ sh 57423 ? 0 | \_ sleep 2596 ? 0 \_ inetd 24834 ? 0 | \_ rlogind 24838 ttyp0 0 | | \_ ksh 24912 ttyp0 0 | | \_ ksh 57504 ? 0 | \_ telnetd ^^^^^^^^^^^^^^^^^^^^^^ command tree ^^^^^^^^^^^^^^^^^^^^ standard ps fields taken from ast-open `ps -T'. see http://www.research.att.com/~gsf/download/tgz/ for details (maybe one I'll will finish this !@#$%^&* port which is still broken in some way ?) for fun, how about a simple awk script like the one in attachment ;^) Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=pstree #!/bin/sh # was ps -ef ps axwo "user pid ppid start tt time command" | awk ' BEGIN { getline } { if (! nchild[$3]) nchild[$3] = 0 father[$2] = $3 children[$3, nchild[$3]] = $2 nchild[$3] ++ start[$2] = $4 tty[$2] = $5 time[$2] = $6 cmd[$2] = $7 for (i = 8; i <= NF; i++) cmd[$2] = cmd[$2] " " $i } function print_parents(pid) { if (pid != 1) prefix = " " print_parents(father[pid]) else prefix = " " printf "%6i %6i %7s %s %s %s\\_ %s\n", \ pid, father[pid], start[pid], tty[pid], time[pid], \ substr(prefix, 1, length(prefix)-2), cmd[pid] return " " prefix } function print_children (pid, prefix, child) { printf "%6i %6i %7s %s %s %s\\_ %s\n", \ pid, father[pid], start[pid], tty[pid], time[pid], \ substr(prefix, 1, length(prefix)-2), cmd[pid] if (! nchild[pid]) return for (child = 0; child < nchild[pid] - 1; child ++) print_children(children[pid, child], prefix " | ") print_children(children[pid, child], prefix " ") } END { if (! whichpid) whichpid = 1 if (! cmd[whichpid]) exit if (father[whichpid]) prefix = " " print_parents(father[whichpid]) else prefix = " " print_children(whichpid, prefix) }' whichpid=$1 --J/dobhs11T7y2rNN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 16:10:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from 12-234-22-238.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by hub.freebsd.org (Postfix) with ESMTP id D969D37B409 for ; Tue, 11 Jun 2002 16:10:51 -0700 (PDT) Received: from Master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-22-238.client.attbi.com (8.12.3/8.12.3) with ESMTP id g5BNAWXN095648; Tue, 11 Jun 2002 16:10:32 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from localhost (doug@localhost) by Master.gorean.org (8.12.3/8.12.3/Submit) with ESMTP id g5BNAHc9000736; Tue, 11 Jun 2002 16:10:17 -0700 (PDT) X-Authentication-Warning: Master.gorean.org: doug owned process doing -bs Date: Tue, 11 Jun 2002 16:10:17 -0700 (PDT) From: Doug Barton To: Andrew Boothman Cc: Will Andrews , Mark Murray , Subject: Re: The great perl rewrite - progress report In-Reply-To: <3D060D08.7060500@cream.org> Message-ID: <20020611160947.A637-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 11 Jun 2002, Andrew Boothman wrote: > Will Andrews wrote: > > On Thu, Jun 06, 2002 at 05:31:12PM +0100, Mark Murray wrote: > > > >>/usr/sbin/sysinstall * - fix - * > > > > > > What part of this uses perl?? > > Perhaps it was just a general comment ;-) Please don't send guesses to the list. Definitely do not send guesses to the list when the correct answer was given a long time ago. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 16:50:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp.noos.fr (verlaine.noos.net [212.198.2.73]) by hub.freebsd.org (Postfix) with ESMTP id DE24C37B41E for ; Tue, 11 Jun 2002 16:50:00 -0700 (PDT) Received: (qmail 17251555 invoked by uid 0); 11 Jun 2002 23:49:58 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.230.194]) (envelope-sender ) by 212.198.2.73 (qmail-ldap-1.03) with SMTP for ; 11 Jun 2002 23:49:58 -0000 Received: from gits.gits.dyndns.org (7x8vbgdjdck4zd4k@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.3/8.12.3) with ESMTP id g5BNnva6044255; Wed, 12 Jun 2002 01:49:58 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.3/8.12.3/Submit) id g5BNnu6I044254; Wed, 12 Jun 2002 01:49:56 +0200 (CEST) (envelope-from root) Message-Id: <200206112349.g5BNnu6I044254@gits.gits.dyndns.org> Subject: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs) In-Reply-To: <20020607112731.GB28015@gits.dyndns.org> To: freebsd stable , freebsd current Date: Wed, 12 Jun 2002 01:49:56 +0200 (CEST) From: Cyrille Lefevre Cc: Trevor Johnson , Dan Nelson , Maxim Sobolev Reply-To: cyrille.lefevre@laposte.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Jun 7, 2002 01:27:31 pm +0200, Cyrille Lefevre wrote: > On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote: > > Dan Nelson wrote: > [snip] > > According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug: > > ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess > > it qualifies as a "non-trivial program". :-) > > FYI, the current pax implementation is able to handle the following > archives from ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/ : > > 100char_longlink.tar > gtarfail.tar > gtarfail2.tar > > but miserably fail on this one : > > long.ustar.gz > > $ uname -a > FreeBSD gits 4.6-RC FreeBSD 4.6-RC #7: Sun Jun 2 16:33:05 CEST 2002 root@gits:/disk2/4.x-stable/src/sys/compile/CUSTOM i386 > $ pax -zvf > -rw-r--r-- 1 486 cvs 4 Apr 19 2000 ___________________ > ___________________________________________________________________________D_099 > /_______________________________________________________________________________ > __________________1000000644 0000746 0003720 00000000004 07077317140 0055507 0 > > $ star -zvtf > 4 -rw-r--r-- jes/cats Apr 19 13:54 2000 __________________________________ > ____________________________________________________________D_099/______________ > ________________________________________________________________________________ > ___100 > > I'll try to fix this... done, here is the patch which may be integrated to 4.6 -release ? Index: /tmp/src/bin/pax/tar.c =================================================================== RCS file: /home/ncvs/src/bin/pax/tar.c,v retrieving revision 1.19 diff -u -r1.19 tar.c --- /tmp/src/bin/pax/tar.c 16 May 2002 01:57:13 -0000 1.19 +++ /tmp/src/bin/pax/tar.c 11 Jun 2002 23:39:16 -0000 @@ -758,7 +758,7 @@ *dest++ = '/'; cnt++; } - arcn->nlen = cnt + l_strncpy(dest, hd->name, sizeof(arcn->name) - cnt); + arcn->nlen = cnt + l_strncpy(dest, hd->name, MIN(TNMSZ + 1, sizeof(arcn->name) - cnt) - 1); arcn->name[arcn->nlen] = '\0'; /* PS : I've finished to merge diffs from OpenBSD last week, but diffs w/ NetBSD are really big... so, be patient :P Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 17:24:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from midway.uchicago.edu (midway.uchicago.edu [128.135.12.12]) by hub.freebsd.org (Postfix) with ESMTP id EC22137B40A; Tue, 11 Jun 2002 17:24:10 -0700 (PDT) Received: from Yggdrasil (adsl-68-20-38-98.dsl.chcgil.ameritech.net [68.20.38.98]) by midway.uchicago.edu (8.12.2/8.12.2) with ESMTP id g5C0OAcL014817; Tue, 11 Jun 2002 19:24:10 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" From: David Syphers Reply-To: dsyphers@uchicago.edu To: Doug Barton Subject: Re: The great perl rewrite - progress report Date: Tue, 11 Jun 2002 19:24:12 -0500 X-Mailer: KMail [version 1.4] Cc: References: <20020611160947.A637-100000@master.gorean.org> In-Reply-To: <20020611160947.A637-100000@master.gorean.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206111924.12437.dsyphers@uchicago.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 11 June 2002 06:10 pm, Doug Barton wrote: > On Tue, 11 Jun 2002, Andrew Boothman wrote: > > > Will Andrews wrote: > > > On Thu, Jun 06, 2002 at 05:31:12PM +0100, Mark Murray wrote: > > > > > >>/usr/sbin/sysinstall * - fix - * > > > > > > > > > What part of this uses perl?? > > > > Perhaps it was just a general comment ;-) > > Please don't send guesses to the list. Definitely do not send guesses to > the list when the correct answer was given a long time ago. I think it was a joke, not a guess. Just saying we should all be doing our part to support the libh project :) -David -- Everyone who believes in telekinesis, raise my hand... Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 18: 7:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by hub.freebsd.org (Postfix) with ESMTP id E467A37B40A; Tue, 11 Jun 2002 18:07:55 -0700 (PDT) Received: from fwd05.sul.t-online.de by mailout06.sul.t-online.com with smtp id 17Hwc6-0007Qa-01; Wed, 12 Jun 2002 03:07:54 +0200 Received: from no-support.loc (520094253176-0001@[80.130.218.152]) by fmrl05.sul.t-online.com with esmtp id 17Hwc4-2EghKiC; Wed, 12 Jun 2002 03:07:52 +0200 Received: from frolic.no-support.loc (localhost.no-support.loc [127.0.0.1]) by no-support.loc (8.12.3/8.12.3) with ESMTP id g5C17kg1036101; Wed, 12 Jun 2002 03:07:46 +0200 (CEST) (envelope-from bjoern@frolic.no-support.loc) Received: (from bjoern@localhost) by frolic.no-support.loc (8.12.3/8.12.3/Submit) id g5C17k49036100; Wed, 12 Jun 2002 03:07:46 +0200 (CEST) From: Bjoern Fischer Date: Wed, 12 Jun 2002 03:07:45 +0200 To: Cyrille Lefevre Cc: freebsd stable , freebsd current Subject: Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs) Message-ID: <20020612010745.GB560@no-support.loc> References: <20020607112731.GB28015@gits.dyndns.org> <200206112349.g5BNnu6I044254@gits.gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200206112349.g5BNnu6I044254@gits.gits.dyndns.org> User-Agent: Mutt/1.3.99i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > PS : I've finished to merge diffs from OpenBSD last week, but diffs > w/ NetBSD are really big... so, be patient :P What about bin/35886? Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 19:27:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id B34A337B410 for ; Tue, 11 Jun 2002 19:27:25 -0700 (PDT) Received: (qmail 25885547 invoked by uid 0); 12 Jun 2002 02:27:24 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.230.194]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for ; 12 Jun 2002 02:27:24 -0000 Received: from gits.gits.dyndns.org (3s7jluf81aishg42@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.3/8.12.3) with ESMTP id g5C2RNa6095467; Wed, 12 Jun 2002 04:27:23 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.3/8.12.3/Submit) id g5C2RKpU095466; Wed, 12 Jun 2002 04:27:21 +0200 (CEST) (envelope-from root) Date: Wed, 12 Jun 2002 04:27:19 +0200 From: Cyrille Lefevre To: Bjoern Fischer Cc: freebsd stable , freebsd current Subject: Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs) Message-ID: <20020612022718.GA87876@gits.dyndns.org> Mail-Followup-To: Cyrille Lefevre , Bjoern Fischer , freebsd stable , freebsd current References: <20020607112731.GB28015@gits.dyndns.org> <200206112349.g5BNnu6I044254@gits.gits.dyndns.org> <20020612010745.GB560@no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020612010745.GB560@no-support.loc> User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 12, 2002 at 03:07:45AM +0200, Bjoern Fischer wrote: > > PS : I've finished to merge diffs from OpenBSD last week, but diffs > > w/ NetBSD are really big... so, be patient :P > > What about bin/35886? already done using the NetBSD way. the problem is that they use LC_TIME (hugh!) to pass the format string to strftime while LC_TIME isn't suppose to contain any format strings but a locale name. so, I don't know yet how to handle this case. whatever, I'm not sure that adding a yet another non portable option would be good. how about using env var PAX_TIMEFMT instead ? something is missing in the SUSV3 standard. -o can't be use for reading (not extracting -- aka no -r nor -w) archive. in other way, I would like to say something like this : pax -o freebsd.timefmt=... -f archive but I can't w/o breaking the standard! grrr. search for the VENDOR keyword in the the following URL for details : http://www.opengroup.org/onlinepubs/007904975/utilities/pax.html Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 20:19:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id B719637B407; Tue, 11 Jun 2002 20:19:20 -0700 (PDT) Received: from fwd07.sul.t-online.de by mailout02.sul.t-online.com with smtp id 17HyfH-0003Xf-00; Wed, 12 Jun 2002 05:19:19 +0200 Received: from no-support.loc (520094253176-0001@[80.130.218.152]) by fmrl07.sul.t-online.com with esmtp id 17HyfF-14ABbEC; Wed, 12 Jun 2002 05:19:17 +0200 Received: from frolic.no-support.loc (localhost.no-support.loc [127.0.0.1]) by no-support.loc (8.12.3/8.12.3) with ESMTP id g5C3JBg1036424; Wed, 12 Jun 2002 05:19:11 +0200 (CEST) (envelope-from bjoern@frolic.no-support.loc) Received: (from bjoern@localhost) by frolic.no-support.loc (8.12.3/8.12.3/Submit) id g5C3JBCm036423; Wed, 12 Jun 2002 05:19:11 +0200 (CEST) From: Bjoern Fischer Date: Wed, 12 Jun 2002 05:19:11 +0200 To: Cyrille Lefevre , freebsd stable , freebsd current Subject: Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs) Message-ID: <20020612031911.GC560@no-support.loc> References: <20020607112731.GB28015@gits.dyndns.org> <200206112349.g5BNnu6I044254@gits.gits.dyndns.org> <20020612010745.GB560@no-support.loc> <20020612022718.GA87876@gits.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020612022718.GA87876@gits.dyndns.org> User-Agent: Mutt/1.3.99i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 12, 2002 at 04:27:19AM +0200, Cyrille Lefevre wrote: [...] > already done using the NetBSD way. the problem is that they use > LC_TIME (hugh!) to pass the format string to strftime while > LC_TIME isn't suppose to contain any format strings but a locale > name. Ew! That won't work for my needs. > I'm not sure that adding a yet another non portable option would > be good. how about using env var PAX_TIMEFMT instead ? PAX_TIMEFMT would be fine. Does it already exist? Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 20:23: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id D00E637B401 for ; Tue, 11 Jun 2002 20:22:57 -0700 (PDT) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXK00GKIPE9BQ@mta6.snfc21.pbi.net> for current@freebsd.org; Tue, 11 Jun 2002 20:22:57 -0700 (PDT) Date: Tue, 11 Jun 2002 20:23:05 -0700 From: Jeffrey Hsu Subject: Re: Crash after world/kernel upgrade In-reply-to: <"Message from Tor.Egge"@cvsup.no.freebsd.org> "of Tue, 11 Jun 2002 16:27:32 GMT." <20020611162732B.tegge@cvsup.no.freebsd.org> To: Tor.Egge@cvsup.no.freebsd.org Cc: killer@lothlorien.no, current@freebsd.org Message-id: <0GXK00GKLPE9BQ@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > typo in unlocking (causing recursive lock instead) Fixed. Thanks. > lack of inet6 support for inpcb locking, e.g. no > handling of locks in in6_pcbdetach. > attempts to destroy held lock in in_pcbdetach Gurg, IPv6 isn't locked up yet! These must be the result of inadvertent interactions with the shared IPv4 code. I'll see what can be done to either mitigate the effects for IPv6 or quickly lock up v6. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 21:36:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemikals.org (cae88-49-048.sc.rr.com [24.88.49.48]) by hub.freebsd.org (Postfix) with ESMTP id 370E937B405; Tue, 11 Jun 2002 21:36:23 -0700 (PDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.12.3/8.12.3) with ESMTP id g5C4aMN6075655; Wed, 12 Jun 2002 00:36:22 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Wed, 12 Jun 2002 00:36:22 -0400 (EDT) From: Wesley Morgan To: current@freebsd.org Cc: ports@freebsd.org Subject: C++ problems Message-ID: <20020612003134.H69960-100000@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I cleaned up my /usr/lib and /usr/include file of stale headers/libs left after the libstdc++ upgrade (maybe this should be in src/UPDATING??), and now any port that uses C++ & autoconf fails to configure... checking if STL implementation is SGI like... no checking if STL implementation is HP like... no configure: error: "no known STL type found - did you forget to install libstdc++-devel ?" However, the configure script WILL succeed if I manually run configure with the same options (grabbed from ps). Weird... Anyone have some thoughts on this? It's a little annoying :) -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ morganw@chemikals.org _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 11 21:38:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38]) by hub.freebsd.org (Postfix) with SMTP id 3B8E937B404 for ; Tue, 11 Jun 2002 21:37:31 -0700 (PDT) Received: (qmail 2465 invoked from network); 12 Jun 2002 04:37:30 -0000 Received: from prop.sonic.net (208.201.224.193) by a.smtp-out.sonic.net with SMTP; 12 Jun 2002 04:37:30 -0000 Received: from blarf.homeip.net (adsl-209-204-188-56.sonic.net [209.204.188.56]) by prop.sonic.net (8.11.6/8.8.5) with ESMTP id g5C4bQM29344 for ; Tue, 11 Jun 2002 21:37:26 -0700 X-envelope-info: Received: by blarf.homeip.net (Postfix, from userid 1000) id 3FB5D19FD; Tue, 11 Jun 2002 21:37:21 -0700 (PDT) Date: Tue, 11 Jun 2002 21:37:21 -0700 From: Alex Zepeda To: current@freebsd.org Subject: Cannot boot with ACPI enabled.. Message-ID: <20020612043720.GA395@zippy.mybox.zip> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached are the dmesg from a kernel that worked (I was away from my 'puter for a few months so I wasn't able to try -current between mid Feb and now) and my kernel config. However, now it'll hang after detecting: acpi_tz0: on acpi0 unless I disable the acpi thermal stuff with the debug.acpi.disable/avoid kernel variables. - alex --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=acpidump Content-Transfer-Encoding: quoted-printable /* RSD PTR: Checksum=3D156, OEMID=3DAward, RsdtAddress=3D0x07ff3000 */ /* RSDT: Length=3D44, Revision=3D1, Checksum=3D172, OEMID=3DAward, OEM Table ID=3DAWRDACPI, OEM Revision=3D0x42302e31, Creator ID=3DAWRD, Creator Revision=3D0x0 */ /* Entries=3D{ 0x07ff3040, 0x07ff55c0 } */ /* DSDT=3D0x7ff30c0 INT_MODEL=3DPIC SCI_INT=3D9 SMI_CMD=3D0xb2, ACPI_ENABLE=3D0xa1, ACPI_DISABLE=3D0xa0, S4BIOS_REQ=3D0x0 PM1a_EVT_BLK=3D0x4000-0x4003 PM1a_CNT_BLK=3D0x4040-0x4041 PM2_TMR_BLK=3D0x4008-0x400b PM2_GPE0_BLK=3D0x400c-0x400f P_LVL2_LAT=3D90ms, P_LVL3_LAT=3D900ms FLUSH_SIZE=3D0, FLUSH_STRIDE=3D0 DUTY_OFFSET=3D1, DUTY_WIDTH=3D1 DAY_ALRM=3D13, MON_ALRM=3D0, CENTURY=3D0 Flags=3D{WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} */ /* DSDT: Length=3D9466, Revision=3D1, Checksum=3D18, OEMID=3DAWARD, OEM Table ID=3DAWRDACPI, OEM Revision=3D0x1000, Creator ID=3DMSFT, Creator Revision=3D0x100000c */ DefinitionBlock ( "acpi_dsdt.aml", //Output filename "DSDT", //Signature 0x1, //DSDT Revision "AWARD", //OEMID "AWRDACPI", //TABLE ID 0x1000 //OEM Revision ) { Scope(\_PR_) { Processor(\_PR_.CPU_, 0, 0x0, 0x0) { } Processor(\_PR_.CPU1, 1, 0x0, 0x0) { } } OperationRegion(CM70, SystemIO, 0x70, 0x2) Field(CM70, ByteAcc, NoLock, Preserve) { CI70, 8, CO71, 8 } IndexField(CI70, CO71, ByteAcc, NoLock, Preserve) { Offset(0x5d), SUSF, 8 } Name(STAT, 0x0) Name(\_S0_, Package(0x4) { 0x5, 0x5, 0x5, 0x5, }) Name(\_S1_, Package(0x4) { 0x4, 0x4, 0x4, 0x4, }) Name(\_S5_, Package(0x4) { Zero, Zero, Zero, Zero, }) OperationRegion(\DEBG, SystemIO, 0x80, 0x1) Field(\DEBG, ByteAcc, NoLock, Preserve) { DBG1, 8 } OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10) Field(EXTM, WordAcc, NoLock, Preserve) { ROM1, 16, RMS1, 16, ROM2, 16, RMS2, 16, ROM3, 16, RMS3, 16, AMEM, 32 } OperationRegion(\SMIC, SystemIO, 0xb2, 0x1) Field(\SMIC, ByteAcc, NoLock, Preserve) { SCP_, 8 } OperationRegion(\TRAP, SystemIO, 0x402f, 0x1) Field(\TRAP, ByteAcc, NoLock, Preserve) { , 1, TR13, 1 } OperationRegion(\GBLE, SystemIO, 0x4021, 0x1) Field(\GBLE, ByteAcc, NoLock, Preserve) { ESMI, 8 } Name(CMDB, Buffer(0x8) { }) CreateByteField(CMDB, 0x0, BYT0) CreateByteField(CMDB, 0x1, BYT1) CreateByteField(CMDB, 0x2, BYT2) CreateByteField(CMDB, 0x3, BYT3) CreateByteField(CMDB, 0x4, BYT4) CreateByteField(CMDB, 0x5, BYT5) CreateByteField(CMDB, 0x6, BYT6) CreateByteField(CMDB, 0x7, BYT7) Name(IDEB, Buffer(0x38) { }) CreateField(IDEB, 0x0, 0x38, CMD0) CreateField(IDEB, 0x38, 0x38, CMD1) CreateField(IDEB, 0x70, 0x38, CMD2) CreateField(IDEB, 0xa8, 0x38, CMD3) CreateField(IDEB, 0xe0, 0x38, CMD4) CreateField(IDEB, 0x0118, 0x38, CMD5) CreateField(IDEB, 0x0150, 0x38, CMD6) CreateField(IDEB, 0x0188, 0x38, CMD7) OperationRegion(APMP, SystemIO, 0xb2, 0x2) Field(APMP, ByteAcc, NoLock, Preserve) { APMC, 8, APMD, 8 } OperationRegion(ELCR, SystemIO, 0x04d0, 0x2) Field(ELCR, ByteAcc, NoLock, Preserve) { ELC1, 8, ELC2, 8 } OperationRegion(GPOB, SystemIO, 0x4034, 0x4) Field(GPOB, ByteAcc, NoLock, Preserve) { GP00, 1, GP01, 1, GP02, 1, GP03, 1, GP04, 1, GP05, 1, GP06, 1, GP07, 1, GP08, 1, GP09, 1, GP0A, 1, GP0B, 1, GP0C, 1, GP0D, 1, GP0E, 1, GP0F, 1, GP10, 1, GP11, 1, GP12, 1, GP13, 1, GP14, 1, GP15, 1, GP16, 1, GP17, 1, GP18, 1, GP19, 1, GP1A, 1, GP1B, 1, GP1C, 1, GP1D, 1, GP1E, 1, GP1F, 1 } Name(OSFL, 0x1) Method(STRC, 2) { If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1)))) { Return(0x0) } Add(SizeOf(Arg0), 0x1, Local0) Name(BUF0, Buffer(Local0) { }) Name(BUF1, Buffer(Local0) { }) Store(Arg0, BUF0) Store(Arg1, BUF1) While(Local0) { Decrement(Local0) If(LNot(LEqual(DerefOf(Index(BUF0, Local0, )), DerefOf(Index(BUF1, = Local0, ))))) { Return(Zero) } } Return(One) } OperationRegion(RTCM, SystemIO, 0x70, 0x2) Field(RTCM, ByteAcc, NoLock, Preserve) { CMIN, 8, CMDA, 8 } IndexField(CMIN, CMDA, ByteAcc, NoLock, Preserve) { Offset(0xf), SHUT, 8 } OperationRegion(\GRAM, SystemMemory, 0x0400, 0x0100) Field(\GRAM, ByteAcc, NoLock, Preserve) { Offset(0x10), FLG0, 8, Offset(0xba), SFLG, 8 } OperationRegion(INFO, SystemMemory, 0x000ff840, 0x1) Field(INFO, ByteAcc, NoLock, Preserve) { KBDI, 1, RTCW, 1, PS2F, 1, IRFL, 2, DISE, 1, SSHU, 1 } OperationRegion(BEEP, SystemIO, 0x61, 0x1) Field(BEEP, ByteAcc, NoLock, Preserve) { S1B_, 8 } OperationRegion(CONT, SystemIO, 0x40, 0x4) Field(CONT, ByteAcc, NoLock, Preserve) { CNT0, 8, CNT1, 8, CNT2, 8, CTRL, 8 } Method(SPKR, 1) { Store(S1B_, Local0) Store(0xb6, CTRL) Store(0x55, CNT2) Store(0x3, CNT2) Store(Arg0, Local2) While(LGreater(Local2, 0x0)) { Or(S1B_, 0x3, S1B_) Store(0x5fff, Local3) While(LGreater(Local3, 0x0)) { Decrement(Local3) } And(S1B_, 0xfc, S1B_) Store(0x0eff, Local3) While(LGreater(Local3, 0x0)) { Decrement(Local3) } Decrement(Local2) } Store(Local0, S1B_) } Scope(\) { Name(PICF, 0x0) Method(_PIC, 1) { Store(Arg0, PICF) } } Method(\_PTS, 1) { If(LEqual(Arg0, 0x5)) { Store(ESMI, Local0) And(Local0, 0xfb, Local0) Store(Local0, ESMI) Store(One, TR13) } If(LEqual(Arg0, 0x1)) { Store(One, TR13) } If(LEqual(Arg0, 0x2)) { Store(One, TR13) } Or(Arg0, 0xf0, Local0) Store(Local0, DBG1) Store(Zero, GP00) If(LEqual(Arg0, 0x4)) { } If(LEqual(Arg0, 0x5)) { Store(One, GP00) } } Method(\_WAK, 1) { Store(0xff, DBG1) Store(One, GP00) Store(0x50, SCP_) Notify(\_SB_.PCI0.UAR1, 0x0) If(LEqual(RTCW, 0x0)) { Notify(\_SB_.PWRB, 0x2) } } Scope(\_SI_) { Method(_MSG, 1) { Store(Local0, Local0) } Method(_SST, 1) { If(LEqual(Arg0, 0x3)) { } If(LEqual(Arg0, 0x1)) { } If(LEqual(Arg0, 0x0)) { } Store(Local0, Local0) } } OperationRegion(TEMM, SystemMemory, 0x000ff810, 0xc) Field(TEMM, WordAcc, NoLock, Preserve) { TP1H, 16, TP1L, 16, TP2H, 16, TP2L, 16, TRPC, 16, SENF, 16 } Name(TVAR, Buffer(0x5) {0x0, 0x0, 0x0, 0x0, 0x0 }) CreateByteField(TVAR, 0x0, PLCY) CreateWordField(TVAR, 0x1, CTOS) CreateWordField(TVAR, 0x3, CTHY) Name(TBUF, Buffer(0x4) {0x0, 0x0, 0x0, 0x0 }) CreateByteField(TBUF, 0x0, DB00) CreateByteField(TBUF, 0x1, DB01) CreateWordField(TBUF, 0x0, DW00) CreateWordField(TBUF, 0x2, DW01) CreateDWordField(TBUF, 0x0, DATD) Name(TSAD, 0x98) Method(SCFG, 1) { WBYT(TSAD, 0x1, Arg0) } Method(STOS, 3) { WWRD(TSAD, 0x3, Arg1, Arg0) } Method(STHY, 3) { WWRD(TSAD, 0x2, Arg1, Arg0) } Method(RTMP) { Store(RWRD(TSAD, 0x0), Local0) And(Local0, 0xff, Local1) ShiftLeft(Local1, 0x8, Local2) ShiftRight(Local0, 0x8, Local3) Or(Local2, Local3, Local0) ShiftRight(Local0, 0x7, Local0) ShiftLeft(Local0, 0x2, Local1) Add(Local0, Local1, Local0) Add(Local0, 0x0aac, Local0) Return(Local0) } OperationRegion(SM00, SystemIO, 0x5000, 0x1) Field(SM00, ByteAcc, NoLock, Preserve) { HSTS, 8 } OperationRegion(SM02, SystemIO, 0x5002, 0x1) Field(SM02, ByteAcc, NoLock, Preserve) { CTLR, 8 } OperationRegion(SM03, SystemIO, 0x5003, 0x1) Field(SM03, ByteAcc, NoLock, Preserve) { CMDR, 8 } OperationRegion(SM04, SystemIO, 0x5004, 0x1) Field(SM04, ByteAcc, NoLock, Preserve) { ADDR, 8 } OperationRegion(SM05, SystemIO, 0x5005, 0x1) Field(SM05, ByteAcc, NoLock, Preserve) { DAT0, 8 } OperationRegion(SM06, SystemIO, 0x5006, 0x1) Field(SM06, ByteAcc, NoLock, Preserve) { DAT1, 8 } Method(SWFS) { And(HSTS, 0x2, Local0) While(LEqual(Local0, Zero)) { Stall(0x1) And(HSTS, 0x2, Local0) } Store(0xff, HSTS) } Method(SBYT, 2) { Store(Arg0, ADDR) Store(Arg1, CMDR) Store(0xff, HSTS) Store(0x44, CTLR) SWFS() } Method(WBYT, 3) { Store(Arg0, ADDR) Store(Arg1, CMDR) Store(Arg2, DAT0) Store(0xff, HSTS) Store(0x48, CTLR) SWFS() } Method(WWRD, 4) { Store(Arg0, ADDR) Store(Arg1, CMDR) Store(Arg2, DAT0) Store(Arg3, DAT1) Store(0xff, HSTS) Store(0x4c, CTLR) SWFS() } Method(RBYT, 2) { Or(Arg0, 0x1, Local1) Store(Local1, ADDR) Store(Arg1, CMDR) Store(0xff, HSTS) Store(0x48, CTLR) SWFS() Return(DAT0) } Method(RWRD, 2) { Or(Arg0, 0x1, ADDR) Store(Arg1, CMDR) Store(0xff, HSTS) Store(0x4c, CTLR) SWFS() Store(DAT0, Local0) ShiftLeft(DAT1, 0x8, Local1) Or(Local0, Local1, Local2) Return(Local2) } Scope(\_TZ_) { PowerResource(PFAN, 0, 0) { Method(_STA) { XOr(GP00, Zero, Local7) Return(Local7) } Method(_ON_) { Store(One, GP00) } Method(_OFF) { If(LEqual(CTOS, 0x0aac)) { Store(One, GP00) } Else { Store(Zero, GP00) } } } Device(FAN_) { Name(_HID, 0x0b0cd041) Method(_INI) { Store(TP1H, CTOS) Store(TP1L, CTHY) } Name(_PR0, Package(0x1) { PFAN, }) } ThermalZone(THRM) { Name(_AL0, Package(0x1) { FAN_, }) Method(_AC0) { If(Or(PLCY, PLCY, Local7)) { Return(TP2H) } Else { Return(TP1H) } } Name(_PSL, Package(0x1) { \_PR_.CPU0, }) Name(_TSP, 0x3c) Name(_TC1, 0x4) Name(_TC2, 0x3) Method(_PSV) { If(Or(PLCY, PLCY, Local7)) { Return(TP1H) } Else { Return(TP2H) } } Method(_CRT) { Return(TRPC) } Method(_TMP) { And(SENF, 0x1, Local6) If(LEqual(Local6, 0x1)) { Return(RTMP()) } Else { Return(0x0b86) } } Method(_SCP, 1) { If(Arg0) { Store(One, PLCY) } Else { Store(Zero, PLCY) } Notify(\_TZ_.THRM, 0x81) } Method(STMP, 2) { Store(Arg1, DW00) If(Arg0) { STHY(DB00, DB01, DW00) } Else { STOS(DB00, DB01, DW00) } } } } Scope(\_GPE) { Method(_L08) { Notify(\_SB_.PCI0.USB0, 0x2) } Method(_L0A) { Notify(\_SB_.PCI0.UAR1, 0x2) } } Scope(\_SB_) { Device(PWRB) { Name(_HID, 0x0c0cd041) Method(_STA) { Return(0xb) } } Device(MEM_) { Name(_HID, 0x010cd041) Method(_CRS) { Name(BUF0, Buffer(0x7a) {0x86, 0x9, 0x0, 0x1, 0x0, 0x0, 0xf, 0x= 0, 0x0, 0x40, 0x0, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, 0x40, 0xf, 0x0, 0x0, 0x40= , 0x0, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, 0x80, 0xf, 0x0, 0x0, 0x40, 0x0, 0x0, = 0x86, 0x9, 0x0, 0x1, 0x0, 0xc0, 0xf, 0x0, 0x0, 0x40, 0x0, 0x0, 0x86, 0x9, 0= x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, = 0x0, 0xff, 0xff, 0x0, 0x0, 0x1, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, 0x0, 0x0, 0x= 0, 0x0, 0x0, 0xa, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0, = 0x0, 0x0, 0x86, 0x9, 0x0, 0x1, 0x0, 0x0, 0xc0, 0xfe, 0x0, 0x10, 0x0, 0x0, 0= x86, 0x9, 0x0, 0x1, 0x0, 0x0, 0xe0, 0xfe, 0x0, 0x10, 0x0, 0x0, 0x79, 0x0 }) CreateDWordField(BUF0, 0x34, ACMM) CreateDWordField(BUF0, 0x4, RMA1) CreateDWordField(BUF0, 0x8, RSS1) CreateDWordField(BUF0, 0x10, RMA2) CreateDWordField(BUF0, 0x14, RSS2) CreateDWordField(BUF0, 0x1c, RMA3) CreateDWordField(BUF0, 0x20, RSS3) CreateDWordField(BUF0, 0x28, RMA4) CreateDWordField(BUF0, 0x2c, RSS4) CreateDWordField(BUF0, 0x5c, EXTM) Subtract(AMEM, 0x00100000, EXTM) If(LNot(LEqual(ROM1, Zero))) { Store(RMA1, RMA2) ShiftLeft(ROM1, 0x8, Local0) Store(Local0, RMA1) ShiftLeft(RMS1, 0x8, Local0) Store(Local0, RSS1) Store(0x8000, RSS2) } If(LNot(LEqual(ROM2, Zero))) { Store(RMA2, RMA3) ShiftLeft(ROM2, 0x8, Local0) Store(Local0, RMA2) ShiftLeft(RMS2, 0x8, Local0) Store(Local0, RSS2) Store(0xc000, RSS3) } If(LNot(LEqual(ROM3, Zero))) { Store(RMA3, RMA4) ShiftLeft(ROM3, 0x8, Local0) Store(Local0, RMA3) ShiftLeft(RMS3, 0x8, Local0) Store(Local0, RSS3) Store(0x00010000, RSS4) } Store(AMEM, ACMM) Return(BUF0) } } Device(PCI0) { Name(_HID, 0x030ad041) Name(_ADR, 0x0) Method(_STA) { Return(0xf) } Method(_CRS) { Name(BUF0, Buffer(0xb8) {0x88, 0xd, 0x0, 0x2, 0x1, 0x0, 0x0, 0x= 0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0x1, 0x47, 0x1, 0xf8, 0xc, 0xf8, 0xc= , 0x1, 0x8, 0x88, 0xd, 0x0, 0x1, 0xc, 0x3, 0x0, 0x0, 0x0, 0x0, 0xf7, 0xc, 0= x0, 0x0, 0xf8, 0xc, 0x88, 0xd, 0x0, 0x1, 0xc, 0x3, 0x0, 0x0, 0x0, 0xd, 0xff= , 0x3f, 0x0, 0x0, 0x0, 0x33, 0x47, 0x1, 0x0, 0x40, 0x0, 0x40, 0x1, 0x42, 0x= 88, 0xd, 0x0, 0x1, 0xc, 0x3, 0x0, 0x0, 0x42, 0x40, 0xff, 0x4f, 0x0, 0x0, 0x= be, 0xf, 0x47, 0x1, 0x0, 0x50, 0x0, 0x50, 0x1, 0x10, 0x88, 0xd, 0x0, 0x1, 0= xc, 0x3, 0x0, 0x0, 0x10, 0x50, 0xff, 0xff, 0x0, 0x0, 0xf0, 0xaf, 0x87, 0x17= , 0x0, 0x0, 0xc, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa, 0x0, 0xff, 0xff, 0= xb, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x87, 0x17, 0x0, 0x0, 0xc,= 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc, 0x0, 0xff, 0xff, 0xd, 0x0, 0x0, 0x= 0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x87, 0x17, 0x0, 0x0, 0xc, 0x3, 0x0, 0x0, = 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0xff, 0xff, 0xbf, 0xfe, 0x0, 0x0, 0x0, 0x0, = 0x0, 0x0, 0xf0, 0xff, 0x79, 0x0 }) CreateDWordField(BUF0, 0xa6, TCMM) CreateDWordField(BUF0, 0xb2, TOMM) Add(AMEM, 0x00010000, TCMM) Subtract(0xfec00000, TCMM, TOMM) Return(BUF0) } Name(PICM, Package(0x1c) { Package(0x4) { 0x0008ffff, 0x0, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x0008ffff, 0x1, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x0008ffff, 0x2, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x0008ffff, 0x3, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x0009ffff, 0x0, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x0009ffff, 0x1, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x0009ffff, 0x2, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x0009ffff, 0x3, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x000affff, 0x0, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x000affff, 0x1, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x000affff, 0x2, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x000affff, 0x3, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x000bffff, 0x0, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x000bffff, 0x1, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x000bffff, 0x2, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x000bffff, 0x3, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x000cffff, 0x0, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x000cffff, 0x1, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x000cffff, 0x2, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x000cffff, 0x3, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x0007ffff, 0x0, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x0007ffff, 0x1, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x0007ffff, 0x2, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x0007ffff, 0x3, \_SB_.PCI0.LNKD, 0x0, }, Package(0x4) { 0x0001ffff, 0x0, \_SB_.PCI0.LNKA, 0x0, }, Package(0x4) { 0x0001ffff, 0x1, \_SB_.PCI0.LNKB, 0x0, }, Package(0x4) { 0x0001ffff, 0x2, \_SB_.PCI0.LNKC, 0x0, }, Package(0x4) { 0x0001ffff, 0x3, \_SB_.PCI0.LNKD, 0x0, }, }) Name(APIC, Package(0x1c) { Package(0x4) { 0x0008ffff, 0x0, 0x0, 0x10, }, Package(0x4) { 0x0008ffff, 0x1, 0x0, 0x11, }, Package(0x4) { 0x0008ffff, 0x2, 0x0, 0x12, }, Package(0x4) { 0x0008ffff, 0x3, 0x0, 0x13, }, Package(0x4) { 0x0009ffff, 0x0, 0x0, 0x11, }, Package(0x4) { 0x0009ffff, 0x1, 0x0, 0x12, }, Package(0x4) { 0x0009ffff, 0x2, 0x0, 0x13, }, Package(0x4) { 0x0009ffff, 0x3, 0x0, 0x10, }, Package(0x4) { 0x000affff, 0x0, 0x0, 0x12, }, Package(0x4) { 0x000affff, 0x1, 0x0, 0x13, }, Package(0x4) { 0x000affff, 0x2, 0x0, 0x10, }, Package(0x4) { 0x000affff, 0x3, 0x0, 0x11, }, Package(0x4) { 0x000bffff, 0x0, 0x0, 0x13, }, Package(0x4) { 0x000bffff, 0x1, 0x0, 0x10, }, Package(0x4) { 0x000bffff, 0x2, 0x0, 0x11, }, Package(0x4) { 0x000bffff, 0x3, 0x0, 0x12, }, Package(0x4) { 0x000cffff, 0x0, 0x0, 0x13, }, Package(0x4) { 0x000cffff, 0x1, 0x0, 0x10, }, Package(0x4) { 0x000cffff, 0x2, 0x0, 0x11, }, Package(0x4) { 0x000cffff, 0x3, 0x0, 0x12, }, Package(0x4) { 0x0007ffff, 0x0, 0x0, 0x10, }, Package(0x4) { 0x0007ffff, 0x1, 0x0, 0x11, }, Package(0x4) { 0x0007ffff, 0x2, 0x0, 0x12, }, Package(0x4) { 0x0007ffff, 0x3, 0x0, 0x13, }, Package(0x4) { 0x0001ffff, 0x0, 0x0, 0x10, }, Package(0x4) { 0x0001ffff, 0x1, 0x0, 0x11, }, Package(0x4) { 0x0001ffff, 0x2, 0x0, 0x12, }, Package(0x4) { 0x0001ffff, 0x3, 0x0, 0x13, }, }) Method(_PRT) { If(LNot(PICF)) { Return(PICM) } Else { Return(APIC) } } Device(PX40) { Name(_ADR, 0x00070000) OperationRegion(PIRQ, PCI_Config, 0x60, 0x4) Scope(\) { Field(\_SB_.PCI0.PX40.PIRQ, ByteAcc, NoLock, Preserve) { PIRA, 8, PIRB, 8, PIRC, 8, PIRD, 8 } } } Device(USB0) { Name(_ADR, 0x00070002) Name(_PRW, Package(0x2) { 0x8, 0x4, }) } Device(PX43) { Name(_ADR, 0x00070003) } Name(BUFA, Buffer(0x6) {0x23, 0xf8, 0xdc, 0x18, 0x79, 0x0 }) Name(BUFB, Buffer(0x6) {0x23, 0x0, 0x0, 0x18, 0x79, 0x0 }) CreateWordField(BUFB, 0x1, IRQV) Device(LNKA) { Name(_HID, 0x0f0cd041) Name(_UID, 0x1) Method(_STA) { And(PIRA, 0x80, Local0) If(LEqual(Local0, 0x80)) { Return(0x9) } Else { Return(0xb) } } Method(_PRS) { Return(BUFA) } Method(_DIS) { Or(PIRA, 0x80, PIRA) } Method(_CRS) { And(PIRA, 0xf, Local0) ShiftLeft(0x1, Local0, IRQV) Return(BUFB) } Method(_SRS, 1) { CreateWordField(Arg0, 0x1, IRQ1) FindSetRightBit(IRQ1, Local0) Decrement(Local0) Store(Local0, PIRA) } } Device(LNKB) { Name(_HID, 0x0f0cd041) Name(_UID, 0x2) Method(_STA) { And(PIRB, 0x80, Local0) If(LEqual(Local0, 0x80)) { Return(0x9) } Else { Return(0xb) } } Method(_PRS) { Return(BUFA) } Method(_DIS) { Or(PIRB, 0x80, PIRB) } Method(_CRS) { And(PIRB, 0xf, Local0) ShiftLeft(0x1, Local0, IRQV) Return(BUFB) } Method(_SRS, 1) { CreateWordField(Arg0, 0x1, IRQ1) FindSetRightBit(IRQ1, Local0) Decrement(Local0) Store(Local0, PIRB) } } Device(LNKC) { Name(_HID, 0x0f0cd041) Name(_UID, 0x3) Method(_STA) { And(PIRC, 0x80, Local0) If(LEqual(Local0, 0x80)) { Return(0x9) } Else { Return(0xb) } } Method(_PRS) { Return(BUFA) } Method(_DIS) { Or(PIRC, 0x80, PIRC) } Method(_CRS) { And(PIRC, 0xf, Local0) ShiftLeft(0x1, Local0, IRQV) Return(BUFB) } Method(_SRS, 1) { CreateWordField(Arg0, 0x1, IRQ1) FindSetRightBit(IRQ1, Local0) Decrement(Local0) Store(Local0, PIRC) } } Device(LNKD) { Name(_HID, 0x0f0cd041) Name(_UID, 0x4) Method(_STA) { And(PIRD, 0x80, Local0) If(LEqual(Local0, 0x80)) { Return(0x9) } Else { Return(0xb) } } Method(_PRS) { Return(BUFA) } Method(_DIS) { Or(PIRD, 0x80, PIRD) } Method(_CRS) { And(PIRD, 0xf, Local0) ShiftLeft(0x1, Local0, IRQV) Return(BUFB) } Method(_SRS, 1) { CreateWordField(Arg0, 0x1, IRQ1) FindSetRightBit(IRQ1, Local0) Decrement(Local0) Store(Local0, PIRD) } } Method(\_SB_.PCI0._INI) { If(STRC(\_OS_, "Microsoft Windows")) { } Else { Store(0x0, OSFL) } } Device(SYSR) { Name(_HID, 0x020cd041) Name(_UID, 0x1) Name(_CRS, Buffer(0x5a) {0x47, 0x1, 0x10, 0x0, 0x10, 0x0, 0x1, = 0x10, 0x47, 0x1, 0x22, 0x0, 0x22, 0x0, 0x1, 0x1e, 0x47, 0x1, 0x44, 0x0, 0x4= 4, 0x0, 0x1, 0x1c, 0x47, 0x1, 0x62, 0x0, 0x62, 0x0, 0x1, 0x2, 0x47, 0x1, 0x= 65, 0x0, 0x65, 0x0, 0x1, 0xb, 0x47, 0x1, 0x74, 0x0, 0x74, 0x0, 0x1, 0xc, 0x= 47, 0x1, 0x91, 0x0, 0x91, 0x0, 0x1, 0x3, 0x47, 0x1, 0xa2, 0x0, 0xa2, 0x0, 0= x1, 0x1e, 0x47, 0x1, 0xe0, 0x0, 0xe0, 0x0, 0x1, 0x10, 0x47, 0x1, 0xd0, 0x4,= 0xd0, 0x4, 0x1, 0x2, 0x47, 0x1, 0x94, 0x2, 0x94, 0x2, 0x1, 0x4, 0x79, 0x0 = }) } Device(PIC_) { Name(_HID, 0xd041) Name(_CRS, Buffer(0x15) {0x47, 0x1, 0x20, 0x0, 0x20, 0x0, 0x1, = 0x2, 0x47, 0x1, 0xa0, 0x0, 0xa0, 0x0, 0x1, 0x2, 0x22, 0x4, 0x0, 0x79, 0x0 }) } Device(DMA1) { Name(_HID, 0x0002d041) Name(_CRS, Buffer(0x25) {0x2a, 0x10, 0x4, 0x47, 0x1, 0x0, 0x0, = 0x0, 0x0, 0x1, 0x10, 0x47, 0x1, 0x80, 0x0, 0x80, 0x0, 0x1, 0x11, 0x47, 0x1,= 0x94, 0x0, 0x94, 0x0, 0x1, 0xc, 0x47, 0x1, 0xc0, 0x0, 0xc0, 0x0, 0x1, 0x20= , 0x79, 0x0 }) } Device(TMR_) { Name(_HID, 0x0001d041) Name(_CRS, Buffer(0xd) {0x47, 0x1, 0x40, 0x0, 0x40, 0x0, 0x1, 0= x4, 0x22, 0x1, 0x0, 0x79, 0x0 }) } Device(RTC_) { Name(_HID, 0x000bd041) Name(_CRS, Buffer(0xd) {0x47, 0x1, 0x70, 0x0, 0x70, 0x0, 0x4, 0= x4, 0x22, 0x0, 0x1, 0x79, 0x0 }) } Device(SPKR) { Name(_HID, 0x0008d041) Name(_CRS, Buffer(0xa) {0x47, 0x1, 0x61, 0x0, 0x61, 0x0, 0x1, 0= x1, 0x79, 0x0 }) } Device(COPR) { Name(_HID, 0x040cd041) Name(_CRS, Buffer(0xd) {0x47, 0x1, 0xf0, 0x0, 0xf0, 0x0, 0x1, 0= x10, 0x22, 0x0, 0x20, 0x79, 0x0 }) } Scope(\) { OperationRegion(SIO1, SystemIO, 0x03f0, 0x2) Field(SIO1, ByteAcc, NoLock, Preserve) { INDP, 8, DATP, 8 } IndexField(INDP, DATP, ByteAcc, NoLock, Preserve) { Offset(0x2), CR02, 8, Offset(0x7), CR07, 8, Offset(0x20), CR20, 8, CR21, 8, CR22, 8, CR23, 8, CR24, 8, CR25, 8, CR26, 8, Offset(0x28), CR28, 8, Offset(0x2a), CR2A, 8, CR2B, 8, CR2C, 8, Offset(0x30), CR30, 8, Offset(0x60), CR60, 8, CR61, 8, CR62, 8, CR63, 8, CR64, 8, CR65, 8, Offset(0x70), CR70, 8, Offset(0x72), CR72, 8, Offset(0x74), CR74, 8, Offset(0xe0), CRE0, 8, CRE1, 8, CRE2, 8, CRE3, 8, CRE4, 8, CRE5, 8, CRE6, 8, CRE7, 8, CRE8, 8, CRE9, 8, CREA, 8, CREB, 8, CREC, 8, CRED, 8, Offset(0xf0), CRF0, 8, CRF1, 8, CRF2, 8, CRF3, 8, CRF4, 8, Offset(0xf6), CRF6, 8, CRF7, 8, Offset(0xf9), CRF9, 8 } Method(ENF1) { Store(0x87, INDP) Store(0x87, INDP) } Method(EXF1) { Store(0xaa, INDP) } } Device(FDC0) { Name(_HID, 0x0007d041) Method(_STA) { ENF1() Store(Zero, CR07) If(CR30) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } EXF1() Return(0x0) } Method(_DIS) { ENF1() Store(0x0, CR07) Store(Zero, CR30) EXF1() } Method(_CRS) { Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0= x1, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x1, 0x1, 0x22, 0x40, 0x0, 0x2a, = 0x4, 0x0, 0x79, 0x0 }) Store(Local0, Local0) Return(BUF0) } Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,= 0x1, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x1, 0x1, 0x22, 0x40, 0x0, 0x2a= , 0x4, 0x0, 0x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateWordField(Arg0, 0x19, IRQL) CreateByteField(Arg0, 0x1c, DMAV) ENF1() Store(Zero, CR07) Store(One, CR30) EXF1() } } Device(UAR1) { Name(_HID, 0x0105d041) Name(_UID, 0x1) Method(_STA) { ENF1() Store(0x2, CR07) If(CR30) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } EXF1() Return(0x0) } Method(_DIS) { ENF1() Store(0x2, CR07) Store(Zero, CR30) EXF1() } Method(_CRS) { Name(BUF1, Buffer(0xd) {0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x8,= 0x8, 0x22, 0x0, 0x0, 0x79, 0x0 }) CreateByteField(BUF1, 0x2, IOLO) CreateByteField(BUF1, 0x3, IOHI) CreateByteField(BUF1, 0x4, IORL) CreateByteField(BUF1, 0x5, IORH) CreateWordField(BUF1, 0x9, IRQW) ENF1() Store(0x2, CR07) Store(CR61, IOLO) Store(CR61, IORL) Store(CR60, IOHI) Store(CR60, IORH) Store(One, Local0) ShiftLeft(Local0, CR70, IRQW) EXF1() Return(BUF1) } Name(_PRS, Buffer(0x33) {0x30, 0x47, 0x1, 0xf8, 0x3, 0xf8, 0x3,= 0x8, 0x8, 0x22, 0x10, 0x0, 0x30, 0x47, 0x1, 0xf8, 0x2, 0xf8, 0x2, 0x8, 0x8= , 0x22, 0x8, 0x0, 0x30, 0x47, 0x1, 0xe8, 0x3, 0xe8, 0x3, 0x8, 0x8, 0x22, 0x= 10, 0x0, 0x30, 0x47, 0x1, 0xe8, 0x2, 0xe8, 0x2, 0x8, 0x8, 0x22, 0x8, 0x0, 0= x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateWordField(Arg0, 0x9, IRQW) ENF1() Store(0x2, CR07) Store(One, CR30) Store(IOLO, CR61) Store(IOHI, CR60) FindSetRightBit(IRQW, Local0) Subtract(Local0, 0x1, CR70) EXF1() } } Device(UAR2) { Name(_HID, 0x0105d041) Name(_UID, 0x2) Method(_STA) { ENF1() If(LEqual(CKID(), 0x9771)) { Store(0x3, CR07) If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } If(LEqual(IRFL, 0x0)) { Store(0x6, CR07) If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } } Else { Store(0x3, CR07) And(CRF1, 0x38, Local0) If(LEqual(Local0, 0x0)) { If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } And(CRF1, 0x38, Local0) If(LNot(LLess(Local0, 0x20))) { If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } } EXF1() Return(0x0) } Method(_DIS) { ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { If(LOr(CR60, CR61)) { Store(0x0, CR30) } Else { Store(0x6, CR07) } } Store(0x0, CR30) EXF1() } Method(_CRS) { Name(BUF2, Buffer(0xd) {0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x8,= 0x8, 0x22, 0x10, 0x0, 0x79, 0x0 }) CreateByteField(BUF2, 0x2, IOLO) CreateByteField(BUF2, 0x3, IOHI) CreateByteField(BUF2, 0x4, IORL) CreateByteField(BUF2, 0x5, IORH) CreateWordField(BUF2, 0x9, IRQW) ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { If(LOr(CR60, CR61)) { Store(0x3, CR07) } Else { Store(0x6, CR07) } } Store(CR61, IOLO) Store(CR61, IORL) Store(CR60, IOHI) Store(CR60, IORH) Store(One, Local0) ShiftLeft(Local0, CR70, IRQW) EXF1() Return(BUF2) } Name(_PRS, Buffer(0x33) {0x30, 0x47, 0x1, 0xf8, 0x3, 0xf8, 0x3,= 0x8, 0x8, 0x22, 0x10, 0x0, 0x30, 0x47, 0x1, 0xf8, 0x2, 0xf8, 0x2, 0x8, 0x8= , 0x22, 0x8, 0x0, 0x30, 0x47, 0x1, 0xe8, 0x3, 0xe8, 0x3, 0x8, 0x8, 0x22, 0x= 10, 0x0, 0x30, 0x47, 0x1, 0xe8, 0x2, 0xe8, 0x2, 0x8, 0x8, 0x22, 0x8, 0x0, 0= x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateWordField(Arg0, 0x9, IRQW) ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { If(LOr(CR60, CR61)) { Store(0x3, CR07) } Else { Store(0x6, CR07) } } Store(One, CR30) Store(IOLO, CR61) Store(IOHI, CR60) FindSetRightBit(IRQW, Local0) Subtract(Local0, 0x1, CR70) EXF1() } } Device(IRDA) { Name(_HID, 0x1005d041) Method(_STA) { ENF1() If(LEqual(CKID(), 0x9771)) { If(LEqual(IRFL, 0x1)) { Store(0x6, CR07) If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } } Else { Store(0x3, CR07) And(CRF1, 0x30, Local0) If(LEqual(Local0, 0x10)) { If(LEqual(CR30, 0x1)) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } } EXF1() Return(0x0) } Method(_DIS) { If(LEqual(DISE, 0x1)) { ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { Store(0x6, CR07) } Store(0x0, CR30) EXF1() } Store(Local0, Local0) } Method(_CRS) { Name(BUF4, Buffer(0xd) {0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x8,= 0x8, 0x22, 0x0, 0x0, 0x79, 0x0 }) CreateByteField(BUF4, 0x2, IOLO) CreateByteField(BUF4, 0x3, IOHI) CreateByteField(BUF4, 0x4, IORL) CreateByteField(BUF4, 0x5, IORH) CreateWordField(BUF4, 0x9, IRQW) ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { Store(0x6, CR07) } Store(CR61, IOLO) Store(CR61, IORL) Store(CR60, IOHI) Store(CR60, IORH) Store(0x0, IRQW) ShiftLeft(0x1, CR70, IRQW) EXF1() Return(BUF4) } Name(_PRS, Buffer(0x33) {0x30, 0x47, 0x1, 0xf8, 0x3, 0xf8, 0x3,= 0x8, 0x8, 0x22, 0x18, 0xc, 0x30, 0x47, 0x1, 0xf8, 0x2, 0xf8, 0x2, 0x8, 0x8= , 0x22, 0x18, 0xc, 0x30, 0x47, 0x1, 0xe8, 0x3, 0xe8, 0x3, 0x8, 0x8, 0x22, 0= x18, 0xc, 0x30, 0x47, 0x1, 0xe8, 0x2, 0xe8, 0x2, 0x8, 0x8, 0x22, 0x18, 0xc,= 0x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateWordField(Arg0, 0x9, IRQW) ENF1() Store(0x3, CR07) If(LEqual(CKID(), 0x9771)) { Store(0x6, CR07) } Store(One, CR30) Store(IOLO, CR61) Store(IOHI, CR60) FindSetRightBit(IRQW, Local0) Subtract(Local0, 0x1, CR70) EXF1() } } Method(CKID) { Store(CR20, Local0) Store(CR21, Local1) ShiftLeft(Local0, 0x8, Local0) Or(Local0, Local1, Local0) Return(Local0) } Device(LPT1) { Name(_HID, 0x0004d041) Name(_UID, 0x1) Method(_STA) { ENF1() Store(0x1, CR07) And(CRF0, 0x2, Local0) If(LNot(LEqual(Local0, 0x2))) { If(CR30) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } EXF1() Return(0x0) } Method(_DIS) { ENF1() Store(0x1, CR07) Store(Zero, CR30) EXF1() } Method(_CRS) { Name(BUF5, Buffer(0xd) {0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x8,= 0x0, 0x22, 0x0, 0x0, 0x79, 0x0 }) CreateByteField(BUF5, 0x2, IOLO) CreateByteField(BUF5, 0x3, IOHI) CreateByteField(BUF5, 0x4, IORL) CreateByteField(BUF5, 0x5, IORH) CreateByteField(BUF5, 0x7, IOLE) CreateWordField(BUF5, 0x9, IRQW) ENF1() Store(0x1, CR07) Store(CR61, IOLO) Store(IOLO, IORL) Store(CR60, IOHI) Store(IOHI, IORH) If(LEqual(IOLO, 0xbc)) { Store(0x4, IOLE) } Else { Store(0x8, IOLE) } Store(One, Local0) Store(CR70, Local5) ShiftLeft(Local0, Local5, IRQW) EXF1() Return(BUF5) } Name(_PRS, Buffer(0x27) {0x30, 0x47, 0x1, 0x78, 0x3, 0x78, 0x3,= 0x8, 0x8, 0x22, 0xb8, 0x0, 0x30, 0x47, 0x1, 0x78, 0x2, 0x78, 0x2, 0x8, 0x8= , 0x22, 0xb8, 0x0, 0x30, 0x47, 0x1, 0xbc, 0x3, 0xbc, 0x3, 0x8, 0x4, 0x22, 0= xb8, 0x0, 0x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateByteField(Arg0, 0x4, IORL) CreateByteField(Arg0, 0x5, IORH) CreateWordField(Arg0, 0x9, IRQW) ENF1() Store(0x1, CR07) Store(One, CR30) Store(IOLO, CR61) Store(IOHI, CR60) FindSetLeftBit(IRQW, Local0) Subtract(Local0, 0x1, Local0) Store(Local0, CR70) EXF1() } } Device(ECP1) { Name(_HID, 0x0104d041) Name(_UID, 0x1) Method(_STA) { ENF1() Store(0x1, CR07) And(CRF0, 0x2, Local0) If(LEqual(Local0, 0x2)) { If(CR30) { EXF1() Return(0xf) } Else { If(LOr(CR60, CR61)) { EXF1() Return(0xd) } } } EXF1() Return(0x0) } Method(_DIS) { ENF1() Store(0x1, CR07) Store(Zero, CR30) EXF1() } Method(_CRS) { Name(BUF6, Buffer(0x18) {0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x8= , 0x8, 0x47, 0x1, 0x0, 0x0, 0x0, 0x0, 0x4, 0x4, 0x22, 0x0, 0x0, 0x2a, 0x0, = 0x0, 0x79, 0x0 }) CreateByteField(BUF6, 0x2, IOLO) CreateByteField(BUF6, 0x3, IOHI) CreateByteField(BUF6, 0x4, IORL) CreateByteField(BUF6, 0x5, IORH) CreateByteField(BUF6, 0x6, ALGN) CreateByteField(BUF6, 0x7, LENG) CreateByteField(BUF6, 0xa, IOEL) CreateByteField(BUF6, 0xb, IOEH) CreateByteField(BUF6, 0xc, IOML) CreateByteField(BUF6, 0xd, IOMH) CreateWordField(BUF6, 0x11, IRQW) CreateByteField(BUF6, 0x14, DMAC) ENF1() Store(0x1, CR07) Store(CR61, Local2) Store(Local2, IOLO) Store(CR60, Local3) Store(Local3, IOHI) Or(Local3, 0x4, Local3) Store(Local3, IOEH) Store(Local3, IOMH) Store(IOLO, IORL) Store(IOLO, IOEL) Store(IOLO, IOML) Store(IOHI, IORH) Store(One, Local0) Store(CR70, Local5) ShiftLeft(Local0, Local5, IRQW) Store(One, Local0) Store(CR74, Local5) ShiftLeft(Local0, Local5, DMAC) Store(IOHI, Local0) ShiftLeft(Local0, 0x8, Local0) Or(Local0, IOLO, Local0) If(LEqual(Local0, 0x03bc)) { Store(0x4, ALGN) Store(0x4, LENG) } EXF1() Return(BUF6) } Name(_PRS, Buffer(0x48) {0x30, 0x47, 0x1, 0x78, 0x3, 0x78, 0x3,= 0x8, 0x8, 0x47, 0x1, 0x78, 0x7, 0x78, 0x7, 0x4, 0x4, 0x22, 0xb0, 0x0, 0x2a= , 0xb, 0x0, 0x30, 0x47, 0x1, 0x78, 0x2, 0x78, 0x2, 0x8, 0x8, 0x47, 0x1, 0x7= 8, 0x6, 0x78, 0x6, 0x4, 0x4, 0x22, 0xb8, 0x0, 0x2a, 0xb, 0x0, 0x30, 0x47, 0= x1, 0xbc, 0x3, 0xbc, 0x3, 0x4, 0x4, 0x47, 0x1, 0xbc, 0x7, 0xbc, 0x7, 0x4, 0= x4, 0x22, 0xb0, 0x0, 0x2a, 0xb, 0x0, 0x38, 0x79, 0x0 }) Method(_SRS, 1) { CreateByteField(Arg0, 0x2, IOLO) CreateByteField(Arg0, 0x3, IOHI) CreateWordField(Arg0, 0x11, IRQW) CreateByteField(Arg0, 0x14, DMAC) ENF1() Store(0x1, CR07) Store(One, CR30) Store(IOLO, CR61) Store(IOHI, CR60) FindSetLeftBit(IRQW, Local0) Subtract(Local0, 0x1, Local0) Store(Local0, CR70) FindSetLeftBit(DMAC, Local1) Subtract(Local1, 0x1, CR74) EXF1() } } Device(PS2M) { Name(_HID, 0x130fd041) Method(_STA) { If(LEqual(PS2F, 0x0)) { Return(0xf) } Else { Return(0x0) } } Method(_CRS) { Name(BUF1, Buffer(0x5) {0x22, 0x0, 0x10, 0x79, 0x0 }) Name(BUF2, Buffer(0x15) {0x47, 0x1, 0x60, 0x0, 0x60, 0x0, 0= x1, 0x1, 0x47, 0x1, 0x64, 0x0, 0x64, 0x0, 0x1, 0x1, 0x22, 0x0, 0x10, 0x79, = 0x0 }) If(LEqual(KBDI, 0x1)) { Return(BUF2) } Else { Return(BUF1) } } } Device(PS2K) { Name(_HID, 0x0303d041) Method(_STA) { If(LEqual(KBDI, 0x1)) { Return(0x0) } Else { Return(0xf) } } Name(_CRS, Buffer(0x15) {0x47, 0x1, 0x60, 0x0, 0x60, 0x0, 0x1, = 0x1, 0x47, 0x1, 0x64, 0x0, 0x64, 0x0, 0x1, 0x1, 0x22, 0x2, 0x0, 0x79, 0x0 }) } Method(\_SB_.PCI0.UAR1._PRW) { If(OSFL) { Return(Package(0x2) { 0xa, 0x4, }) } Else { If(STAT) { Return(Package(0x2) { 0xa, 0x3, }) } Else { Return(Package(0x2) { 0xa, 0x1, }) } } } Method(\_SB_.PCI0.UAR2._PRW) { If(OSFL) { Return(Package(0x2) { 0xa, 0x4, }) } Else { If(STAT) { Return(Package(0x2) { 0xa, 0x3, }) } Else { Return(Package(0x2) { 0xa, 0x1, }) } } } } } } /* APIC: Length=3D92, Revision=3D1, Checksum=3D102, OEMID=3DAward, OEM Table ID=3D, OEM Revision=3D0x0, Creator ID=3D, Creator Revision=3D0x0 */ --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.today" ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2002 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 5.0-CURRENT #22: Sat Feb 16 16:46:41 PST 2002 root@zippy.mybox.zip:/usr/src/sys/i386/compile/ZIPPY_SMP Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc04e5000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (451.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 134152192 (131008K bytes) avail memory = 125419520 (122480K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Pentium Pro MTRR support enabled dsobject-0568: *** Warning: Reference \\_PR_.CPU0 at AML 903 not found Using $PIR table, 7 entries at 0xc00fdcf0 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (500.6C) acpi_button0: on acpi0 acpi_pcib0: port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 IOAPIC #0 intpin 19 -> irq 2 IOAPIC #0 intpin 17 -> irq 9 IOAPIC #0 intpin 18 -> irq 10 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 IOAPIC #0 intpin 16 -> irq 11 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xe000-0xe01f irq 2 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 pci0: at device 9.0 (no driver attached) fxp0: port 0xe400-0xe43f mem 0xdb000000-0xdb0fffff,0xdb100000-0xdb100fff irq 10 at device 10.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto psxface-0294: *** Error: Method execution failed, AE_AML_UNINITIALIZED_LOCAL can't fetch resources for \\_SB_.PCI0.FDC0 - AE_AML_UNINITIALIZED_LOCAL fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 fdc0: cannot reserve I/O port range (1 ports) fdc0: cannot reserve I/O port range (1 ports) npx0: on motherboard npx0: INT 16 interface atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: