Re: Some info on the kgmon(8) manual page (regarding current) needed

[Bruce Evans]

On Wed, 27 Mar 2002, Robert Watson wrote:

> On Wed, 27 Mar 2002, Hiten Pandya wrote:
>
> > According to me, the utility shouldn't be using a hardcoded path to the
> > booting kernel, as this would affect kernels which were made by:
> >
> >   makeoptions   KERNEL=foo#Build kernel "foo" and install "/foo"
> >
> > What are your suggestions?
>
> The utility doesn't appear to have any hard-coded paths in it at all.  It
> gets them from one of two places: getbootfile(), or the command line.  If
> getbootfile() is used then it's right.  If you specify it on the command

The getbootfile() call is also wrong.  The default for kvm_openfiles()
(which happens to be getbootfile()) should be used.  Then kgmon would
know nothing about the details of where the kernel is, and shouldn't
document them.  Only kvm really knows where the kernel is.  More
important programs like fstat, ps (!) and pstat already use the default
for kvm_openfiles() and know nothing about the details except for
misdocumenting them by saying that the default is /kernel.

This was discussed when getbootfile() was implemented in 1994.
Documenting the details was considered to be too unwieldy.  Many
utilities that access the kernel use other parts of kvm ("-M core" and
"-N system" are basically the user interface to kvm_openfiles()) without
documenting exactly how kvm implements these or even referencing
kvm_openfiles(3).

A closer look shows that kvm_openfiles(3) and its getbootfile() call are
now almost irrelevant too.  Normally the kernel is live and symbols are
obtained using kldsym(2) (see kvm_nlist(3)); the "-N system" arg and
the result of getbootfile() are essentially ignored in this case.
Liveness is determined by the "-M core" arg.  The default corefile is
/dev/kmem, and using this or any other device file gives a "live" kernel.

The name of the kernel becomes relevant when the output of kgmon is used.
gprof doesn't know anything about kernels, so it needs a normal executable
file with symbols.  kgmon provides no hints about its name.  I always
invoke gprof on kernels using:

gprof -u `sysctl -n kern.bootfile` gmon.out

(kgmon has not been converted to produce .gmon instead of gmon.out,
so you have to tell gprof the name of the gmon file too.  If kgmon generated
.gmon, then it would actually need to know the name of the kernel.)

> line and that's wrong, it's your fault.  It's worth noting, as I did to
> Garance out-of-band, that the path returned by getbootfile() may be wrong
> for a variety of reasons, including:
>

> - The kernel at that path has been replaced for some or another reason,
>   including kernel upgrade.
>
> - The file system root doesn't match that used by the boot loader, either
>   because chroot() has occurred for the current process, or because the
>   root and boot devices differ (e.g., network load of kernel, local root
>   file system).
>
> getbootfile() is relatively unreliable, as such, but is a decent default.

It is supposed to be fairly reliable.  syslogd() still depends on it to
supply the kernel name which it prepends to every line of log files, and
I don't remember a single report about this name being wrong :-).

Bruce


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Hiten Pandya]

--- Robert Watson <[EMAIL PROTECTED]> wrote:
> I'd avoid your later changes involving describing how getbootfile() relies
> on sysctl in the kgmon(8) man page.  That's an implementation detail of
> the API, not of kgmon, and while it probably won't change, putting the
> information there increases the chances of it getting stale, as well as
> exposing system MIB information that has a well-documented API for
> accessing it.  Talking about the possible failure modes of the call
> probably is relevant, since that impacts correct functionality of
> kgmon(8).  Giorgos' patch, modulo reference to -N, is probably the right
> answer.

Understood. :-)

  -- Hiten

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Robert Watson]

On Wed, 27 Mar 2002, Hiten Pandya wrote:

> According to me, the utility shouldn't be using a hardcoded path to the
> booting kernel, as this would affect kernels which were made by: 
> 
>   makeoptions   KERNEL=foo#Build kernel "foo" and install "/foo"
> 
> What are your suggestions? 

The utility doesn't appear to have any hard-coded paths in it at all.  It
gets them from one of two places: getbootfile(), or the command line.  If
getbootfile() is used then it's right.  If you specify it on the command
line and that's wrong, it's your fault.  It's worth noting, as I did to
Garance out-of-band, that the path returned by getbootfile() may be wrong
for a variety of reasons, including:

