Re: nroff -man broken?

[Ruslan Ermilov]

On Tue, Apr 24, 2001 at 10:25:47PM +0200, Riccardo Torrini wrote:
> # man man
> Formatting page, please wait...mdoc error: end-macro (.em)
>respecification is not allowed. (#20)
>Should this have been `.Em ...'?
> User Abort.
> Done.
> 
> 
> This happens over last week.  World of this night (after
> cvsup with also make kernel and mergemaster, for 4 times).
> I have also tryed to remove all */man/cat*/*gz compiled
> manuals with but luck :(  Any hints?  Thanks.
> 
There was a problem caused by broken `make cleandir' behavior.
Make sure you have src/share/mk/bsd.obj.mk, revision 1.35.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: vm_mtx

[Joseph Mallett]

Those who dial will know its meaning: 6545666,555,666,654555654

On Tue, 24 Apr 2001, Julian Elischer wrote:

> Poul-Henning Kamp wrote:
> >
>
> > I'm sure you are fully aware of the implications of the strategically
> > placed "supposed" in your own sentence.  I have never heard anybody
> > get Mach code multithreaded yet.
>
> Mach has successfully run in multiprocessor multithreadded
> systems since 1991.

Yep. Distributed processing, too.

>
> >
> --
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000-2001
> ---> X_.---._/
> v
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>


--
[ Joseph Mallett]
[ xMach Core Team xMach: Proactively Unbloated Microkernel BSD ]
[ Proud Open/Free/Net/4.4BSD User; C Programmer; Mad ] [ www.xMach.org ]




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

Re: vm_mtx

[Julian Elischer]

Poul-Henning Kamp wrote:
> 

> I'm sure you are fully aware of the implications of the strategically
> placed "supposed" in your own sentence.  I have never heard anybody
> get Mach code multithreaded yet.

Mach has successfully run in multiprocessor multithreadded
systems since 1991.

> 
-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v

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

Re: Boot messages

[Garrett Wollman]

[Followups to -questions, please.]

< 
said:

> unknown:  can't assign resources

Keyboard controller.

> unknown:  can't assign resources

PS/2 mouse port.

> unknown:  can't assign resources

Serial port whose settings conflict with one of your configured serial
ports.

> unknown:  can't assign resources

Floppy disk controller.

See .

-GAWollman


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

Re: Boot messages

[Garrett Wollman]

< said:

> This is not a bug.  This is an FAQ.  So much that it's actually
> documented in (*gasp!*) the FAQ:

Unfortunately, the A in the FAQ is wrong.

The ``can't assign resources'' messages indicate that the devices are
legacy ISA devices for which a non-PnP-aware driver is compiled into
the kernel.  These include devices such as keyboard controllers, the
programmable interrupt controller chip, and several other bits of
standard infrastructure.  The resources can't be assigned because
there is already a driver using those addresses.

If it didn't say ``can't assign resources'', then *and only then* is
the device in question not configured in the kernel.  AIUI such
messages are currently disabled unless one boots in verbose mode.

-GAWollman



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

Native ACL support for Samba (fwd)

[Robert Watson]

Figured people running 5.0-CURRENT might be interested in this news -- I
know this is a feature we've been asked about frequently, and Chris has
done a great job in making it happen :-).  There are still a few tweaks
being worked out in the ACL code, and we need to write some regression
tests, but it seems to work quite well.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services

-- Forwarded message --
Date: Tue, 24 Apr 2001 19:17:52 -0400
From: Chris Faulhaber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Native ACL support for Samba

With the release of Samba 2.2.0, samba offers ACL support to
remote clients.  I just committed the changes to the FreeBSD
CVS tree required to allow Samba to access the FreeBSD ACLs.
With an updated -current system and samba-devel port (define
WITH_ACL_SUPPORT), Windows NT 4.0 and 2000 clients can now
remotely manipulate ACLs.  Testing and comments are
appreciated.

In addition, the ACL utilities, getfacl and setfacl, have
been updated to fully make use of the ACL editing library.
They should compile on most ACL-enabled systems (tested on
Linux + ACL patches) with little or no change.

For the requisite screenshot, see http://www.fxp.org/jedgar/ACL/ :)

-- 
Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED]

FreeBSD: The Power To Serve   -   http://www.FreeBSD.org

 PGP signature

