Re: panic in get_next_dirent

[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  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  
Don't _EVER_ lose your sense of humour !   


signature.asc
Description: PGP signature

Re: make install failed on XFree86-4-client (with 6/10 -current)

[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.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 install failed on XFree86-4-client (with 6/10 -current)

[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]>
  
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: loader failure

[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>   
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: loader failure

[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>   
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: loader failure

[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  
> > 
> > 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]>
     
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: CURRENT and P-IV problems

[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/
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: CURRENT and P-IV problems

[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/
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: ipfilter not broken for me

[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/
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: Revision 1.88 of kern_linker.c breaks module loading for diskless

[Brian Somers]

> On Fri, 26 Apr 2002, Brian Somers wrote:
> 
> BS>The intent is to discover whether there's a filesystem yet (vn_open()
> BS>will die horribly otherwise).
> BS>
> BS>My use of rootdev is (obviously) flawed.  AFAICT, either rootvp
> BS>or rootvnode should be used, but I can't tell the difference between
> BS>the two at a glance and am lacking development resources right now
> BS>(my development box seems to enjoy dropping cores too frequently to
> BS>build a kernel at the moment).
> BS>
> BS>If somebody could test that rootvnode or rootvp are non-NULL after
> BS>an NFS-mounted root is set up, I'd thankfully approve the quick
> BS>fix... :*)
> 
> dlc1# gdb -k /boot/kernel/kernel /dev/mem
> (no debugging symbols found)...
> IdlePTD at phsyical address 0x00392000
> initial pcb at physical address 0x082bdda0
> panic messages:
> ---
> ---
> #0  0xc017b968 in mi_switch ()
> (kgdb) p rootdev
> $1 = -1
> (kgdb) p rootvnode
> $2 = -843452416
> (kgdb) p rootvp
> $3 = -843452416
> (kgdb)
> 
> They obviously point to the same thing and are non-NULL (root is NFS).

Thanks.  I've committed the change.

> harti
> -- 
> harti brandt, 
>http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
>   [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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: Revision 1.88 of kern_linker.c breaks module loading for diskless

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

[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/
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: mktime() doesn't fix deadzones...

[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/
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: segfault in getpwuid()?

[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/
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" )

[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. 
> [EMAIL PROTECTED] FreeBSD Committer 

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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" )

[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]>
     
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 Dial of External Modem Fails in 'Current'

[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/
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: rev 1.61 of /sys/netinet/in.c breaks ISDN

[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/
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: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT

[Brian Somers]

> On Tue, Nov 27, 2001 at 04:20:54PM +0000, 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/
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: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT

[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/
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: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT

[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/
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: cvsup-devel port build problem (pm3-base)

[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/
Don't _EVER_ lose your sense of humour !  

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 
+ #include 
+ #include 
++#if __FreeBSD_version >= 500024
++#include 
++#else
+ #include 
++#endif
+ #include 
+ #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 
+ #include 
+ #include 
++#if __FreeBSD_version >= 500024
++#include 
++#else
+ #include 
++#endif
+ #include 
+ #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

Re: cvsup-devel port build problem (pm3-base)

[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  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 
>  #include 
>  #include 
> +#if __FreeBSD__ >= 5
> +#include 
> +#else
>  #include 
> +#endif
>  #include 
>  #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/
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

ACPI panic at boot time in -current

[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=0x183f9ff
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:  on motherboard
npx0: INT 16 interface
acpi0:  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:  on acpi0
acpi_tz0:  on acpi0
acpi_button0:  on acpi0
acpi_pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on acpi_pcib0
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xfcf0-0xfcff at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  at device 7.2 on pci0
uhci0: Could not map ports
device_probe_and_attach: uhci0 attach returned 6
pci0:  at device 7.3 (no driver attached)
pci0:  at device 8.0 (no driver attached)
pcm0:  mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 
8.1 on pci0
pci0:  at device 9.0 (no driver attached)
pccbb0:  irq 0 at device 10.0 on pci0
pccbb0: PCI Memory allocated: 1000
acpi_pcib0: device is routed to IRQ 9
cardbus0:  on pccbb0
pccard0: <16-bit PCCard bus> on pccbb0
pccbb1:  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/
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: Anyone had luck with 3Com HomeConnect ADSL Modem Dual Link???

[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/
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: stdio change, other libraries needs bumping too!

[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/
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

More SIG4s during make world

[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/
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: another panic (mix ppp and usb to taste)

[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/
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: Copyright Contradiction in libalias

[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/
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: Copyright Contradiction in libalias

[Brian Somers]

> Check with Charles to see if he really wants to abandon copyright claims
> to his code, or whether he was really implying some really liberal open source 
> license.

With the BSD Copyright (only) he keeps the intellectual copyright on 
the original.  That's what I've changed it to (as per his agreement).
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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: Copyright Contradiction in libalias

[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/
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: Syntax change in ppp?

[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/
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: Syntax change in ppp?

[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=8051 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/
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

Should developers run current ? (was: XDM and X)

[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/
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: /home: mount pending error: blocks 14 files 3

[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/
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: /home: mount pending error: blocks 14 files 3

[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/
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: /home: mount pending error: blocks 14 files 3

[Brian Somers]

The error means that your machine crashed with soft-updates enabled, 
leaving 14 blocks and 3 files still allocated on disk (using up 
blocks & inodes).

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.

To fix it, correct fstab and run fsck -B.

> I've never had this before, and I have traced the message to ufs/ffs/ffs_vnops.c on 
>line 634.
> 
> I have recently noticed [since my last svsup] that this is happening on boot and 
>shutdown [in which case, the messasge is also in
> the same file, but for umount conditions].
> 
> I am not a filesystem expert..  How concerned should I be?
> 
> This is -current a week or two old [before all the lockup threads began]...
> 
> jim
> -- 
> ET has one helluva sense of humor!
> He's always anal-probing right-wing schizos!

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
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: Userbase of -current

[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/
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

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

[Brian Somers]

> < 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]>
     
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: trouble with glob patch (ftp exploit)

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

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

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

[Brian Somers]

> Brian Somers wrote:
> 
> > 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.
> 
> Attached please find relevant log. I could add that now the problem became even
> more frequent, so I would appreciate any help.
> 
> Thank you!
> 
> -Maxim
[.]
> Phase: Pap Output: sobomax1 
[.]
> Phase: Pap Input: SUCCESS ()

So authentication is ok.

[.]
> IPCP: deflink: LayerUp.
> IPCP: myaddr 212.35.189.239 hisaddr = 212.35.189.18

The IP layer is up.

[.]
> IPCP: deflink: RecvTerminateReq(3) state = Opened
> IPCP: deflink: LayerDown: 212.35.189.239
[.]

And the peer closes the connection.

To be honest, I have no idea what's going on here.  It doesn't even 
look as if you sent any data.  I think you may have to ask your ISP 
why they're closing the connection :/
-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.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

this mornings installkernel is bad

[Brian Somers]

Hi all,

It looks like this mornings buildkernel/installkernel is not a good 
thing to install.  Trying to buildworld with it produces sig4s (and I 
think some sig6s) from the compiler:

May 30 12:58:39 dev /boot/kernel/kernel: pid 20690 (cc1), uid 0: exited on signal 4 
(core dumped)
May 30 13:00:32 dev /boot/kernel/kernel: pid 28006 (cc1), uid 0: exited on signal 4 
(core dumped)

This has happened on each of 3 attempts to buildworld and buildkernel 
with the latest kernel.

Reverting to ``boot kernel.stable'' where kernel.stable is from May 
23 gives an environment where buildworld & buildkernel both work ok.
-- 
Brian <[EMAIL PROTECTED]>
     
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

[Brian Somers]

> In message  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]>
     
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

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

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

[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]>
  <http://www.Awfulhak.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

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

[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  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]>
  <http://www.Awfulhak.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)

[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/_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  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]>
  <http://www.Awfulhak.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

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

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

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/_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// and into sys/sys/.

Comments ?

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.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)

[Brian Somers]

> > Most headers that define ioctls are in .  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/_io.h so I'd 
spell digiio.h /usr/include/sys/digi_io.h.

-- 
Brian <[EMAIL PROTECTED]>
     
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

[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 .  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]>
  <http://www.Awfulhak.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

[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  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  being out of date,
> and sometimes helps mainly for headers like  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]>
     
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

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

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

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

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

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

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

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

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

[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]>
  <http://www.Awfulhak.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'?)

[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]>
  <http://www.Awfulhak.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'?)

[Brian Somers]

> Brian Somers <[EMAIL PROTECTED]> writes:
> > 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 []
> 
> It deals with it.  It conveniently ignores the second '[]' :-).
> Seriosly though, what do you expect it to do in this case?  It can
> either read some more from stdin, or use the same input it used for
> the first case of '[]'.  I also can't think of a case when either one
> of these would be useful.

I can't think of a case either :*]

> I guess the only reason we would want this is if SUSv2 defines it, but
> even that may not matter since we probably won't support the silly
> '-i[nospace]' semantic (other than being silly, I can't think of how
> to implement it without writing a custom getopt() facility).

Absolutely - we wanna avoid that sort of mucking about.

> > 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.
> 
> Any advice on testing this (you did write rev. 1.9 of xargs.1, after
> all)?  I created a file with 4500 words like this:
> 
>   /this/is/a/very/long/path/name/because/I/am/testing/some/posix/limit/10
> 
> which ended up being 330 kB.  It ran the `utility' multiple times like
> I expected it to.  That said, I don't know what kind of failure mode
> to expect.  I.e., if the patch is wrong, should it have failed with
> something like, "xargs: exec: argument list too long", or would it
> just produce incorrect output (which I didn't really check for)?

Yes, I was expecting it to fail with E2BIG.  Sorry for doubting your 
patches - they work as advertised from the looks of it !  Nice one.

> Thanks,

Thank you !

>   Dima Dorfman
>   [EMAIL PROTECTED]

-- 
Brian <[EMAIL PROTECTED]>
  <http://www.Awfulhak.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'?)

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

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

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

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

[Brian Somers]

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

> --
> E-Mail: Alexander Kabaev <[EMAIL PROTECTED]>
> Date: 21-Apr-2001
> Time: 11:08:13
> --

-- 
Brian <[EMAIL PROTECTED]>
     
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'?)

[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]>
  <http://www.Awfulhak.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'?)

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

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

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

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

[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=dirpref&num=100&hl=en&lr=&safe=off&rnum=2&seld=905073910&ic=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]>
     
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

[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=dirpref&num=100&hl=en&lr=&safe=off&rnum=2&seld=905073910&ic=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]>
     
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

[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]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail t

Re: Recent interface/routing changes breaks on-demand PPP

[Brian Somers]

> On Sun, Mar 25, 2001 at 02:46:22AM +0100, Brian Somers wrote:
> > > > On Fri, Mar 23, 2001 at 23:11:56 +0000, 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]>
  <http://www.Awfulhak.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?

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

[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]>
  <http://www.Awfulhak.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

[Brian Somers]

> On Fri, Mar 23, 2001 at 23:11:56 +0000, 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]>
  <http://www.Awfulhak.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

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

[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]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cp MAKEDEV /dev - on a system with devfs

[Brian Somers]

> 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]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cp MAKEDEV /dev - on a system with devfs

[Brian Somers]

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

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

[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]>
>      
> Don't _EVER_ lose your sense of humour !

-- 
Brian <[EMAIL PROTECTED]>
     
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

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

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

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

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

[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]>
     
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: pcm driver and DEVFS

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

[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=8051 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=8051 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]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: weird cvs update problem

[Brian Somers]

> 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]>
  <http://www.Awfulhak.org>   
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: weird cvs update problem

[Brian Somers]

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