- The kernel at that path has been replaced for some or another reason,
  including kernel upgrade.

- The file system root doesn't match that used by the boot loader, either
  because chroot() has occurred for the current process, or because the
  root and boot devices differ (e.g., network load of kernel, local root
  file system).

getbootfile() is relatively unreliable, as such, but is a decent default. 

> In any case, I will take the precautions which Giorgos has put in place,
> and will produce the patches accordingly. :)

I'd avoid your later changes involving describing how getbootfile() relies
on sysctl in the kgmon(8) man page.  That's an implementation detail of
the API, not of kgmon, and while it probably won't change, putting the
information there increases the chances of it getting stale, as well as
exposing system MIB information that has a well-documented API for
accessing it.  Talking about the possible failure modes of the call
probably is relevant, since that impacts correct functionality of
kgmon(8).  Giorgos' patch, modulo reference to -N, is probably the right
answer.

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


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Hiten Pandya]

--- Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> How about http://people.FreeBSD.org/~keramida/diff/kgmon.txt ?

Hmm, the patch looks pretty good, but we can use a bit of rewording which
will reflect what the code does.  Something like the following:

-- START --
Extract the name list from the specified system instead of the default
system bootreturned by getbootfile(3) call.  The value returned by
getbootfile(3), which is same as the value found in the "kern.bootfile"
sysctl.
--- END ---

> This was made after I chatted a bit with Robert Watson, and I'd like your
> comments before making any more changes to that poor manpage.  If we reword
> bits here and there and finally make it reflect as closely as possible what
> the code does, it will be cool :)

I know the above the suggestion I have given is a bit long, but clarifies
the matter completely according to me.  In this way, we do not have to
have /boot/kernel/kernel everywhere lying around the man page; but feel
free to give any suggestions. :)

Thanks,

  -- Hiten

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Bruce Evans]

On Wed, 27 Mar 2002, Hiten Pandya wrote:

> How come the kgmon(8) is still refering to /kernel?  Is this a bug or I
> am unaware of something? :)  If it is a bug, than I probably someone can
> commit the change in behalf of me.. :)

Same reason that most man pages that say where the kernel is still refer
to /kernel.  In section 8, only the ones related to booting and modules
(not including boot(8)) have been changed to refer to /boot/kernel.
/kernel is the correct place for me, so I won't be fixing this :-).

Bruc


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Giorgos Keramidas]

On 2002-03-27 16:44, Hiten Pandya wrote:

> --- Robert Watson <[EMAIL PROTECTED]> wrote:
> > I've committed a tweak to the man page, but think that the page may
> > actually be wrong in a more general sense: kgmon appears to use
> > getbootfile() so will actually use whatever path the sytem booted with.
> > While by default that will be /boot/kernel/kernel, it may be something
> > else, in which case kgmon tries to DTRT.
>
> According to me, the utility shouldn't be using a hardcoded path to the
> booting kernel...

How about http://people.FreeBSD.org/~keramida/diff/kgmon.txt ?

This was made after I chatted a bit with Robert Watson, and I'd like your
comments before making any more changes to that poor manpage.  If we reword
bits here and there and finally make it reflect as closely as possible what
the code does, it will be cool :)

Giorgos Keramidas   FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr}  http://www.FreeBSD.org/docproj/


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Hiten Pandya]

--- Robert Watson <[EMAIL PROTECTED]> wrote:
> I've committed a tweak to the man page, but think that the page may
> actually be wrong in a more general sense: kgmon appears to use
> getbootfile() so will actually use whatever path the sytem booted with.
> While by default that will be /boot/kernel/kernel, it may be something
> else, in which case kgmon tries to DTRT.

Unless changed with the -N flag it provides.

: --- Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
: There might be utilities left that use /kernel, instead of the currently
: used /boot/kernel/kernel, to find the kernel.  This means that before the
: manpage is changed, the appropriate source files need to be checked, to
: make sure that the manpage reflects what really happens in the programs
: themselves.  We don't want to blindly substitute /boot/kernel/kernel for
: all the instances of /kernel, and make the manpages inconsistent with the
: source, right?

According to me, the utility shouldn't be using a hardcoded path to the
booting kernel, as this would affect kernels which were made by:

  makeoptions   KERNEL=foo#Build kernel "foo" and install "/foo"

What are your suggestions?