[feedback on fix] kern/22208: vr0: MII without any phy! problem when coming back from Windows

[anarcat]

Hi.

[I don't know if this belongs to current, but please be nice and fwd
this to the proper entity if needs be. Please also keep me as Cc: ]

I stumbled on this quite old pr today, looking for a fix for my problem
(see subject).

I can confirm that the fix works here. Just tested it on -stable
(4.3-RC4). Just applying the patch, config && make depend && make &&
make install && reboot.

I can also say that a few persons have suffered this behavior, having
looked through the mailing list archives, seeing only unanswered
questions.

However, I witness a workaround for the bug, I think. I turned of my
machine using "shutdown" in windows instead of rebooting when switching
to fbsd. And the card was detected automagically. :)

So if this could be commited and MFC'd this would be nice. :) It works.

Thanks,

A.

>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->wpaul 
Responsible-Changed-By: johan 
Responsible-Changed-When: Sun Oct 22 11:07:25 PDT 2000 
Responsible-Changed-Why:  
Over to vr maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22208 

 PGP signature

Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable

[Bruce Evans]

On Tue, 24 Apr 2001, Terry Lambert wrote:

> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there

$ sysctl -a | grep maxf
kern.maxfiles: 360
kern.maxfilesperproc: 360

`maxfiles' and `maxfilesperproc' have been runtime tunable for more
than 5 years (but there are still bugs in the implementation of this).

> are some nasty pageable region allocations for networking that
> appear to require contiguous regions for no good reason which I
> can discern).  That means that the best we can do right now is
> boot-time, so here it is:

True, things based on stale values of the variables don't work right.

> --
> Index: conf/param.c
> ===

Don't put anything more in param.c.  Almost everything in it can be
done better using tunables or sysctls.  The only thing that it is now
useful for is centralizing the #defines for bogus defaults based on
MAXUSERS.  This is unnecessary for tunables, since they don't need
static initializers.  E.g., the tunable for kern.maxfiles can be

TUNABLE_INT_DECL("kern.maxfiles", 2 * maxproc, maxfiles);

instead of

TUNABLE_INT_DECL("kern.maxfiles", MAXFILES, maxfiles);

Then maxfiles can be declared in the right place (not here).  There
would be a problem getting tunables set in the right order if maxproc
were tunable.  We also have a sysctl for maxproc, but it was made
read-only due to allocation problems for exec_map which went away long
ago.  Apparently the allocation problems for maxfiles and maxfilesperproc
aren't so serious, since the sysctls for these have always been
read-write.  The problems with these sysctls are more with their
interactions with setrlimit().

Bruce


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

Re: Boot messages

[Riccardo Torrini]

On 24-Apr-01 (23:19:59/GMT) Dima Dorfman wrote:

>>   WARNING: Driver mistake: repeat make_dev("pcaudio")
>>   WARNING: Driver mistake: repeat make_dev("pcaudioctl")

> As it says, this is a driver mistake.  It's a bug.

Ok.  It happens from first days of devfs.  I'm looking into
gnats but there isn't any reference to it.  Must send a PR?


>>   unknown:  can't assign resources...

> This is not a bug.  This is an FAQ.

Yes.  I know.  I'll try to explain better: where can I find a
list of unsupported PnP devices?  I only have an ethernet isa
card (ex0) and a sound isa card (AWE64).  Where all that PnP
devices come from?  Here is my dmesg:

[...]
pca0 at port 0x40 on isa0
ex0:  at port 0x300-0x30f irq 10 on isa0
ex0: Manual config, 16-bit bus, board id 0x006, stepping 0x0
ex0: Ethernet address 00:aa:00:ad:44:7c
sbc0:  at port 0x220-0x22f,0x330-0x331,0x388-0x38b
   irq 5 drq 1,5 on isa0
pcm1:  on sbc0
midi0:  on sbc0
midi1:  on sbc0
joy0:  at port 0x200-0x207 on isa0
midi2:  at port
   0x620-0x623,0xa20-0xa23,0xe20-0xe23 on isa0
emu2: DRAM size = 512KB
unknown:  can't assign resources
pca1:  at port 0x61 on isa0
WARNING: Driver mistake: repeat make_dev("pcaudio")
WARNING: Driver mistake: repeat make_dev("pcaudioctl")
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
[...]


And this?   What is it?  isa0: unexpected small tag 14


Thanks in advance,
Riccardo.

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

