Re: panic in get_next_dirent
Hopefully it's not still broken. I attempted to fix the problem with r211684 but the fix was essentially a no-op, it didn't fix or break anything. I believe r211818 fixed the problem in head and r212137 fixed it in stable/8. Can you try an upgrade to at least r211818 and see if that solves the problem? Thanks. On Thu, 02 Sep 2010 11:48:44 +0300 Andriy Gapon a...@icyb.net.ua wrote: Brian, after I upgrade from beginning-of-June kernel to end-of-August one (r211758) I get a panic in get_next_dirent which happens during parallel access to FS like during buildworld with -jN. I am upgrading kernel to the latest revision as of today. Could this be something that you accidentally broke and then fixed while pursuing your NFS issue? -- Andriy Gapon -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Re: make install failed on XFree86-4-client (with 6/10 -current)
Well, this has been happening for about a year on my dev box. It's not gcc 3.1 specific. I've never gotten around to figuring out why it works on some machines. On Sat, 29 Jun 2002 19:41:51 -0700, David O'Brien wrote: On Sat, Jun 29, 2002 at 11:30:48PM +0100, Brian Somers wrote: The problem is because the glxinfo program uses CCLINK to link, but it's a c++ program. Changing the CCLINK to CXXLINK works. We can't be the only ones seeing this -- surely anyone using Gcc 3.1 on their i386 (any OS) box. Has anyone [that cares] emailed any of the XFree86 guys?? -- Brian [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.Awfulhak.orgbrian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make install failed on XFree86-4-client (with 6/10 -current)
I've been seing this problem for ages on my dev box, but it doesn't happen on other boxes. The problem is because the glxinfo program uses CCLINK to link, but it's a c++ program. Changing the CCLINK to CXXLINK works. I have no idea why there's no problem on some machines. On Mon, 17 Jun 2002 12:09:14 +0800, Ying-Chieh Liao wrote: make build all ok, but failed on install should I rebuild world first ? installing in programs/glxinfo... rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib /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)' *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs/glxinfo. *** Error code 1 -- self-producing in perl : $_=q(print\$_=q($_);eval;);eval; -- V Vinay -- Brian [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.Awfulhak.orgbrian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). Yes, the daddr_t backout has fixed the loader and the filesystem problems. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT and P-IV problems
On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote: Try disabling -pipe when building the compiler. This seems to make things more stable here (CFLAGS=-O in /etc/make.conf) - as if building the kernel with -pipe sometimes produces a kernel that subsequently murders the compiler with sig11/sig4 all the time. If so, then we have a bug in our pipe ('|', not 'gcc -pipe') implimentation. That would seem to be the case - assuming my hypothesis is correct - which is far from being a sure thing at this point. If things stay stable for the next week or so, I'll set the machine up to start doing parallel builds and see where we go from there... -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT and P-IV problems
Hi, Try disabling -pipe when building the compiler. This seems to make things more stable here (CFLAGS=-O in /etc/make.conf) - as if building the kernel with -pipe sometimes produces a kernel that subsequently murders the compiler with sig11/sig4 all the time. This is just marginally more than theory at the moment though. You may need to bootstrap a new kernel by building it on another machine to get things running again. Hi all, I experiment very strange problems here at the moment with a new server. Buildworld survives about 30 secondy, the errors are SIG4 (90%) and SIG11 (10%). And I cannot compile any important programs :-/ I've exchanged all relevant parts: - Power Supply: 300W, for PIV with additional CPU supply - CPU (PIV, 2Ghz, 512K cache) - Ram with ECC correction - Board (Intel D845BG) - SCSI Card. (it happens also on ATA) We have these boards running fine here. And now to the strange part. It does not happen with STABLE. This let's me beleave that this is a CURRENT problem. I'm really really pointless. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfilter not broken for me
On Sat, Apr 27, 2002 at 04:01:28PM +1000, Darren Reed wrote: In some email I received from Doug Barton, sie wrote: On Fri, 26 Apr 2002, Ruslan Ermilov wrote: =20 I tested this on i386 only with 2 days old -CURRENT (today's is broken due to the import of latest IPFilter suite) =20 I updated to the latest and greatest last night around midnight and built/installed -current just fine. What about the ipfilter import = is broken, and have you let Darren know? I haven't seen anything on the li= sts about it... =20 I have not received any email about it. I tested building all the ipfilt= er binaries and kernel after the import and came up clean. if ref5 was a bit quicker =20 That was probably a local problem on one of the Brian's fast machines where I initially attempted to finally test my patch (unsynched cvsup update?). Sorry for the false alarm, I can't check it right now anyway. Yes... I've had periods where the compiler drops cores all over the place, and other periods where things work fine. It's on a P4-1.7Ghz and has behaved like this since about last August. The only variable is the kernel - some kernels work and some don't. I've spent many 10s of hours trying to track it down, and I still have no idea what causes it - except that some kernels ``just work'' and some don't. Maybe it depends on the humidity in the room when a kernel is built or something - and I'm only half joking here ! FWIW ru, /boot/kernel/kernel seems ok now. /boot/kernel.sig/kernel isn't. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Revision 1.88 of kern_linker.c breaks module loading for diskless
In message [EMAIL PROTECTED], Harti Brandt write s: the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. Ah, that would explain a problem I saw recently on a netbooted box where kldload only worked with full module paths. Could `rootvnode' be checked for NULL instead? Hi, The intent is to discover whether there's a filesystem yet (vn_open() will die horribly otherwise). My use of rootdev is (obviously) flawed. AFAICT, either rootvp or rootvnode should be used, but I can't tell the difference between the two at a glance and am lacking development resources right now (my development box seems to enjoy dropping cores too frequently to build a kernel at the moment). If somebody could test that rootvnode or rootvp are non-NULL after an NFS-mounted root is set up, I'd thankfully approve the quick fix... :*) Cheers. Ian -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/usr.sbin/ppp Makefile async.c async.h atm.c bundle.c ccp.c ccp.h chap.c chap.h chat.c command.c datalink.c datalink.h defs.c defs.h ether.c exec.c i4b.c lcp.c lcp.h main.c mppe.c netgraph.c netgraph.h physical.c physical.h route.c tcp.c ...
Hello. brian 2002/03/30 04:30:11 PST Modified files: usr.sbin/ppp Makefile async.c async.h atm.c bundle.c ccp.c ccp.h chap.c chap.h chat.c command.c datalink.c datalink.h defs.c defs.h ether.c exec.c i4b.c lcp.c lcp.h main.c mppe.c physical.c physical.h route.c tcp.c tty.c udp.c : 1.126 +13 -17src/usr.sbin/ppp/bundle.c In the 6th chunk, a decrement to bundle.unit after succeeding ID0kldload() is lost. This results in the unit number of tun device set to 1(tun1) instead of 0(tun0) when if_tun.ko is not yet kldload'ed() before ppp is invoked. If I exit from ppp and start it again, ppp uses tun0, leaving tun1 behind. After that and receiving a few megabytes, I've experienced a mysterious panic (getnewvnode: free vnode isn't). The panic itself, though, is something similar to that I'm always seeing whenever I didn't kill pccardd before doing acpiconf -s3, so it might be unrelated to this issue. Anyway, a patch is attached. Regards. [.] Committed - thanks. I'd seen that it was doing this, but hadn't got around to tracking it down :*) I don't think the vnode thing is associated. That's probably a locking problem that jhb may (or may not) have fixed already. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mktime() doesn't fix deadzones...
Hi, I've cc'd -standards as I think this would be of interest there. IMHO the SQL code you quote in the PR should fail with an ``invalid time'' error. Personally I like the fact that mktime() returns -1 - it allows date's -v option to act sanely, although I must admit it was a PITA to get right. The really big question is, how can you ``fix'' mktime() ? If a value of 2002-4-7 2:0:0.0 becomes 2002-4-7 3:0:0.0 PDT, then you can deduce that 2 == 3 and go on to deduce other equally bizarre things Thinking about it makes my head hurt ! I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: segfault in getpwuid()?
Yes, I think I can ! I'll bet the binary in question is using libc.so.4 *AND* libc.so.5 because of a third library that has a libc.so.4 dependency. This confused me for quite some time with apache. for f in /usr/local/lib/*.so do objdump -x $f 2/dev/null | grep -q NEEDED.*libc.so.4 echo $f done Can anyone explain this to me? #0 0x286613cc in _ftello () from /usr/lib/libc.so.5 #1 0x28661358 in ftello () from /usr/lib/libc.so.5 #2 0x286612f6 in ftell () from /usr/lib/libc.so.5 #3 0x28678ef7 in .cerror () from /usr/lib/libc.so.5 #4 0x28676c9e in isatty () from /usr/lib/libc.so.5 #5 0x2865f621 in _nsyy_init_buffer () from /usr/lib/libc.so.5 #6 0x2865f577 in _nsyy_create_buffer () from /usr/lib/libc.so.5 #7 0x2865e9c3 in _nsyylex () from /usr/lib/libc.so.5 #8 0x28657680 in _nsyyparse () from /usr/lib/libc.so.5 #9 0x2865905d in _nsdbtget () from /usr/lib/libc.so.5 #10 0x286591dc in nsdispatch () from /usr/lib/libc.so.5 #11 0x2863085a in getpwuid () from /usr/lib/libc.so.5 #12 0x2814db0e in g_get_any_init () at gutils.c:539 #13 0x2814ddb9 in g_get_home_dir () at gutils.c:623 #14 0x2859bd97 in gnomelib_init () from /usr/X11R6/lib/libgnome.so.5 #15 0x282123bf in gnome_init_with_popt_table () from /usr/X11R6/lib/libgnomeui.so.5 #16 0x282124ae in gnome_init () from /usr/X11R6/lib/libgnomeui.so.5 #17 0x281765b5 in gnome_CORBA_init () from /usr/X11R6/lib/libgnorba.so.5 #18 0x805dddb in main () #19 0x8058ee5 in _start () A listing at #12: 534 # endif /* !HAVE_GETPWUID_R */ 535 536 if (!pw) 537 { 538 setpwent (); 539 pw = getpwuid (getuid ()); 540 endpwent (); 541 } 542 if (pw) 543 { (that's from glib12) This makes panel,gnome-session, etc all crash on start. -current as of this morning. -Seth -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). It's probably worth holding off for now and committing it after the 7 days. The 2 months between then and the DP2 release can shake out any problems it causes. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. If you're referring to the problems loading libpng.so (and probably other shared libraries), I can confirm that it's been fixed now. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPP Dial of External Modem Fails in 'Current'
I rebuilt 'Current' over the weekend with a make buildworld/install world and make buildkernel/install kernel and 'ppp -ddial papchap' gives the following error(s) when trying to dial an external modem: Warning set ifadr: Invalid command Warning set ifadr: Falied 1 Does anyone know what might be causing this ?? Sorry I'm a bit late in replying. The above command is ``set ifaddr'', not ``set ifadr'' :) Thanks, Glenn G. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
Hi, with rev 1.61 of in.c I4B directly hangs up after dialing out. At the moment I run a current kernel as of yesterday with a netinet directory as of today except for in.c (which is at rev 1.60 here) and everything works fine. Hi, Can you give me more details about the failure - error messages, your configuration, what you're using (sppp?), that sort of stuff ? The change makes the kernel fail attempts to add POINTOPOINT interfaces with conflicting IPv4 destination addresses. Are you in a situation where you're expecting this to be possible ? If so, can you explain more about why it's required ? Cheers. Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 06:35:49AM -0800, David Wolfskill wrote: Found this to be helpful after seeing: stage 2: cleaning up the object tree ... === usr.bin/tip .depend, line 886: Inconsistent operator for tip make: fatal errors encountered -- cannot continue and the tail end of /usr/obj/usr/src/usr.bin/tip/.depend (which was 886 lines long) was: /usr/obj/usr/src/i386/usr/include/errno.h \ /usr/obj/usr/src/i386/usr/include/limits.h \ /usr/obj/usr/src/i386/usr/include/sys/syslimits.h tip: /usr/obj/usr/src/i386/usr/lib/libc.a I don't use -DNOCLEAN or anything like that, so it looks as if forcibly removing the /usr/obj/usr/src/usr.bin/tip directory does something that the normal make buildworld does not... and which is useful in this case. Still building, but I'm way beyond that stage, at least. Cc:ing Warner, in case UPDATING might merit a brief mention. Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should work as well. And yes, mentioning this in UPDATING ASAP would be great. I don't think this is UPDATING material. People shouldn't be using -DNOCLEAN unless they understand the consequences. Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, 27 Nov 2001 18:03:45 +0200, Ruslan Ermilov wrote: | Did you do a component build without `make obj'? That would leave | turds, and I'm pretty sure the buildworld target doesn't repeat the | cleandir target. | | depend is included by make(1) automatically, before a cleandir | target has a chance to be executed. Try this: Oh, bummer. All the more reason to have one's nightly CURRENT builds preceded with a rm -rf /usr/obj. :-) A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than ``make buildworld'' anyway :*) Ciao, Sheldon. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 04:20:54PM +, Brian Somers wrote: A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than ``make buildworld'' anyway :*) Really? Is this recommended? Yes, except I meant ``rm -fr /usr/obj/*''. ==Michael Mad doc PR submitter Lucas -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsup-devel port build problem (pm3-base)
I sent John Polstra a similar patch some time ago Any news about getting this committed John (P) ? Hi, I ran into some problems building the cvsup-devel port. In one of it's dependants, the c file is attempting to include nfs/nfs.h which is nolonger valid. /usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4/RTHeapDepC.c As a quick fix I symlinked nfs.h - ../nfsclient/nfs.h which allowed the compile to complete. The following more generic/correct fix could probably be dropped into the files directory as patch-XX: --- RTHeapDepC.c.orig Mon Nov 19 00:27:30 2001 +++ RTHeapDepC.cMon Nov 19 00:28:21 2001 @@ -98,7 +98,11 @@ #include sys/time.h #include nfs/rpcv2.h #include nfs/nfsproto.h +#if __FreeBSD__ = 5 +#include nfsclient/nfs.h +#else #include nfs/nfs.h +#endif #include ufs/ufs/ufsmount.h #endif -John ps: I also ran into problems with libutil.h but I haven't determined where the actual problem is coming from. Copying /usr/src/lib/libutil/libutil.h to /usr/include avoids the immediate problem. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsup-devel port build problem (pm3-base)
John Polstra [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Brian Somers [EMAIL PROTECTED] wrote: I sent John Polstra a similar patch some time ago Any news about getting this committed John (P) ? There is already an open PR with a patch. I think Mark Murray is working on committing it. I don't have the systems needed to test it myself at the moment. Mark, any news on this ? FWIW, I've attached the patch that makes things work here. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org Index: patch-l1 === RCS file: /home/ncvs/ports/lang/pm3-base/files/patch-l1,v retrieving revision 1.1 diff -u -r1.1 patch-l1 --- patch-l121 Jul 2001 21:07:55 - 1.1 +++ patch-l111 Oct 2001 00:01:13 - @@ -1,6 +1,18 @@ libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c.old Thu Jun 1 02:54:33 2000 -+++ libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c Tue Jun 12 14:07:31 2001 -@@ -693,7 +693,9 @@ +--- libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c.orig Thu Oct 11 00:59:24 2001 libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c Thu Oct 11 01:00:50 2001 +@@ -98,7 +98,11 @@ + #include sys/time.h + #include nfs/rpcv2.h + #include nfs/nfsproto.h ++#if __FreeBSD_version = 500024 ++#include nfsclient/nfs.h ++#else + #include nfs/nfs.h ++#endif + #include ufs/ufs/ufsmount.h + #endif + +@@ -693,7 +697,9 @@ void *data; { int result; struct ufs_args *u_data; @@ -10,7 +22,7 @@ struct nfs_args *n_data; ENTER_CRITICAL; -@@ -704,11 +706,13 @@ +@@ -704,11 +710,13 @@ MAKE_READABLE(u_data); MAKE_READABLE(u_data-fspec); result = syscall(SYS_mount, type, dir, flags, data); Index: patch-l2 === RCS file: /home/ncvs/ports/lang/pm3-base/files/patch-l2,v retrieving revision 1.2 diff -u -r1.2 patch-l2 --- patch-l210 Sep 2001 21:37:26 - 1.2 +++ patch-l211 Oct 2001 00:04:58 - @@ -1,6 +1,18 @@ libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c.old Thu Jun 1 02:54:33 2000 -+++ libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c Tue Jun 12 14:07:31 2001 -@@ -693,7 +693,9 @@ +--- libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c.orig Wed May 31 18:54:24 +2000 libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.cThu Oct 11 00:29:03 2001 +@@ -98,7 +98,11 @@ + #include sys/time.h + #include nfs/rpcv2.h + #include nfs/nfsproto.h ++#if __FreeBSD_version = 500024 ++#include nfsclient/nfs.h ++#else + #include nfs/nfs.h ++#endif + #include ufs/ufs/ufsmount.h + #endif + +@@ -693,7 +697,9 @@ void *data; { int result; struct ufs_args *u_data; @@ -10,7 +22,7 @@ struct nfs_args *n_data; ENTER_CRITICAL; -@@ -704,11 +706,13 @@ +@@ -704,11 +710,13 @@ MAKE_READABLE(u_data); MAKE_READABLE(u_data-fspec); result = syscall(SYS_mount, type, dir, flags, data); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI panic at boot time in -current
Hi, I was wondering if anybody has any suggestions about why this might be happening in -current: Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x32f34 data=0xf9c+0x1028 syms=[0x4+0x49c0+0x4+0x61a]- Copyright (c) 1992-2001 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 #5: Wed Oct 10 06:33:14 BST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAK Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 97342057 Hz CPU: Pentium II/Pentium II Xeon/Celeron (97.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 201261056 (196544K bytes) avail memory = 191459328 (186972K bytes) Preloaded elf kernel /boot/kernel/kernel at 0xc043e000. Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc043e0a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc043e15c. Preloaded elf module /boot/kernel/acpi.ko at 0xc043e208. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc0354cc2 (122) VESA: MagicGraph 256 AV 48K Using $PIR table, 6 entries at 0xc00fdf60 npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcf0-0xfcff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller at device 7.2 on pci0 uhci0: Could not map ports device_probe_and_attach: uhci0 attach returned 6 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pci0: display, VGA at device 8.0 (no driver attached) pcm0: NeoMagic 256AV mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 pci0: serial bus, FireWire at device 9.0 (no driver attached) pccbb0: RF5C478 PCI-CardBus Bridge irq 0 at device 10.0 on pci0 pccbb0: PCI Memory allocated: 1000 acpi_pcib0: device is routed to IRQ 9 cardbus0: Cardbus bus (newcard) on pccbb0 pccard0: 16-bit PCCard bus on pccbb0 pccbb1: RF5C478 PCI-CardBus Bridge irq 0 at device 10.1 on pci0 pccbb1: PCI Memory allocated: 10001000 acpi_pcib0: possible interrupts: 9 panic: free: multiple freed item 0xc14f75f0 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db t Debugger(c02d159b) at Debugger+0x44 panic(c02d0031,c14f75f0,0,c14f75f0,c0460adc) at panic+0x70 free(c14f75f0,c0430ba0,c0460a6c,c041f218,c14f75f0) at free+0x197 AcpiOsFree(c14f75f0,1,c150be9c,c0460b2c,c14ef9c0) at AcpiOsFree+0x10 AcpiRsSetSrsMethodData(c14e57a0,c0460adc,c0460b64,c0427626,c14e57a0) at AcpiRsSetSrsMethodData+0xc4 AcpiSetCurrentResources(c14e57a0,c0460adc,c14d5188,c14f3c80,c14f9d88) at AcpiSetCurrentResources+0x2b acpi_pcib_route_interrupt(c14f3c80,c14f9d00,1) at acpi_pcib_route_interrupt+0x6a2 pci_alloc_resource(c14f8700,c14f9d00,1,c0460c0c,0) at pci_alloc_resource+0xa6 bus_alloc_resource(c14f9d00,1,c0460c0c,0,) at bus_alloc_resource+0x5d pccbb_attach(c14f9d00,c14f9d00,c14f3c80,c14f8700,0) at pccbb_attach+0x3d0 device_probe_and_attach(c14f9d00) at device_probe_and_attach+0x9a bus_generic_attach(c14f8700,c14f8700,c0cdb680,c14f4a40,1) at bus_generic_attach+0x16 device_probe_and_attach(c14f8700) at device_probe_and_attach+0x9a bus_generic_attach(c14f3c80,c14d5088,c0cdb680,c14f3c80,c0460c90) at bus_generic_attach+0x16 acpi_pcib_attach(c14f3c80,c14f3c80,c0cdb680,c0cdb680,0) at acpi_pcib_attach+0x189 device_probe_and_attach(c14f3c80) at device_probe_and_attach+0x9a bus_generic_attach(c0cdb680,c0cdb61c,c0cdb600,c0cd2560,c0460cf8) at bus_generic_attach+0x16 acpi_probe_children(c0cdb680,c14cd088,c0cdb880,c0cdb680,6) at acpi_probe_children+0x62 acpi_attach(c0cdb680,c0cdb680,c0cdb880,c0cdb880,1) at acpi_attach+0x1d5 device_probe_and_attach(c0cdb680) at device_probe_and_attach+0x9a bus_generic_attach(c0cdb880,c14a6088,c0cdbb80,c0460d5c,c01c2786) at bus_generic_attach+0x16 nexus_attach(c0cdb880,c0cdb880,c0cd8dc8,465000,1) at nexus_attach+0xe device_probe_and_attach(c0cdb880) at device_probe_and_attach+0x9a root_bus_configure(c0cdbb80,c02f07c0,0,4) at root_bus_configure+0x16 configure(0,45dc00,45d000,0,c0126aac) at configure+0x22 mi_startup() at mi_startup+0x90 begin() at begin+0x43 Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour !
Re: Anyone had luck with 3Com HomeConnect ADSL Modem Dual Link???
Hi... Has anyone on this list had any luck dealing with 3Com HomeConnect ADSL Modem Dual Link? I am stuck with this peace of hardware and please don't flame me ;) I connect the modem to an xl card sitting on the PC. I am running a fairly recent -CURRENT system. Here is my /etc/ppp/ppp.conf: [.] I have set net.graph.nonstandard_pppoe=1 You could try running ``tcpdump -i xl0 -e -l not ip'' to see if any of your traffic is being replied to (and to ensure it goes out with the dodgy header numbers). Any tips? tq... /john Live Free OR Die -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdio change, other libraries needs bumping too!
Andrey A. Chernov wrote: On Thu, Sep 20, 2001 at 18:32:57 +0400, Andrey A. Chernov wrote: After stdio changes 4.4 binaries linked with libtermcap/libcurses refuse to work: /usr/libexec/ld-elf.so.1: /usr/lib/libcurses.so: Undefined symbol __stdout p It is because compat 4.4 libc not have __stdoutp, which required by recompiled libtermcap/libncurses. It means that ncurses major (and probably some other) needs bumping. Please, fix. Here the list of libraries infected with new std{in,out,err}p pointer which major is not bumped yet, so 4.x binaries shared linked with them will not works: No, we added the hooks to RELENG_4 and tool the 4.4-RELEASE libc.so.4 and included it in compat4x before the change. Make sure you have COMPAT4X=yes in your /etc/make.conf and no bump is required. But this isn't the default. Thinking about this scares me. Am I right in saying that std{in,out,err} are now real symbols rather than being #defines to the __sF array an that the real symbols will *always* simply refer to the same memory as the __sF array through the life of libc.so.4 ? If that's the case, then that sounds reasonable. Otherwise I'm scared :*) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
More SIG4s during make world
Hi, Just a quick note to say that my -current box has started dropping cores during make world again. I have a kernel from August 11 that works ok, and had one from August 18 that was causing sig 4 at random places. I accidently overwrote my Aug 18 kernel.old, but Aug 25, 27 and 28 are still dropping cores all over the place. My machine config has changed slightly since this happened in May, It's now a P4/1.7GHz with 384Mb RAM. As before, I can give people access to the box if required - although unfortunately I haven't got enough room in swap for a kernel core any more (oops!) -- but that can be fixed if required. If anybody has any suggestions, I'd be glad to hear them, otherwise I'll try rolling the sources forward from the 11th to try to discover when the breakage occurred. Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: another panic (mix ppp and usb to taste)
As I was trying to let the Palm Pilot connect to my desktop through usb using PPP, I tried to run /usr/sbin/ppp -quiet -direct -nat /dev/ugen0 FWIW, that should be: /usr/sbin/ppp -quiet -direct -nat /dev/ugen0 as ppp -direct needs to be able to write to descriptor 0 too. I'll leave Nick to comment on the USB side of things :*) [.] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. Say for example that you do ``set ifaddr A B'' and then ``telnet X'' when the link is down. telnet does a connect(X), resulting in a local binding to address A with a destination address of X. ppp brings the link up and negotiates C -- D, but keeps A -- B on the interface. The initial ``telnet X'' packet (A -- X) can now be transmitted, but ppp's alias address is now C. It NATs the packet to C -- X and sends it out. X gets it and sends a packet back to C. Your ISP routes to C correctly and your ppp process unNATs it back to A. Thus your ``first connection'' works when in reality it should not. If you ``iface clear'' on linkup, ppp doesn't NAT the A -- X packet and X replies to A -- which your ISP (of course) can't route. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. That may be because most connections consist of a DNS lookup followed by the connect... but I'm not sure about that. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. It should work ok now. Adding an interface address only needs to special-case things when either the source or destination addresses conflict with ones that are already assigned to the interface. [.] -- Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
This is my fault. Charles gave me permission to change these files to a BSD license a while ago. It looks like I got it wrong :-/ I'll fix it now. I was doing some things in libalias when something caught my eye, $ cat alias.c /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */ /*- * Copyright (c) 2001 Charles Mott [EMAIL PROTECTED] * All rights reserved. * [snip usual BSD licence legalese and comments about the code.] This software is placed into the public domain with no restrictions on its distribution. This is contained in several files in there. This is a contradiction. Public domain software can't also have copyright notices and a bunch of license disclaimers. The BSD-style copyright header was added back in June. You can't just take something in the public domain and slap a copyright on it, but IANAL. Still, the comments in the code as written are self-contradictory. It can't have a BSD-license _and_ be public domain. And since again IANAL, I am not saying which needs to stay or which needs to go, but one of those statements does. -- Crist J. Clark [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
Check with Charles to see if he really wants to abandon copyright claims to his code, or whether he was really implying some really liberal open source license. With the BSD Copyright (only) he keeps the intellectual copyright on the original. That's what I've changed it to (as per his agreement). -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
+---[ Brian Somers ]-- | Check with Charles to see if he really wants to abandon copyright claims | to his code, or whether he was really implying some really liberal open source | license. | | With the BSD Copyright (only) he keeps the intellectual copyright on | the original. That's what I've changed it to (as per his agreement). Oh, I thought he put in the comment to the effect it was in the Public Domain, if you did that you're naughty! d8) If he did that, he probably needs to rethink it. He originally wrote it to say it was in the public domain. I asked him if he minded me making it a BSD license and he said ok only I didn't do the whole job :*) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Should developers run current ? (was: XDM and X)
I've cc'd freebsd-current here. This is a followup to a small thread on the UK user group list about the stability of -stable. Joe Karthauser [EMAIL PROTECTED] wrote: On Sat, Aug 04, 2001 at 02:42:44PM +0100, Nik Clayton wrote: =20 This hasn't suddenly changed in FreeBSD -- the -current/-stable branches have worked like this since at least the 2.x days. It's always been the case that if you're using FreeBSD in a production environment you should deploy any new version on to test machines first, and make sure that it works in your environment. =20 I agree. Over the years I've updated many production servers to -stable, and of course periodically things break, I remember having major difficulties when r caused regular panics :) On the otherhand the majority of changes to -stable are for subsystems and rarely affect the stability of the entire machine. For my uses that was sufficient. Something has changed. IMHO the developer base has been segregated in the last year, mainly due to the the part-real, part-perceived instability of -current. There now seem to be two categories of developer: o The developer that's too dumb/stupid/smart/proud/lazy to run -stable and will keep fighting any problems that turn up in -current. o The developer that's probably been hit by one of the nastier -current bugs in the past year and has decided (on quite practical grounds) that it's better to develop under -stable. I believe this to be a bad thing. Back in the old days -stable was reserved for bug fixes and some features/enhancements. ABI and API changes weren't allowed. When someone made a mistake, they got the same clout across the back of the head that they do now, but things didn't break that often because relatively less was MFC'd. Now, because people are actively developing on -stable, they really need to push their work back into -stable so that they don't have to manage local source trees, trees that become more and more fragile as time passes. Because of this, -stable is now pretty similar to the -current we had a couple of years ago something that breaks a bit now and again, but not to a major degree as things should really be shaken out to some extent before they're committed there. -stable is no longer a branch that you can follow with a production system -- it's too risky. To this end, the RELEASE branches have been created. The release branches kind of address the problem because what's merged into them is kept to a minimum and is controlled by a few individuals that will not bend it's charter. There are downfalls to this system though - namely that each minor release upgrade contains huge numbers of feature additions/enhancements, making it difficult for people to regression-test production systems. Personally, I believe that the developers that are now developing under -stable should simply be lured back onto -current. Doing this may be enough to make -stable stable again -- if developers have no big incentive or requirement to have their code in -stable, but just have the overheads of having to merge it and read the -stable list, it may tip the balance back towards how things worked before. I appreciate that there are a huge number of issues -- things such as -current carrying so many enhancements that a major release upgrade becomes an enormous task. I believe there should be a balance somewhere, and to get closer to that balance, we need to attract our developers back to -current. Joe -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /home: mount pending error: blocks 14 files 3
On Thu, 02 Aug 2001 10:42:29 +0100, Brian Somers wrote: If the error keeps turning up, I would guess that you have a 0 or empty fsck field in /etc/fstab and fsck -s therefore not fixing the problem. Nope. I have passno set for the filesystem on which I also see this. I used to have background fsck enabled, but I disabled it because of horrid unkillable fsck behaviour. Perhaps background fsck did something nasty to my filesystem that normal fsck isn't seeing? The soft-updates code stores two block counts and two file counts in the superblock so that df(1) can give sane answers for filesystems where soft-updates is enabled. fsck(8) fixes them up (and frees off the bitmaps etc) on my machines ok. Ciao, Sheldon. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /home: mount pending error: blocks 14 files 3
On 02-Aug-01 Sheldon Hearn wrote: On Thu, 02 Aug 2001 09:33:41 MST, John Baldwin wrote: I get these messages when I reboot or crash before the background fsck finishes sometimes. Sometimes I get them when the filesystems are clean, too. They always happen when the previous boot did a background fsck, however. Then you're not seeing the whole problem. :-) As I said, I'm not using background fsck any more and have had several fsck runs report the filesystem as clean since I turned it off. Hmm, any more. I didn't see them at all until I started using background fsck. *shrug* I get them all the time though myself. I thought they were a feature of background fsck. Perhaps they aren't. :( Maybe fsck is failing to clean your filesystem or something ? A boot -s followed by a successful fsck should get rid of them. I was seeing them at Usenix and mentioned it to Kirk. He explained their nature -- ie, you've just got some blocks and inodes marked in use that shouldn't be. Or maybe these numbers are the only thing corrupt about your fs so they're not being re-written after fsck finishes ??? Ciao, Sheldon. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
In message [EMAIL PROTECTED] Vincent Poy writes: : Somehow I always thought there were more than 50 people who are : really running current. We do stress test it though and it had : performed flawlessly over the past 8 years. Question though, does anyone : happen to know what the largest maxusers variable is that one can define : in the kernel config file? We have it at 512 but what's the highest : number people have used reliably? Thanks. I've had at least 50 different people talk to me about NEWCARD, which is only available in current... Sorry, they were all me. I figured I'd present a stronger case that way !!! Warner -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble with glob patch (ftp exploit)
In message [EMAIL PROTECTED], default013 - subscriptio ns writes: Hi, thanks for the tip, but I attempted the new instructions and got this error... It seemed like it went a bit farther but... [/usr/src/lib/libc]# make all install Warning: Object directory not changed from original /usr/src/lib/libc cc -pg -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBI NTERFACE_PRIVATE -DINET6 -DPOSIX_Mo cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/libc. [/usr/src/lib/libc]# cd /usr/src/libexec/ftpd [/usr/src/libexec/ftpd]# make all install Warning: Object directory not changed from original /usr/src/libexec/ftpd cc -O -pipe -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -I/us r/src/libexec/ftpd/../../contrib-cc cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/libexec/ftpd. Looks like some kind of hardware problem; memory, CPU, MB. Also make sure that your case is being sufficiently cooled and that the CPU fan is not plugged with dust. I'm not convinced that this is the problem - not with -current at the moment anyway. I have a machine here that's been seeing sig 11 quite a bit during buildworld recently. I get them regularly (almost always during a buildworld on an empty /usr/obj), but if I boot from a kernel from May 23, a full buildworld works fine -- every time. Note that this is with an identical compiler etc (just a reboot with an old kernel). I haven't tried to track the problem down because of the relatively long period after May 25 when nothing worked... Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Fri, 15 Jun 2001 23:33:07 +1000 (EST), Bruce Evans [EMAIL PROTECTED] said: Here's an example of a complication: what is the semantics of /tmp/foo/bar where foo is a symlink to ? I think the pathname resolves to /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't point anywhere. But this is at least consistent with the historic (pre-POSIX) behavior where the filename is equivalent to .. Your spell checker didn't seem to catch your mis-spelling of hysteric :I -GAWollman -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from May
A current world with a May 23 kernel works ok, so you may be lucky :) I get the following panic on a GENERIC kernel from around May 23: (copied by hand) /usr/src/sys/kern/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c:428 panic: sleeping process owns a mutext Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger() panic() propagate_priority() _mtx_lock_sleep() obreak() syscall() syscall_with_err_pushd() this looks a lot like... my system cvsupped around May 25 reliably causes a panic when I $ cp /cdrom/distfiles/somefiles /tmp I've written down the message from the debugger: /usr/src/sys/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c: 428 panic: sleeping process owns a mutex Debugger(panic) trace Debugger(...) panic() propagate_priority() _mtx_lock_sleep() ffs_write() vn_write() writev() syscall() syscall_with_err_pushed() from the current archives. What can I do get this thing through a make world? Would a recent kernel over the existing userland have any hope between then and now? Thanks. Chad -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPP modem dial is completely broken
With new PPP I can't dial to my provider anymore. Two variants: 1) PPP says Clearing choked output queue and connection stuck forever with carrier on. Nothing else happens. 2) PPP says Too many IPCP NAKs sent - abandoning negotiation and drop carrier forever without further redialing. About months old PPP works fine with the same config. Can you send me a copy of the LCP IPCP logs (``set log lcp ipcp phase'') ? Cheers. -- Andrey A. Chernov http://ache.pp.ru/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
I got the same results as you. It eventually worked when I copied the entry matching my card into /etc/pccard.conf and hard-wired the irq as the same as the pcic device (9 in my case): $ cat /etc/pccard.conf irq 9 card Lucent Technologies WaveLAN/IEEE config auto wi 9 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop With a ? instead of the 9 on the config line, I got an irq resource allocation failure. Go figure ! So the question remains.. where was I supposed to change the interrupt mentionned in the UPDATING entry.. if not in the pccard.conf, then where? I certainly get the 'hangs' mentionned as being a symptom of NOT doing it.. Warner? On Fri, 8 Jun 2001, Mike Smith wrote: On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote: kernel: pcic1: TI PCI-1225 PCI-CardBus Bridge irq 11 at device 4.1 on pci0 in pccard.conf I had irq 11 is this not what I was supposed to do? Sorry, I guess maybe this directive is counter-intuative. It supposed to be a list of the free irq's in the system for pccardd to use with inserted pccards when configuring them. Trying to use the irq that the cardbus bridge already has will definetly result in a resource allocation failure. Er, well, it shouldn't, and more to the point, in most modern laptops you *have* to share the two. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unrecognised CBCP packet [strange problems with ppp(8)]
I've had reports of this in the past. The other end is sending a ``code 5'' packet - something that doesn't appear in the spec :( ppp(8) just ignores these (emitting a warning), they shouldn't be causing any problems themselves (even if CBCP is actually being used). Try enabling IPCP logging. You may be having a problem at that level, or alternatively, perhaps the peer thinks you've already got a connection and is (rudely) dropping the connection because of that. Hi, I'm having strange problems with one of local dial-up providers: without any visible reasons from time to time I can't establish PPP connection during 20-30 minutes. Shortly after going into `Network' mode ppp(8) complains about `Unrecognised CBCP packet' and drops down line. Restarting ppp/machine/modem etc. doesn't help and provider's technical people have no idea what could be wrong. Attached please find piece of log, please let me know if any additional information would be necessary. -Maxim Phase: bundle: Authenticate Phase: deflink: his = PAP, mine = none Phase: Pap Output: sobomax1 Ppp ON vega Phase: Pap Input: SUCCESS () Phase: deflink: lcp - open Phase: bundle: Network PPp ON vega Warning: Unrecognised CBCP packet (code 5, length 4) PPp ON vega Phase: deflink: open - lcp Phase: bundle: Terminate ppp ON vega Phase: deflink: Carrier lost Phase: deflink: Disconnected! Phase: deflink: lcp - logout Phase: deflink: Disconnected! Phase: deflink: logout - hangup Phase: deflink: Connect time: 32 secs: 248 octets in, 235 octets out -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: softupdates related problem in -current
On Sun, May 27, 2001 at 10:18:43PM -0700, Doug Barton wrote: Another problem I'm having in -current right now is with softupdates. Wh= en the system panic'ed the first time, it came up ok and fsck'ed fine with no apparent loss of data. However, during the fsck it complained bitterly about my superblocks, and when it was done and the system booted, the softupdates attribute was missing from the filesystems that had it set.= =20 Yep, I've seen this too. I think this is related to the bogus ``corrupt first superblock'' message that forces a manual fsck (-b32 doesn't work, -Tufs:-b32 is required) two times out of three. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src UPDATING
In message Pine.BSF.4.31.0105290848330.514-10@nihil Michael Reifenberger writes: : Have you tried to start aviplay ( coming from ports/graphics/avifile ) or using : whine? Nope. vmware does the job too, and I believe star-office. Warner -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP **: sys/miscfs file systems moved
Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? It may also be worth mentioning that people should move /usr/include to (say) /usr/include.not before their next installworld and nuke /usr/include.not after it completes. Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ** HEADS UP **: sys/miscfs file systems moved
On Wed, May 23, 2001 at 12:52:40PM +0100, Brian Somers wrote: Dear -CURRENT users, Please note that: - FDESC, FIFO, NULL, PORTAL, PROC, UMAP and UNION file systems were repo-copied from sys/miscfs to sys/fs. - Renamed the following file systems and their modules: fdesc - fdescfs, portal - portalfs, union - unionfs. - Renamed corresponding kernel options: FDESC - FDESCFS, PORTAL - PORTALFS, UNION - UNIONFS. - Install header files for the above file systems. Warner, could you please add this to UPDATING? It may also be worth mentioning that people should move /usr/include to (say) /usr/include.not before their next installworld and nuke /usr/include.not after it completes. Why? Only new headers get installed, no old headers were withdrawn. Mea Culpa, I thought you had moved the installed /usr/include/?*fs files to /usr/include/fs/ Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck
This happens to me ``almost all the time'' on my dev box: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1a 25406382600 15113835%/ devfs110 100%/dev procfs 440 100%/proc /dev/ad0s1e 2540637 233731 0%/tmp /dev/ad1s2a 49623926424 430116 6%/var /dev/ad1s2e4466254 1448160 266079435%/usr /dev/ad0s1f 775487 392540 32090955%/usr/obj /dev/ad1s1a 10145116 5631076 370243260%/usr/ports/distfiles /dev/ad1s1e 10145116 4957632 437587653%/usr/audio /dev/ad1s1g4963030 3621790 94419879%/usr/packages /dev/ad1s1f 10145116 4790396 454311251%/cvs /dev/ad1s2f 330596761 30414901 0%/spare1 The interesting thing is that it always happens on /usr and /cvs and no other partitions. Both of these partitions have large directory hierarchies Also, FWIW it now takes nearly 30 minutes to fsck my laptop's disk (20Gb 5400rpm). That's not good Has anyone else been trying out the background fsck? Last night I was working on the ithread code some and managed to panic my laptop while ejecting a pccard. Anyways, the kernel ate itself while trying to flush its buffers and I ended up with a dirty filesystem. I rebooted and let fsck -p do its usual thing, except that it freaked out. The actual fsck of / proceeded fine (actual fs activity when I panic'd my machine was very low, so the filesystems weren't corrupted, just marked dirty). When it got to /usr and /var, however, fsck freaked out and claimed that the primary superblock didn't match the first alternate. At this point I first had a heart attack. Once I recovered from that, I attempted read-only mounts of /usr and /var which did succeed, except that each mount spewed out a message to the kernel console about losing x files and y blocks. Confident that my fs wasn't totally hosed after doing some ls's, I unmounted /usr and /var and ran a non-preen fsck on them, which insisted on using an alternate superblock, but otherwise proceeded fine (except that it seemed to take longer than usual). Once the fscks's finished, it seemed to be all ok. Is anyone else seeing any weird stuff like this? I've never had fsck complain about the superblocks after a crash before. df -t ufs Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a148823847175220162%/ /dev/ad0s2f 10191770 7052563 232386675%/usr /dev/ad0s2e 99183142547699516%/var mount -t ufs /dev/ad0s2a on / (ufs, local) /dev/ad0s2f on /usr (ufs, local) /dev/ad0s2e on /var (ufs, local) grep ufs /etc/fstab /dev/ad0s2a / ufs rw 1 1 /dev/ad0s2f /usrufs rw 2 2 /dev/ad0s2e /varufs rw 2 2 Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. It seems to be off now. :( -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Ta. On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev tree with an average of 1+epsilon files per directory is even worse than a /sys/dev tree with an average of about 3 files per directory (not counting 4 CVS files per directory). ppbus actually installs a lot of kernel-only headers so /sys/dev/ppbus is not all that small. Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Well, now we know what it shouldn't be :*0 I've created /usr/include/dev/digi/digiio.h pending any better suggestions. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Where to put include files (was: cvs commit: src Makefile.inc1)
Most headers that define ioctls are in sys. I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Might I guess it should probably be called /usr/include/sys/io[ctl], and digiio.h put there. Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd spell digiio.h /usr/include/sys/digi_io.h. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
[cc'd to -arch and not to cvs-committers] For anyone that's reading -arch and hasn't seen this on -current, the thread is discussing userland sources that have -I../../sys in their Makefile and then #include sys/dev/blahio.h. I think everyone agrees that these headers should be made public, the question is ``where to put them ?''. Warner wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). The SHARED variable in src/include/Makefile makes this side of things tricky too - we've got to be careful that we either keep our sources together and maintain a resemblance of the hierarchy in /usr/include or split our sources. When I was working on Solaris I found it better to have the *io.h files in sys (separate from the driver) as it made it very clear that it was a public interface - the driver lived somewhere that just got built into a module and wasn't seen by the outside world. So I think I'd tend to vote (FWIW) for moving digiio.h (and other similar things) out of sys/dev/drivername/ and into sys/sys/. Comments ? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, 16 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give sys includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like sys/user.h being out of date, and sometimes helps mainly for headers like sys/user.h which declare system structures that are groped in by userland. But it is just a bug in general. I have -I../../sys in src/usr.sbin/digictl/Makefile. I put it there because the digi ioctl interface header isn't actually installed anywhere. There's no good reason for this except that I couldn't think of a good place (/usr/include/sys/digi/ ?). I cribbed the idea from the vinum(8) build. How should this be done - and where should I install digiio.h if that's what's required ? Cheers. Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Huh??!? xterm: Error 14, errno 2: No such file or directory
This makes xterm work again. Any objections to a commit ? David Wolfskill wrote: Built -CURRENT rebooted after mergemaster as usual, and some X applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to a non-X login, logged in , set DISPLAY to m147:0.0, issued xterm , and got an xterm OK. Known problem. phk changed the semantics of /dev/tty in the most recent commits. Traditional behavior for a process *without* a controlling tty when it opens /dev/tty is to get ENXIO. Formerly, ctty_open() returns ENXIO: cttyopen(dev, flag, mode, p) { struct vnode *ttyvp = cttyvp(p); if (ttyvp == NULL) return (ENXIO); ... and now: ctty_clone(void *arg, char *name, int namelen, dev_t *dev) { struct vnode *vp; if (*dev != NODEV) return; if (strcmp(name, tty)) return; vp = cttyvp(curproc); if (vp == NULL) return; here, leads to ENOENT. *dev = vp-v_rdev; } There used to be a device for the ctty. We still maintain it for the non-devfs case. The following hack may work, I have not tested or even compiled it: Index: kern/tty_tty.c === RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v retrieving revision 1.34 diff -u -r1.34 tty_tty.c --- tty_tty.c 2001/05/14 08:22:56 1.34 +++ tty_tty.c 2001/05/15 08:30:17 @@ -177,6 +177,8 @@ static void ctty_clone __P((void *arg, char *name, int namelen, dev_t *dev)); +static dev_t ctty; + static void ctty_clone(void *arg, char *name, int namelen, dev_t *dev) { @@ -187,9 +189,11 @@ if (strcmp(name, tty)) return; vp = cttyvp(curproc); - if (vp == NULL) - return; - *dev = vp-v_rdev; + if (vp == NULL) { + if (ctty) + *dev = ctty; + } else + *dev = vp-v_rdev; } @@ -201,6 +205,7 @@ if (devfs_present) { EVENTHANDLER_REGISTER(dev_clone, ctty_clone, 0, 1000); + ctty = make_dev(ctty_cdevsw, 0, 0, 0, 0666, ctty); } else { make_dev(ctty_cdevsw, 0, 0, 0, 0666, tty); } This hack recreates a /dev/ctty hook that works the old way, and makes /dev/tty switch through to that one instead. This is evil and is probably even more broken than before, but I think it will work. The alternative is to edit the XFree86 xterm source and rebuild it. look for xc/programs/xterm/main.c where it opens /dev/tty and then checks an inclusive list of errno's, including ENXIO and ENODEV etc. Add ENOENT to the list of 'acceptable' errors. Incidently, the xterm binary is broken, it does not use libutil/openpty(). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Huh??!? xterm: Error 14, errno 2: No such file or directory
Have you got v1.23 of sys/fs/devfs/devfs_vnops.c and are you running as non-root ? On Tue, May 15, 2001 at 01:34:27AM -0700, Peter Wemm wrote: David Wolfskill wrote: Built -CURRENT rebooted after mergemaster as usual, and some X applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to a non-X login, logged in , set DISPLAY to m147:0.0, issued xterm , and got an xterm OK. Known problem. phk changed the semantics of /dev/tty in the most recent commits. Traditional behavior for a process *without* a controlling tty when it opens /dev/tty is to get ENXIO. I am confused now. I have just finished building and installing world and kernel from top-of-the-tree sources: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #42: Tue May 15 18 :32:49 CEST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX i386 and I am (for the first time ever) a proud owner of a devfs-powered FreeBSD system. So far things are looking A-OK. Having read about all the trouble people were having with xterms, I grew a bit anxious and fired up X. It crashed because the config file contained /dev/mouse and that node no longer exists, but of course correcting it to /dev/sysmouse made things work. Then... I proceeded to open an xterm... and it opened! Just right-clicked the root window and chose xterm form the popup menu and it worked without any patch... although I am confident I do have the latest of phk-s commits and I am running on a new kernel... I am using XFree-3.3.6 and olvwm if that at all counts... of course I am happy to see no problems but why are others seeing them? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Mon, 7 May 2001 10:18:38 -0700 [EMAIL PROTECTED] wrote: Lets try another realistic example: cp -uvp ab* cde*.f* g? h/*.i? j/kl /m What's the find | cpio invocation for that? When you come up with it, it echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ... Messy - No, Portable - Yes. BT - wrong. cp flattens the hierarchy, cpio does not. I think this was a trick question :*P -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
On Mon, Apr 23, 2001 at 11:33:24AM -0700, John W. De Boskey wrote: After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. I thought people generally agreed the right fix was to add functionality to `xargs', not `cp' as you aren't scratching the general itch. In fact, I think enough people disagreed that xargs(1) should be modified as it can be done with scripts. Personally, I'd prefer Dima's xargs(1) fix. -- -- David ([EMAIL PROTECTED]) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
[.] The xargs weenies have also offered an explicit patch that could be tried, but that patch is being ignored by you. It is not a matter of talking ourselves to death, it's a matter that we're looking for feedback from anyone who wants to respond to the proposed xargs changes. If you need an immediate fix, I'll be happy to change Dimi's patch to use a different letter, and commit the change later tonight. We'll forget this ask for input stage, if Jordan really finds it so bothersome. To be fair to Jordan, I don't think this is aimed at the individuals, but more at the discussion that was filling his mail box... Let's not take a shouldn't-have-been-quoted email out of context eh ? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
It is inconceivable that the proposed patch to 'xargs' would increase your running time. I don't mean the standard '-I' change, which would certainly destroy performance, but the proposed patch to 'xargs' which solves your specific problem in a general way. I'm still curious as to why you think the proposed change to xargs will cause you ANY performance problem. I simply can not imagine where you would get a performance problem from the -Y idea (though I'm still tempted to change the letter for that proposed option). I suspect that the bulk of the readers of this thread weren't paying attention. To summarise, the actual patch that Dima wrote made blah | xargs -Y {} cp {} somedir work as expected, replacing {} with as much of stdin as will fit. It was then suggested that #! /bin/sh cmd=$1 last=$2 shift 2 exec $cmd $@ $last would solve the problem and the only argument against it was that ENV could corrupt the script and induce an E2BIG. I didn't consider that argument strong enough, so I stepped out - that's why I'm not writing this email. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
No rain here, it is ARG_MAX - 2048: -s size Set the maximum number of bytes for the command line length pro- vided to utility. The sum of the length of the utility name and the arguments passed to utility (including NULL terminators) will be less than or equal to this number. The current default value for size is ARG_MAX - 2048. 2K would be a pretty big env, root default std is about 367 bytes. Ok, I'll stop arguing. I guess I have to agree that you can script around the problem if you're careful. FWIW, the above is really ARG_MAX - 4k (the documentation is wrong - I recently updated xargs.1 in -current) and this seems to be *exactly* the right threshold. Take a look at the commit message with that xargs.1 commit... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Rodney W. Grimes [EMAIL PROTECTED] wrote: Before anyone starts writing scripts, consider that {} will be replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the stuff coming off the pipe. If your combined arguments plus environment exceeds ARG_MAX execve(2) will give you E2BIG. No rain here, it is ARG_MAX - 2048: -s size Set the maximum number of bytes for the command line length pro- vided to utility. The sum of the length of the utility name and the arguments passed to utility (including NULL terminators) will be less than or equal to this number. The current default value for size is ARG_MAX - 2048. 2K would be a pretty big env, root default std is about 367 bytes. Yes, that is probably not a portable assumption to make, but it is far better than using non-standard options to xargs. If I'm not mistaken, the size of the environment is already taken into account by the xargs utility (subtracted from ARG_MAX). So this isn't an issue at all. Unless xargs runs a command with lots of arguments and that command increases the environment size then tries to run another command with the same arguments - bang (E2BIG). Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote: Sorry for butting in. Adding new non-portable functionality to solve the problem which could be adequitely taken care of using existing and well known techniquies is not appropriate, I completely agree with you on that. And I'm still waiting to see those well known techniques. Attached small script should solve this problem and doesn't require introducing incompatible option in the standard tool. For example: find /usr/src -type f | xargs larg cp targetdir For speed purposes it could be implemented in raw C. -Maxim #!/bin/sh if [ ${#} -le 2 ]; then echo "Usage: larg command lastarg arg1 [arg2 ...]" exit 0 ^ oops :-) fi COMMAND=${1} LASTARG=${2} shift 2 exec ${COMMAND} "${@}" "${LASTARG}" Yes, I think this will work as long as your environment isn't polluted by something like $ENV (any increase in the environment size will effect xargs's calculation of how many arguments will fit on the command line). Of course I still prefer the xargs fix - as you said above, it'd be nicer in C :-) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: cp -d dir patch for review (or 'xargs'?)
On Sun, 22 Apr 2001 13:16:31 +0100, Brian Somers wrote: On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote: Sorry for butting in. Adding new non-portable functionality to solve the problem which could be adequitely taken care of using existing and well known techniquies is not appropriate, I completely agree with you on that. And I'm still waiting to see those well known techniques. Attached small script should solve this problem and doesn't require introducing incompatible option in the standard tool. For example: find /usr/src -type f | xargs larg cp targetdir For speed purposes it could be implemented in raw C. -Maxim #!/bin/sh if [ ${#} -le 2 ]; then echo "Usage: larg command lastarg arg1 [arg2 ...]" exit 0 ^ oops :-) fi COMMAND=${1} LASTARG=${2} shift 2 exec ${COMMAND} "${@}" "${LASTARG}" Yes, I think this will work as long as your environment isn't polluted by something like $ENV (any increase in the environment size will effect xargs's calculation of how many arguments will fit on the command line). I don't see why it matters. The only thing that matters here is number of args accepted by the shell. Anyway this is a 2-minute prototype... ;) As you can see, the problem in fact could be easily solved using "well known techniques". Of course I still prefer the xargs fix - as you said above, it'd be nicer in C :-) I still don't see why it couldn't be an separate tool (perhaps more general that my prototype). I don't see that such a tool would be used without xargs, whereas users of xargs often want/expect this sort of facility - or so I believe. -Maxim -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote: (cat bigfilelist; echo destdir) | xargs cp I like this version of the patch!! It's much much cleaner than hacking up cp or xargs, it even follows the unix principle of using simple tools and glueing them togeather to do bigger jobs, is unix implementation independent, and is very clear in what it does. It's clean, simple, and unfortunately, totally bogus. Try: echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo Now consider what would happen with the above suggested construct with a very long file list. bleck... try this for your sample: $ (echo 1 2 3 4 5 6 7 8 9 | xargs -n 4) | while read x; do echo -n $x; echo " dst" done 1 2 3 4 dst 5 6 7 8 dst 9 dst $ I don't see a problem with adding an option to cp to treat the first argument as the target instead of the last argument. It's a simple solution, the code change is simple, and it produces the exact desired result. What's the problem? It's yet another non-portable option. I hate to appear rude, but has anybody in this discussion actually used xargs for what it's meant to be used ? How do you do this in a script: cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/. Before anyone starts writing scripts, consider that {} will be replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the stuff coming off the pipe. If your combined arguments plus environment exceeds ARG_MAX execve(2) will give you E2BIG. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote: How do you do this in a script: cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/. for i in `find /path/to/source -type f`; do cp $i /path/to/dest/ done What's all the fuss about? Have you tried that for values of /path/to/source with lots of files ? Something like find blah | while read i; do cp $i /dest/.; done is better, but it runs cp too many times. Ciao, Sheldon. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
So we have two problems: 1) Calling cp(1) repetitively is inefficient. 2) The argument list is too big for cp(1). Extending cp(1) will not solve (2). Extending xargs(1) will solve both. So why is an extension to cp(1) being proposed? I wasn't proposing that cp should be changed - I don't think it should. I'm just guilty of using a stale subject line :-/ Ciao, Sheldon. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
I looked at your patches and immediately thought ``these patches can't be right'' as I was expecting it to deal with things such as xargs -I [] echo args are [], duplicated are [] I'm also dubious about the patches working for large volumes on standard input. At this point I scrapped the email I was composing 'cos I didn't have time to look into it further :-/ I think it's important to test any patches with a large number of large path names as input - so that ARG_MAX is reached before the 5000 argument limit and we can see that we don't end up getting E2BIG because of an accidental overflow/miscalculation. Sorry I don't have more time to spend on it :-/ I don't have a copy of SuSv2 or anything else that defines -I and -i, but from what I can gather, -i is the same as "-I {}" and -I allows things like this: dima@spike% ./xargs -I [] echo CMD LINE [] ARGS test CMD LINE this is the contents of the test file ARGS dima@spike% ./xargs -I [] echo CMD [] LINE ARGS test CMD this is the contents of the test file LINE ARGS dima@spike% ./xargs -I [] echo [] CMD LINE ARGS test this is the contents of the test file CMD LINE ARGS Does that mean everyone is blind and missed my arrogant cross-post of the amazingly short patch to do this, or are we just interested in discussing it and not testing the implementation? ;-) FWIW, I'm not sure the patch is entirely correct; xargs' processing of this stuff looks like black magic. It works, but I'm not sure if I failed to cater to some other weird assumptions it makes. This is why it'd help if someone would at least look at it. Thanks, Dima Dorfman [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Putting that option into cp seems rather GNUish to me, but not very UNIXish. :-) Yes. I think most people agree that changing cp is not good. Just my 2 Euro cents. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Dima Dorfman [EMAIL PROTECTED] wrote: I don't have a copy of SuSv2 or anything else that defines -I and -i, http://www.secnetix.de/~olli/susv2/xcu/xargs.html but from what I can gather, -i is the same as "-I {}" and -I allows things like this: Not exactly. The difference is that the option-argument to -i is optional and -- if present -- has to follow without whitespace after the -i. This is a violation of the common utility syntax guidelines, but has been adopted by SUSv2 because it was widely implemented. So ``-i'' is the same as ``-I {}'', and ``-i[]'' (no space!) is the same as ``-I []''. I don't think we should adopt these semantics. I'm coming around to Dima's -Y option - which must have an argument. Unfortunately, when you use -i or -I, then each line from stdin is used as a signle argument, and the utility is invoked once for every line, unless I misunderstand what SUSv2 is saying. :-( I guess that settles it then. This is a dumb restriction and doesn't seem to fit in very well with how xargs works. Again, Dima's idea is IMHO superior. But as I said in my other follow-up, I'm not convinced that the patch deals with ARG_MAX overflows properly (I may be wrong though). -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Garance A Drosihn [EMAIL PROTECTED] writes: Or maybe something to indicate where the list of arguments should go in a command. Hrm. Let's say '-Y replstr' or '-y[replstr]' (no blank after -y). If no [replstr] is given on -y, it defaults to the two characters '[]'. Then one might do: cat big_file_list | xargs -y cp [] target_directory This is a great idea! I'm willing to implement it if nobody else wants to. If you add this (which I think is a good idea), please make it option free with {} as the default arglist and -i to override that string in line with sysv's xargs: find something | xargs cp {} target_directory or find something | xargs -i '[]' cp '[]' target_directory Although it's possible to break something that uses a literal {} as an argument, I think this is better than introducing semantics that'll confuse people. Dima Dorfman [EMAIL PROTECTED] Cheers. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysctl optimisations (was: Filesystem gets a huge performance boost)
OK... this brings up the question of what other cool optimizations are there that may have been disabled in the past for reasons that are no longer pertinent? It might be worthwhile to create an /etc/sysctl.conf file with commented out examples of configurations for various systems. For example, # For more modern systems that have a reasonable amount of RAM #vfs.vmiodirenable=1 # Low memory systems # Systems that need lots of randomness # Low resource systems that need less randomness # Super high performance TCP options for various situations etc. I'm sure y'all can come up with more. It might also be desirable to put these in etc/defautls/rc.conf, but I think something of this nature might be better suited in a freer format. I would have thought a bunch of comments in /etc/sysctl.conf would be sufficient. Doug -- Perhaps the greatest damage the American system of education has done to its children is to teach them that their opinions are relevant simply because they are their opinions. Do YOU Yahoo!? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
[.] The second improvement, contributed by [EMAIL PROTECTED], is a new directory allocation policy (codenamed "dirpref"). Coupled with soft updates, the new dirpref code offers up to a 60x speed increase in gluk's tests, documented here:" http://groups.google.com/groups?q=dirprefnum=100hl=enlr=safe=offrnum=2seld=905073910ic=1 I do like the dirpref stuff, but I can't comment much on it except that it looks like a good change that should be fairly easy to bring into FreeBSD. I'm not 100% convinced about the algorithm to avoid clusters filling up with directory-only entries (it looks like a worst-case would fill a cluster with 50% directories and 50% files leaving a bad layout when the directories are populated further), but then the non-dirpref scheme has some far worse worst-case scenarios ;-) Just to follow up on myself... it seems the dirpref stuff was committed to FreeBSD this morning :-] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
Why VMIO dir works better if directories are placed close to each other? I think it only makes the cache data of an individual directory stay in the memory longer. Is there a way to measure the effectiveness of the disk drive's cache? The real performance gain is seen when doing stuff with large directory hierarchies such as /usr/ports or (I think) a squid cache. The close proximity of the directories means they can be read/written far more quickly than before (where they were specifically placed in different clusters). -Zhihui -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
Another important change is that it is no longer necessary to run tunefs in single user mode to activate soft updates. All that is needed is to add the "softdep" mount option to the partitions you want soft updates enabled on in /etc/fstab." [.] I especially like not having to run tunefs :-) [.] Having the softdep option in fstab(5) doesn't gel well with the recent background-fsck work being introduced by Kirk - although it works from what I can tell. In both OpenBSD and NetBSD, a filesystem mounted with the ``softdep'' option will update the super-block flags with the FS_DOSOFTDEP bit, so it's easy for fsck(8) to tell how an unclean filesystem was last mounted. In fact, OpenBSD has ``if 0''d code that allows unclean filesystem mounts if they have that FS_DOSOFTDEP bit set (NetBSD doesn't seem to have this). The problem I think is where a ``mount -u'' is done to downgrade a filesystem from soft-udpates to no soft-updates. Both OpenBSD and NetBSD have comments to the effect /* * Flush soft dependencies if disabling it via an update * mount. This may leave some items to be processed, * so don't do this yet XXX. */ and both ignore the problem (leaving soft-updates set). I don't think there's a satisfactory way of doing this - in much the same way as downgrading a read-write filesystem to read-only doesn't quite work. If certain operations are in effect (like a background fsck in the first instance or a reference is held to a file with a zero link count in the second), all hell can break loose. Having said all that, I quite like the softdep option in OpenBSD NetBSD, despite it only being a half-option :-) The second improvement, contributed by [EMAIL PROTECTED], is a new directory allocation policy (codenamed "dirpref"). Coupled with soft updates, the new dirpref code offers up to a 60x speed increase in gluk's tests, documented here:" http://groups.google.com/groups?q=dirprefnum=100hl=enlr=safe=offrnum=2seld=905073910ic=1 I do like the dirpref stuff, but I can't comment much on it except that it looks like a good change that should be fairly easy to bring into FreeBSD. I'm not 100% convinced about the algorithm to avoid clusters filling up with directory-only entries (it looks like a worst-case would fill a cluster with 50% directories and 50% files leaving a bad layout when the directories are populated further), but then the non-dirpref scheme has some far worse worst-case scenarios ;-) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release broken in telnetd
Hi, I'm not convinced that the patch will help. It looks like the error is because it's using the ppp.lo that was built with crypto support but without the mppe bits. Maybe other objects (such as ccp.o in this case - which seems to be built with HAVE_DES and therefore includes MPPEAlgorithm in it's struct ccp_algorithm) aren't being rebuilt ? Maybe the make clean isn't cleaning ccp.o etc ? Hi! This was tricky. Due to the old bug in release/Makefile (it did not pass -DRELEASE_CRUNCH when building list of object files for crunched binary), ${OBJS} list for ppp was computed incorrectly, and ppp/Makefile had a special glue to build empty object files: : .if defined(RELEASE_CRUNCH) : # We must create these objects because crunchgen will link them, : # and we don't want any unused symbols to spoil the final link. : CFLAGS+=-DNONAT -DNORADIUS -DNOI4B -DNOSUID : OBJS+= chap_ms.o mppe.o id.o nat_cmd.o radius.o : chap_ms.o mppe.o id.o nat_cmd.o radius.o: : null_${.PREFIX}.c : cc -c -o ${.TARGET} null_${.PREFIX}.c : .endif Recall that release/Makefile executes `make subclean all' against the crunchgen(1) generated .mk file. Previously, `subclean' was executed with the -DRELEASE_CRUNCH; this removed chap_ms.o, and subsequent `make all' had a chance to build chap_ms.o from the stub rule above: : # make -n -DRELEASE_CRUNCH chap_ms.o : null_chap_ms.c : cc -c -o chap_ms.o null_chap_ms.c Now that -DRELEASE_CRUNCH is moved to crunchgen(1) .conf files (recall that I needed this so that ${OBJS} are computed correctly for telnet/Makefile), ppp/Makefile got broken. `subclean' does not cleans chap_ms.o, and subsequent `make all' considers it up-to-date. The attached patch should fix this. Please let me know... Actually, I have just committed a fix to crunchgen(1) so that it runs `make clean' with the ${BUILDOPTS}, to avoid possible failures in the future. This fix alone should be enough to fix the broken `make release', but please test with the attached patch too. : ru 2001/03/30 00:04:25 PST : : Modified files: : usr.sbin/crunch/crunchgen crunchgen.c : Log: : `buildopts' may affect the selection of object files. : Make sure we pass $(BUILDOPTS) to the `clean' target : so that `make clean' works on the same set of object : files. Otherwise, we may end up with an incorrectly : built and up-to-date object file. : : Revision ChangesPath : 1.26 +2 -2 src/usr.sbin/crunch/crunchgen/crunchgen.c On Thu, Mar 29, 2001 at 07:10:57PM +0200, John Hay wrote: Hi Ruslan, Could you please try the attached patch and let me know? I had to move -DRELEASE_CRUNCH to *_fixit.conf so that ${OBJS} are computed correctly for usr.bin/telnet. I have tried it, but now it breaks in boot_crunch: ## cc -O -pipe-DCRUNCHED_BINARY -c tunefs_stub.c ld -dc -r -o tunefs.lo tunefs_stub.o /usr/obj//usr/src/sbin/tunefs/tunefs.o crunchide -k _crunched_tunefs_stub tunefs.lo cc -static -o boot_crunch boot_crunch.o sh.lo find.lo sed.lo test.lo rm.lo pwd.l o ppp.lo sysinstall.lo newfs.lo minigzip.lo cpio.lo fsck.lo ifconfig.lo route.lo slattach.lo mount_nfs.lo dhclient.lo arp.lo hostname.lo rtsol.lo pccardc.lo pcc ardd.lo usbd.lo usbdevs.lo tunefs.lo -ll -ledit -lutil -lkvm -lmd -lcrypt -lftpi o -lz -lnetgraph -ldialog -lncurses -lmytinfo -ldisk -lipx ppp.lo: In function `MakeKey': ppp.lo(.text+0xfe): undefined reference to `des_set_odd_parity' ppp.lo: In function `DesEncrypt': ppp.lo(.text+0x142): undefined reference to `des_set_key' ppp.lo(.text+0x14f): undefined reference to `des_ecb_encrypt' ppp.lo: In function `MPPEKeyChange': ppp.lo(.text+0x7b6): undefined reference to `RC4_set_key' ppp.lo(.text+0x7ca): undefined reference to `RC4' ppp.lo: In function `MPPEOutput': ppp.lo(.text+0x85b): undefined reference to `RC4_set_key' ppp.lo(.text+0x898): undefined reference to `RC4' ppp.lo(.text+0x8bd): undefined reference to `RC4' ppp.lo: In function `MPPEInput': ppp.lo(.text+0x9f7): undefined reference to `RC4_set_key' ppp.lo(.text+0xa18): undefined reference to `RC4' ppp.lo(.text+0xa4e): undefined reference to `RC4' *** Error code 1 Stop in /usr/src/release/boot_crunch. *** Error code 1 ... ### -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
On Sun, Mar 25, 2001 at 02:46:22AM +0100, Brian Somers wrote: On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote: 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). Here, ppp configures the interface as soon as it sees the ``set ifaddr'' line and never undoes that configuration. An ``add'' with a fixed IP number would never have worked if it's before the ``set ifaddr''. If it's after the ``set ifaddr'', nothing should ever remove it (as the interface will stay configured). 2. Ppp is not in -auto mode. Here, ppp won't assign the interface address 'till IPCP is up. Any attempt to ``add'' a route with a static IP number in ppp.conf should fail. So, the recent routing changes shouldn't have made a difference. Anyone know what I'm missing ? Andre, what does your ppp.conf look like and how are you running ppp ? ppp in -auto mode, "add" is after "set ifaddr" In which case your interface should stay configured despite the link coming down and your route should *not* be deleted. I'll see if I can reproduce this here (I need to upgrade a machine first). This was happening because ppp was deleting then re-adding the interface address when IPCP came up, causing the new routing code to nuke the static route. I've added an optimisation to stop this from happening, so your configuration should work ok again with src/usr.sbin/ppp/iface.c 1.17. You mean, ppp(8) does not do this now if negotiated address does not change? Yep. -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote: 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). Here, ppp configures the interface as soon as it sees the ``set ifaddr'' line and never undoes that configuration. An ``add'' with a fixed IP number would never have worked if it's before the ``set ifaddr''. If it's after the ``set ifaddr'', nothing should ever remove it (as the interface will stay configured). 2. Ppp is not in -auto mode. Here, ppp won't assign the interface address 'till IPCP is up. Any attempt to ``add'' a route with a static IP number in ppp.conf should fail. So, the recent routing changes shouldn't have made a difference. Anyone know what I'm missing ? Andre, what does your ppp.conf look like and how are you running ppp ? ppp in -auto mode, "add" is after "set ifaddr" In which case your interface should stay configured despite the link coming down and your route should *not* be deleted. I'll see if I can reproduce this here (I need to upgrade a machine first). This was happening because ppp was deleting then re-adding the interface address when IPCP came up, causing the new routing code to nuke the static route. I've added an optimisation to stop this from happening, so your configuration should work ok again with src/usr.sbin/ppp/iface.c 1.17. -- Andrey A. Chernov http://ache.pp.ru/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with tun device and trafshow/tcpdump?
I found this message in one of my inboxs - I forgot to reply :*) I believe this was fixed last October (at BSDCon)... can you confirm ? Hi everyone. Ok apologies first to anyone who has been asked this question before, I've searched the mail lists and cannot find anything like this recently. The problem is when using user ppp and some kind of traffic monitor program like trafshow or tcpdump. There are three problems I've noticed: 1, When using trafshow there's no incoming packets seen at all. 2, When using tcpdump or trafshow there's no name resolution on any packets shown. 3, When using tcpdump, incoming packets can been seen on the tun device, except incoming icmp. Can anyone suggest a fix for this? I was also told that 4.0-RELEASE is affected by this. Thanks for your time. Steve. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
Do you mean that "add" PPP command now intentionally broken for any address excepting *ADDR? Then, what is the reason to have numeric argument there? Or do you mean that PPP must be fixed now? Where is the fix? I mean that: 1. If you use HISADDR, ppp(8) will automatically re-add route after link is brought down and then back up. 2. If you use static IP address in ppp.conf, ppp(8) will add that route only once. This route will also cache local interface address at the time the route is added. Execute `route -vn get default' to see what I am talking about. 3. The routing code was fixed to delete routes which use non-existent interface addresses. This code will wipe such a route. 4. If you need routes with static gateway addresses, put `add!' command to ppp.linkup script. This way, routes will be activated every time the link is up, and will use the correct source IP address. 5. This affects not only ppp(8). Add default route that points to the LAN; change the IP address on interface; observe that the default route has gone away. The reason is that if we don't do this, we may end up using the old (now non-existing) local IP address. I've thought about this quite a bit... I'm not sure that I understand the problem. I know of two (static IP) scenarios: 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). Here, ppp configures the interface as soon as it sees the ``set ifaddr'' line and never undoes that configuration. An ``add'' with a fixed IP number would never have worked if it's before the ``set ifaddr''. If it's after the ``set ifaddr'', nothing should ever remove it (as the interface will stay configured). 2. Ppp is not in -auto mode. Here, ppp won't assign the interface address 'till IPCP is up. Any attempt to ``add'' a route with a static IP number in ppp.conf should fail. So, the recent routing changes shouldn't have made a difference. Anyone know what I'm missing ? Andre, what does your ppp.conf look like and how are you running ppp ? Cheers. Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent interface/routing changes breaks on-demand PPP
On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote: 1. Ppp is in -auto mode (or a ``set mode auto'' has been done). Here, ppp configures the interface as soon as it sees the ``set ifaddr'' line and never undoes that configuration. An ``add'' with a fixed IP number would never have worked if it's before the ``set ifaddr''. If it's after the ``set ifaddr'', nothing should ever remove it (as the interface will stay configured). 2. Ppp is not in -auto mode. Here, ppp won't assign the interface address 'till IPCP is up. Any attempt to ``add'' a route with a static IP number in ppp.conf should fail. So, the recent routing changes shouldn't have made a difference. Anyone know what I'm missing ? Andre, what does your ppp.conf look like and how are you running ppp ? ppp in -auto mode, "add" is after "set ifaddr" In which case your interface should stay configured despite the link coming down and your route should *not* be deleted. I'll see if I can reproduce this here (I need to upgrade a machine first). -- Andrey A. Chernov http://ache.pp.ru/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp MAKEDEV /dev - on a system with devfs
Brian Somers [EMAIL PROTECTED] wrote: I thought only sysv kept non-startup executables in /etc. There's one real oddity in FreeBSD: [EMAIL PROTECTED]:/etc :; ll rmt lrwxrwxrwx 1 root wheel 13 Jan 28 13:42 rmt - /usr/sbin/rmt* I think that's there for compatibility... programs that want to talk to remote tapes execute ``rsh /etc/rmt ...'' (or is ssh the default these days?). Plus the rc scripts, dhclient-exit-hooks, pccard_ether, and netstart. I guess you could argue that these are more like executable system configuration files, along with others like /etc/start_if.iface. Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] "I never wanted to be a weather forecaster -- I wanted to be... a lumberjack! Leaping from tree to tree as they float down the mighty rivers of British Columbia! The giant redwood! The larch! The The mighty scots pine! ..." -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to mergemaster
Hi, After 100erts of mergemaster sessions, I'm looking for a way to improve mergemaster. 1st thing, mergemaster displays per default all in changed files. That's ok for the first time, but if you maintain many hosts, this is annoying a lot. There should be an options to display all changed files anyway, so you can watch what has changed. (but off by default) So I have ideas to improve merge-master: 1. Add md5 checksum to the the file-header: --- [.] 2. Have a special database with md5 checksums - [.] 3. Have a cvs-aware option. If the installed and new version numbers differ, mergemaster does a cvs diff -u -rINSTALLEDVERSION newversion | patch INSTALLEDFILE. If this works, everyone's happy. If not, it forces you to modify the new file 'till there are no bits in it. Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp MAKEDEV /dev - on a system with devfs
In message [EMAIL PROTECTED], Jean Louis Ntakpe writes: Hi, In /usr/src/etc/Makefile: "make distribution" is still trying to copy MAKEDEV to /dev on a system with devfs mounted to /dev. Since devfs is default, is this behaviour correct or my /etc/make.conf is missing something ? I think that MAKEDEV should be moved away from /dev. Ideally it belongs somewhere rather obscure, but /etc/MAKEDEV is ok with me. /sbin would be better. I thought only sysv kept non-startup executables in /etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Thank you ! This confused the hell out of me when I first bumped into it on Solaris ! Something to read in the morning -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
Just to follow up, this was fixed with v1.9 of src/lib/libc/stdio/findfp.c Thanks Maxim ! I've cc'd -current as I think something more sinister is going on. To recap, I'm having trouble running xsane on -current from about two days ago. fopen() is failing... The attached patch exposes more about what's wrong. Interestingly enough, the file it's trying to create is in /tmp (mode 1777, separate filesystem), and according to truss: lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 7 (0x7) /tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create for preview-level 0: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 127 (0x7f) /tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create for preview-level 1: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 127 (0x7f) break(0x8134000) = 0 (0x0) /tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create for preview-level 2: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) fopen() is failing after calling lstat() (I assume via _open()) !!! As if the "wb" didn't mean O_CREAT ??!? Very strange. [.] And just to top it all, I see this in my daily report (first time I've ever seen it on this machine...): dev.lan.Awfulhak.org kernel log messages: microuptime() went backwards (18415.166882 - 18415.158249) microuptime() went backwards (18490.192910 - 18490.187579) microuptime() went backwards (19572.644000 - 19572.638237) microuptime() went backwards (19878.637972 - 19878.637330) microuptime() went backwards (20043.869158 - 20043.868971) microuptime() went backwards (20074.159108 - 20074.152253) microuptime() went backwards (20210.078270 - 20210.072448) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Fwd: cvs commit: src/lib/libc/stdio findfp.c]
Yes, at least half way through an installworld, xsane works again :-) Thanks. Hi, Please check to see if it would solve your problems with fopen(). -Maxim Original Message Subject: cvs commit: src/lib/libc/stdio findfp.c Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST) From: Maxim Sobolev [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] sobomax 2001/02/07 09:34:49 PST Modified files: lib/libc/stdio findfp.c Log: Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once. Tested by: knu, sobomax and other #bsdcode'rs Revision ChangesPath 1.9 +2 -2 src/lib/libc/stdio/findfp.c -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote: =20 Looks like some way of clustering this might achieve a lot. =20 what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. Joe The problem seems to have gone away after this (kindly pointed out to me by Maxim after my other post about xsane dropping cores): : Subject: cvs commit: src/lib/libc/stdio findfp.c : Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST) : From: Maxim Sobolev [EMAIL PROTECTED] : To: [EMAIL PROTECTED], [EMAIL PROTECTED] : : sobomax 2001/02/07 09:34:49 PST : : Modified files: : lib/libc/stdio findfp.c : Log: : Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once. : : Tested by: knu, sobomax and other #bsdcode'rs : : Revision ChangesPath : 1.9 +2 -2 src/lib/libc/stdio/findfp.c -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. This is on a Feb 4 kernel. NetBSD next -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange fopen() behaviour (was: xsane patch to maintainer)
Hi, Would you mind if I commit the attached patch for the xsane port ? It makes sense - rather than dropping a core when fopen() fails (and fclose() is called with a NULL arg). It happens when your home directory isn't writable :-/ I've cc'd -current as I think something more sinister is going on. To recap, I'm having trouble running xsane on -current from about two days ago. fopen() is failing... The attached patch exposes more about what's wrong. Interestingly enough, the file it's trying to create is in /tmp (mode 1777, separate filesystem), and according to truss: lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 7 (0x7) /tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create for preview-level 0: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 127 (0x7f) /tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create for preview-level 1: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f) = 127 (0x7f) break(0x8134000) = 0 (0x0) /tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create for preview-level 2: No such file or directory write(2,0xbfbfe48c,128) = 128 (0x80) fopen() is failing after calling lstat() (I assume via _open()) !!! As if the "wb" didn't mean O_CREAT ??!? Very strange. Anyway, here's the patch if you're interested. I'll look into things further on Wednesday. Cheers. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! --- src/xsane-preview.c.origSun Jan 14 15:35:06 2001 +++ src/xsane-preview.c Tue Feb 6 03:03:18 2001 @@ -2802,6 +2802,7 @@ int i; char buf[256]; char filename[PATH_MAX]; + FILE *fp; DBG(DBG_proc, "preview_new\n"); @@ -2830,9 +2831,17 @@ if (preview_make_image_path(p, sizeof(filename), filename, i)=0) { umask(0177); /* create temporary file with "-rw---" permissions */ - fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for win32 */ - umask(XSANE_DEFAULT_UMASK); /* define new file permissions */ - p-filename[i] = strdup(filename);/* store filename */ + fp = fopen(filename, "wb"); /* make sure file exists, b = binary mode for +win32 */ + if (fp == NULL) { +fprintf(stderr, "%s: could not create for preview-level %d: %s\n", filename, +i, strerror(errno)); +p-filename[i] = NULL; + } + else + { +fclose(fp); +umask(XSANE_DEFAULT_UMASK);/* define new file permissions */ +p-filename[i] = strdup(filename);/* store filename */ + } } else {
Re: Strange fopen() behaviour
I've cc'd -current as I think something more sinister is going on. To recap, I'm having trouble running xsane on -current from about two days ago. fopen() is failing... The attached patch exposes more about what's wrong. Interestingly enough, the file it's trying to create is in /tmp (mode 1777, separate filesystem), and according to truss: lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f)= 7 (0x7) /tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create for preview-level 0: No such file or directory write(2,0xbfbfe48c,128)= 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f)= 127 (0x7f) /tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create for preview-level 1: No such file or directory write(2,0xbfbfe48c,128)= 128 (0x80) getuid() = 15 (0xf) lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or directory' umask(0x7f)= 127 (0x7f) break(0x8134000) = 0 (0x0) /tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create for preview-level 2: No such file or directory write(2,0xbfbfe48c,128)= 128 (0x80) fopen() is failing after calling lstat() (I assume via _open()) !!! As if the "wb" didn't mean O_CREAT ??!? Very strange. [.] And just to top it all, I see this in my daily report (first time I've ever seen it on this machine...): dev.lan.Awfulhak.org kernel log messages: microuptime() went backwards (18415.166882 - 18415.158249) microuptime() went backwards (18490.192910 - 18490.187579) microuptime() went backwards (19572.644000 - 19572.638237) microuptime() went backwards (19878.637972 - 19878.637330) microuptime() went backwards (20043.869158 - 20043.868971) microuptime() went backwards (20074.159108 - 20074.152253) microuptime() went backwards (20210.078270 - 20210.072448) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm driver and DEVFS
On Fri, Feb 02, 2001 at 04:11:29PM +0900, Yoshihiro Koya wrote: Hello, I did make world a couple days ago. The system was built from cvsup'd source on Jan 30: -- elf make world started on Tue Jan 30 06:23:38 JST 2001 -- The system uses DEVFS. But I have some issue around sound drivers. I usually use mpg123(Version 0.59r (1999/Jun/15)) or x11amp(version 0.8). Before using DEVFS, I was able to adjust sound volume in the sophisticated manner. But, after installing DEVFS, I wasnt adjust sound volume. It might be difficult to run x11amp with DEVFS. On the other hand, mpg123 works. But, its sound is too loud. Added to this, before install DEVFS, I found /dev/dsp1 or /dev/dsp0 in /dev. But I only found the different kind of files: % ls /dev [skip] The files /dev/dsp1.0 and /dev/dsp1.1 are new to me. Of course, I tried to do % x11amp -e /dev/dsp1.0 % x11amp -e /dev/dsp1.1 % x11amp -e /dev/dspW1.0 % x11amp -e /dev/dspW1.1 But in vain. Does some have solution or suggestion? Yep. I have these in my /etc/rc.devfs: = ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer = This produces almost exactly same environment both with DEVFS and without. Strange. I have a stock rc.devfs and get the above links too :-) $ cd /sys/dev/sounds/pcm $ fgrep make_dev_alias *.c sound.c:dsp = make_dev_alias(pdev, "dsp"); sound.c:dspW = make_dev_alias(pdev, "dspW"); sound.c:audio = make_dev_alias(pdev, "audio"); sound.c:mixer = make_dev_alias(pdev, "mixer"); -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 32 days in the brand new millenium... -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp/samba (configuration?) question
You should get away with adding your ``set ifaddr'' line to ppp.linkdown (you can remove the ``iface clear'' too). If this isn't the right place for this, I apologize. Feel free to set followups appropriately. I'm running ppp on a -current system (12/7/2000 vintage) named `moran'. I'm using it as a gateway for small in-home network (a couple of windoze boxes and a laptop running -stable), and I have NAT enabled. ppp is started automatically at boot as follows: /usr/sbin/ppp -quiet -auto -nat mintel Here's the appropriate part of ppp.conf: mintel: allow users rjk set openmode active 5 set phone 1234567 set timeout 2700 set socket /var/tmp/internet "" set authname a set authkey b deny lqr disable lqr set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 delete all add default HISADDR enable dns In ppp.linkdown, I have: mintel: iface clear I'm using 10.1.0.0/24 internally, and moran is also running dhcpd and samba. Everything is working fine, except (you knew there'd be an except, right?:) the windoze boxes on my local network can't find the samba server on moran immediately after moran reboots. After some experimenting with config files and playing with ethereal, I think I know what's going on but I don't know what to do about it. If I don't put "10.0.0.1 localhost" in /etc/hosts, rebooting is very slow; I have to wait for ppp to make a connection before sendmail gets going. If I add it to /etc/hosts I don't have to wait on sendmail but I have problems with nmbd. With the above configuration for ppp, ifconfig always shows 2 IP addresses associated with tun0. Immediately after boot, it looks like (for example): tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 10.0.0.1 -- 255.255.255.255 netmask 0x inet 63.xx.xx.13 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 After I lose my connection for whatever reason (which normally happens at least 3 or 4 times a day with our local telephone service :() ppp automatically redials and reconnects. After this happens, ifconfig would show: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1514 inet 63.xx.xx.13 -- 255.255.255.255 netmask 0x inet 63.xx.xx.47 -- 63.xx.xx.2 netmask 0xff00 Opened by PID 115 The 10. address is gone, my last address is still there but points to 255.255.255.255, and my new address is fine. ethereal shows that nmbd is saying it lives at 10.0.0.1. If I kill nmbd and restart it after having lost and remade my ppp connection, everything is fine. Note that this only affects nmbd. Browsers and ssh work just fine. Have I got something misconfigured? Should ppp be keeping my last IP address around like that? Sorry for the length of this message. Any comments and/or suggestions? Thanks. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 / -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
ISTR Christian Weisgerber [EMAIL PROTECTED] was having this problem too. I don't know if there was any fix as such I have a -current system from Dec. 7 on which I'm trying to do a cvs update in preparation of make world, and am seeing wierd stuff like this: cvs server: Updating crypto/kerberosIV/appl/afsutil U crypto/kerberosIV/appl/afsutil/Makefile.in U crypto/kerberosIV/appl/afsutil/aklog.c U crypto/kerberosIV/appl/afsutil/kstring2key.c U crypto/kerberosIV/appl/afsutil/pagsh.c cvs server: Updating crypto/kerberosIV/appl/bsd U crypto/kerberosIV/appl/bsd/Makefile.in U crypto/kerberosIV/appl/bsd/README.login U crypto/kerberosIV/appl/bsd/bsd_locl.h U crypto/kerberosIV/appl/bsd/encrypt.c U crypto/kerberosIV/appl/bsd/forkpty.c U crypto/kerberosIV/appl/bsd/kcmd.c U crypto/kerberosIV/appl/bsd/klogin.c U crypto/kerberosIV/appl/bsd/krcmd.c U crypto/kerberosIV/appl/bsd/login.c U crypto/kerberosIV/appl/bsd/login_access.c U crypto/kerberosIV/appl/bsd/login_fbtab.c U crypto/kerberosIV/appl/bsd/osfc2.c U crypto/kerberosIV/appl/bsd/pathnames.h_ U crypto/kerberosIV/appl/bsd/rcmd_util.c cvs update: warning: unrecognized response ` If there are any IP options on `sock', die.' from cvs server cvs update: warning: unrecognized response ` */' from cvs server cvs update: warning: unrecognized response `' from cvs server cvs update: warning: unrecognized response `void' from cvs server cvs update: warning: unrecognized response `ip_options_and_die (int sock, struct sockaddr_in *fromp)' from cvs server cvs update: warning: unrecognized response `{' from cvs server cvs update: warning: unrecognized response `#if defined(IP_OPTIONS) defined(HAVE_GETSOCKOPT)' from cvs server cvs update: warning: unrecognized response ` u_char optbuf[BUFSIZ/3], *cp;' from cvs server cvs update: warning: unrecognized response ` char lbuf[BUFSIZ], *lp;' from cvs server The file data is somehow getting mixed into the "control stream" or something. The cvs server is a 5.0-2506-CURRENT machine that has been working fine for many months (and I don't see the same problem when cvs updating from other machines). I notice that "cvs" was updated to version 1.11 on 10/31/00... Has anyone else seen this, and if so, what's the fix?? Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
Brian Somers [EMAIL PROTECTED] wrote: ISTR Christian Weisgerber [EMAIL PROTECTED] was having this problem too. Sorry, you're misremembering. I've never seen anything like this. You're right you know - my apologies ! -- Christian "naddy" Weisgerber [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IGMP queries
If it is true, how can I filter it to stop resetting the idle-timeout? I'm on flat rate now, but even so I don't want to be online 24h/day... Add this to your ppp profile: set filter alive N deny igmp Leif -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to debug ppp
What happens if you ``disable acfcomp protocomp'' and ``deny acfcomp protocomp'' in your config ? This should be negotiable with isdn but perhaps our requesting it is upsetting the peer ? It still doesn't work sometimes. I have a complete log (From dialing to hangup) at http://www.neland.dk/arnold.log My ppp.conf is at http://www.neland.dk/arnold.conf Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MAGICNUM[6] 0xa14dc70c Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: PROTOCOMP[2] Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: ACFCOMP[2] Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MRRU[4] 1506 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: 1: LayerStart Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: 1: State change Stopped -- Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: 1: RecvConfigReq(2) state = Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MAGICNUM[6] 0xa14dc70c Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: PROTOCOMP[2] Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: ACFCOMP[2] Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRRU[4] 1506 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: 1: SendConfigAck(2) state = Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) - Original Message - From: "Brian Somers" [EMAIL PROTECTED] To: "Leif Neland" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 29, 2000 2:10 AM Subject: Re: How to debug ppp Well, I haven't seen this before !!! Your ISP is *insisting* that you negotiate a multi-link connection. You can do this by simply adding set mrru 1506 to your config. I sometimes have trouble connecting to my flat-rate isp via i4bsd. Most of the time it works, but sometimes the handshake fails. What is the log trying to tell me here? What can I tell my isp? When it fails, I can connect to another isp, which charges per minute charges, which I rather not use when I have flat rate. Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: Phone: x Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: Connected! Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: opening - dial Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: 1: Dial attempt 1 of 2 Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: dial - carrier Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: /dev/i4brbch0: CD detected Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: carrier - login Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: login - lcp Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: FSM: Using "1" as a transport Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Initial -- Closed Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: Entering STOPPED state for 2 s econds Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Closed -- Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x0bde8bbc Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: LayerStart Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Stopped -- Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(2) state = Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:37 arnold ppp[7
Re: How to debug ppp
:36 arnold ppp[56941]: tun0: LCP: MRRU[4] 1506 Dec 6 00:21:36 arnold ppp[56941]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 6 00:21:36 arnold ppp[56941]: tun0: LCP: 1: SendConfigRej(9) state = Req-Sent Dec 6 00:21:36 arnold ppp[56941]: tun0: LCP: PROTOCOMP[2] Dec 6 00:21:36 arnold ppp[56941]: tun0: LCP: ACFCOMP[2] Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: 1: RecvConfigReq(10) state = Req-Sent Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MRU[4] 1500 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MAGICNUM[6] 0x01e25945 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: PROTOCOMP[2] Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: ACFCOMP[2] Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MRRU[4] 1506 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: 1: SendConfigRej(10) state = Req-Sent Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: PROTOCOMP[2] Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: ACFCOMP[2] Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: 1: SendConfigReq(1) state = Req-Sent Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MRU[4] 1500 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MAGICNUM[6] 0xc23c4361 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: MRRU[4] 1506 Dec 6 00:21:38 arnold ppp[56941]: tun0: LCP: SHORTSEQ[2] Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: Carrier lost Dec 6 00:21:40 arnold ppp[56941]: tun0: LCP: 1: State change Req-Sent -- Starting Dec 6 00:21:40 arnold ppp[56941]: tun0: LCP: 1: LayerFinish Dec 6 00:21:40 arnold ppp[56941]: tun0: LCP: 1: State change Starting -- Initial Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: Disconnected! Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: lcp - logout Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: Disconnected! Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: logout - hangup Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: Connect time: 16 secs: 351 octets in, 228 octets out Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: : 19 packets in, 29 packets out Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: total 36 bytes/sec, peak 50 bytes/sec on Wed Dec 6 00:21:40 2000 Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: 1: hangup - closed Dec 6 00:21:40 arnold ppp[56941]: tun0: Phase: bundle: Dead - Original Message - From: "Brian Somers" [EMAIL PROTECTED] To: "Leif Neland" [EMAIL PROTECTED] Cc: "Brian Somers" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 05, 2000 11:40 PM Subject: Re: How to debug ppp What happens if you ``disable acfcomp protocomp'' and ``deny acfcomp protocomp'' in your config ? This should be negotiable with isdn but perhaps our requesting it is upsetting the peer ? It still doesn't work sometimes. I have a complete log (From dialing to hangup) at http://www.neland.dk/arnold.log My ppp.conf is at http://www.neland.dk/arnold.conf Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MAGICNUM[6] 0xa14dc70c Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: PROTOCOMP[2] Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: ACFCOMP[2] Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: MRRU[4] 1506 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: 1: LayerStart Dec 5 22:28:28 arnold ppp[55986]: tun0: LCP: 1: State change Stopped -- Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: 1: RecvConfigReq(2) state = Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MAGICNUM[6] 0xa14dc70c Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: PROTOCOMP[2] Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: ACFCOMP[2] Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRRU[4] 1506 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: 1: SendConfigAck(2) state = Ack-Se nt Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: MRU[4] 1500 Dec 5 22:28:29 arnold ppp[55986]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) - Original Message - From: "Brian Somers" [EMAIL PROTECTED] To: "Leif Neland" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 29, 2000 2:10 AM Subject: Re: How to debug ppp Well, I haven't seen this before !!! Your ISP is *insisting* that you negotiate a multi-link connection. You can do this by simply adding set
Re: How to debug ppp
Well, I haven't seen this before !!! Your ISP is *insisting* that you negotiate a multi-link connection. You can do this by simply adding set mrru 1506 to your config. I sometimes have trouble connecting to my flat-rate isp via i4bsd. Most of the time it works, but sometimes the handshake fails. What is the log trying to tell me here? What can I tell my isp? When it fails, I can connect to another isp, which charges per minute charges, which I rather not use when I have flat rate. Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: Phone: x Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: Connected! Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: opening - dial Nov 27 20:48:35 arnold ppp[7461]: tun0: Chat: 1: Dial attempt 1 of 2 Nov 27 20:48:35 arnold ppp[7461]: tun0: Phase: 1: dial - carrier Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: /dev/i4brbch0: CD detected Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: carrier - login Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: login - lcp Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: FSM: Using "1" as a transport Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Initial -- Closed Nov 27 20:48:36 arnold ppp[7461]: tun0: Phase: 1: Entering STOPPED state for 2 s econds Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Closed -- Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigReq(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x0bde8bbc Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(1) state = Stopped Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: LayerStart Nov 27 20:48:36 arnold ppp[7461]: tun0: LCP: 1: State change Stopped -- Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(2) state = Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(2) state = Req-Sent Nov 27 20:48:37 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Looping: Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: 1: RecvConfigReq(3) state = Req-Sent Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRU[4] 1500 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MAGICNUM[6] 0x08f8f450 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: PROTOCOMP[2] Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: ACFCOMP[2] Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: ENDDISC[9] MAC 00:10:bc:06:fa:00 Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: 1: SendConfigRej(3) state = Req-Sent Nov 27 20:48:38 arnold ppp[7461]: tun0: LCP: MRRU[4] 1506 Until hangup Leif -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP over ATM
Sorry to chime in so late, but ppp(8) already has ATM support... I must confess that I haven't tested it and don't know how it works, but it may be worth looking at. A netgraph node would definitely be preferable. On Sun, 22 Oct 2000 03:41:27 +0200, Poul-Henning Kamp wrote: Who knows about the ATM stuff in the kernel? We have two ATM stacks: * The minimalist "chuck" stack. * The full-blown HARP stack. Neither support netgraph. Are you aware of any efforts to add PPP over ATM or Netgraph support to the current ATM code? I'm not aware of any activity in the ATM code at all... Ok, well if I were to netgraphify the ATM code, would mpd be sufficient to get PPP over ATM working? (I have a lot of reading up to do, but if I can decide on the correct direction to start off in I could save myself alot of time ;)). And for the record I have done ethernet drivers in Linux and OS/2. But I am quite unfamiliar with the FreeBSD networking code. I have only submitted patches to the kernel for cyrix code optimizations. :) I looked into netgraph and it seems to be a very modular and a wise approach to take if it sufficient for this purpose. Brian Smith -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP patch (CHAP81 + MPPE)
Hi, Thanks for the patches. I've committed the changes although I'm having problems with MPPE. I suspect the problems are actually in the CCP stuff though - and I've suspected this for some time, something to do with running ppp back-to-back (and not over a tty). I'll look into this soon. Anyway, thanks again for your work. It's really appreciated. Hi! Here is a patch attached (made from current from 2813). Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and supports MPPE encryption protocol. With all these ppp can participate in MS VPN. Please look at this, and tell me what you think? Bye! [.] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message