In any case, I will take the precautions which Giorgos has put in place,
and will produce the patches accordingly. :)

Thanks,

  -- Hiten Pandya

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Robert Watson]

I've committed a tweak to the man page, but think that the page may
actually be wrong in a more general sense: kgmon appears to use
getbootfile() so will actually use whatever path the sytem booted with.
While by default that will be /boot/kernel/kernel, it may be something
else, in which case kgmon tries to DTRT.

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

On Wed, 27 Mar 2002, Hiten Pandya wrote:

> Hi all,
> 
> According to -current, isnt the kernel file located /boot/kernel?
> 
> How come the kgmon(8) is still refering to /kernel?  Is this a bug or I
> am unaware of something? :)  If it is a bug, than I probably someone can
> commit the change in behalf of me.. :)
> 
> Thanks,
> 
> -- 
> Hiten Pandya
> http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD)
> http://www.FreeBSD.org - The Power to Serve
> 
> Public Key: http://www.pittgoth.com/~hiten/pubkey.asc
> --- 4FB9 C4A9 4925 CF97 9BF3  ADDA 861D 5DBD E4E3 03C3 ---
> 


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Andrew R. Reiter]

On Wed, 27 Mar 2002, Hiten Pandya wrote:

:> Generate diffs -- send-pr.
:
:Does this apply to all the manual pages in -CURRENT? where /kernel
:should be /boot/kernel/kernel?  If this is the case, then I can just
:send one or two big PRs which have the patches.
:
:What are your suggestions? :)

This discussion should probably take place within the context of bug
reporting system; please submit a pr and we can discuss there.

:
:Thanks,
:
:-- 
:Hiten Pandya
:http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD)
:http://www.FreeBSD.org - The Power to Serve
:
:Public Key: http://www.pittgoth.com/~hiten/pubkey.asc
:--- 4FB9 C4A9 4925 CF97 9BF3  ADDA 861D 5DBD E4E3 03C3 ---
:

--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Hiten Pandya]

> Generate diffs -- send-pr.

Does this apply to all the manual pages in -CURRENT? where /kernel
should be /boot/kernel/kernel?  If this is the case, then I can just
send one or two big PRs which have the patches.

What are your suggestions? :)

Thanks,

-- 
Hiten Pandya
http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD)
http://www.FreeBSD.org - The Power to Serve

Public Key: http://www.pittgoth.com/~hiten/pubkey.asc
--- 4FB9 C4A9 4925 CF97 9BF3  ADDA 861D 5DBD E4E3 03C3 ---



msg36645/pgp0.pgp
Description: PGP signature

Re: Some info on the kgmon(8) manual page (regarding current) needed

[Andrew R. Reiter]

On Wed, 27 Mar 2002, Hiten Pandya wrote:

:Hi all,
:
:According to -current, isnt the kernel file located /boot/kernel?
:
:How come the kgmon(8) is still refering to /kernel?  Is this a bug or I
:am unaware of something? :)  If it is a bug, than I probably someone can
:commit the change in behalf of me.. :)

Generate diffs -- send-pr.

:
:Thanks,
:
:-- 
:Hiten Pandya
:http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD)
:http://www.FreeBSD.org - The Power to Serve
:
:Public Key: http://www.pittgoth.com/~hiten/pubkey.asc
:--- 4FB9 C4A9 4925 CF97 9BF3  ADDA 861D 5DBD E4E3 03C3 ---
:

--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

Some info on the kgmon(8) manual page (regarding current) needed

[Hiten Pandya]

Hi all,

According to -current, isnt the kernel file located /boot/kernel?

How come the kgmon(8) is still refering to /kernel?  Is this a bug or I
am unaware of something? :)  If it is a bug, than I probably someone can
commit the change in behalf of me.. :)

Thanks,

-- 
Hiten Pandya
http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD)
http://www.FreeBSD.org - The Power to Serve

Public Key: http://www.pittgoth.com/~hiten/pubkey.asc
--- 4FB9 C4A9 4925 CF97 9BF3  ADDA 861D 5DBD E4E3 03C3 ---



msg36632/pgp0.pgp
Description: PGP signature

some info

[Hiten Pandya]

hi all,
sorry for running -current.. but i am an enthusiastic
and challenging man...(boy)...

anyways.. whats a mutex and a lock order reversal...
if you could point to some good manual on these
subjects... thanks...