Re: cp -d dir patch for review (or 'xargs'?)

[Dima Dorfman]

Garance A Drosihn <[EMAIL PROTECTED]> writes:
> At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
> >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? ;-)
> 
> Well, I'm in the middle of a massive reorganization of
> all my machines at home (to fit in a new G4 Cube!), so
> I'm not paying as much attention to this as I would like.
> I think it's really great that Dima has volunteered to do
> the work...:-)
> 
>  From what I have been following, you had one patch to add
> the '-I' and '-i' options, and a different patch to add
> the newly proposed '-Y' option.  Right?

No, not quite.  It's the same patch.  The second one just has the 'Y'
option renamed to 'I' because I thought they did the same thing: they
don't.

> 
> The '-I' option is of interest because it is used in some
> other OS's, and is even defined in some standards, such as
> the SingleUnixSpec.  From that:
> 
> -I replstr
> Insert mode: utility will be executed for each line from
> standard input, taking the entire line as a single argument,
> inserting it in arguments for each occurrence of replstr.
> A maximum of five arguments in arguments can each contain
> one or more instances of replstr. Any blank characters at
> the beginning of each line are ignored. Constructed arguments
> cannot grow larger than 255 bytes. Option -x is forced on.
> 
> I think that if we're going to add a '-I', then we should
> follow that description.  Note that '-I', by definition,
> forces '-n 1'.  It will always pick up only one file from
> the input to xargs per command that xarg will generate.
> It allows things like:

Adding support for 'I' the way it's described above wouldn't be a
trivial as it was to add 'Y'.  The latter adds about 15 lines, while
the former may involve some restructuring of the code.

Xargs compiles the arguments to  as an array of pointers.  It
also has assumptions that argv is only touched in the begining.  It
wasn't a problem for -Y since it doesn't support the replstr being
embedded in an argument (e.g., for a replstr of "{}", "something{}"
will not work as one arugment, only "{}" will), and it didn't have to
touch argv more than twice (I just added a small loop before all
invocations of run()).  With -I, it'd probably be necessary to put a
large chuck of what is now main() inside a loop.  It's not exactly
rocket science, but not something I can whip up in an hour, either.
I'll see what I can do probably later this week.

Dima Dorfman
[EMAIL PROTECTED]

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

Re: Boot messages

[Dima Dorfman]

Riccardo Torrini <[EMAIL PROTECTED]> writes:
>   pca1:  at port 0x61 on isa0
>   WARNING: Driver mistake: repeat make_dev("pcaudio")
>   WARNING: Driver mistake: repeat make_dev("pcaudioctl")

As it says, this is a driver mistake.  It's a bug.  I don't know if
it's new or not since I don't have any computers with a sound card
(and thus have no need for pcaudio*).

>   unknown:  can't assign resources
>   unknown:  can't assign resources
>   unknown:  can't assign resources

This is not a bug.  This is an FAQ.  So much that it's actually
documented in (*gasp!*) the FAQ:

http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#PNP-RESOURCES

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

Boot messages

[Riccardo Torrini]

I'm trying to understand why this happens at boot and if is
my fault (maybe), strange hardware or undocumented feature :)
  isa0: unexpected small tag 14

  unknown:  can't assign resources

  pca1:  at port 0x61 on isa0
  WARNING: Driver mistake: repeat make_dev("pcaudio")
  WARNING: Driver mistake: repeat make_dev("pcaudioctl")

  unknown:  can't assign resources
  unknown:  can't assign resources
  unknown:  can't assign resources

What kind of hardware is inside my case?

I have only an AWE64 and an Intel Pro/10 (both isa devices)
and I am using devfs so how can I make_dev() something?
And also why soft links into /dev get lost after reboot?
How can I make them persistent?  Must do every boot?


Any help appreciated.  Thanks.
Riccardo.

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

PICOBSD stale?

[Leif Neland]

The ready-made PICOBSD-diskimages all seems to be based on FreeBSD 3.x

I also doesn't seem to be able to make picobsd from current sources, althugh I didn't 
try that hard.

Is picobsd stale?

Leif


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

RE: PATCH to make maxfiles, maxfiles per proc boot-time tunable

[Terry Lambert]

] Why assign them the value of 0?  Why not just stick them in the BSS?
] The SI_SUB_TUNABLE checks will initialize them to a value anyways..

