Re: panic in get_next_dirent

2010-09-03 Thread Brian Somers
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)

2002-06-30 Thread Brian Somers

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)

2002-06-29 Thread Brian Somers

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

2002-05-15 Thread Brian Somers

  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

2002-05-15 Thread Brian Somers

 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

2002-05-15 Thread Brian Somers

  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

2002-05-07 Thread Brian Somers

 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

2002-05-04 Thread Brian Somers

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

2002-04-29 Thread Brian Somers

 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

2002-04-25 Thread Brian Somers

 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 ...

2002-04-14 Thread Brian Somers

 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...

2002-04-10 Thread Brian Somers

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()?

2002-04-05 Thread Brian Somers

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 )

2002-03-08 Thread Brian Somers

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 )

2002-03-08 Thread Brian Somers

 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'

2002-01-22 Thread Brian Somers

 
 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

2001-12-06 Thread Brian Somers

 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

2001-11-27 Thread Brian Somers

 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

2001-11-27 Thread Brian Somers

 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

2001-11-27 Thread Brian Somers

 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)

2001-11-21 Thread Brian Somers

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)

2001-11-21 Thread Brian Somers

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

2001-10-11 Thread Brian Somers

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???

2001-09-25 Thread Brian Somers

 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!

2001-09-22 Thread Brian Somers

 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

2001-08-28 Thread Brian Somers

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)

2001-08-25 Thread Brian Somers

 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?

2001-08-20 Thread Brian Somers

 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?

2001-08-20 Thread Brian Somers

 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

2001-08-20 Thread Brian Somers

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

2001-08-20 Thread 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).
-- 
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

2001-08-20 Thread Brian Somers

 +---[ 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)

2001-08-04 Thread Brian Somers

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

2001-08-03 Thread Brian Somers

 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

2001-08-03 Thread Brian Somers

 
 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

2001-07-22 Thread Brian Somers

 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)

2001-06-18 Thread Brian Somers

 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

2001-06-18 Thread Brian Somers

 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

2001-06-18 Thread Brian Somers

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

2001-06-12 Thread Brian Somers

 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

2001-06-09 Thread Brian Somers

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)]

2001-05-29 Thread Brian Somers

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

2001-05-29 Thread Brian Somers

 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

2001-05-29 Thread Brian Somers

 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

2001-05-23 Thread Brian Somers

 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

2001-05-23 Thread Brian Somers

 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

2001-05-18 Thread Brian Somers

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)

2001-05-18 Thread Brian Somers

 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)

2001-05-18 Thread Brian Somers

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

2001-05-17 Thread Brian Somers

 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)

2001-05-17 Thread Brian Somers

  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)

2001-05-17 Thread Brian Somers

[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

2001-05-16 Thread Brian Somers

 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

2001-05-15 Thread Brian Somers

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

2001-05-15 Thread Brian Somers

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

2001-05-09 Thread Brian Somers

 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)

2001-04-25 Thread Brian Somers

 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)

2001-04-25 Thread Brian Somers

[.]
 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)

2001-04-25 Thread Brian Somers

 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'?)

2001-04-23 Thread Brian Somers

 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'?)

2001-04-23 Thread Brian Somers

 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'?)

2001-04-22 Thread Brian Somers

 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'?)

2001-04-22 Thread Brian Somers

 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'?)

2001-04-21 Thread Brian Somers

  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'?)

2001-04-21 Thread Brian Somers

 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'?)

2001-04-21 Thread Brian Somers

 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'?)

2001-04-21 Thread Brian Somers

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'?)

2001-04-21 Thread Brian Somers

 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'?)

2001-04-21 Thread Brian Somers

 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'?)

2001-04-20 Thread Brian Somers

 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)

2001-04-17 Thread Brian Somers

   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

2001-04-10 Thread Brian Somers

[.]
   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

2001-04-10 Thread Brian Somers

 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

2001-04-09 Thread Brian Somers

 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

2001-04-01 Thread Brian Somers

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

2001-03-26 Thread Brian Somers

 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

2001-03-24 Thread Brian Somers

  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?

2001-03-24 Thread Brian Somers

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

2001-03-23 Thread Brian Somers

  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

2001-03-23 Thread Brian Somers

 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

2001-03-13 Thread Brian Somers

 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

2001-03-13 Thread Brian Somers

 
 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

2001-03-12 Thread Brian Somers

 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...)

2001-02-15 Thread Brian Somers

 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

2001-02-09 Thread Brian Somers

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]

2001-02-08 Thread Brian Somers

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

2001-02-08 Thread Brian Somers

 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

2001-02-06 Thread Brian Somers

 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)

2001-02-05 Thread Brian Somers

 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

2001-02-05 Thread Brian Somers

 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

2001-02-02 Thread Brian Somers

 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

2001-01-11 Thread Brian Somers

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

2001-01-07 Thread Brian Somers

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

2001-01-07 Thread Brian Somers

 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

2001-01-01 Thread Brian Somers

 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

2000-12-05 Thread Brian Somers

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

2000-12-05 Thread Brian Somers
: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

2000-11-28 Thread Brian Somers

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

2000-11-06 Thread Brian Somers

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)

2000-10-29 Thread Brian Somers

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



  1   2   3   >