help is appreciated...

thanks again...


=
regards,
Hiten Pandya
<[EMAIL PROTECTED]>


MOTD: I just like _pumping_ the daylights out of a
PENGUIN!!!

__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

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

Re: some info (new)

[Maxime Henrion]

Hiten Pandya wrote:
> MH> The lock order verification is not part of the mtx
> MH> API.  It's debugging
> MH> stuff activated by default in -CURRENT.  If you do
> MH> not want to see these
> MH> warnings, remove ``options WITNESS'' from your
> MH> kernel conf or patch the
> MH> code to solve the problem :-)
> 
> hi,
> i know that bit.. the WITNESS option is commented
> which says about the mutexes, but what i mean.. if i
> wanted to patch a lock order reversal... how would i
> do that... (i am newbie [not so newbie..])..

First, locate the faulting part of code, then just modify it so that it
enforces the established lock order.  The way to fix it is somewhat
obvious, but it may indeed be very hard in some cases.

Good luck,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code

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

Re: some info (new)

[Hiten Pandya]

MH> The lock order verification is not part of the mtx
MH> API.  It's debugging
MH> stuff activated by default in -CURRENT.  If you do
MH> not want to see these
MH> warnings, remove ``options WITNESS'' from your
MH> kernel conf or patch the
MH> code to solve the problem :-)

hi,
i know that bit.. the WITNESS option is commented
which says about the mutexes, but what i mean.. if i
wanted to patch a lock order reversal... how would i
do that... (i am newbie [not so newbie..])..

thanks...

=
regards,
Hiten Pandya
<[EMAIL PROTECTED]>


MOTD: I just like _pumping_ the daylights out of a
PENGUIN!!!

__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

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

Re: some info

[Maxime Henrion]

Hiten Pandya wrote:
> hi all,
> sorry for running -current.. but i am an enthusiastic
> and challenging man...(boy)...
> 
> anyways.. whats a mutex and a lock order reversal...
> if you could point to some good manual on these
> subjects... thanks...
> 
> help is appreciated...
> 
> thanks again...

A mutex is an algorithmic object used to serialize operations.  It
stands for ``mutual exclusion''.  It's useful when the same code is ran
several times in parallel.  For example, if two threads wanted to modify
a linked list in the same time, there is a chance that the linked list
would get corrupted since an insert or remove operation is not atomic
(one of the thread could get preempted when it has not finished to
remove or insert an element, and thus the linked list is not in a normal
state).

In such cases, every part of the code that modify the linked list has to
obtain the mutex before doing it and release after.  If another thread
tries to acquire the mutex, it will block until the first thread has
released it.

When some code has to obtain two locks or more, deadlocks might happen.
If thread 1 has lock A and tries to acquire lock B while thread 2 has
lock B and wants lock A, then both threads will block indefinitely.  To
solve this, one way is to always obtain the lock in the same order.  The
warning messages you got show that some code is violating this lock
order somewhere.

I found ``Unix Internals'' from Uresh Vahalia to be a very good book on
this topic.

Hope this helps,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code

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

Re: some info (new)

[Maxime Henrion]

Hiten Pandya wrote:
> one more question... if there is a lock order
> reversal.. is there a way that can be solved.. for
> e.g. by using on of the MTX_XX things...

The lock order verification is not part of the mtx API.  It's debugging
stuff activated by default in -CURRENT.  If you do not want to see these
warnings, remove ``options WITNESS'' from your kernel conf or patch the
code to solve the problem :-)

Regards,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code

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

Re: some info (new)

[Hiten Pandya]

hi maxime...
thanks very very much.. now i get it...,
its like.. a mutex is a lock, which is used when
things are done in parralel and to avoid corruption of
the data which is being processed... i took an example
of the way i used to lock files in PERL, in order to
avoid multiple writes at the same time...

one more question... if there is a lock order
reversal.. is there a way that can be solved.. for
e.g. by using on of the MTX_XX things...

thanks...
regards...