Mostly, to leave them where I found them, for paranoia reasons.


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable

[Terry Lambert]

] This looks good except that ncallout is still based on MAXFILES,
] without this being fixed I think people might get bitten by
] raising the tuneable too high then being unable to allocate
] enough callouts.  Can you take a look at this and make sure there's
] nothing else using MAXFILES like that?

Everywhere else uses the value of the variable, rather than
the value of the MAXFILES manifest constant; this is true for
4.3-release, if not for -current, so -current should be checked
too, I suppose, but I can't see someone intentionally adding
another dependency.


I actually also have a question for you: what bad things really
happen if ncallout is (relatively) much smaller than maxfiles?
As far as I can tell, it doesn't cause real problems...


The "ncallout" value should technically be a power of 2; I think
the code in the various machdep.c is probably broken, and that
the valloc() ought to use "callwheelsize" instead of "ncallout",
so that "callwheelbits" is not inaccurate, nor is "callwheelmask".

In any case, I really can't see how to easily do this at runtime,
short of stuffing a SYSINIT(SI_SUB_TUNABLES, SI_ORDER_ANY) into
param.c; that really won't work, since the machdep.c code is
executed very early on in the boot cycle.

It seems that it needs to have a more direct reference to a:

TUNABLE_INT_FETCH("kern.ncallout", 0, ncallout);

Early on in cpu_startup().

I guess if you want to get technical, the fact that the sockets
and so on are allocated based on the value of maxfiles, and set
themselves based on a maximum value of both means that the
sockets stuff should be ripped out as a tunable entirely, and
left to rely only on maxfiles (not MAXFILES).

I guess that should you also want to get technical, the sysctl
for kern.maxfiles should really be read-only after boot, and
not read-write, since the socket structures have already been
(incorrectly) sized by the time you have a chance to adjust the
number in user space.

FWIW: ncallout is actually a larger can of worms than I wanted
to open, which is why I didn't just make it its own tunable...
would that be an acceptable compromise?


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

nroff -man broken?

[Riccardo Torrini]