Hiten Pandya
<[EMAIL PROTECTED]>
--- Maxime Henrion <[EMAIL PROTECTED]> wrote:
> Hiten Pandya wrote:
> > hi all,
> > sorry for running -current.. but i am an
> enthusiastic
> > and challenging man...(boy)...
> > 
> > anyways.. whats a mutex and a lock order
> reversal...
> > if you could point to some good manual on these
> > subjects... thanks...
> > 
> > help is appreciated...
> > 
> > thanks again...
> 
> A mutex is an algorithmic object used to serialize
> operations.  It
> stands for ``mutual exclusion''.  It's useful when
> the same code is ran
> several times in parallel.  For example, if two
> threads wanted to modify
> a linked list in the same time, there is a chance
> that the linked list
> would get corrupted since an insert or remove
> operation is not atomic
> (one of the thread could get preempted when it has
> not finished to
> remove or insert an element, and thus the linked
> list is not in a normal
> state).
> 
> In such cases, every part of the code that modify
> the linked list has to
> obtain the mutex before doing it and release after. 
> If another thread
> tries to acquire the mutex, it will block until the
> first thread has
> released it.
> 
> When some code has to obtain two locks or more,
> deadlocks might happen.
> If thread 1 has lock A and tries to acquire lock B
> while thread 2 has
> lock B and wants lock A, then both threads will
> block indefinitely.  To
> solve this, one way is to always obtain the lock in
> the same order.  The
> warning messages you got show that some code is
> violating this lock
> order somewhere.
> 
> I found ``Unix Internals'' from Uresh Vahalia to be
> a very good book on
> this topic.
> 
> Hope this helps,
> Maxime Henrion
> -- 
> Don't be fooled by cheap finnish imitations ; BSD is
> the One True Code


=
regards,
Hiten Pandya
<[EMAIL PROTECTED]>


MOTD: I just like _pumping_ the daylights out of a
PENGUIN!!!

__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

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

Re: "md" driver, some info

[Matthew Dillon]

:The "md" driver I committed today is mostly a proof-of-concept thing
:which came out of a chat with Peter Wemm.
:
:It acts like a disk in all aspects, although it will be hard to boot
:from it :-)
:
:It will do very simple compression, in that a sector (512bytes)
:which is filled with the same character throughout, will not be
:allocated as a full sector, instead just the byte value is saved.
:
:In practice this means that making a 10M filesystem doesn't take
:10M of ram, until you fill data into it.  The driver will also free
:the sectors after you delete a file from the filesystem (ufs only).
:
:# disklabel -r -w md0 auto
:# newfs md0c
:# vmstat -m | grep "   MD s"
:   MD sectors   635   318K318K 21136K  6350 0  512
:# mount /dev/md0c /mnt
:# cp /kernel /mnt
:# vmstat -m | grep "   MD s"
:   MD sectors  4178  2089K   2089K 21136K 41780 0  512
:# rm /mnt/kernel
:# vmstat -m | grep "   MD s"
:   MD sectors   636   318K   2120K 21136K 42400 0  512
:# umount /mnt
:# dd if=/dev/zero of=/dev/rmd0
:# vmstat -m | grep "   MD s"
:   MD sectors 0 0K   2120K 21136K 42400 0  512
:#

That's very interesting.  You can do the same thing with the VN
device, using swap-backing, except it does not do any compression.

test3:/root# vnconfig -s labels -c -S 32g vn0
test3:/root# pstat -s
Device  1K-blocks UsedAvail Capacity  Type
/dev/od0b 10484480  1048448 0%Interleaved
/dev/da1b 10484480  1048448 0%Interleaved
/dev/da2b 10484480  1048448 0%Interleaved
Total 31453440  3145344 0%

test3:/root# disklabel -r -w vn0 auto
test3:/root# newfs /dev/rvn0c
Warning: Block size restricts cylinders per group to 8.
/dev/rvn0c: 67108864 sectors in 2048 cylinders of 1 tracks, 32768 sectors
32768.0MB in 256 cyl groups (8 c/g, 128.00MB/g, 8128 i/g)
super-block backups (for fsck -b #) at:
 32, 262176, 524320, 786464, 1048608, 1310752, 1572896, 1835040, 2097184,
 2359328, 2621472, 2883616, 3145760, 3407904, 3670048, 3932192, 4194336,
 4456480, 4718624, 4980768, 5242912, 5505056, 5767200, 6029344, 6291488,
...
 62128160, 62390304, 62652448, 62914592, 63176736, 63438880, 63701024,
 63963168, 64225312, 64487456, 64749600, 65011744, 65273888, 65536032,
 65798176, 66060320, 66322464, 66584608, 66846752

test3:/root#  pstat -s
Device  1K-blocks UsedAvail Capacity  Type
/dev/od0b 104844888092   960356 8%Interleaved
/dev/da1b 104844888064   960384 8%Interleaved
/dev/da2b 104844888064   960384 8%Interleaved
Total 3145344   264220  2881124 8%
test3:/root# mount /dev/vn0c /mnt
test3:/root# cp /kernel /mnt
test3:/root# 
test3:/root# pstat -s
Device  1K-blocks UsedAvail Capacity  Type
/dev/od0b 104844888764   959684 8%Interleaved
/dev/da1b 104844888704   959744 8%Interleaved
/dev/da2b 104844888704   959744 8%Interleaved
Total 3145344   266172  2879172 8%

test3:/root# rm /mnt/kernel
test3:/root# pstat -s
Device  1K-blocks UsedAvail Capacity  Type
/dev/od0b 104844888092   960356 8%Interleaved
/dev/da1b 104844888064   960384 8%Interleaved
/dev/da2b 104844888064   960384 8%Interleaved
Total 3145344   264220  2881124 8%

test3:/root# umount /mnt
test3:/root# vnconfig -u vn0
test3:/root# pstat -s
Device  1K-blocks UsedAvail Capacity  Type
/dev/od0b 10484480  1048448 0%Interleaved
/dev/da1b 10484480  1048448 0%Interleaved
/dev/da2b 10484480  1048448 0%Interleaved
Total 31453440  3145344 0%


However, for general use it is recommended that one use the 
'reserve' flag for swap-backed VN filesystems to pre-reserve all
necessary swap in order to maintain performance.  And enabling
softupdates on it once you've newfs'd is also a good idea.

Just for kicks:

test3:/root# vnconfig -s labels -c -S 4t vn0
test3:/root# disklabel -r -w vn0 auto
test3:/root# disklabel vn0
...
bytes/sector: 4096
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 10737418240unused0 0   # (Cyl.0 - 4194303)
test3:/root# pstat -s
Device  1K-blocks UsedAvail Capacity  Type
Total 31453448  3145336 0%

test3:/root# newfs /dev/rvn0c
preposterous size 0 <---

I find that totally amusing.  I think I'm going to fix newfs, it really
should be able to handle a 4 terrabyte filesystem.

:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."

-Matt
Matthew Dillon 
<[EMAIL PROTEC

"md" driver, some info

[Poul-Henning Kamp]

The "md" driver I committed today is mostly a proof-of-concept thing
which came out of a chat with Peter Wemm.

It acts like a disk in all aspects, although it will be hard to boot
from it :-)

It will do very simple compression, in that a sector (512bytes)
which is filled with the same character throughout, will not be
allocated as a full sector, instead just the byte value is saved.

In practice this means that making a 10M filesystem doesn't take
10M of ram, until you fill data into it.  The driver will also free
the sectors after you delete a file from the filesystem (ufs only).

# disklabel -r -w md0 auto
# newfs md0c
# vmstat -m | grep "   MD s"
   MD sectors   635   318K318K 21136K  6350 0  512
# mount /dev/md0c /mnt
# cp /kernel /mnt
# vmstat -m | grep "   MD s"
   MD sectors  4178  2089K   2089K 21136K 41780 0  512
# rm /mnt/kernel
# vmstat -m | grep "   MD s"
   MD sectors   636   318K   2120K 21136K 42400 0  512
# umount /mnt
# dd if=/dev/zero of=/dev/rmd0
# vmstat -m | grep "   MD s"
   MD sectors 0 0K   2120K 21136K 42400 0  512
#

Currently the size is arbitrarily set at 2 sectors, just shy
of 10MB.

The driver can be nice-ified in various ways, suggestions and 
patches are welcome.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: silo overflows in CURRENT ... some info that may help

[Matthew Thyer]

Re-nicing wont help as I have just confirmed that the problem occurs
if I run MAME, exit MAME and then get on the net.

Very wierd...  after running MAME, the serial port is unusable for
ppp unless I reboot.   Just doing a DNS lookup causes several silo
overflows.   MAME does something very strange to the system.

I will grep the MAME source code for anything related to serial
ports.

Doug Russell wrote:
> 
> On Sun, 2 May 1999, Matthew Thyer wrote:
> 
> > I have been investigating the silo overflow situation for some time.
> >
> > I can trigger them every time by the following action:
> >
> > - Run M.A.M.E. (Multi arcade machine emulator) and then try to
> > download something. (I am using user mode ppp).
> 
> Can you nice M.A.M.E. slightly?
> 
> Later.. 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: silo overflows in CURRENT ... some info that may help

[Doug Russell]

On Sun, 2 May 1999, Matthew Thyer wrote:

> I have been investigating the silo overflow situation for some time.
> 
> I can trigger them every time by the following action:
> 
> - Run M.A.M.E. (Multi arcade machine emulator) and then try to
> download something. (I am using user mode ppp).

Can you nice M.A.M.E. slightly?

Later.. 





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

silo overflows in CURRENT ... some info that may help

[Matthew Thyer]

I have been investigating the silo overflow situation for some time.

I can trigger them every time by the following action:

- Run M.A.M.E. (Multi arcade machine emulator) and then try to
download something. (I am using user mode ppp).

I believe that the sio driver is its own worst enemy in that once
you get one silo overflow, it seems that the driver tries to compensate
but it only makes it worse as I continue to get them and the serial port
is unusable after that.   Exiting MAME doesn't help, I have to reboot
or I will be unable to do the smallest thing such as download my mail.

I dont think its just MAME but rather anything that thrashes the
interrupt system.

This is not related to newbus as it occurrred before then in just the
same manner.

I have seen this effect on my home system no matter what combination
of motherboard, modem, serial hardware.

I was running a patch to sio.c before newbus came in to improve the
speed at which the FIFO buffers were processed but MAME would still
trigger the start of the silo overflow storm.

With either a patched or unpatched system I can download huge files
no problems as long as I dont run MAME at any time.

Now dont say "just dont do that" (I know some of you will want to).

Kernel config is attached.
/etc/ppp/ppp.conf (edited) is attached.
dmesg output is also attached.

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC,
#  NCR PCI SCSI, APM and Intel PIIX power management.
#   $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $
# based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $
#
machine i386
ident   "MATTE"
maxusers20
options INCLUDE_CONFIG_FILE # Include this file in kernel
config  kernel  root on wd0
cpu I686_CPU
options CPU_DISABLE_5X86_LSSER  # Dont use if you use memory mapped I/O 
device(s).
options CPU_FASTER_5X86_FPU # Faster FPU exception handler
options NO_F00F_HACK# Disable Pentium F00F hack
# COMPATIBILITY OPTIONS
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options USER_LDT# Let processes manipulate their local 
descriptor table (needed for WINE)
options SYSVSHM # Enable SYSV style shared memory
options SYSVSEM # Enable SYSV style semaphores
options SYSVMSG # Enable SYSV style message queues
options MD5 # Include a MD5 routine in the kernel
options VM86# Allow processes to switch to vm86 
mode (needed for doscmd)
# DEBUGGING OPTIONS
options DDB # Enable the kernel debugger
#optionsINVARIANTS  # Extra sanity checking (slower)
#optionsINVARIANT_SUPPORT   # Include sanity checking 
functions
options UCONSOLE# Allow users to grab the console
options USERCONFIG  # Boot -c editor
options VISUAL_USERCONFIG   # Visual boot -c editor
# NETWORKING OPTIONS
options INET# Internet communications protocols
# Network interfaces:
pseudo-device   ether   # Generic Ethernet
pseudo-device   loop# Network loopback device
pseudo-device   tun 1   # Tunnel driver(user process ppp)
pseudo-device   streams # SysVR4 STREAMS emulation
# FILESYSTEM OPTIONS
options FFS # Berkeley Fast Filesystem
options FFS_ROOT# FFS usable as root device
options NFS # Network Filesystem
options CD9660  # ISO 9660 Filesystem
options MFS # Memory Filesystem
options MSDOSFS # MSDOS Filesystem
options PROCFS  # Process Filesystem
options NSWAPDEV=4  # Allow this many swap-devices
options SOFTUPDATES # SoftUpdates aka delayed writes
controller  pci0
controller  ncr0
options P1003_1B
options _KPOSIX_PRIORITY_SCHEDULING
options _KPOSIX_VERSION=199309L
# SCSI DEVICE CONFIGURATION (CAM SCSI)
controller  scbus0  at ncr0 # Base SCSI code
diskda0 at scbus0 target 0
disk