# man man
Formatting page, please wait...mdoc error: end-macro (.em)
   respecification is not allowed. (#20)
   Should this have been `.Em ...'?
User Abort.
Done.


This happens over last week.  World of this night (after
cvsup with also make kernel and mergemaster, for 4 times).
I have also tryed to remove all */man/cat*/*gz compiled
manuals with but luck :(  Any hints?  Thanks.


Ciao,
Riccardo.

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

RE: PATCH to make maxfiles, maxfiles per proc boot-time tunable

[John Baldwin]

On 24-Apr-01 Terry Lambert wrote:
> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there
> are some nasty pageable region allocations for networking that
> appear to require contiguous regions for no good reason which I
> can discern).  That means that the best we can do right now is
> boot-time, so here it is:
> 
> 
> --
> Index: conf/param.c
> ===
> RCS file: /home/cvs/local_repo/FreeBSD/sys.releng4/conf/param.c,v
> retrieving revision 1.1.1.1
> diff -c -r1.1.1.1 param.c
> *** conf/param.c  2001/03/21 00:50:42 1.1.1.1
> --- conf/param.c  2001/04/19 20:57:59
> ***
> *** 44,49 
> --- 44,51 
>   #include "opt_param.h"
>   
>   #include 
> + #include   /* getenv_int */
> + #include  /* TUNABLE_INT_DECL */
>   
>   /*
>* System parameter formulae.
> ***
> *** 67,74 
>   #endif
>   int maxproc = NPROC;/* maximum # of processes */
>   int maxprocperuid = NPROC-1;/* maximum # of processes per
user */
> ! int maxfiles = MAXFILES;/* system wide open files limit
*/
> ! int maxfilesperproc = MAXFILES; /* per-process open files limit
*/
>   int ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
>   int mbuf_wait = 32; /* mbuf sleep time in ticks */
>   
> --- 69,78 
>   #endif
>   int maxproc = NPROC;/* maximum # of processes */
>   int maxprocperuid = NPROC-1;/* maximum # of processes per
user */
> ! int maxfiles = 0;   /* system wide open files limit */
> ! TUNABLE_INT_DECL("kern.maxfiles", MAXFILES, maxfiles);
> ! int maxfilesperproc = 0;/* per-process open files limit */
> ! TUNABLE_INT_DECL("kern.maxfilesperproc", MAXFILES, maxfilesperproc);
>   int ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
>   int mbuf_wait = 32; /* mbuf sleep time in ticks */

Why assign them the value of 0?  Why not just stick them in the BSS?
The SI_SUB_TUNABLE checks will initialize them to a value anyways..

-- 

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/

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

Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable

[Alfred Perlstein]

* Terry Lambert <[EMAIL PROTECTED]> [010424 11:59] wrote:
> It seems to me that these things are not boot-time tunable, and
> should be (really, they should be runtime tunable, but there
> are some nasty pageable region allocations for networking that
> appear to require contiguous regions for no good reason which I
> can discern).  That means that the best we can do right now is
> boot-time, so here it is:

This looks good except that ncallout is still based on MAXFILES,
without this being fixed I think people might get bitten by
raising the tuneable too high then being unable to allocate
enough callouts.  Can you take a look at this and make sure there's
nothing else using MAXFILES like that?

> 
> 
> --
> Index: conf/param.c
> ===
> RCS file: /home/cvs/local_repo/FreeBSD/sys.releng4/conf/param.c,v
> retrieving revision 1.1.1.1
> diff -c -r1.1.1.1 param.c
> *** conf/param.c  2001/03/21 00:50:42 1.1.1.1
> --- conf/param.c  2001/04/19 20:57:59
> ***
> *** 44,49 
> --- 44,51 
>   #include "opt_param.h"
>   
>   #include 
> + #include   /* getenv_int */
> + #include  /* TUNABLE_INT_DECL */
>   
>   /*
>* System parameter formulae.
> ***
> *** 67,74 
>   #endif
>   int maxproc = NPROC;/* maximum # of processes */
>   int maxprocperuid = NPROC-1;/* maximum # of processes per user */
> ! int maxfiles = MAXFILES;/* system wide open files limit */
> ! int maxfilesperproc = MAXFILES; /* per-process open files limit */
>   int ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
>   int mbuf_wait = 32; /* mbuf sleep time in ticks */
>   
> --- 69,78 
>   #endif
>   int maxproc = NPROC;/* maximum # of processes */
>   int maxprocperuid = NPROC-1;/* maximum # of processes per user */
> ! int maxfiles = 0;   /* system wide open files limit */
> ! TUNABLE_INT_DECL("kern.maxfiles", MAXFILES, maxfiles);
> ! int maxfilesperproc = 0;/* per-process open files limit */
> ! TUNABLE_INT_DECL("kern.maxfilesperproc", MAXFILES, maxfilesperproc);
>   int ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
>   int mbuf_wait = 32; /* mbuf sleep time in ticks */
>   
> --
> 
> 
>   Terry Lambert
>   [EMAIL PROTECTED]
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

PATCH to make maxfiles, maxfiles per proc boot-time tunable

[Terry Lambert]

It seems to me that these things are not boot-time tunable, and
should be (really, they should be runtime tunable, but there
are some nasty pageable region allocations for networking that
appear to require contiguous regions for no good reason which I
can discern).  That means that the best we can do right now is
boot-time, so here it is:


--
Index: conf/param.c
===
RCS file: /home/cvs/local_repo/FreeBSD/sys.releng4/conf/param.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 param.c
*** conf/param.c2001/03/21 00:50:42 1.1.1.1
--- conf/param.c2001/04/19 20:57:59
***
*** 44,49 
--- 44,51 
  #include "opt_param.h"
  
  #include 
+ #include /* getenv_int */
+ #include/* TUNABLE_INT_DECL */
  
  /*
   * System parameter formulae.
***
*** 67,74 
  #endif
  int   maxproc = NPROC;/* maximum # of processes */
  int   maxprocperuid = NPROC-1;/* maximum # of processes per user */
! int   maxfiles = MAXFILES;/* system wide open files limit */
! int   maxfilesperproc = MAXFILES; /* per-process open files limit */
  int   ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
  int   mbuf_wait = 32; /* mbuf sleep time in ticks */
  
--- 69,78 
  #endif
  int   maxproc = NPROC;/* maximum # of processes */
  int   maxprocperuid = NPROC-1;/* maximum # of processes per user */
! int   maxfiles = 0;   /* system wide open files limit */
! TUNABLE_INT_DECL("kern.maxfiles", MAXFILES, maxfiles);
! int   maxfilesperproc = 0;/* per-process open files limit */
! TUNABLE_INT_DECL("kern.maxfilesperproc", MAXFILES, maxfilesperproc);
  int   ncallout = 16 + NPROC + MAXFILES;   /* maximum # of timer events */
  int   mbuf_wait = 32; /* mbuf sleep time in ticks */
  
--


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

Re: [RFC] RELNOTESng for 5-CURRENT

[Kris Kennaway]

On Tue, Apr 24, 2001 at 09:25:34AM -0700, Alfred Perlstein wrote:

> Sounds like some excellent work that was long over due.  Go for it. :)

Agreed.

I've always found there are doc hackers willing to help with markup
problems on request, so I don't think that's a serious issue.

Kris

 PGP signature

Re: upgrading from 3.0 to 4.3

[Leif Neland]

> 
> I think the only path that we "officially" support is 3.x -> 3.4-stable ->
> 4.0-R -> 4.x-stable.  

Is this official path described somewhere?

i.e. cvsup to RELENG_3
make world
make kernel
reboot
cvsup to ...
eg-

I've got a 3.2-release I'd like to update.
Perhaps I just should do a binary?

Leif

Leif

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

RE: Install kernel gets divide overflow

[John Baldwin]

On 24-Apr-01 Gregory Bond wrote:
> [please CC replies; I'm not on the -current list]
> 
> I'm trying to boot a -CURRENT kernel to confirm it really does fix a problem 
> with my hardware (see kern/26046).
> 
> I've tried a couple of snapshots from current.freeebsd.org between 1st the
> 15th
> April.  None has booted.  Each dies with an integer divide trap after
> (during?)
> PnP processing. (This is booting the install floppies, not after an install).
> 
> Is this 
>  a) a known problem that will be fixed sometime soon, so just keep trying 
> occasionally
>  b) a big surprise to all concerned and deserving of further investigation, 
> starting with the output from "boot -v"
> ?

Weird, I installed the April 19 snap here locally on a testbox without any
problems.

-- 

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/

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

[Oliver Fromme]

Brian Somers <[EMAIL PROTECTED]> wrote:
 >> 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).

True, but that's certainly not xarg's fault (and
it cannot be fixed in the scope of xargs).  xargs
has no way to know if the command will enlarge its
environment, and by what amount.  In such a case
it's probably up to the script writer to chose a
sensible value for xargs -s .

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)

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

Re: vm_mtx

[Alan Cox]

> The Mach code we originally inherited was supposed to already by
> multiprocessor safe.  Did we manage to eliminate that capability?

Yes and no.  The vm_map layer still has the necessary locking calls,
but the vm_object and pmap layers don't.  The pmap is still similar
enough that the original locking scheme could be reapplied, perhaps
mechanically.

Alan


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

Re: [RFC] RELNOTESng for 5-CURRENT

[Alfred Perlstein]

* Bruce A. Mah <[EMAIL PROTECTED]> [010424 09:04] wrote:
> (Apologies to -doc people who have probably heard this ad nauseum.)
> 
> Over the past few months, I've been working on a project that I've
> taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and
> related files that we package along with a FreeBSD distribution.
> I've been soliciting feedback from the other -doc folks, and it's time
> to socialize this out to a wider audience.
> 
> The main problem this is intended to solve is that there's a lot of
> information in many different files, and not all of its is
> consistent.  For example, a list of hardware supported by FreeBSD can
> currently be found in four different places (the alpha and i386
> RELNOTES.TXT files, HARDWARE.TXT, and the Handbook).
> 
> What I've done is to reorganize and reformat all of the *.TXT files.
> The new versions of these files are done in DocBook/SGML, which is the
> markup language used for the Handbook, FAQ, and so on.
[snip]
> 
> I'd very much like to get comments from people.

Sounds like some excellent work that was long over due.  Go for it. :)

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]]
http://www.egr.unlv.edu/~slumos/on-netbsd.html

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

Re: PATCH: move struct netexport to struct mount

[Alfred Perlstein]

* Poul-Henning Kamp <[EMAIL PROTECTED]> [010424 03:08] wrote:
> 
> http://phk.freebsd.dk/patch/export.patch
> 
> 20010424export.patch
> 
> This patch moves the netexport structure from the fs-specific
> mountstructure to struct mount.
> 
> This makes the "struct netexport *" paramter to the vfs_export
> and vfs_checkexport interface unneeded.
> 
> Consequently that all non-stacking filesystems can use
> vfs_stdcheckexp().
> 
> At the same time, make it a pointer to a struct netexport
> in struct mount, so that we can remove the bogus AF_MAX
> and #include  from 

Nice, go for it.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]]
Represent yourself, show up at BABUG http://www.babug.org/

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

Re: vm_mtx

[Alfred Perlstein]

* Poul-Henning Kamp <[EMAIL PROTECTED]> [010424 08:36] wrote:
> In message <[EMAIL PROTECTED]>, Garrett Wollman write
> s:
> >< said:
> >
> >> You can find the work I've done so far to make a giant vm mutex
> >> here:
> >
> >The Mach code we originally inherited was supposed to already by
> >multiprocessor safe.  Did we manage to eliminate that capability?
> 
> I'm sure you are fully aware of the implications of the strategically
> placed "supposed" in your own sentence.  I have never heard anybody
> get Mach code multithreaded yet.

It's not just that, looking at the old code it doesn't seem to deal
very well actually performing the IO, there's also other issues
that Alan Cox and Matt Dillon explained to me where in certain
locations vm_object lists are traversed in forward and reverse
order, this causes a lock order problem, it could be fixed by
possibly sharing a lock across object chains, but for now moving
to a giant lock is still a step in the right direction because
as I've mentioned, with everything still under Giant we've still
got decent performance.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

[RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

(Apologies to -doc people who have probably heard this ad nauseum.)

Over the past few months, I've been working on a project that I've
taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and
related files that we package along with a FreeBSD distribution.
I've been soliciting feedback from the other -doc folks, and it's time
to socialize this out to a wider audience.

The main problem this is intended to solve is that there's a lot of
information in many different files, and not all of its is
consistent.  For example, a list of hardware supported by FreeBSD can
currently be found in four different places (the alpha and i386
RELNOTES.TXT files, HARDWARE.TXT, and the Handbook).

What I've done is to reorganize and reformat all of the *.TXT files.
The new versions of these files are done in DocBook/SGML, which is the
markup language used for the Handbook, FAQ, and so on.

This gives us several distinct advantages:

1.  By using conditional inclusion of text, we can have one set of
source files that contains platform-independent text plus text
applicable to particular architectures (no more double commits for
each new release note).  Looking down the road, when we support
other architectures (for example, ia64 or ppc), we'll have a
scalable way of handling them.

2.  By going to DocBook, we can produce release notes in formats other
than plain ASCII text; for example, we can do HTML or PDF.  We
gain greater readability, plus we can take advantages of features
such as hyperlinks within documents.  Of course the boot floppies
still get the TXT files.

3.  By adopting the same naming conventions and directory structures
as the doc/ subtree, we can support translations of release notes,
if the translation teams are so inclined.

4.  Reorganizing the *.TXT files elminates some redundant information
and reduces the number of files that people have to read through
(they're a bit longer, but better-organized).

There are two disadvantages to going this route.  I think they're
fairly minor:

1.  Generating a set of release notes requires the DocBook toolchain
to be built, as well as the doc/ subtree.  Note that RELNOTESng
will have absolutely no effect on the buildworld/installworld
procedure.

2.  It raises the bar a bit for committers wanting to make changes to
the release notes, since they'll need to make changes to the
DocBook files.

Barring objections, I want to commit RELNOTESng, plus a patch to src/
release/Makefile, to the CVS tree.  RELNOTESng still needs a bit of
testing, and so for now, I have it controlled by a make(1) flag
defaulting to off.  Once the bugs have been shaken out, I'll make
RELNOTESng the default and stop maintaining the *.TXT files. Eventually,
the *.TXT files will get removed.

There's a snapshot of RELNOTESng for -CURRENT, updated irregularly,
at:

http://people.freebsd.org/~bmah/relnotes/

It contains PDF, HTML, and TXT versions of the various documents, as
well as a tarball of my working sources, the patch for
src/release/Makefile to integrate RELNOTESng into the release build,
and an ISO of a 5.0-CURRENT, i386 release I did with RELNOTESng
enabled.

I'd very much like to get comments from people.

Bruce.



 PGP signature

Re: vm_mtx

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Garrett Wollman write
s:
>< said:
>
>> You can find the work I've done so far to make a giant vm mutex
>> here:
>
>The Mach code we originally inherited was supposed to already by
>multiprocessor safe.  Did we manage to eliminate that capability?

I'm sure you are fully aware of the implications of the strategically
placed "supposed" in your own sentence.  I have never heard anybody
get Mach code multithreaded yet.

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

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

vm_mtx

[Garrett Wollman]

< said:

> You can find the work I've done so far to make a giant vm mutex
> here:

The Mach code we originally inherited was supposed to already by
multiprocessor safe.  Did we manage to eliminate that capability?

-GAWollman


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

Re: duplicate locks and lock order reversal

[J Wunsch]

John Baldwin <[EMAIL PROTECTED]> wrote:

>> my current kernel cvsupped around Apr 14th tells me about
>> duplicate locks and lock order reversal. Is this reason to worry?

> This is a FAQ.  Please keep up with -current if you are tracking it.

That's simply impossible.  We would need another 24 hours per day to
follow all mailing lists on a daily basis.  Some people of us have a
day job and a family. ;-)

If it's a FAQ, we should IMHO maintain this as a document, sorta
like /usr/src/UPDATING is being maintained.  Something like
/usr/src/ERRATA or that?  When branching off into -stable, this
file can be left out.
-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

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

PATCH: move struct netexport to struct mount

[Poul-Henning Kamp]

http://phk.freebsd.dk/patch/export.patch

20010424export.patch

This patch moves the netexport structure from the fs-specific
mountstructure to struct mount.

This makes the "struct netexport *" paramter to the vfs_export
and vfs_checkexport interface unneeded.

Consequently that all non-stacking filesystems can use
vfs_stdcheckexp().

At the same time, make it a pointer to a struct netexport
in struct mount, so that we can remove the bogus AF_MAX
and #include  from 

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

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

Re: vm_mtx

[Alfred Perlstein]

* Alfred Perlstein <[EMAIL PROTECTED]> [010423 21:51] wrote:
> You can find the work I've done so far to make a giant vm mutex
> here:
> 
> http://people.freebsd.org/~alfred/vm.diff

I've refreshed the diff, it now makes it to:

vfs_default.c 545  <- recurses on vm_mtx here, oops. :)
vop_stdcreatevobject
vop_defaultop
vfs_object_create
ffs_mountfs
ffs_mount
vfs_mountroot_try
vfs_mountroot
mi_startup


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

Re: vm_mtx

[Alfred Perlstein]

* Rik van Riel <[EMAIL PROTECTED]> [010423 23:27] wrote:
> On Mon, 23 Apr 2001, Alfred Perlstein wrote:
> 
> > requires vm_page_queues_mtx:
> >  manipulation of vm_page_queues
> 
> [snip]
> 
> > pmaps spotted:
> > pmap_copy_page
> > pmap_page_protect
> 
> There is potential for nasty lock ordering conflicts here.
> 
> Page faults will govm_mtx -> vm_page_queues_mtx
> The pageout code goes  vm_page_queues_mtx -> vm_mtx

Actually vm_page_queues_mtx == vm_mtx.  At a later date I may look
at finegraining the vm_mtx down a bit, as it stands there was a
lot of code that manipulates flags inside of vm_pages and vm_objects
by using atomic ops.  Obviously this works ok when there's only
one consumer but it's really expensive to do so and would probably
do a lot better under a single mutex.

> Alternatively, the pageout code is all under the vm_mtx,
> during the whole duration, but that would lock out the
> other CPUs during a potentially long time.
> 
> It would also mean the kernel needs to have 2 versions
> of all the pmap functions ... one where the vm_mtx is
> already taken and one that needs to take the vm_mtx by
> itself (the alternative, fixing all the callers, is
> probably worse).

Fixing callers makes more sense from a performance standpoint,
basically there's probably signifigant amounts of code that
expects the vm not to change out from under it in between calls
into the vm.

> 
> An alternative could be to use trylock functions and
> let the pageout code back off whenever somebody is in
> a page fault. This will work because eventually all the
> page faulters will be waiting for free memory and none
> of them has any of the VM locks...

Well right now we're SOL on all sides, but honestly with it all
still under Giant the performance is OK, if we're able to lock down
a major subsystem we can only expect performance to get better.

Anyhow, at this point i'm more interested in people stepping up
with diffs rather than discussing my current broken ones. :)


-- 
-Alfred Perlstein - [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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