Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]

[Rodney W. Grimes]

> On 2017-Mar-2, at 7:19 AM, Steve Kargl  
> wrote:
> 
> On Thu, Mar 02, 2017 at 01:10:21PM +0100, Mateusz Guzik wrote:
> > On Wed, Mar 01, 2017 at 09:45:07AM -0800, Mark Millard wrote:
> >> 
> >>> Summary of the transition interval:
> >>> 
> >>> So for powerpc64 (and powerpc?) It is a good
> >>> idea to avoid anything that is after -r313254
> >>> and before -r314474 in head. (Would this be
> >>> appropriate for a UPDATING notice given its
> >>> span?)
> >>> 
> >>> There may be other architectures that might have
> >>> a similar status(?): the last fixes involved were
> >>> not in Machine Dependent code. (Some architectures
> >>> are apparently insensitive to the errors, such as
> >>> amd64).
> >>> 
> >> 
> >> When following current you are expected to be on the newest revision,
> >> so I don't think mentioning interim broken releases makes much sense.
> >> 
> > 
> > Documenting the range may aid those bisecting src/ to find a bug. 
> > How is one to know that anything in the range that Mark points
> > out should be skipped on powerpc64?
> > 
> > -- 
> > Steve
> 
> I have tested with a TARGET_ARCH=powerpc -r314473 build and
> its kernel version has locking problems like
> TARGET_ARCH=powerpc64 does for that version.
> 
> [Note: This was run on a PowerMac G5 so-called "Quad Core"
> so most of the memory was ignored.]
> 
> Both TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc need -r314474
> or later as of the new locking.
> 
> I've not explicitly tested other architectures. As I remember
> armv6/v7 are classified as having some from of a weak memory
> model compared to the likes of amd64. If so armv6/v7 might be
> candidates for having problems. There might be other candidates.

I also had locking issues on amd64 around this build time that
sent me down a week long rabbit hole chasing what I thought was
a bug in the new AMD/IOMMU code.  IMHO if we can at least
flag prior snapshot builds as "Broken for reason X" it might
save someone some time and time is a one way depleting resource
usually worth saving if possible.

If needed I can dig out the specifc build.  Oh, nvm, let me
just do that, it was r309302.  This revision I beleive is
a november snapshot.  It has kernel panics due to spinlock
timeout and sparatic deadlock that is undetected.


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: effect of strip(1) on du(1)

[Rodney W. Grimes]

-- Start of PGP signed section.
[ Charset ISO-8859-1 unsupported, converting... ]
> On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" 
>  wrote:
> >> du(1) is using fts_read(3), which is based on the stat(2) information.
> >> The OpenGroup defines st_blocksize as "Number of blocks allocated for
> >> this object."  In the case of ZFS, a write(2) may return before any
> >> blocks are actually allocated.  And thanks to compression, gang
> ...
> >My gut tells me that this is gona cause problems, is it ONLY
> >the st_blocksize data that is incorrect then not such a big
> >problem, or are we returning other meta data that is wrong?
> 
> Note that it's st_blocks, not st_blocksize.
Yes, I just ignore that digretion, as well as the digretion into fts_read
being anything special about this, as it just ends up calling stat(2) in
the end anyway.

> 
> I did an experiment, writing a (roughly) 113MB file (some data I had
> lying around), close()ing it and then stat()ing it in a loop.  This is
> FreeBSD 10.3 with ZFS and lz4 compression.  Over the 26ms following the
> close(), st_blocks gradually rose from 24169 to 51231.  It then stayed
> stable until 4.968s after the close, when st_blocks again started
> increasing until it stabilized after a total of 5.031s at 87483.  Based
> on this, st_blocks reflects the actual number of blocks physically
> written to disk.  None of the other fields in the struct stat vary.
 ^^^
Thank you for doing the proper regression test, that satisfies me that
we dont have a lattent bug sitting here and infact what we have is
exposure of the kernel caching, which I might be too thrilled about,
is just how its gona have to be.

> 
> The 5s delay is presumably the TXG delay (since this system is basically
> unloaded).  I'm not sure why it writes roughly ? the data immediately
> and the rest as part of the next TXG write.
> 
> >My expectactions of executing a stat(2) call on a file would
> >be that the data returned is valid and stable.  I think almost
> >any program would expect that.
> 
> I think a case could be made that st_blocks is a valid representation
> of "the number of blocks allocated for this object" - with the number
> increasing as the data is physically written to disk.  As for it being
> stable, consider a (hypothetical) filesystem that can transparently
> migrate data between different storage media, with different compression
> algorithms etc (ZFS will be able to do this once the mythical block
> rewrite code is written).

I could counter argue that st_blocks is:
st_blocks   The actual number of blocks allocated for the file in
 512-byte units.

Nothing in that says anything about "on disk".  So while this thing
is sitting in memory on the TXG queue we should return the number of
512 byte blocks used by the memory holding the data.
I think that would be the more correct thing than exposing the
fact this thing is setting in a write back cache to userland.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: effect of strip(1) on du(1)

[Rodney W. Grimes]

> On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper  wrote:
> > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
> >  wrote:
> > ...
> >> Even if that is the case file system cache effects should NOT be
> >> visible to a userland process.   This is NOT as if your running
> >> 2 different processing beating on a file.  Your test cases are
> >> serialially syncronous shell invoked commands seperated with
> >> && the results should be exact and predictable.
> >>
> >> When strip returns the operation from the userland perspecive
> >> is completed and any and all processeses started after that
> >> should have the view of the completed strip command.
> >>
> >> This IS a bug.
> >
> > Would the same statement necessarily apply if the filesystem was
> > writing things asynchronously to the backing storage?
> > Thanks,
> > -Ngie
> 
> du(1) is using fts_read(3), which is based on the stat(2) information.
> The OpenGroup defines st_blocksize as "Number of blocks allocated for
> this object."  In the case of ZFS, a write(2) may return before any
> blocks are actually allocated.  And thanks to compression, gang
> blocks, and deduplication, at this point it's not even possible for
> ZFS to know how many blocks it will need to allocate.  I think
> st_blocksize should be interpreted as a "best effort" output.  Just
> like df(1), you can't rely on du's output to be mathematically precise
> in any way.  I certainly don't see any way to fix it besides doing
> something like an fsync(2) before getting stat information, and we
> certainly don't want to do that.

My gut tells me that this is gona cause problems, is it ONLY
the st_blocksize data that is incorrect then not such a big
problem, or are we returning other meta data that is wrong?

Waving hands over this report as async write behind meta
data issues is not making sure we dont have a more serious
problem.

My expectactions of executing a stat(2) call on a file would
be that the data returned is valid and stable.  I think almost
any program would expect that.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: effect of strip(1) on du(1)

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
>  wrote:
> ...
> > Even if that is the case file system cache effects should NOT be
> > visible to a userland process.   This is NOT as if your running
> > 2 different processing beating on a file.  Your test cases are
> > serialially syncronous shell invoked commands seperated with
> > && the results should be exact and predictable.
> >
> > When strip returns the operation from the userland perspecive
> > is completed and any and all processeses started after that
> > should have the view of the completed strip command.
> >
> > This IS a bug.
> 
> Would the same statement necessarily apply if the filesystem was
> writing things asynchronously to the backing storage?

Caching should^h^h^h^hshall be transparent to a userland process.
Are you actually advocating that a userland process should
be able to see that zfs is write caching meta data?

The strip(1) command has completed and exited, pola dictates
that anything I asked strip(1) to do be reflected in all commands
or system calls executed after it.

Anything else would be a bug.

> Thanks,
> -Ngie

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: effect of strip(1) on du(1)

[Rodney W. Grimes]

> On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy  wrote:
> > On 2017-Mar-02 22:29:46 +0300, Subbsd  wrote:
> >>During some interval after strip call, du will show 512B for any file.
> >>If execute du(1) after strip(1) without delay, this behavior is reproduced 
> >>100%:
> >
> > What filesystem are you using?  strip(1) rewrites the target file and du(1)
> > reports the number of blocks reported by stat(2).  It seems that you are
> > hitting a situation where the file metadata isn't immediately updated.
> >
> > --
> > Peter Jeremy
> 
> 
> Got it. My filesystem is ZFS. Looks like when ZFS open and write data
> to file, we get wrong number of blocks during a small interval after
> writing. Thanks for pointing this out!

Even if that is the case file system cache effects should NOT be
visible to a userland process.   This is NOT as if your running
2 different processing beating on a file.  Your test cases are
serialially syncronous shell invoked commands seperated with
&& the results should be exact and predictable.

When strip returns the operation from the userland perspecive
is completed and any and all processeses started after that
should have the view of the completed strip command.

This IS a bug.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Fwd: Re: how to reduce the size of /usr/share/i18n data?

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> 
> So I am to take it that no-one has any idea how this stuff works and 
> how to stub it out?

I would be rather tempted to rm -r /usr/share/i18n and see what
fails.  Anything that fails should be patched to deal with the
fact locale date is missing.

Then the stub out would be a simple mater of making
src/share/i18n a SUBDIR += in the src/share Makefile
inside an .ifdef WITH_LOCALE or WITH_I18N.

Further stubbing out should be pursued if we want to get back
some of our embeded-friendly needs by making all of the locale
related code conditionally compiled during a make world.

Depressing fact:  The i18n directory alone is larger than
a full 386BSD 0.1+sources+patchkit install.

> On 1/11/2016 7:11 PM, Julian Elischer wrote:
> >
> > 01.11.2016 17:53, Julian Elischer ?:
> >> there are a number of packages that want to link with or use that 
> >> data, and you can't always disable it, but it's very very big 
> >> (38MB?), especially in the context of an appliance that doesn't 
> >> really need it at all.
> >>
> >>
> >> If anyone has a procedure to follow to put that onto a diet, maybe 
> >> just as a stub then I'm all ears.
> >
> > +1
> >
> > Introduction of such large part of base system is kind of 
> > catastrophe for embedded systems
> > that need only ASCII and may be additionally one of "good old" 8-bit 
> > locales.
> >
> > FreeBSD 11 got pretty large and embedded-unfriendly without clear 
> > way to exclude such unneeded parts.
> >

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Oversight in /etc/defaults/rc.conf

[Rodney W. Grimes]

> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===
> >> --- etc/defaults/rc.conf   (revision 302482)
> >> +++ etc/defaults/rc.conf   (working copy)
> >> @@ -695,6 +695,7 @@
> >>  rctl_enable="YES" # Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"   # rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
    Missing explination of knob
> >>  iovctl_files=""   # Config files for iovctl(8)
> >>
> >>  ##
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 
> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"

What ever is resolved you also need to add a # comment describing it.

> 
> instead?
> 
>   Cheers,
> 
>   Matthew

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 'make includes' ownership patch

[Rodney W. Grimes]

> On Mon, May 28, 2001 at 10:31:58AM -0700, Rodney W. Grimes wrote:
> > > On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
> > > > > This was on my TODO.  The only problem with INCOWN/INCGRP not being
> > > > > used here is that they were introduced long after include/Makefile.
> > > > 
> > > > And perhaps one should go read the commit message that introduced them...
> > > > it was an experiment, a sample test designed to only be used in -current
> > > > /usr/src/lib, that BDE, Sheldon and myself had long followon conversations
> > > > about, and got dropped into the cracks.
> > > 
> > > What was the reasoning for a serperate owner specification from BIN*?
> > 
> > Simple orthagonality.  Ie, each bsd.*.mk file typically has a seperate
> > set of *{DIR/OWN/GRP/MODE} specs.  bsd.inc.mk was cloned from another
> > bsd.*.mk file.
> 
> Well, I don't mind how it gets fixed, but it's very unorthogonal at
> the moment having to set two sets of OWN/GRP variables in order to
> make includes as non-root.
> 
> Someone tell me what they should be using and I'll fix it.

Change bsd.own.mk to:
INCOWN?=${BINOWN}
INCGRP?=${BINGRP}
INCMODE?=   ${NOBINMODE}

as a temporary hack until INC* and bsd.inc.mk is completed/gutted/replaced/
whatever.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

Re: 'make includes' ownership patch

[Rodney W. Grimes]

> On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
> > > This was on my TODO.  The only problem with INCOWN/INCGRP not being
> > > used here is that they were introduced long after include/Makefile.
> > 
> > And perhaps one should go read the commit message that introduced them...
> > it was an experiment, a sample test designed to only be used in -current
> > /usr/src/lib, that BDE, Sheldon and myself had long followon conversations
> > about, and got dropped into the cracks.
> 
> What was the reasoning for a serperate owner specification from BIN*?

Simple orthagonality.  Ie, each bsd.*.mk file typically has a seperate
set of *{DIR/OWN/GRP/MODE} specs.  bsd.inc.mk was cloned from another
bsd.*.mk file.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

Re: 'make includes' ownership patch

[Rodney W. Grimes]

> On Sat, May 26, 2001 at 03:06:00PM -0700, Kris Kennaway wrote:
> > On Sat, May 26, 2001 at 02:59:22PM -0700, Kris Kennaway wrote:
> > > Shouldn't the includes/Makefile be installing headers using
> > > INCOWN/INCGRP instead of BINOWN/BINGRP?  I ran into this when trying
> > > to do a 'make includes' as a normal user.
> > 
> > Oops, hit send too soon; more changes are required of the same form.
> > Before I go to the trouble of doing those, I might as well get
> > confirmation whether this is the right thing to do.
> > 
> This was on my TODO.  The only problem with INCOWN/INCGRP not being
> used here is that they were introduced long after include/Makefile.

And perhaps one should go read the commit message that introduced them...
it was an experiment, a sample test designed to only be used in -current
/usr/src/lib, that BDE, Sheldon and myself had long followon conversations
about, and got dropped into the cracks.

The name INC* is not clear as to be correct, per BDE it probably should be
HDR* or HDRS* (I specifically avoided that since existing Makefiles used
that, not knowing that BDE had seperately been eyeing HDRS* for what I
ended up calling INC*.)

Since, other commiters have ignored direct, and inderect requests not to
propogate this INC* experiment, and it now infects all the way back to
at least 3.x* and possibly 4.*, making it near impossible to clean up :-(.

So feel free to ignore this email and change src/include/Makefile any
way you wish...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

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

[Rodney W. Grimes]

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

My example should work for that, just replace the initial echo
with ``cd /topdir; find . -type f'', and replace your xargs
with my script, using -n 100 or -s of some sane value.

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

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

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

[Rodney W. Grimes]

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

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

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

[Rodney W. Grimes]

> 
> Folks,
> 
> although there was much rejoicing, I think there's no need for a
> new option to cp. Just use the toolbox, it's not too hard:
> 
> (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.

[You even taugh this old dog a new trick he totally blanked out on!!]

> 
> Or even
> 
> echo destdir >>bigfilelist
> xargs cp < bigfilelist
> 
> should do the trick.

I don't like this one, bigfilelist gets modified and may need
to be used again for something else.  Please don't commit this version
of the patch :-)

> Regards,
> 
>   Jens
> -- 
> Jens Schweikhardt http://www.schweikhardt.net/
> SIGSIG -- signature too long (core dumped)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

Re: ** HEADS UP ** portmap daemon renamed to rpcbind

[Rodney W. Grimes]

> Ok guys.  I just had to fix a problem with portmap in -stable related
> to binding to specific IP addresses so replies to UDP packets come 
> 'from' the proper IP address (for multi-homed hosts).

This has been a problem with portmap for as long as I can remember (back
to the SunOS 3.5 days) and if you have finally fixed it WONDERFULL!!!

I hope you have commited it, or well soon, to -stable, as this one has
surely been one to send many a young admin screaming from his cubicle
yelling ``but it should work, it really should just work''.

> Question:  Does the rpcbind program in -current have the same problem
> or has it already been fixed by whomever you imported the code from?
> (If it hasn't been fixed I'll be happy to fix it.  I'm hoping it has,
> though).

Given the length of time that this problem has existed some how I doubt
it...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

Re: tape device names and devfs

[Rodney W. Grimes]

> Christian Weisgerber wrote:
> > Steve Kargl <[EMAIL PROTECTED]> wrote:
> > 
> > I haven't heard any screaming yet.  Besides, this is -CURRENT.
> > devfs has also abandoned symlinks for 'r' disk devices.
> > 
> 
> The "r" in tape device names has traditionally meant "r"ewind.
> The "r" in disk names (such as rda0) meant a "r"aw device.

That is incorrect.  r is raw in both cases.  n is used to
designate non-rewind devices.  Please read mtio(4) and sa(4).

non-raw tape devices don't make since... they aren't random
block addressable devices.

> Raw devices (or block devices) were removed from current.  The
> rewind and non-rewind tape device names were changed under
> devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO
> violates POLA).
> 
> I suspect we'll hear scream when 5.0 is released and early
> adopters start to have their backup scripts die.
> 
> -- 
> Steve
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

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

Re: Core dumps on Current Make World this morning

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
> :
> >> In message <[EMAIL PROTECTED]> Matthew 
>Jacob writes:
> >> : Same with me.
> >> 
> >> This sounds like a job for Captain UPDATING:
> >
> >Don't you just need to rebuild vi/ex?  Ie would not:
> > cd /usr/src/usr.bin/vi;
> > make cleandir && make obj && make depend && make all install
> >
> >fix the problem?
> >
> >Two buildworlds seems like a big sledgehammer when a small tap with
> >a 2oz would do :-)
> 
> It's actually libc you need to reinstall (unless your vi/ex is
> statically linked).

Okay...
cd /usr/src/lib/libc;
make cleandir && make obj && make depend && make all install


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Core dumps on Current Make World this morning

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]> Matthew Jacob 
>writes:
> : Same with me.
> 
> This sounds like a job for Captain UPDATING:

Don't you just need to rebuild vi/ex?  Ie would not:
cd /usr/src/usr.bin/vi;
make cleandir && make obj && make depend && make all install

fix the problem?

Two buildworlds seems like a big sledgehammer when a small tap with
a 2oz would do :-)


> 20010101:
>   ex and vi were broken by some changes to sys/queue.h.  If
>   you have a bad vi (and are getting core dumps when building
>   termcap), you can work around this problem by adding -k to
>   your command line.  This will cause the build to complete
>   and install a new vi.  Once that's done, you can rebuild again
>   without the -k to pick up anything that might have been
>   ignored by the -k option.
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: randomdev entropy gathering is really weak

[Rodney W. Grimes]

> On Fri, 21 Jul 2000, Mark Murray wrote:
> 
> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next restart. We
> > call this data the reseed file."
> 
> I'm all for storing a sample at shutdown and using it to help seed the
> PRNG at startup, but it shouldn't be the only seed used (for example, the
> case where the system has never been shut down (cleanly) before and so has
> no pre-existing seed file is a BIG corner case to consider since thats how
> the system is at the time it first generates SSH keys after a fresh
> install).
> 
> It might be only an academic vulnerability, but if someone can read your
> HD during the time the system is shut down then I'd prefer them not to
> know the precise state when the system next starts up again. Yes, if they
> can read they can probably also write, but it seems like a mistake when
> there's nothing really gained by saving the complete state, as opposed to
> an extract.

And for folks like us who do mass installs via dd if=/dev/da1 of=/dev/da2,
where da1 is a mastered image created via ``make installworld DESTDIR=/mnt'',
the corner case is very large.  I have been bitten by an event where the
master disk was booted once before replication, and thus all systems
had _IDENTICAL_ /etc/ssh contents.  Not a very good idea !!

We have amended the manufacturing process now, so that part of the
disk replication is the nuking and regeneration of /etc/ssh.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

...
> >As far as I can tell the fxp driver doesn't even use the tx_fifo in the
> >825xxx chips :-)
> 
>The 82557-9 have a 2KB internal buffer for transmits. They don't start
> transmitting until a programmed threshold is reached - this is to insure
> that PCI bus latency doesn't result in the transmitter getting stalled.
> The fxp driver starts out with this threshold set at 512 bytes, but will
> increase it (512 bytes at a time) when a DMA underrun occurs. Of course
> once the threshold reached 1536, then an entire 1500 byte packet is DMA'd
> into the buffer before the transmit begins.

Can you point me to the part of if_fxp.c that does this, as alls I can find
about any form of fifo in the code are these references:

Guardian# grep -i fifo *fxp*
if_fxp.c:   cbp->rx_fifo_limit =8;  /* rx fifo threshold (32 bytes) */
if_fxp.c:   cbp->tx_fifo_limit =0;  /* tx fifo threshold (0 bytes) */
if_fxpreg.h:volatile u_int  rx_fifo_limit:4,
if_fxpreg.h:tx_fifo_limit:3,

No place do I find anything that does any adjustments to these values :-(.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> > Ohh... and a finally note, DEC blew the chip design by only including
> > a 160byte threshold point given that PCI 2.0 spec says it should have
> > been 500bytes!!
> 
> It wouldn't be the first thing DEC had screwed up in the design of
> these NICs.  On the other hand, Intel has owned the silicon for a
> couple of years now, which is more than enough time to unscrew it if
> they really wanted to.  Clearly, they'd rather be selling 82559s

As far as I can tell the fxp driver doesn't even use the tx_fifo in the
825xxx chips :-)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

> On Friday, 14th July 2000, "Rodney W. Grimes" wrote:
> 
> >>  I suspect an interaction between the ATA driver and VIA chipsets,
> >> because other than the network, that's all that is operating when I see
> >> the underruns.  And my Celeron with a ZX chipset is immune.
> >
> >I've seen them on just about everything, chipset doesn't seem to matter,
> >IDE or SCSI doesn't seem to matter.
> 
> Well, maybe they are just a fact of life.  But using just my vague knowledge
> of how PCI works, it doesn't look inevitable to me.  So I see bugs. :-)

Yes, there are bugs, it's in the poor specification of the PCI bus, and
in the even poorer implementation of PCI in hardware.  To qoute from the
PCI 2.0 spec, starting at the bottom of page 44, section 3.4.4.3
Latency Guidelines:

In most PCI systems, typical access latency is both short (likely
under 2us) and easily quantified.  However, worst case latency
(however rare) may not only be quite long, but in some cases quite
difficult to predict.  For example, latency to a standard expansion
adapter (ISA/EISA/MC) through a bridge is often a function of adapter
behavior, not PCI behavior.  (This is especially problematic since
some existing adapters are not compliant with latency parameters
defined by the associated bus standard.)  To compensate, masters
that require guaranteed worst case access latency must provide adequate
buffering for 30 microseconds.  This implies a minimum of about 50 bytes
of buffering for a 10Mbit/second LAN, and about 500 bytes for a
100Mbit/second LAN.  (If the buffers are line organized [i.e., 16- or
32-bit aligned] to imporove PCI and target memory utilization, minimum
buffer size likely increases.)  In spite of worst case uncertainty,
30 microseconds should provide sufficient margin for realizable system
designs.

My calculations say that 30uS is long enough to transfer about 3960Bytes,
now you see the problem???

I think the current driver behavior is near optimal, it backs down until
it becomes latency proof (store and forward is latency proof).  The only
thing it might do better is deal with the fact that short term bus starvation
should not effect long term performance, and as long as the underun events
have a tolerable frequence it should not down grade to store and forward.

Right now the code immediately steps the TXTHRESH every time we get an
underrun, this should probably use a frequency counter and not do this
unless we are seeing some untolerable rate of underruns.  Especially
when makeing the transition to store and forward.

Ohh... and a finally note, DEC blew the chip design by only including
a 160byte threshold point given that PCI 2.0 spec says it should have
been 500bytes!!  (Well, they blew it when the did the DC2114x enhancement
to the the DC2104x chip by not increasing the fifo depth to compensate
for the higher rate at which the fifo is emptied.)

> 
> >> Getting even more technical, it appears to me that the current driver
> >> instructs the 21143 to poll for transmit packets (ie a small DMA)
> >> every 80us even if there are none to be sent.  I don't know what percentage
> >> of bus time this might be, or even how to calculate it (got some time Rod?)
> >
> >I'll have to look at that.  If it is a simple 32 bit read every 80uS
> >thats something like .1515% of the PCI bandwidth, something that shouldn't
> >matter much.  (I assumed a simple 4 cycle PCI operation).  Just how big
> >is this DMA operation every 80uS?
> 
> I believe it is just one 32 bit read.  But I don't understand that aspect
> of the hardware very well yet.  I also suspect that this polling adds
> to the latency, but again, I haven't got to the end of that either.
> Sometimes other things can distract you from even the most interesting
> technical matter. :-)

:-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

[cc: trimmed to -current]

> >>>Does anyone here actually measure these latencies?  I know for a fact
> >>>that nothing I've ever done would or could be affected by extra latencies
> >>>that are as small as the ones we are discussing.  Does anybody at all
> >>>depend on the start-transmitting-before-DMA-completed feature we are
> >>>discussing?
> >> 
> >> I don't like the idea of removing that feature.  Perhaps it should be a
> >> sysctl or ifconfig option, but it should definitely remain available.
> >> Those minute latencies are critical to those of us who use MPI for
> >> complex parallel calculations.
> >
> >I have to agree here.  The store and forward adds an approximate
> >11uS (by theory under ideal conditions 1500bytes@132MB/s = 11uS,
> >practice actually makes this worse as typical PCI does something
> >less than 100MB/s or 15uS) to a 120uS packet time on the wire (again,
> >ideal, but here given that switches, and infact often cut-through
> >switches, are used for these types of things, ideal and practice
> >are very close.)
> >
> >I don't think these folks, nor myself, are wanting^H^H^H^H^H^H^Hilling
> >to give up 12.5%.
> 
> OK.  It seems that repairing the feature, rather than disabling it is
> the most popular option.  Still, I am quite interested in finding anyone
> who actually measures these things, and is affected by them. 

As already pointed out, anyone running computational code on a compute
cluster that is passing data around is directly affected by this.  I know
of at least 3 sites that converting to store and forward would destroy
as far as ``operational'' status goes.  They have gone the extra mile to
even use cut-through ethernet switches and I can assure you that an 11uS
delay per packet would have a significant impact on cluster performance.
They don't directly measure these values, but none the less they would
have an impact.

Also for those using dc21x4x cards in high load router and/or firewall
situations would notice this, though it would be harder to measure (well,
actually a pps test should show it quite clearly, as my above 12.5% was
based on full size packets, this becomes a larger percentage as packet
size is decreased).

> These very
> same people might be able to trace why we get the underruns in the first
> place.

Of the sites I know of they don't get these messages :-). 
I have noticed that I see them more often with the dc driver than I
do with the de driver, ie now that I am upgrading more and more of
our systems to 4.x from 3.x I have started to see these on machines
that have never reported them before.  Now this may be the driver,
or it could be some other part of system that has changed.

>  I suspect an interaction between the ATA driver and VIA chipsets,
> because other than the network, that's all that is operating when I see
> the underruns.  And my Celeron with a ZX chipset is immune.

I've seen them on just about everything, chipset doesn't seem to matter,
IDE or SCSI doesn't seem to matter.

> Back to the technical, for a moment.  I have verified that stopping the
> transmitter on the 21143 is both sufficient and necessary to enable the
> thresholds to be set.  I have code that works on my machine.  I intend
> to commit it when I think it looks neat enough.

Good.  That should help the folks with the major complaint of 2 to 3 second
network outages when one of the occur.  It may also be possible to simply
start out one step further down on the fifo level and eliminate the message
for most people.  (When I do see these it usually only happens once or
maybe twice, then the box is silent about it from then on.  I have never
seen a box back off to store and forward mode that didn't have some other
serious hardware related problem.)

> Getting even more technical, it appears to me that the current driver
> instructs the 21143 to poll for transmit packets (ie a small DMA)
> every 80us even if there are none to be sent.  I don't know what percentage
> of bus time this might be, or even how to calculate it (got some time Rod?)

I'll have to look at that.  If it is a simple 32 bit read every 80uS
thats something like .1515% of the PCI bandwidth, something that shouldn't
matter much.  (I assumed a simple 4 cycle PCI operation).  Just how big
is this DMA operation every 80uS?

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc driver and underruns (was: Strangeness with 4.0-S)

[Rodney W. Grimes]

> On Thu, 13 Jul 2000, Stephen McKay wrote:
> 
> >>Guess it will show up if you measure latencies (or your application is
> >>doing lots of RPCs). But as soon as there is a cheap 100baseT switch in
> >>the path to the destination, there will be store-and-forward at work ;-)
> >
> >Does anyone here actually measure these latencies?  I know for a fact
> >that nothing I've ever done would or could be affected by extra latencies
> >that are as small as the ones we are discussing.  Does anybody at all
> >depend on the start-transmitting-before-DMA-completed feature we are
> >discussing?
> 
> I don't like the idea of removing that feature.  Perhaps it should be a
> sysctl or ifconfig option, but it should definitely remain available.
> Those minute latencies are critical to those of us who use MPI for
> complex parallel calculations.

I have to agree here.  The store and forward adds an approximate
11uS (by theory under ideal conditions 1500bytes@132MB/s = 11uS,
practice actually makes this worse as typical PCI does something
less than 100MB/s or 15uS) to a 120uS packet time on the wire (again,
ideal, but here given that switches, and infact often cut-through
switches, are used for these types of things, ideal and practice
are very close.)

I don't think these folks, nor myself, are wanting^H^H^H^H^H^H^Hilling
to give up 12.5%.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: if_de as a module...

[Rodney W. Grimes]

> 
> This doesn't happen for me except in this (loadable de) case.

Well a bit more digging...
netstat -rn
205.238.40.30  205.238.40.30  UHW18 2563  dc0860

Now why oh why is gated and/or the kernel creating that route when
ifconfig dc0
dc0: flags=8843 mtu 1500
inet 205.238.40.1 netmask 0xffe0 broadcast 205.238.40.31
ether 00:80:c8:57:cc:45 
media: autoselect (10baseT/UTP) status: active
supported media: autoselect 100baseTX  100baseTX 10baseT/UTP 
 10baseT/UTP none

Now, 205.238.40.30 is a router, this route is visible in ospf,
here on the originating box:
205.238.40.30/32   -   local   CP   0   0   11049  11702

and here on another gated/FreeBSD box:
205.238.40.30  198.145.92.1   UGH 1  932  de1

and here from a Cisco:
O   205.238.40.30/32 [110/440] via 205.238.44.1, 00:07:33, Ethernet0

Now, what in the hell is deleting the normal arp:
? (205.238.40.30) at 0:c0:7b:6a:28:f0 [ethernet]

and replacing it with the above 205.238.40.30/205.238.40.30 route.

I've even done an ``arp -S 205.238.40.30 0:c0:7b:6a:28:f0'' to create
a ``permanant'' entry and IT gets replaced!!!

ARGHHH!!!!

> On Mon, 10 Jul 2000, Rodney W. Grimes wrote:
> 
> > > > Umm- started okay:
> > > :
> > > > and then died:
> > > > 
> > > > rplookup 192.67.166.155 failed: could not allocate llinfo
> > > > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > > > arplookup 192.67.166.155 failed: could not allocate llinfo
> > > > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > > > arplookup 192.67.166.155 failed: could not allocate llinfo
> > > > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > > > NFS Portmap: RPC: Port mapper failure - RPC: Timed out
> > > 
> > > Bleagh. Fooey. :-(
> > > 
> > > Biiilll!!?? :-)
> > 
> > I don't think this is Bill.  What does the output of
> > netstat -rn | grep 192.67.166.155 look like when the
> > above is occuring?
> > 
> > I am having similiar problems here, I just upgraded one of our
> > main boarder routers and started getting this stuff.  Is what
> > is happening is a host specific route is getting installed
> > by gated, and this is causing arplookup/arpresolve to have
> > problems when it tries to go create the llinfo.
> > 
> > We just upgraded this router from 3.4-stable of January vintage
> > to 4.0-STABLE FreeBSD July 2 vintage.  I have seen this in the
> > past, and though it was long gone, but now that I am looking
> > at it again I see what is happening, 
> > 
> > The message we get is the same as yours:
> > Jul  9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate
> > llinfo
> > Jul  9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30
> > rt
> > 
> > Now if I look in my routing table when this is going on (sorry don't have
> > it saved off anyplace I can cut and paste from right now) I see a host
> > route out another interface!!!  Yes, we have a large ospf network, yes
> > that route will work, no it is not the right route damn it, there is a
> > direct route via an interface, and we are trying to use it, but something
> > is blowing chunks in rtalloc1.
> > 
> > -- 
> > Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]
> > 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: if_de as a module...

[Rodney W. Grimes]

> > Umm- started okay:
> :
> > and then died:
> > 
> > rplookup 192.67.166.155 failed: could not allocate llinfo
> > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > arplookup 192.67.166.155 failed: could not allocate llinfo
> > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > arplookup 192.67.166.155 failed: could not allocate llinfo
> > arpresolve: can't allocate llinfo for 192.67.166.155rt
> > NFS Portmap: RPC: Port mapper failure - RPC: Timed out
> 
> Bleagh. Fooey. :-(
> 
> Biiilll!!?? :-)

I don't think this is Bill.  What does the output of
netstat -rn | grep 192.67.166.155 look like when the
above is occuring?

I am having similiar problems here, I just upgraded one of our
main boarder routers and started getting this stuff.  Is what
is happening is a host specific route is getting installed
by gated, and this is causing arplookup/arpresolve to have
problems when it tries to go create the llinfo.

We just upgraded this router from 3.4-stable of January vintage
to 4.0-STABLE FreeBSD July 2 vintage.  I have seen this in the
past, and though it was long gone, but now that I am looking
at it again I see what is happening, 

The message we get is the same as yours:
Jul  9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate
llinfo
Jul  9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30
rt

Now if I look in my routing table when this is going on (sorry don't have
it saved off anyplace I can cut and paste from right now) I see a host
route out another interface!!!  Yes, we have a large ospf network, yes
that route will work, no it is not the right route damn it, there is a
direct route via an interface, and we are trying to use it, but something
is blowing chunks in rtalloc1.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: cvs-crypto unknown

[Rodney W. Grimes]

> > cvsup4.freebsd.org does not know about cvs-crypto.
> > 
> > What is the correct collection?
> 
> src-crypto

Oopsss... never mind.  I think this has all been folded into
the baseline cvs target.  *-crypto is no more.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: cvs-crypto unknown

[Rodney W. Grimes]

> cvsup4.freebsd.org does not know about cvs-crypto.
> 
> What is the correct collection?

src-crypto


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: /sys hierarchy

[Rodney W. Grimes]

> On Sunday, July 02, 2000, Rodney W. Grimes wrote:
> > Actually the whole src/sys/compile thing should go away, it is
> > one of the last things that has to be dealt with for a totally
> > read-only mounted /usr/src.  IMHO it should be moved to /usr/obj,
> > and /usr/obj should, if it hasn't already, be enhanced to include
> > a ${MACHINE_ARCH} component.
> 
>It does already, but how do you propose the user build and
> install the kernel?  ``cd /usr/obj ...'' is inconsistent with any
> current procedures.

Just the argument to the cd has changed, the command sequence is
still:
cd blah
make depend && make && make install.

cd blah is currently
cd ../../compile/${KERNNAME}
it becomes
cd /usr/obj/`pwd`/${KERNNAME}

config(8) will need to produce a better makefile using `pwd` to
figure out the path to the kernel sources.  BDE probably has lots
of tips about how to do this.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: /sys hierarchy

[Rodney W. Grimes]

...
> I feel masochistic at the moment, so here's a suggestion.  Feel free
> to rip it all up to pieces, ya'll.  And to start off: I like green
> bikesheds.  (I.e. let's settle on something sensible and not get

I prefer blue ones :-)

...
> 
> Ok (/me dons the asbestos suit, climbs into the concrete room and locks
> the door.)  Here is my proposal.  It attempts to follow these loose guidelines:

Let me go hunting for flame thrower and concrete saw :-)

> - MD code under sys/${MACHINE_ARCH}
> - device drivers (including bus's such as cam and usb) under sys/dev

Perhaps, sys/bus and sys/dev, instead of lumping it all into one
sys/dev.  

> - networking under net/
That one is going to be a really really hard one over the longrun,
it is going to make the source code incompatible with every other
BSD based source tree requireing path mangling anytime something
is brought in from some place else.  Especially look at what
this would do to the /usr/include/net* hierarchy and how that
effects userland code.  Take a look at how many man pages this
would impact (to get an idea do ``cd /usr/share/man/man3;
zgrep netinet *''.)

> sys/
...
>   net/  - move existing contents to net/base or something similar
...
>atm/ - formerly sys/netatm
>natm/- formerly sys/netatm
Ooopsss... natm/ should go away, you already have a better place for that :-)

>ncp/ - formerly sys/netncp
>ns/  - formerly sus/netns
  ^
We have no sus directory :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: /sys hierarchy

[Rodney W. Grimes]

> On Sunday, July 02, 2000, John Baldwin wrote:
> > Sounds good to me actually.  Although, should it be ${MACHINE_ARCH}/compile
> > instead in keeping with the mentioned goal of keeping all MD stuff under
> > ${MACHINE_ARCH}?
> 
>I think that compile/${MACHINE_ARCH} is the proper way to do
> this.  Everything else is source only, all the object files end
> up inside compile/ so there's only one place to clean up.

Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src.  IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Abit BP6 - UDMA66 and non IBM disks

[Rodney W. Grimes]

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> It seems Arun Sharma wrote:
> > I have the following disk:
> > ad4: 9787MB  [19885/16/63] at ata2-master using UDMA33
> > and am experiencing hangs when I run it with UDMA66.
> 
> That exact disk model cant do UDMA66 reliably, even Linux has it
> on the blacklist in the driver
> 
> > I read the threads from Feb, where it was said that non IBM disks
> > had problems with the UDMA66 code in FreeBSD. Some of you said that
> > the disks worked just fine with other OSes.
> 
> Not all non IBM disks has problems, that was not the message back
> then, at least not from me. What I said, and still says, is that
> Maxtor and WDC has a bad reputation on making drives that can't work
> reliably with UDMA66, quantum has its share too but not so bad. 
> IBM's on the other hand works as expected...

Perhaps that is why Western Digital has gotten the nick name around
here of ``We Don't Care''.  :-)  In all seriousness we stopped using
WD drives in the retail store front computers over 2 years ago due to
they problems we have had with them.  Been using Fujitsu with very
good luck, and IBM on the higher end and been very happy with them.

We use to be big in Quantum scsi drives, but with IBM finally getting
it's supplier side act togeather as far as channel avaliability of the
SCSI products we've switched the AAI commercial server side over to them.
I can't remeber when the last problem was, ohh.. yea... 1 doa unit out
of 32 drives, probably caused during the assembly process of stuffing
them in the kingston canisters (a not too gental operation).  Infact
now that I think about it that is the only problem we have had with
IBM drives in over 500 units sold.  Not bad, thats a .2% AQL, something
I don't recall seeing in any disk drive product line we have used over
the last 8 years !!

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: SMP changes and breaking kld object module compatibility

[Rodney W. Grimes]

{First one bounced by hub with ``out of memory'' error... second attempt}

> > Are there any 3rd party NIC klds yet?
> 
> NTMK.
It's not quite a kld, but ET Inc's modules are distributed as a .o.

Also I know of work underway to support some of the fancier SDL WanNic
cards that would have to be kld's or .o's as well, due to NDA on parts
of the code used to develope them.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: SMP changes and breaking kld object module compatibility

[Rodney W. Grimes]

> On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
> 
> > That is also partly why you are also lacking the respect and support of a 
> > wider audience. If you act like FreeBSD is just a "developer's sandbox", 
> > that's what it will be. If you want it to be something greater than that, you
> > must consider what you are doing to third party developers and end users.
> 
> Developers and early adopters are the ones tracking -STABLE. Users are
> installing binary snapshots and releases.

Some users do install snapshots and/or releases.  Snap shots occur on a
regular basis and are affected by this change in API.

> No-one in their right mind would release a module for "4.0-STABLE sometime
> between april and may". They release for 4.0-RELEASE or 4.1-RELEASE,
> this would not cause problems for those people.

Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying
to use vendor X module for 4.0-release.  Get it??

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: SMP changes and breaking kld object module compatibility

[Rodney W. Grimes]

> > Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
> > so every vendor that has ever tried to use them has been bitten by the
> > fact that they have to maintain N version for each branch of FreeBSD???
> 
> Can you list some specific examples?  I'm not trying to be a wise-ass,
> I'm trying to figure out which vendors are using KLDs in general since
> I've still yet to actually bump into a real-life example of this kind
> of breakage in the field.  I'm not saying that it's never happened,
> I'm simply saying that I've not seen it and would like some details on
> such incidents - company name and module type will do fine.

I have never been able to keep our ET Inc based routers any where near
up to date as far as kernels go, no, they don't use kld's, they use .o's,
but it is caused by the same set of problems.

I do know from interacting with Dennis at ET Inc that the changes
in the interfaces of the FreeBSD kernel have kept him from even trying to
be very up to date with driver code.

I also have a kld from a source I can't say, to support hardware I can't tell
about...  (No, this is not a straw man, it's called NDA red tape :-().

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: SMP changes and breaking kld object module compatibility

[Rodney W. Grimes]

> On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
> > On a released system, I may not have the sources to recompile the module.
> > It might be a proprietary module that I got with the hardware, for example.
> 
> How real is this?  What modules are we talking about?  The last time
> I queried on `-stable' for users of third-party modules, only one was
> revealed.

Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
so every vendor that has ever tried to use them has been bitten by the
fact that they have to maintain N version for each branch of FreeBSD???

> Are all modules effected, or only those that use certain interfaces?

Given that this is a change in splxxx() I suspect that it breaks
most modules, but probably not all modules.  A quick grep -l spl * | wc
vs ls | wc shows 77 out of 100, not exact due to probable false hits on
spl, but it gets us the ball park, significant is what is says.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Rodney W. Grimes]

> 
> :
> :In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> :
> :>There's another good reason to MFC the linux patch on wednesday... 
> :>that is, to do it at the same time the SMP cleanup is MFC'd, and that
> :>is because both patch sets require the linux kernel module to be 
> :>recompiled and I'd rather not force people to do that twice. 
> :
> :Matt, this is not a valid reason either.
> :
> :Unless there is *urgent* and *overriding* reasons, and that basically
> :means that the security-officer says so, all changes must be shaken
> :out in -current first.
> :
> :That's just the way it is Matt.  Get used to it.
> :
> :--
> :Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> 
>I think you're confused, Poul.  I've gone over the commits made
>to the tree by people over the last few months and frankly there
>are dozens of simultanious -current and -stable commits.  A quick
>check shows that most of them are trivial bug fixes.  

And look at how many of them had to be patched, re-merged, etc.  IMHO
people are getting way way to loose with MFC right after a commit.  I
don't even want to see a MFC for a 1 character spelling fixed MFC'ed
in less than 3 days anymore.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Rodney W. Grimes]

> There's another good reason to MFC the linux patch on wednesday... 
> that is, to do it at the same time the SMP cleanup is MFC'd, and that
> is because both patch sets require the linux kernel module to be 
> recompiled and I'd rather not force people to do that twice. 
> 
> The SMP patchset, in fact, requires that all kernel modules be 
> recompiled due to the locks that were removed from the spl*() macros.

In that case I have a strong objection to the SMP patchset being
merged to 4.0.  I have kernel modules in object format only that
are working now, which this would break :-(.

Either way, nothing ever should me an immediate MFC, even a blantant
security hole should not be MFC'ed immediately, code needs to be
tested, and some other person might find a few niglets that need
cleaned up before you MFC it.  Who knows, you might even break the
system, and an immediate MFC would break both at once.

Never, ever should anything be immediatly merged.  IMHO, no even
spelling fixes, as I have seen those done wrong, patched, and MFC'ed
again.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: missing functionality

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> > to include support for the MCA bus.  The vast majority of MCA bus
> > machines in existence utilize ESDI because they predate the UDMA and
> 
> AFAIK, the only MCA disk controller supported does SCSI.

The IBM PS/2 family supported them all, ST506, ESDI and SCSI...

Being that I have all the IBM PS/2 FE service documents, a quick
look at just the Model 80 option list gives me:

90X9063 Fixed Disk Drive Adapter (ESDI)
72X8540 Fixed Disk Drive Adapter (ST506)
15F6779 SCSI Adapter/A With Cache

I probably also have at least 1 of each of these cards around here...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Overwhelming messages from /sys/netinet/if_ether.c

[Rodney W. Grimes]

> No...

Yes...  that is just the type of thing the link local RFC reserved address
space is for.

> In message <[EMAIL PROTECTED]>, Mathew Kanner writes:
> >On Apr 07, Donn Miller wrote:
> >> Since I started using a cable modem and dhclient, my system has been
> >> literally overwhelmed with messages like:
> >> 
> >> /kernel: arp: xx:xx:xx:xx:xx:xx is using my IP address 0.0.0.0!
> >> 
> >
> > I haven't tried this but how about changing the
> >/sbin/dhclient-script to not use 0.0.0.0 as the address that wakes up
> >the interface.  
> >
> > --Mat
> >
> >
> >To Unsubscribe: send mail to [EMAIL PROTECTED]
> >with "unsubscribe freebsd-current" in the body of the message
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Overwhelming messages from /sys/netinet/if_ether.c

[Rodney W. Grimes]

> > > The message in question can be extremely useful in case there is IP address
> > > clash on the local network. I suggest we just change the code in question to
> > > ignore clashes over 0.0.0.0 address only.
> > 
> > No, don't do that, anyone arping 0.0.0.0 on any network around here
> > I sure as heck want to know about it asap!
> 
> Then use a tool designed for the job.  You'll only get this message on a 
> system that's a DHCP client and currently trying to get a lease.  I don't 
> think that you would ever get any utility from the code as it stands, so 
> the change is not going to affect you.

I get plenty of utility from it as it stands.  Any time I see one of these
in a syslog I go track it down and shoot the cause.

> (Note that if you were to configure a system to listen on 0.0.0.0 in 
>  order to use this message, you would then be arping for 0.0.0.0, which 
>  would appear to defeat your purpose.)

My use of the message has nothing to do with wanting to use 0.0.0.0, it's
another part of the diagnostics used in maintaining networks for people.
Knowing that someone is arping 0.0.0.0 lets me know someone has jacked
into one of the networks and trying to either use DHCP or has mis-configured
thier box, or is trying to hack.

I won't object to the change if a sysctl knob is put around it, that
defaults to the way things are now, if someone doesn't care to see
these messages due to being on borked networks, fine, let them turn
it off.

> Can I kindly suggest that you go find a bridge or a dam or some 
> gun-control law to go oppose for a few months?  This random sniper 
> activity is pretty irritating. 8(

It is not random sniper activity.  I've been on this list since it
was created.  I respond when I have something to say and am silent
when I have nothing to say.

Also that comment is un-called for, it's on the edge of policy violation,
and I expect to be respected, no matter how much you may dislike me.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Overwhelming messages from /sys/netinet/if_ether.c

[Rodney W. Grimes]

> FreeBSD dhclient-script assigns 0.0.0.0 address to the interface in PREINIT
> in order to bring interface up. Windows seems to do that as well or
> there is no sane explanation for the relatively big number of these  nasty
> messages I am getting every time MediaOne network goes down and several PCs
> sharing the same cable network segment attempt to renew their lease at the same
> time.

Ahhh... then perhaps a better fix is to change the gratitious arp routine
to _not_ emit the bogus arp who-has arp-i-am when an interface is ifconfig'ed
to 0.0.0.0 rather than cause the error logging code to be disabled?

> 
>  
> On 07-Apr-00 Rodney W. Grimes wrote:
> >> The message in question can be extremely useful in case there is IP address
> >> clash on the local network. I suggest we just change the code in question to
> >> ignore clashes over 0.0.0.0 address only.
> > 
> > No, don't do that, anyone arping 0.0.0.0 on any network around here
> > I sure as heck want to know about it asap!  Someone someplace on
> > that stupid telco's DSL bridged network is mis-configured and
> > sending out arp messages for the 0 addresses.  Easy enough to
> > cause though:
> > 
> > ifconfig xx0 0.0.0.0 up
> > 
> > should do the trick...
> > 
> --
> E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
> Date: 07-Apr-00
> Time: 14:35:14
> --
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Overwhelming messages from /sys/netinet/if_ether.c

[Rodney W. Grimes]

> The message in question can be extremely useful in case there is IP address
> clash on the local network. I suggest we just change the code in question to
> ignore clashes over 0.0.0.0 address only.

No, don't do that, anyone arping 0.0.0.0 on any network around here
I sure as heck want to know about it asap!  Someone someplace on
that stupid telco's DSL bridged network is mis-configured and
sending out arp messages for the 0 addresses.  Easy enough to
cause though:

ifconfig xx0 0.0.0.0 up

should do the trick...


> On 07-Apr-00 Donn Miller wrote:
> > Since I started using a cable modem and dhclient, my system has been
> > literally overwhelmed with messages like:
> > 
> > /kernel: arp: xx:xx:xx:xx:xx:xx is using my IP address 0.0.0.0!
> > 
> > Man, these messages were pouring out of syslogd like mad, and my
> > /var/log/messages* files had to be deleted, because they were growing
> > so huge.  There were literally hundreds of these messages pouring out
> > via syslogd per second, and they were coming non-stop.  There were so
> > many messages coming out, my hard drive was overwhelmed until dhclient
> > finally obtain/ed a lease.  That said, I suggest we make the following
> > patch to /sys/netinet/if_ether.c:
> > 
> > --- if_ether.c.orig Wed Mar 29 02:50:39 2000
> > +++ if_ether.c  Fri Apr  7 11:24:54 2000
> > @@ -554,9 +554,9 @@
> > return;
> > }
> > if (isaddr.s_addr == myaddr.s_addr) {
> > -   log(LOG_ERR,
> > +   /* log(LOG_ERR,
> >"arp: %6D is using my IP address %s!\n",
> > -  ea->arp_sha, ":", inet_ntoa(isaddr));
> > +  ea->arp_sha, ":", inet_ntoa(isaddr)); */
> > itaddr = myaddr;
> > goto reply;
> > }
> > 
> > 
> > - Donn
> 
> --
> E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
> Date: 07-Apr-00
> Time: 11:49:33
> --
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Experts only please! (was Re: Preliminary SMP/BGL patch)

[Rodney W. Grimes]

> At 2:57 PM -0500 2000/3/24, Garance A Drosihn wrote:
> 
> >  At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
> >> This is not a 'normal Matt patch' that 'just works'.  Ok, it seems to
> >> just work, but it's not a normal Matt patch.  If there were a
> >> designation before 'early alpha' this patch would get it.
> >
> >  "Rough-draft proposal for early alpha version"
> 
>   "Theoretical basis for early access to code virtually guaranteed 
> to mess up your system in highly entertaining ways, although the 
> complete reinstall and rebuild might be rather annoying"

Proof Of Concept (POC) is probably the more accurate term...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: patches for test / review

[Rodney W. Grimes]

> On Tue, Mar 21, 2000 at 01:14:45PM -0800, Rodney W. Grimes wrote:
> > > On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> > > > :> 
> > > > :> I would think that track-caches and intelligent drives would gain
> > > > :> much if not more of what clustering was designed to do gain.
> > > > :
> > > > :Hm. But I'd think that even with modern drives a smaller number of bigger
> > > > :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
> > > 
> > > > As long as you do not blow away the drive's cache with your big I/O's,
> > > > and as long as you actually use all the returned data, it's definitely 
> > > > more efficient to issue larger I/O's.
> > > 
> > > Prefetching data that is never used is obviously a waste. 256K might be a
> > > bit big, I was thinking of something like 64-128Kb 
> > > 
> > > Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 
> > 
> > Your a bit behind the times with that set of numbers for modern SCSI
> > drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
> > most common.
> 
> Your drives are more modern than mine ;-) What drive has 16 Mb? Curious
> here..

Seagates latest and greatest drives have a 4MB cache standard and an option
for 16MB.  These are 10K RPM chetta drives.  


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: patches for test / review

[Rodney W. Grimes]

> On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> > :> 
> > :> I would think that track-caches and intelligent drives would gain
> > :> much if not more of what clustering was designed to do gain.
> > :
> > :Hm. But I'd think that even with modern drives a smaller number of bigger
> > :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
> 
> > As long as you do not blow away the drive's cache with your big I/O's,
> > and as long as you actually use all the returned data, it's definitely 
> > more efficient to issue larger I/O's.
> 
> Prefetching data that is never used is obviously a waste. 256K might be a
> bit big, I was thinking of something like 64-128Kb 
> 
> Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 

Your a bit behind the times with that set of numbers for modern SCSI
drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
most common.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Streamlining FreeBSD installations across many machines

[Rodney W. Grimes]

> In article <[EMAIL PROTECTED]>, Rodney W. Grimes
> <[EMAIL PROTECTED]> wrote:
> 
> > A much faster way to do this is to just dd the first few megabytes
> > of the disk (dd if=foo of=/dev/rXXd bs=32768 count=1024).  Then use
> > dump | restore to populate the disk.
> 
> Do you run newfs on the receiving disk before the dump|restore?  It
> seems like if you didn't then the free block bitmaps in the cylinder
> groups would contain garbage.

Ooopsss.. left a step out... yes.. we newfs the disk after the dd
operations.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> >> The maximum for full-duplex is utterly irrelevant, since the bounds on
> >> performance for half-duplex Ethernet networks come from CSMA/CD.
> 
> > I will say it one last time, duplex falls out of the equations when you
> > solve for ``maximal''.
> 
> Nonsense.

Either stop saying that or put up the formula's like I did that show
that duplex enters into the L2 maximal data rate.

> > It has 0 meaning in the numbers used.  Go read
> > my analysis and tell me why I can't pump 12MB/sec on 100BaseTX,
> 
> By no means -- you certainly can do that, if you have only one station
> sending at a time.  Of course, a monologue is by definition not useful
> communication.

You have a very twisted definition of communication.

> > You keep throwing P(coll) in, P(coll) only occurs if your upper layer is
> > causing P(coll) by doing things like ack packets.
> 
> I'd certainly like to see a demonstration of your network using ESP
> for reliability.

Have you ever calculated the BER of a controlled CSMA/CD network?  It
is something like 10^-9.  I could show you 4 working implementations
of this, but I would have to call the boys in grey coats afterwards.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> >> I answered SPECIFICALLY about half-duplex.
> 
> > The duplex does not in any way effect the maximal link layer transmission
> > data rate.  You seem to keep forgetting the maximal part...
> 
> The maximum for full-duplex is utterly irrelevant, since the bounds on
> performance for half-duplex Ethernet networks come from CSMA/CD.

I will say it one last time, duplex falls out of the equations when you
solve for ``maximal''.  It has 0 meaning in the numbers used.  Go read
my analysis and tell me why I can't pump 12MB/sec on 100BaseTX, tell
me that my 15 years of doing 97.5% of data clock on ethernet just doesn't
happen.  Then tell me why it can't happen, show me numbers and equations
and I'll show you how you forget the keyword maximal and keep jumping
over to something less than maximal as your not narrowing the scope of
what it is your measureing/calculating.

You keep throwing P(coll) in, P(coll) only occurs if your upper layer is
causing P(coll) by doing things like ack packets.  CSMA/CD does not
define this.  It defines the exact things I have used in the calculations
to derive the number.  There is no other number and no other formula
to apply when solving for maximal.  I can back up my numbers with lab
data, 15 years of lab data.

The only thing that effects maximal data transfer on a CSMA/CD network
is IFG, MTU (not the upper layer MTU the layer 2 frame MTU) and layer
2 overhead bytes as clearly formulated in my post (preamble, Start of
Frame, Source Address, Destination Address, type and CRC).

The IFG is the multi-access window, if no one else accesses the media
during the IFG (technically a violation of spec) one is free to start
your next frame of transmission.  If 2 nodes attempt to access the
media at end of IFG you have P(coll), solving for maximal says that
this never occurs to get maximal.  THAT IS THE END OF THE STORY AS
IT WORKS IN THE REAL WORLD DAY AFTER DAY IN 4 DESIGNS I HAVE DONE
FOR PEOPLE.  

The only bloody ack that can cause a collission in our l3 design
occurs after the whole of the data transfer, thus they don't effect
our 1 way data transfer rate except by 64 bytes in Megabytes of
data which shows up out in the 4th or 5th digit and is _NOT_ the
maximal link layer data rate (the link layer is till doing 97.5%
of data clock, the data is just going the other way :-)).

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> > I specifically excluded P(coll) by stating point to point or effectively
> > point to point via switching.
> 
> Rod, please bother to READ what people write before spewing nonsense.

I did read it, and did not spew nonsense.  P(coll) is non-sense when
talking about maximal.

> The original question asked SPECIFICALLY about half-duplex.

It also asked about ``maximal'', I solved the equations for maximal,
to achive maximal P(coll)=0.

> I answered SPECIFICALLY about half-duplex.

The duplex does not in any way effect the maximal link layer transmission
data rate.  You seem to keep forgetting the maximal part...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> >> [I wrote:]
> >> quite right.  In a CSMA/CD medium access protocol, like that used by
> >> Ethernet, the actual capacity of the link is always(*) somewhat less than
> >> 100%; the exact value depends on the precise parameters of the
> >> transmissions at both ends.(**)
> 
> >> (*)In non-trivial conditions; i.e., when actual work is being done.
> >> (**)I've heard numbers between 70% and 95%.
> 
> > And the major set of parameters that effect the higher side of this
> > number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap)
> > and the protocol overhead of what ever proto you are using.
> 
> Nope.  Those two values are defined by the protocol, and are not
> parameters at all.  (It's only a parameter if it could conceivably be
> varied in an experiment.)

Don't tell the guys at PARC, Intel, DEC or TRW these are not parameters,
the MTU as defined by the ethernet specification has a minimal and
maximal value.  That pretty much makes it a parameter.  Also the 1518
bytes is the in-spec maximal but many chips, even the old 82586, could
be programmed to do 4K or larger frames.  (TRW takes advantage of the
82586's ability to do 16KByte frames for pumping huge images around
very effecently on ethernet.  Given that I have worked on real world
systems that modify the MTU to reach a desired goal I can state without
a doubt that MTU is a paramter, as I have changed not just in experiments
or on paper, but in the real world with 1000's of systems deployed using
the tweaked value, including having to hack out the jabber circuits in
hubs to deal with the frame size.)

>  The relevant parameters are the
> transmission schedules of the end stations, which are of course
> dynamic in most real-world applications, but not necessarily so.

Those parameters mean nothing when caclulating the Data Link layer
maximal transmission rate possible.  If they use them then you are
calculation something else, like the application maximal transmission
rate.

 
> These can be boiled down into a single number P(coll), which is the
> probability that two stations will cause a collision by transmitting
> at precisely the same time.  Although this seems unlikely, certain
> kinds of network protocols can unintentionally synchronize
> end-stations to the extent of causing pessimal behavior.

I specifically excluded P(coll) by stating point to point or effectively
point to point via switching.  P(coll) is 0 in this situation, again
going to my note of keyword ``maximal''.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Streamlining FreeBSD installations across many machines

[Rodney W. Grimes]

> Perhaps this would be of interest in CURRENT issues:
> 
> 
> We have several servers that we plan on deploying across the US.  Their 
> purpose in life is network status and monitoring.   The hardware profiles 
> are exactly the same...
> 
> Currently, we're using DD to mirror a disk image onto a new installation, 
> and them nanually tweaking all the necessary configurations.   It's 
> tedious, and is going to get hellish with the amount we plan on deploying.

A much faster way to do this is to just dd the first few megabytes of
the disk (dd if=foo of=/dev/rXXd bs=32768 count=1024).  Then use
dump | restore to populate the disk.  (We actually have 3.x and 4.x
recent build filesystems that are built weekly on a master loading
machine just for this purpose.)

We mass produce system disk this way and it is much faster than a whole
disk image operation especially when dealing with drives much larger than
2G bytes.

> I'm wondering if there might not be a way to streamline this install 
> process, such that a boot floopy and script could be created to take a 
> minimum amount of information, and then "do the right thing" as for the 
> install.   Things like putting in the packet filters, the kernel, IP 
> config, etc.
> 
> Surely someone has done this before...?

We do it on a weekly basis, 4 to 32 disks at a time...

> Any pointers would be greatly appreciated.
Hope this gives you some ideas...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> On Fri, Feb 25, 2000 at 01:25:59AM -0800, Rodney W. Grimes wrote:
> > 
> > There was a patch of DC21143 chips it seems that has a very strange
> > thermal problem.  Can you tell me what your hub link lite is doing
> > when you see this major slow down?
> 
> Nope ... as this machine is connected directly to the UTP-socket in the
> wall .. which is connected to an HP-switch which is hidden in a locked 19"
> rackmount (without a looking glass).

:-(.  Then do the next best thing, look at the lights on the back of
the card (another reason I like the KNE100TX, it has them, not all
DC21x4x cards do.)

> > If you abort all traffic does the link light keep blinking wildly?
> > 
> > If you power the machine down for an hour or so and let everything cool
> > down nice and cool does it seem to work for a longer period of time before
> > the speed drops?
> 
> As far as i can remember leaving the system powered down for a longer
> period of time indeed seems to make the connection work properly again for
> a (little) while ... at least a short power-down to give everything a
> chance to reinitialize hardly ever seems to be working.

Sounds like we might be on the right track.

> > If you see any of these symptoms call Kingston tech support, describe
> > the problem to them, ask them for an RMA number :-)
> > 
> > What is the date code on your DC21143 chip (I think I am recalling that
> > you said you had a KNE100TX, and I am assuming you do, and that it is
> > of new enough vintage to be the 21143 chip, and that it might be in this
> > same range of chips we had problems with (33% of 4 lots of 20 cards would
> > go to la la land within 1 to 2 hours of being placed into burn in).
> 
> Well .. it's not my own system which is having these problems but of a
> friend of mine ... I'll check this information with him today and have a
> talk with the place that sold us this card.
> 
> Thank you very much for providing this insight ...

Your welcome.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> On Thu, Feb 24, 2000 at 02:07:40PM -0500, Garrett Wollman wrote:
> > < said:
> > Assuming you mean ``100BASE-T (half duplex)'' here... This is not
> > quite right.  In a CSMA/CD medium access protocol, like that used by
> > Ethernet, the actual capacity of the link is always(*) somewhat less than
> > 100%; the exact value depends on the precise parameters of the
> > transmissions at both ends.(**)
> 
> Ok ... we all know what exactly should be theoretical maximum and all ...
> but that wasn't exactly my question ... I have having weird problems with
> the network performance permanently dropping to below 100 kB/s (while still
> in 100 Mbps/FDX). Is there anybody that could give a plausible explanation
> for this break-down ?

There was a patch of DC21143 chips it seems that has a very strange
thermal problem.  Can you tell me what your hub link lite is doing
when you see this major slow down?

If you abort all traffic does the link light keep blinking wildly?

If you power the machine down for an hour or so and let everything cool
down nice and cool does it seem to work for a longer period of time before
the speed drops?

If you see any of these symptoms call Kingston tech support, describe
the problem to them, ask them for an RMA number :-)

What is the date code on your DC21143 chip (I think I am recalling that
you said you had a KNE100TX, and I am assuming you do, and that it is
of new enough vintage to be the 21143 chip, and that it might be in this
same range of chips we had problems with (33% of 4 lots of 20 cards would
go to la la land within 1 to 2 hours of being placed into burn in).

The problem seems to have started shortly after Intel took over production
of the chips from DEC.  I have not seen the problem in the last 6 lots
of product.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: dc0 wierdness with Compex Freedomline

[Rodney W. Grimes]

> < said:
> 
> 
> > The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s
> > (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide
> > by 8] I realize my punctuation may be off, but there you are.
> 
> Assuming you mean ``100BASE-T (half duplex)'' here... This is not

Just to put a final nit pick on this...
100BASE-T is not defined by the standards.  100baseTX, 100baseFX, and
100baseT4 are.
> quite right.  In a CSMA/CD medium access protocol, like that used by
> Ethernet, the actual capacity of the link is always(*) somewhat less than
> 100%; the exact value depends on the precise parameters of the
> transmissions at both ends.(**)
> 
> -GAWollman
> 
> (*)In non-trivial conditions; i.e., when actual work is being done.
> 
> (**)I've heard numbers between 70% and 95%.

And the major set of parameters that effect the higher side of this
number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap)
and the protocol overhead of what ever proto you are using.

For those really interested in the nuts and bolts of the calculations
for this I refer you to ``Switched, Fast and Gigabit Ethernet Third Edition''
Robert Bryer & Sean Riley, ISBN 1-57870-073-6 chapter 7, ''Bandwidth: How
Much Is Enough?''.  Also chapter 2 in the same book for some of the data
used below and for a more indepth explination of what all these things
are, for that matter, 802.* :-)

Some interesting numbers:  (In a format that might help some people
understand where the magic numbers 1500, 1518 and 1538 come from in
ethernet documentation (though few folks but ethernet framer geeks
would ever deal with the 1538 number :-)).

  Layer 2 maximal data rate:  (ie, raw ethenet packets, no protocol)
data / ( IFG + ( Preamble + SFD ) + DA + SA + type + data + CRC ) =
1500 / ( 12  + ( 7+ 1   ) + 6  + 6  + 2+ 1500 + 4   )  = 97.53%
1500 / ( 12  + ( 8  ) + 1518)  = 97.53%
1500 / ( 1538   )  = 97.53%

So infact the Layer 2 maximal data rate of 100BaseTX is 97.5929Mb/s or
12.1912MB/s.  I'll leave the Layer 3 to 7 calculation up to the reader,
as I am a hardware geek and I showed you how to do the calculations
at the hardwire layer, you software geeks can go figure out the
overhead for the software layers :-).

Please note that ``maximal'' is a key word in the above discussion, so
please don't tell me that not all frames are 1500 bytes of data, because
if they are not 1500 bytes of data you didn't solve the problem for the
maximal.

The first hardware that I know of that was ever capable of doing the
95.53% at the link layer was the i82586 by Intel on 10base, and you
had to lock the sucker up in continues ring search mode with a good
shared memory access mechanism to make it hit that.  You needed very
large chunks of shared memory (MB's) to sustain a very long burst of traffic
at wire speed.  You can not use ethernet in a shared mode and achive
these numbers (point to point or effectivly point to point via switching
only).

Anyone quoteing ethernet or any other MAC layer data rates without atleast
as much detail as above is practicing abuse of statistics and not presenting
hard factual data which should be treated as such.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Hardware for 4.0

[Rodney W. Grimes]

> <<[EMAIL PROTECTED]> said:
> 
> > IBM Hard drives...
> 
> If you can actually get them  Last time I bought a drive we
> weren't able to get IBM in any reasonable timeframe and ended up with
> a Seagate instead.  (And that Cheetah 18LP's not a bad drive, either.)

Should you run into that problem again give me a call.  We deal directly
with one of the larger official distributors of IBM hard drives.  Last
inventory check showed about 4,000+ IBM 25L1900/25L1910's on the shelf.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Hardware for 4.0

[Rodney W. Grimes]

> Hello,
> 
> I'm purchasing a server to run 4.0 on.  It won't be in production
> immediately, but I need to get a quote ASAP.
> 
> What SCSI card would people recommend?  It doesn't need RAID.
> Any particular SCSI tape drive?
We are partial to the TekRAM 390-F symbios 53C875 based controller.

> I'll probably buy a midrange Asus motherboard and a nice Intel fxp
> NIC to go on it.  Any other recommendations?

IBM Hard drives...

And if you get the ASUS P3B board don't let it run in jumper free
mode, nail the settings down with the jumpers as we have seen one
too many times that this board likes to _think_ the CPU has changed
and fails during a remote reboot.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: openssl in -current

[Rodney W. Grimes]

> Hmmm.  I'm beginning to wonder if openssl shouldn't just be backed-out
> at this point.  The situation with RSA makes this far more problematic
> than I think anyone first thought, and I've seen a lot of breakage so
> far for what appears to be comparatively little gain over what we had
> before with the ports collection version.

I'll ack that:  ACK ACK ACK!!


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Dummy ethernet interface.

[Rodney W. Grimes]

> Giorgos Keramidas writes:
> > Is there some way to ifconfig up a dummy ethernet interface, one that
> > will work like the loopback one (lo0) on FreeBSD?
> 
> If you want an interface that loops back, you can have more than
> one loopback interface (lo0, lo1, lo2, ...).
> 
> If you want an interface that discards everthing, you can create
> a netgraph interface ("ngctl mkpeer iface foo inet") and leave it
> unconnected.

Or do it with the proper BSD pseudo-device:
#  The `disc' pseudo-device implements a minimal network interface,
#  which throws away all packets sent and never receives any.  It is
#  included for testing purposes.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: make installworld broken???

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> > Good analysis deleted...
> > 
> > > src/usr.bin/xinstall could probably have been named src/usr.bin/install,
> > > but PROG has to be xinstall regardless.  I guess they kept the two as
> > > xinstall for consistancy and in case there were other gotcha's like this.
> > 
> > But you forgot what happens if you have a ``file'' named install:
> > 
> > cd /tmp
> > mkdir install
> > make install
> > 
> > Now you know the real reason the directory is called ``xinstall''.
> 
> Ahh yes, of course.  'cd src/usr.bin; make install'  would fail. :-)

Actually it use to silently do the wrong thing... nothing at all that is :-)

It doesn't anymore since the .mk system has a special internal target
that deals with the fact that src/usr.bin is simply a directory that has to
be iterated over:

Orbit.hpc1.com:root{101}# cd /usr/src/usr.bin
Orbit.hpc1.com:root{102}# mkdir install
Orbit.hpc1.com:root{103}# make install
===> apply
install -c -s -o root -g wheel -m 555   apply /usr/bin
install -c -o root -g wheel -m 444 apply.1.gz  /usr/share/man/man1
===> at
install -c -s -o root -g wheel -m 4555   at /usr/bin
...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: make installworld broken???

[Rodney W. Grimes]

Good analysis deleted...

> src/usr.bin/xinstall could probably have been named src/usr.bin/install,
> but PROG has to be xinstall regardless.  I guess they kept the two as
> xinstall for consistancy and in case there were other gotcha's like this.

But you forgot what happens if you have a ``file'' named install:

cd /tmp
mkdir install
make install

Now you know the real reason the directory is called ``xinstall''.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: very silent, but heavy filesystem-crash

[Rodney W. Grimes]

...
> 
>  Starting an 'fsck' results in:
> 
> cage:[/] # fsck /scratch
> ** /dev/da1s1g
> ** Last Mounted on /scratch
> ** Phase 1 - Check Blocks and Sizes
> PARTIALLY TRUNCATED INODE I=16
> SALVAGE? [yn] ^C
> * FILE SYSTEM MARKED DIRTY *

Next step is run the ``save'' fsck:

fsck -n /scratch >/someplacewithspace 2>&1

Then take a look at the logfile and see just how many
more errors it would have found had you let it procede...

> I interrupted the fsck-run as soon as I decided that it might be
> advisable to leave it in its hosed state just for the case that
> there is some illuminated filesystem-hacker who would like to
> take a peek. (I would allow ssh-access to the box ...)

$1.00/MB for me to recover it if you need it.  I don't do it for
fun.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Comments on this patch?

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]> "David O'Brien" writes:
> : > BTW, I'm getting numbers that are 2x bigger than before :-(.I had
> : > makebuildworld down to around 1:20 at one point, but now it is 2:40.
> : 
> : Which compilers for both times?
> 
> What ever was on -current as of 2.5 years ago.  This is comparing the
> make buildworld of 3 years ago with the make buildworld of today.
> This was in the 8/5/97 timeframe.  I got the buildworld time down to
> 1:20 on my machine with async mount options and two spindles.  Now
> with the faster spindle and an even faster spindle, my buildworld
> times are 2:40.  There may have been some things i turned off in the
> make.conf that I have on now.  NOTCL was included before, for
> example.  My machine was 128M in 97 and is 196M now.
> 
> So I'd say this is with 2.7.3 and the compiler in today's current.
> There's so much that has changed in the last 2.5 years so this is more
> like grousing rather than pointing to a problem.

Actually makeworld times jumped significantly with Marcels revamped
make world target.  For now I can live with the penality, but it should
be looked at and carefully fixed^H^H^H^H^Hoptimized.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: (FWD) Re: cvs commit: src/etc/periodic/daily 200.backup-pass

[Rodney W. Grimes]

> 
> On 27-Jan-00 David O'Brien wrote:
> > I would appreciate it if those that want things changed would please try
> > Sheldon's `sed' expression below and report back how it worked for you.
> 
> That will expose passwords of users whose entries are commented out,

My awk script does not have that problem.  If the line has 10 colons in it
field 2 will be munged.  It don't care if you give it straight password,
diff -u or diff -c or even diff.  It may have problems with diff -y.

...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Problems installing FreeBSD 4.0 20000125-CURRENT

[Rodney W. Grimes]

> < said:
> 
> >> 3. On the first reboot after installing, the keyboard was in a funny
> >> state.
> 
> > Urk, can't reproduce it.  I need a reproducible sequence of operations
> > before we'll have any hope of tackling this one.
> 
> >> Control-alt-del definitely didn't work, so I had to power off and
> >> reboot.  This hasn't repeated itself.
> 
> > Same here.
> 
> I have on a number of occasions had my laptop boot with a
> non-functional keyboard.  Sometimes the keyboard is just locked; other
> times it generates garbage.  Never managed to isolate the
> circumstances in which this happened (but it didn't happen with a
> kernel from last September or there-abouts).  Haven't had it happen on
> a desktop or server yet.

I have seen this on numerious occasion, but have never tracked it down
to any one specific thing.  All on desktop and servers, but thats
only because we don't do laptops.

I have not seen it in quite some time (about a month), so I am thinking
it has probably been unknowingly fixed someplace.  I'll keep an eye
out for it.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: (FWD) Re: cvs commit: src/etc/periodic/daily 200.backup-passwd

[Rodney W. Grimes]

> 
> 
> On Thu, 27 Jan 2000 00:23:23 PST, "David O'Brien" wrote:
> 
> > I think what you really want is:
> > 
> > sed 's/^\([^:#@+-]*\):[^:]*:/\1:(password):/'
> 
> Eeek, I don't know why I sent you that.  It should have been:
> 
>   sed 's/^\([ +-][^+-][^:]*\):[^:]*:/\1:(password):/'

IMNSO sed is the wrong tool here, awk can deal with the
password file much easier than sed and should handle just
about any input just so long as it doesn't add any :'s to the
lines that we are trying to mungle the password out of:

BEGIN {FS=":"; OFS=":"; ORS=""}

//  {if (NF==10) {
print $1,"(password):"
for (n = 3; n <=NF; n++) print $n,"";
} else
print $0;
print "\n";

Defantily works on diff, diff -u and diff -c.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: FIC SD-11 not happy with ata

[Rodney W. Grimes]

> %> %It seems Russell L. Carter wrote:
> %> %> %It seems Russell L. Carter wrote:
> %> %> %> 
> %> %> %> I swapped out my motherboard and am seeing this now:
> %...
> %
> %> 
> %> )(*&$#%$#  stupid magazine benchmarkers never actually test 
> %> things like IO...  gr
> %
> %We in the computer hardware business have a better name for ``FIC'',
> %Fix It Continuously.  They are not known for their quality, or should
> %I say they are known for their lack of quality :-).
> 
> How about FIO: Fix it Once.  I swapped in an ASUS K7 and now everything
> is back to normal:

I thought we had protected our tradesecret on how to fix the FIC
problem, seems someone else figured it out too :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Please help spread the CVSup mirror load more evenly

[Rodney W. Grimes]

> On Mon, Jan 24, 2000 at 02:17:54PM +0100, Brad Knowles wrote:
> > At 11:34 PM +1300 2000/1/22, Joe Abley wrote:
> > 
> > >  This should give you a relative performance metric between the servers
> > >  you measured, hopefully with local network performance variations
> > >  cancelled out by the fact that all tests are run around the same time.
> > 
> > This is a really cool idea!  Are you going to be writing some 
> > code to do this for us?  ;-)
> 
> Can do if people think it is worthwhile. Could be done quite easily
> in a wrapper to cvsup, I would thought. It _will_ need a static
> test set to be installed at each of the cvsup mirrors to be useful
> though.

This does not need to really be a wrapper around cvs, folks should run
a tool 1 time to pick the best guess as to what server they should be
using, stick that value in thier cvsup file and be done with it.  If
jdp calls for a ``this server is being overloaded please move'' folks
should rerun the selection tool and pick new servers.  This latter
event happens 2 or 3 times a year, it is a waste to run this every time
you start up cvsup and can cause the grief if you change cvsup servers
in <1 hour due to the update policy of the mirrors.

This thread should die probably die...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: With feature freeze being in place

[Rodney W. Grimes]

> In article ,
> Alex Zepeda  <[EMAIL PROTECTED]> wrote:
> > 
> > I'm looking at /usr/{src,}/share/examples/cvsup/gnats-supfile, and as
> > "equipped" it's not working (well it goes through the motions but checks
> > out no files).  Hmm.
> 
> It works for me.  Not all mirrors carry the more esoteric
> collections like gnats.  I know that cvsup[15678] carry it.  I think
> cvsup2 doesn't, and I'm not sure about 3 and 4.

cvsup4 carries it, as of the upgrade to cvsupd 16.1 (also added www and doc):
Ohhh.. and please update your cvsup-mirror stats, the sizes of things are way
way way out of date:

{102}% ls
CVSROOT distrib doc gnats   ports   src www

{105}% du -sk *
15534   CVSROOT
411 distrib
64790   doc
104577  gnats
136353  ports
594028  src
56562   www


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Please help spread the CVSup mirror load more evenly

[Rodney W. Grimes]

> On Fri, 21 Jan 2000, David O'Brien wrote:
> 
> > On Fri, Jan 21, 2000 at 07:03:51PM -0500, Chuck Robey wrote:
> > > I don't know ... I think it might be a good idea for the cvsup client to
> > > make a connection to a cvsup master, get redirected from that master to
> > > the actual handler of the connection, and then work.  That way, a config
> > > file on the master could be set up to know the capabilities of the other
> > > machines (network availability, machine speed, etc) and dole out
> > > connections weighted on that.
> > 
> > How is a cvsup master to know anything about the path from me to any
> > given cvsup mirror?  Knowing something about the path from me to the
> > master and the path from the master to the mirror tells zero about the
> > path from me to the mirror.
> > 
> > Being on an .EDU network, I have a *very* different path to other .EDU
> > machine participating in Inetnet2.  My path to cvsup3 is a prime example.
> > This "cvsup master" will have no idea about this.
> 
> I guess it means, is the main component trying to be balanced the server
> resources or the network resources.  I may be wrong, but I think that the
> server resources are more likely to be the most important bottleneck, and
> this method detects that, with minimal network effects.
> 
> If you think that it's really the network that's going to be the
> bottleneck, then you wouldn't want to use this method.  I don't think I'm
> wrong, but I'm willing to listen to arguments on it.

I think, and am pretty sure as hostmaster for cvsup4, that the bottleneck
is a combination of both.  We use the max connection limit to control
the load on the server, and simply refuse connections beyond the acceptable
load limit.  As far as I know none of the servers run unlimited connection
counts so we already have a load controlling mechanism.

I know from a network bandwidth point of view I can tell when someone
with T-1 or better comes on and pulls a full copy from us, it shows up
quite nicely in the load graphs.

I also know from looking at our logs that some people would get faster
cvsup's if they changed which mirror they are pulling from.  (Anyone
directly attached to Verio should no longer be using us, but the new
Verio provided server instead.)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Please help spread the CVSup mirror load more evenly

[Rodney W. Grimes]

> > > Hi David,
> > > 
> > > John can implement a ping echo packet protocol for cvsup whose
> > > response can have "cool" information on the server. Steven's
> > > book on Networking already has the code for doing network latency
> > > calculations . It is more like if John has the time to implement
> > > such scheme 
> > 
> > You don't even need to modify the protocol.  Just write a small
> > tcp program that times the 3 way handshake on open to all the
> > servers, take the one with the sortest time and spit that out
> > for the user to stuff in his cvsupfile.
> > 
> > 15 lines of perl should be more than enough :-)
> > 
> Hi,
> 
> Thats gross server load balancing . The network travel time
> does not tell you how how loaded the machine is or the server.

It may be gross to the server but it is optimal to the networks :-)

> 
> There are  couple of RFCs on network load balancing with 
> respect to servers or services and I am sure that there
> are also widely available research papers. 

Most of those concentrate on balancing the load on the server
itself.  How about balancing the load on the network paths,
I doubt very much that we have a server load problem near as
much as we have a network load problem due to people not
having ready access to the data that says ``this server is
closest network wise to me''.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Please help spread the CVSup mirror load more evenly

[Rodney W. Grimes]

> Hi David,
> 
> John can implement a ping echo packet protocol for cvsup whose
> response can have "cool" information on the server. Steven's
> book on Networking already has the code for doing network latency
> calculations . It is more like if John has the time to implement
> such scheme 

You don't even need to modify the protocol.  Just write a small
tcp program that times the 3 way handshake on open to all the
servers, take the one with the sortest time and spit that out
for the user to stuff in his cvsupfile.

15 lines of perl should be more than enough :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: FIC SD-11 not happy with ata

[Rodney W. Grimes]

> %It seems Russell L. Carter wrote:
> %> %It seems Russell L. Carter wrote:
> %> %> 
> %> %> I swapped out my motherboard and am seeing this now:
...

> 
> )(*&$#%$#  stupid magazine benchmarkers never actually test 
> things like IO...  gr

We in the computer hardware business have a better name for ``FIC'',
Fix It Continuously.  They are not known for their quality, or should
I say they are known for their lack of quality :-).


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> :> Sometimes we just want to nfs-mount things on the same
> :> machine.
> :
> :Sick, poor in performance and the wrong tool for the job.  
> :See mount_null(8) for more details on how to do it right.
> :
> :> 
> :> One more example: I don't like /var/news so I mount locally
> :> /var/news
> :> to /archive/news on the same system instead of using
> :> symlinks. 
> :> My rc.local manages it for me.
> :
> :Sick.  See above.
> 
> I gotta agree, this is sick.  But to put the icing on the cake:  LOCAL
> NFS MOUNTS CAN LEAD TO LOW-MEMORY DEADLOCKS.  Even with my recent fixes
> to -current there is still a non-zero chance of this happening.

This use to be documented some place, but I can't find it :-(.

[Good example of how to do things deleted]

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Additional option to ls -l for large files

[Rodney W. Grimes]

Sorry, I will slow down my reading and stop flipping 2^10 into 10^3.


> From: Rodney W. Grimes [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 12, 2000 9:53 PM
> 
> 
> [in regards to a previous post preferring base-10 for K and M units...]
> >> I'm sorry but I would find it non-obvious and more confusing.  When ls or
> a
> >> similar disk/memory utility tells me xxxK or xxxM, I would expect it to
> be
> >> in 2^10 or 2^20 units.  To appear otherwise would surprise me.
> 
> >I guess you get suprised a lot then.  The only folks that I know of who
> >regulary use K and M as base 10 when talking about disk and memory are
> >the disk drive manufactures.
> >
> >Does you machine have 128MB or 134MB.  You must have missed this earlier
> >in the thread
> >
> >All of the boot time reporting is in 2^20 MB:
> >ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S
> >
> >Due the math if you doubt me, oh, and Quantum calls this a 3.2G disk
> >drive :-)
> 
> I think if you re-read my post you'll find that we are in vehement
> agreement.

I have doned the cap  <|:-)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> ...
> > 
> > Independent of order of export/mounting the dead lock occurs.  Cross
> > mounting via NFS is a verbotten thing in the sysadmin world of production
> > systems.  :-)  I have had to fix it at several sites admin'd by newbies...
> > 
> 
> I'm not sure you are really understanding the problem. We
> don't want
> to read RFCs or such professional sysadmin red books...

But a lot of us around here do just that, don't expect us to make
changes just because it suites _your_ needs as that change may very
well not suite the _other_ 95% of the users.

> 
> Sometimes we just want to nfs-mount things on the same
> machine.

Sick, poor in performance and the wrong tool for the job.  
See mount_null(8) for more details on how to do it right.

> 
> One more example: I don't like /var/news so I mount locally
> /var/news
> to /archive/news on the same system instead of using
> symlinks. 
> My rc.local manages it for me.

Sick.  See above.

> 
> But, is it really so difficult to move portmap to /sbin.

It is not difficult to move the binary.  The difficulty is in changing
the sequence of events that control when the binary is run.  No one
here has objected to moving the binary that I have seen, it has been
changing when things occur.

> Why?
portmap/mountd are heavy users of syslog, you _should_ have syslogd
running before portmap/mountd.  syslogd is started between network_pass1
and network_pass2.

> Linux have portmap in /sbin and it runs. 

That argument holds 0 ground here.  And it's not the objection to your
change we raised.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Additional option to ls -l for large files

[Rodney W. Grimes]

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> I'm sorry but I would find it non-obvious and more confusing.  When ls or a
> similar disk/memory utility tells me xxxK or xxxM, I would expect it to be
> in 2^10 or 2^20 units.  To appear otherwise would surprise me.

I guess you get suprised a lot then.  The only folks that I know of who
regulary use K and M as base 10 when talking about disk and memory are
the disk drive manufactures.

Does you machine have 128MB or 134MB.  You must have missed this earlier
in the thread

All of the boot time reporting is in 2^20 MB:
ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S

Due the math if you doubt me, oh, and Quantum calls this a 3.2G disk
drive :-)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> [..]
> > So no disk, so just what is it that you are exporting???
> 
> Just a comment:
> 
> I've seen scenarios where a local disk is attached holding a kernel,
> bootblocks loader etc, but otherwise booting from a server over NFS.  And
> it exported the rest of it's disk for general use...  It's easier than
> netbooting, allows each machine to contribute disk space to the cluster in
> addition to compute cycles, keyboard, screen etc.

See other mail about the evilness of cross mounting NFS, this especially
applies in a cluster!  You can't bloody cold start the beast easily.

One way I have seen it worked around is to flag the NFS mounts -background
so that they don't hang the boot process.  Still evil lurks in these
corners of the world...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> On Wed, Jan 12, 2000 at 01:23:14AM -0800, Rodney W. Grimes wrote:
> 
> > Also moving them to pass1 would bring up nfs exports before we
> > brought up nfs mounts.  syslogd would not be running to catch
> 
> Shouldn't nfs exports happen before nfs mounts, so that machines
> which have nfs interdependencies don't sit there waiting for one
> another? (I think we've had to change this several times in the
> FreeBSD rc scripts, I guess the reason it might be the other way
> around is incase /usr is nfs mounted?)

If your talking about dead lock caused by mutual cross mounting
between 2 systems via NFS the NFS rule book says ``don't do that,
it hurts''.

Independent of order of export/mounting the dead lock occurs.  Cross
mounting via NFS is a verbotten thing in the sysadmin world of production
systems.  :-)  I have had to fix it at several sites admin'd by newbies...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> 
> Hi,
> 
> > should not have to run either, *even* for diskless boot.
> > 
> > What's all this about loopback mounts in fstab about?  What does
> > that have to do with diskless startup?
> 
> Ok. I just rethought everything. It seems that a move is
> unnecessary because:
> 
> - Sharity light and cfs are started from /usr/loca/etc/rc.d
> - diskless stations do not have anything to export
> 
> So are there any problems with the order change in /etc/rc.network
> (moving portmap and mountd to network pass_1) you can imagine ?

They don't logically belong in pass1, which is for bringing up
the network logical layer.  These run above the logical layer.

Also moving them to pass1 would bring up nfs exports before we
brought up nfs mounts.  syslogd would not be running to catch
errors, etc.  Moving things in /etc/rc is not to be taken
lightly, it has taken 10 years to get what we have there in a
shape that just DTRT for 99% of the folks.

Perhaps if you can give us some specifics on exactly what it is
that your having problems doing and/or what it is that you are
trying to do we can come up with a correct solution.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> 
> > > portmap(8) and therefore mountd(8) should be started before
> > > the nfs filesystems get mounted. But because portmap(8) is in
> > > /usr/sbin , users with a nfs mounted /usr filesystem or with
> > > diskless filesystems will have big problems.
> 
> I mean, that if I do the change of startup-order, diskless
> installations will be broken.
> 
> > > This will fix loopback and local mounts in fstab. Untill now
> > > this has not been possible because of the above reasons. Btw:
> > > Linux also has portmap(8) installed in /sbin.
> 
> > You only need portmap and mountd to _export_ nfs, not to mount
> > them.
> 
> For a normal installation this is ok, but as I said, diskless
> installs ...

Lets see, your booting diskless during the install, which means you have
no disk to export until you have fdisk/newfs'ed one, your not going to
get very far without /usr in this process.

So no disk, so just what is it that you are exporting???

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: move portmap(8) from /usr/sbin to /sbin

[Rodney W. Grimes]

> 
> Hi,
> 
> I think we should move portmap(8) to /sbin for the following reason:
> 
> portmap(8) and therefore mountd(8) should be started before
> the nfs filesystems get mounted. But because portmap(8) is in
> /usr/sbin , users with a nfs mounted /usr filesystem or with
> diskless filesystems will have big problems.
> 
> This will fix loopback and local mounts in fstab. Untill now
> this has not been possible because of the above reasons. Btw:
> Linux also has portmap(8) installed in /sbin.
> 
> I'm prepared for a big fight :) Can you give me any arguments
> against this change ?

It makes no since...

Why would a machine that mounts /usr over nfs need to export
filesystems?  If it's got enough disk space to make it worth
exporting stuff from the box it surely has enough space for
it's own copy of /usr.

You only need portmap and mountd to _export_ nfs, not to mount
them.

Orbit.hpc1.com:root{208}# ps ax | grep mount
Orbit.hpc1.com:root{209}# ps ax | grep port
Orbit.hpc1.com:root{210}# df
Filesystem  1K-blocks UsedAvail Capacity  Mounted on
/dev/da0s1a 63503215193690437%/
/dev/da0s1d 63503  45857965 1%/tmp
/dev/da0s1e 63503  48357940 1%/var
/dev/da0s1f127023820303483270%/usr
/dev/da0s1g381103   2511709944572%/usr/src
/dev/da0s1h   1233503   208025   92679818%/A
procfs  440   100%/proc
198.145.92.8:/A   1309170  11274637697494%/mnt

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Additional option to ls -l for large files

[Rodney W. Grimes]

> At 2:49 PM -0800 1/11/00, Rodney W. Grimes wrote:
> > > >Another thing that ``works for me''.  Only make it ki, mi, and gi
> > > >to fit with the new binary mode international appreviation standards,
> > > >unless of cource you use base 10 divisors.
> > >
> > > Why not KB, MB or GB, since that's what you're actually reporting?
> >
> >Because KB MB and GB mean different things than KiB MiB and GiB.
> >
> >K = 10^3, Ki = 2^10
> >M = 10^6  Mi = 2^20
> >G = 10^9  Gi = 2^30
> 
> personally, I'd just as soon use K, M, and G and have it mean
> the base-10 values.  If I'm looking at a decimal number for one
> file (because it's small enough), I don't want a base-2 version
> of the similar number for some other (larger) file in the same
> listing.
> 
> (ie, whatever letters you use, please just divide the values
> by 1000 instead of 1024).

Please don't, there is already far to much precedence in both the
computing world and other commands (df -k and du -k come to mind
right off the top of my head, sysinstall uses them in the disklabel
and partition editor, etc)

df man page:
 -k  Use 1024-byte (1-Kbyte) blocks rather than the default.  Note
 that this overrides the BLOCKSIZE specification from the environ-
 ment.
du man page:
 -k  Display block counts in 1024-byte (1-Kbyte) blocks.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Additional option to ls -l for large files

[Rodney W. Grimes]

[Charset windows-1252 unsupported, skipping...]
Arghh... windblows... 


> >> I'm currently dealing with an increasing set of *very* large files,
> >> most of them in the order of gigabytes. It becomes impossible to
> >> figure the size of a file with ls -l with 9 or more digits displayed.
> >> I would propose a new flag to ls which will together with option -l
> >> change the unit to kilobytes for files larger than one megabyte, to
> >> megabytes for files larger than one gigabyte and gigabytes for files
> >> larger than one terabyte. A 'k', 'm' or 'g' respectively should be
> >> appended.
> >> 
> >> Would such a patch find the blessing of the team and the maintainer
> >> of ls ?
> >
> >Another thing that ``works for me''.  Only make it ki, mi, and gi
> >to fit with the new binary mode international appreviation standards,
> >unless of cource you use base 10 divisors.
> 
> Why not KB, MB or GB, since that's what you're actually reporting?

Because KB MB and GB mean different things than KiB MiB and GiB.

K = 10^3, Ki = 2^10
M = 10^6  Mi = 2^20
G = 10^9  Gi = 2^30

> What is this "binary mode international abbreviation standard"?

See above...  

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Additional option to ls -l for large files

[Rodney W. Grimes]

> I'm currently dealing with an increasing set of *very* large files,
> most of them in the order of gigabytes. It becomes impossible to
> figure the size of a file with ls -l with 9 or more digits displayed.
> I would propose a new flag to ls which will together with option -l
> change the unit to kilobytes for files larger than one megabyte, to
> megabytes for files larger than one gigabyte and gigabytes for files
> larger than one terabyte. A 'k', 'm' or 'g' respectively should be
> appended.
> 
> Would such a patch find the blessing of the team and the maintainer
> of ls ?

Another thing that ``works for me''.  Only make it ki, mi, and gi
to fit with the new binary mode international appreviation standards,
unless of cource you use base 10 divisors.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: 4.0 slower than 3.4?

[Rodney W. Grimes]

> In article <[EMAIL PROTECTED]>,
> james  <[EMAIL PROTECTED]> wrote:
> 
> > It's interesting though how i had no ipf rules whatsoever, yet it 
> > introduced so much latency, as Alexander has pointed out in another email. 
> > Why is ipf so slow? I was planning on switching from ipfw/natd to 
> > ipf/ipnat, but i don't think i want to now - considering it's so darn slow.
> 
> If you want to do NAT, I can tell you without even trying it that
> ipfilter's NAT will be much faster than natd's.  With natd, every
> packet has to go out from the kernel to userland and back to have its
> headers rewritten.  That's a lot of overhead.  Not so with ipfilter --
> it's all done inside the kernel.

Think SMP, think lots of high speed NIC's, think about multiple divert
rules to seperate natd's, think about the one big kernel lock and then
think about your answer again :-)

(Yes, I know latency will always be slightly longer, but overall
through put can be signficantly higher when packets are passed over
the kernel/user interface due to the big giant kernel lock.)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: ipfw optimizations

[Rodney W. Grimes]

> > clnsrv "allow" tcp   ""   43 "${tcp_nicname_c}""${tcp_nicname_s}"
> > clnsrv "allow" tcp   ""   53 "${tcp_domain_c}" "${tcp_domain_s}"
> ...
> > ... on and on up to the 1024 and then a few splattered after that.
> 
> looks like the search path can become extremely long!.

Yes, on under powered routers I sometimes take a dump of ``ipfw -a'' and
take a look at the counts and reorder the rules.  Note that 95% of tcp
traffic hits a rule before all of these that is ``tcp established'',
so the only time we run down through the search is on a setup packet.

Most of our routers running this have plenty of CPU power due to the
demands of gated/bgp/ospf so this has not become an issue.

I can always add a few skipto's as well that would speed things up if
I needed to :-)

ipfw add 5000 skipto 2 tcp from any to any 22-113


> 
> > The single largest optimization would probably be a dispatch based on
> > source or destination port, the latter being more prevelent.
> 
> ok... dispatch on ports is easy to implement, easier than dispatch
> on (masked) IP's.

A Patricia tree might work well here, it would defanitly work well for
any attempt to dispatch on masked IP's.

> > I can't easily send out the actual IP firewall list, it may expose
> > what ever router I grabbed it off of to an attack :-)
> 
> understand -- this is why i just asked only about the structure of the
> ruleset and the length of the longest search path.

:-)  Even a 50% loaded set of T-1's running the 300 rule set on an old
Pentium-II 300 uses more CPU time doing bgp/ospf than it does doing
the firewall rules :-)


One thing has hit me about your implementation of this scattered rule
set, nahhh.. shouldn't be a problem if done as pointers to rules, but
the couting of packets and bytes must be done in the pre-exploded rule
set.

Also have you thought about adding a special interface device name to
handle packets as they traverse ip_forward?  I know Poul's or someone
elses drawing of the H style firewall could be implemented if we had
a way to apply rules as they traverse the ip_forward code and an easy
way to expand your scheme to include that would be to add something
like ``via fwd, in via fwd, out via fwd''.  Note that I _think_ but
am not certain that NAT tapping/injection occurs in ip_forward so this
could be of benefit to those doing NAT.

Anotherwords the full blown H style 2 interface firewall has 6 nodes:

1  2
|  |
|  |
5--6
|  |
|  |
3  4

Nodes 1/2 are the input/output of one interface, 3/4 are the
input/output of the other interface and 5/6 are the input/output
side of the forward/translator engine. 

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: ipfw optimizations

[Rodney W. Grimes]

> > No, this is completly reasonable now that I understand what it is your
> > proposing.  Even the memory footprint is minimal if pointers to the
> > actual rules is all we store in the per interface list, my largest set
> > duplicated over 8 interfaces would only be 3200 rules.  Stored as
> 
> I'd be curious to know what your 400-rule set looks like, what is
> the longest search path through that ruleset, and whether that
> ruleset could be made more efficient to run by implementing some
> kind of switch() statement (eg. for selecting based on interfaces),
> or hash tables (e.g. you want to allow/deny to a list of random
> addresses...).

If you search the archives you'll find a function I wrote in /bin/sh
called clnsrv is what creates 90% of the rules.  Ahh.. hech.. here...

# clnsrv(action, proto, sport, dport, clients, servers)
clnsrv() {
action=$1;  shift
proto=$1;   shift
sport=$1;   shift
dport=$1;   shift
clients=$1; shift
servers=$1; shift


if [ X"${proto}" = X"tcp" ]; then
setup="setup"
base=1
else
setup=""
base=4
fi
if [ X"${dport}" = X"" ]; then
ruleoffset=${sport}
else
ruleoffset=${dport}
fi
if [ ${ruleoffset} -gt 1899 ]; then
ruleoffset=1900
fi
rule=`expr ${base} + \( ${ruleoffset} \* 10 \)`
for cln in ${clients} ; do
for srv in ${servers} ; do
${fadd} ${rule} ${action} ${proto} \
from ${cln} ${sport} to ${srv} ${dport} ${setup}
done
done

rule=`expr ${rule} + 9`
${fadd} ${rule} ${CLASS} log ${proto} from any ${sport} to any ${dport}
}

Then this is called like so:
clnsrv "allow" tcp   20   "" "${tcp_ftpdata_c}""${tcp_ftpdata_s}"
clnsrv "allow" tcp   ""   21 "${tcp_ftp_c}""${tcp_ftp_s}"  
clnsrv "allow" tcp   ""   22 "${tcp_ssh_c}""${tcp_ssh_s}"
clnsrv "allow" tcp   ""   23 "${tcp_telnet_c}" "${tcp_telnet_s}"
clnsrv "allow" tcp   ""   25 "${tcp_smtp_c}"   "${tcp_smtp_s}"
clnsrv "allow" tcp   ""   43 "${tcp_nicname_c}""${tcp_nicname_s}"
clnsrv "allow" tcp   ""   53 "${tcp_domain_c}" "${tcp_domain_s}"
clnsrv "allow" tcp   ""   79 "${tcp_finger_c}" "${tcp_finger_s}"
clnsrv "allow" tcp   ""   80 "${tcp_http_c}"   "${tcp_http_s}"
clnsrv "allow" tcp   ""  110 "${tcp_pop3_c}"   "${tcp_pop3_s}"
clnsrv "allow" tcp   ""  111 "${tcp_sunrpc_c}" "${tcp_sunrpc_s}"
clnsrv "allow" tcp   ""  113 "${tcp_ident_c}"  "${tcp_ident_s}"
... on and on up to the 1024 and then a few splattered after that.

Note that those variables ``tcp_ftp_c'' are often long lists of IP
prefixes, and tcp_ftp_s is a single IP or ``any'', dependent on where
this firewall is in the network topology, so these calls can quickly
build into fairly long ipfw lists.  Often the _c and _s will be lists,
causing the double nested loop to product a few not so meaningful rules,
but that has been fairly rare, bgp being the big exception :-).

Also this same routine is called again for a whole pile of udp ports.

The single largest optimization would probably be a dispatch based on
source or destination port, the latter being more prevelent.

I can't easily send out the actual IP firewall list, it may expose
what ever router I grabbed it off of to an attack :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: ipfw optimizations

[Rodney W. Grimes]

...
> 
> 
> Yes I agree, I love ipfw functionality. You were asking for ideas on how to
> optimize ipfw. What I suggested is that in its INTERNAL representation of
> the rules, ipfw could split the rules on a per interface/direction basis.
> This means that you will not look at the rules that are known to not apply
> to your interface AND direction, hence saving some time.
> 
> Again I am not asking for modification of the "user interface" of ipfw which
> is nice and to the point.
> 
> As you and Rod mention, the ability to have rules applicable to all
> interfaces in one shot is great.
> 
> What I was thinking about is when you build the "per-interface" list of
> rules, use what is provided in the interface part of the rule to determine
> where it belongs:
> 
> 
> ipfw add allow ip from joe to bob in recv ed0
>=> this rule is to be added only in the inbound list for interface ed0
> 
> ipfw add allow ip from joe to bob via ed0
>=> this rule is to be added to both inbound and outbound lists for i/f
> ed0
> 
> ipfw add allow ip from joe to bob
>=> this rule is to be added to the inbound and outbound lists for all
> i/fs

Now I see what you are getting at.
> 
> In the future we could also use negative logic to add a rule to all
> interfaces except the one mentioned...
> 
> Also as I said earlier, you don't have to do anymore interface checking when
> it is implemented this way. The fact that you use such or such list is
> enough.

Gotcha, this could potentially eliminate a lot of compare operations.

> Also to respond to some comments from Rod, this scheme duplicates the rules,
> but it does so behind the scene, so it does not add more complexity to the
> way you configure ipfw. Actually it remains completely compatible with the
> current behaviour of ipfw.
> 
> Is that SO unreasonable 

No, this is completly reasonable now that I understand what it is your
proposing.  Even the memory footprint is minimal if pointers to the
actual rules is all we store in the per interface list, my largest set
duplicated over 8 interfaces would only be 3200 rules.  Stored as
pointers to rules this would be all of 12.8kbytes, certainly not
enough to worry about :-).

Come up with some patches and I'll be glad to test and review them
for you...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: ipfw optimizations

[Rodney W. Grimes]

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
> 
> > > One of the things I would do to optimize ipfw is:
> > > - instead of keeping one list with all the rules, split the list (the
> > >   internal one) by interface and by direction (one list for ed1
> incoming,
> > >   one list for ed1 outgoing, etc.).
> >
> > I often do this manually in long rule sets by using things like
> >
> > ipfw add 1000 skipto 1 from any to any via de0
> > ipfw add 1001 skipto 2 from any to any via de1
> > ...
> > ipfw add 1 skipto 15000 from any to any in via de0
> > #process outbound on de0 rules here
> > ipfw add 15000 blah blah # processing inbound on de0 rules here
> 
> [...]
> 
> > Anotherwords, don't burden the ipfw with code that can easily be done
> > by an intellegent user, and some more examples/documentation...
> 
> Yep, and there happens to be a rule that you would like to be tested in
> every case, but you don't want to test it at the begining (before the
> switch) but sometime in the middle. With your scheme (which is the only
> reasonable one currently), you have to duplicate that rule for every branch.
> This is fine, but if now you need to modify the rule somewhat, don't forget
> to modify it everywhere. This can rapidly become a maintenance nightmare.

Thats what m4 is for :-)  I don't normally write direct rule sets as a
simple list of ipfw commands, but as a combination of sh script that is
actually written by an m4 input file.  I never write the same line twice,
and even lines that are similar either end up being a m4 macro, or
a shell function for more complicated ones with lots of arguments.

> 
> What I was proposing is that the per-interface switch be done implicitely by
> ipfw. So if you do:
> 
> ipfw add allow ip from joe to bob via de0
> ipfw add allow ip from arthur to joe in recv de0
> ipfw add allow ip from john to any
> 
> You get the proper rule tree generated:
(Which also happes to be very far from optimal rule set with meaningless
rules being run)
> 
> -> ed0 RX:
> allow ip from joe to bob
More than likely from joe to bob is only either a RX or TX packet,
infact unless your using multiple IP addresses on ed0 by definition
of routing it would have to be one or the other, otherwise this
box should never see that packet as it is not routing it.

> allow ip from arhur to joe
> allow ip from john to any

> 
> -> ed0 TX:
> allow ip from joe to bob
> allow ip from john to any
> 
> -> ed1 (TX or RX)
> allow ip from john to any
The ``from john'' rule probably only applies to one of the 3
interfaces, unless john happens to be multiple routed.

> 
> 
> By the way, in terms of optimization you will save:
> 
> - 2 * number of interfaces rules (the skiptos) that have to be tested for
> most packets

And your scheme could easily end up with 100's of rules that don't even
make since for that interface/that direction.  Attempting to build these
lists with intelegence has been tried in the past, and I have yet to
see one that doesn't produce far more rules than are actually needed.

> - 2 tests for each rule after (you don't need to retest the interface nor
> the direction, it has been.
> 
> 
> If you go further in that logic and implement a per protocol switch, you
> reduce the number of test even more.

The ipfw dispatch command I mentioned in other email would be an
effecient optimization... what I see here would probably be far
from optimal as explained above.
> 
> 
> To answer a previous question about the number of interfaces, I use FreeBSD
> as a gateway with 2 ethernet interfaces and 3 tunnel interfaces (ipsec) to
> remote locations. I guess that most cases where you really worry about ipfw
> is in gateways where a minimum of 2 interfaces seems reasonable.

We use it here with 4 to 8 ethenets per box... and larger rule sets run
into the 300 to 400 range in count.

> 
> Again, I am not saying that you can not implement a similar behaviour with
> ipfw as it is now, I am just saying that if you want to optimize it, you
> want to reduce the number of test you perform for each rule. What I am
> proposing is one way of doing it (and as a side effect, it makes managing a
> tree like set of rule easier).

Having to managed systems that do it both ways (basically your trying to
go to a Cisco acess-list model) I can say that ipfw actually produces a
smaller set of rules (or at least for what we are doing it does.)  And
a rule set that is easier to figure out what is going on.  What we do
with about 12 rules in ipfw takes me 12 rules per interface on a cisco,
and your scheme would duplicate it to that same 12*interface set, but
run it no faster.  (Yes, I use m4 to write the cisco rule set too so
it's not that big a deal except when your on the router itself trying
to figure out what is going wrong :-()

How about this for a start/stab at syntax for a dispatch command:

ipfw add dispatch interface de0=1,de1=2,ed0=3
# Note we fall pass the above rule if 

Re: ipfw optimizations

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
> >> One of the things I would do to optimize ipfw is:
> >> - instead of keeping one list with all the rules, split the list (the
> >>   internal one) by interface and by direction (one list for ed1 incoming,
> >>   one list for ed1 outgoing, etc.).
> >
> >one skipto rule is enough to switch between two rulesets depending
> >on direction, so this is not really worthwhile.
> >I agree that having a `switch' type of rule for selecting interfaces
> >would be a reasonable gain of efficiency (but then again.. how 
> >many interfaces is one using!)
> 
> I still think we should split the current "one huge list of rules"
> into several lists:
> 
>   Two lists per interface:
>   one list of rules for inbound packets
>   one list of rules for outbound packets
...

I use to think this was the way to do it too, until I went and figured
out how to do the exact same thing using the current setup.  What we
have now is actually more flexiable than this proposed configuration
in that it allows a superset of this, plus you don't have to duplicate
rules in multiple sets, ie:
ipfw add 1000 deny ip from 10.0.0.0/8 to any
ipfw add 1001 deny ip from any to 10.0.0.0/8
covers all interfaces, I don't have to add those and the 6 others to
every interface rule set like we do on the Ciscos.

The skipto situation may be slightly ineffecient due to the number
of comparisons needed, perhaps adding the ability to dispatch more
directly rather than a chain of skipto's, though I can't come
up with a simple syntax for this off the top of my head. :-(

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: ipfw optimizations

[Rodney W. Grimes]

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi Luigi,
> 
> 
> > i am looking at (minor) optimizations of the ipfw code in order to reduce
> > the running time in the common cases.
> >
> > I have a few ideas (mostly along the lines of optimizing for the
> > most commonly-used rules). An obvious candidate is the 'match all'
> > rule (all from any to any), but can people suggest other common
> > usage of rules in ipfw ?
> 
> One of the things I would do to optimize ipfw is:
> - instead of keeping one list with all the rules, split the list (the
>   internal one) by interface and by direction (one list for ed1 incoming,
>   one list for ed1 outgoing, etc.).

I often do this manually in long rule sets by using things like

ipfw add 1000 skipto 1 from any to any via de0
ipfw add 1001 skipto 2 from any to any via de1
...
ipfw add 1 skipto 15000 from any to any in via de0
#process outbound on de0 rules here
ipfw add 15000 blah blah # processing inbound on de0 rules here

Do similiar things at 2...

You can reduce the number of skipto's by using a more explicit set
of rules at 1000, such as doing full 4 way branch:
ipfw add 1000 skipto 1 from any to any in via de0
ipfw add 1001 skipto 15000 from any to any out via de0
ipfw add 1002 skipto 2 from any to any in via de1
ipfw add 1003 skipto 25000 from any to any out via de1

Anotherwords, don't burden the ipfw with code that can easily be done
by an intellegent user, and some more examples/documentation...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: 4.0 code freeze scheduled for Jan 15th

[Rodney W. Grimes]

...
> 
> I strongly suggest to not release 4.0 till the IPv6 import has been finished.
> Beside the need for IPv6 it would be wrong to ship a release with a half-
> complete implementation.

I expect every person that has made similiar statements here and bore
all the developers with the additional workload of reading them to
download 4.0-current, enable INETV6 and start applying every patch
that the KAME group posts to the -committers list and have complete
review feedback within 48 hours of such patches being posted.

If you, the users, are not ready to do this, STOP asking those to be
the folks so described:

``We the willing have been doing so much with so little for so long
that we are now qualified to do anything with absolutely nothing at all''.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: new man pages

[Rodney W. Grimes]

> Where do I look for new man pages? I would like to read those for the
> new ata driver and for ntpd. They were not created during a build
> world some 5 days ago. And I cannot find them in
> /usr/src/share/man/man4, where I would expect man ata/ad in any case.

Sos already answered about ata/ad, I'll add some info for ntpd.

xntpd was recently renamed ntpd, but the documentation and manual
pages was not. 

You'll find the manual page for ntpd with a ``man xntpd''.

And a side note for PHK.  Could you change the rm -f /usr/sbin/xntpd
to instead replace /usr/sbin/xntpd with a LINK to ntpd for maximal
compatibility.  You should probably also do an MLINK for ntpd->xntpd
man pages.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: xntpd - VERY old folks, how about updating? :-)

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
> :
> 
> >Does it help in the 3.4-stable version to set the second value in ntpdrift
> >to 1?
> 
> Yes, although I have never checked all the boundary conditions
> to make sure the kernel-pll is stable over the entire envelope.
> 
> I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
> the problems I find with Dave Mills.

Keep up the work, hopefully it can be MFC'd soon

> 
> >And why has the manual page never been updated, it is clearly wrong
> >when it talks about the contents of driftfile!  :-(
> 
> I updated neither the manpage nor the code because of the above.
> 
> >> Anyway, ntpd4 is in CURRENT...
> >
> >Well... that won't help the 20 or so boxes here doing this all the
> >time:
> >Jan  1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
> >Jan  1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
> 
>   (-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
> 
> Your clock is too sick, (or our calibration of it is hosed), no
> version of {X}NTP will touch a clock which is outside +/- 500ppm.

I see this on 20 systems... so we need to do some work, even if
the clocks really are off that much as it seems this is going to
be quite common.

> 
> Could you try to measure the 14.31818... MHz base frequency and
> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
> so I pressume you have a counter ?)

I'll have to wait tell later this week when I am out at the place
all the RadioActive toys are to get my hands on a counter.  Alls I
have hear are scopes and DMM's, and the scope hasn't seen a cal lab
in 20+ years, so I don't trust it for anything like this. :-)
>
> If they're both OK, then we have a code problem...

I'll let you know what I find.  Just for grins I restarted a few of
them with driftfile="0 1" to see what it does... can't hurt me much :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: xntpd - VERY old folks, how about updating? :-)

[Rodney W. Grimes]

> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >> 
> >> >This is not a port, its part of the RELEASE!
> >> >
> >> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
> >> >instead of what you SHOULD get, which is a slew on the system clock.
> >> 
> >> Remember to get the kernel code involved.  To do this:
> >> 
> >>create a driftfile containing "0 1\n"
> >>start xntpd
> >> 
> >> That will help.
> >
> >No it won't.  I've been running xntpd for oh, four or five years now on
> >various things.  Yes, the drift file is there (and has been).  Still got the
> >step time messages.
> 
> Uhm, Karl, please try to calm down, OK ?
> 
> I didn't talk about having a driftfile, I talked about using the kernel
> PLL:  ("Remember to get the kernel code involved.") 
> 
> With xntpd the kernel-pll is very optional, in fact only the source tells
> you that the magic secret second field in your driftfile controls if
> the kernel-PLL should be used or not.

Does it help in the 3.4-stable version to set the second value in ntpdrift
to 1?

And why has the manual page never been updated, it is clearly wrong
when it talks about the contents of driftfile!  :-(

> 
> Anyway, ntpd4 is in CURRENT...

Well... that won't help the 20 or so boxes here doing this all the
time:
Jan  1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
Jan  1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)

[Rodney W. Grimes]

...
> I'm pretty sure that the box was getiting receive interrupts because
> every time I sent a packet to it from the outside systat -vm showed
> a PCI interrupt for the network device.  However 'netstat -in 1' did
> not show the statistics for the received packets until 64 had 
> accumulated.  It could be that the statistics are not being accumulated
> on a per-reception basis and that the receive packets are actually
> getting through, and that its the transmit side which is broken.  I don't
> know the code well enough yet to make the determination.

If things are done in these drives as they are in the if_de driver then
what you are seeing is the fact that if_opackets and are only
updated when the tx ring is reclaimed by an interrupt, not
when we actually queue the packet to the card.  This has been a source
of confusion for a long time, and IMNSO we should move the if_ipackets+=
in the code.  Here is an idle box, with an dc21143 in it showing probably
what you are seing (the only network traffic to this box is the output
of this running netstat -I de0 1 command:
input  (de0)   output
   packets  errs  bytespackets  errs  bytes colls
 1 0 60  0 0138 0
 2 0182  0 0250 0
 2 0158  0 0138 0
... 100 + lines of output deleted...
 3 0256  0 0138 0
 1 0 60122 0138 0
 3 0256  0 0138 0
 1 0 60  0 0138 0

Search for lines like this:
sc->tulip_if.if_opackets += xmits;

in the driver to see when we update the counter, then look at how
interrupt per packet drivers do it and propose a nice clean solution :-)



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Weird story with dump | restore

[Rodney W. Grimes]

> On Fri, Dec 17, 1999 at 10:47:59AM +0200, Vallo Kallaste <[EMAIL PROTECTED]> 
>wrote:
> 
> [snip]
> 
> > It's very annoying, I have only fair experiences with dump/restore back
> > to the 2.2.2 days until now.
> 
> Sorry for the long post and partially? false alert.
> 
> Something in my mind waked up and I checked what type of bsize and fsize
> the other machines have. Now I remember a little discussion in the
> cvs-all list, at that time phk committed something about default flags
> for newfs or so and there was rgrimes involved into discussion. He was
> suggesting following flags for filesystem creation for newer, bigger
> disks:
> 
> newfs -b16384 -f2048 -u2048 -c128 -i4096
> 
> I've used them since with no problems whatsoever. Now I got the dump
> done on the machine with default filesystem, the bugger is unusual
> filesystem I guess. Is it expected behavior? Does anybody know why it
> can't be done?

A few more details please.  Are you having problems when you are
dumping from a file system formatted as above, or is it a restore
going to this type of file system, or are both the source and destination
file system formatted as above?

EXACTLY what dump/restore pipeline command did you run?

I'll try to duplicate this here... I suspect a blocking/unblocking
operation is highly un optimized to deal with these large block size
file systems and/or your exasting a kernel resource during this
operation.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Serious server-side NFS problem

[Rodney W. Grimes]

...
> (200-300 MHz) clients.  That's *with* packet loss (for some reason when
> my fxp ethernets pump data out that quickly they tend to cause packet
> loss in other parts of my HUBed network, which I find quite annoying).

Interesting you should say that  I've been playing with some broadcom
based ASIC 100BaseTX full duplex switches and I actually loose more packets
due to overrunning the buffers in the switch than I do if I used a half duplex
standard hub.  :-(

Performance for most things overall on the network is better with the
switch, but direct high bandwidth traffic between 2 machines has suffered
due to the conversion to a fully switched network.

Seems FreeBSD (using dc21143 based cards) can pump data around so damn
fast that the switch can't keep up :-(.  I need to do some more testing
to find out if this occurs between ports on the same ASIC or only when
packets have to go out to the ASIC to ASIC bridge bus.

Also how do the fxp and dc based cards respond to flow control?
Do we obey it?  Do the cards even understand it?

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Init Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) ) )

[Rodney W. Grimes]

> On Thu, Dec 16, 1999 at 01:22:46AM -0500, Donn Miller wrote:
> 
>  > runlevels, OpenBSD does not or goes with an entirely different
>  > system), them would it be fair to consider FreeBSD "BSD"?  The
>  > advantage here is that FreeBSD would mature into it's own type of
>  > UNIX with a BSD heritage.
>  
> Can we please not have this thread again?  Anyone who is interested
> in following up on anything whatsoever to do with SysV runlevels 
> should first familiarize themselves with the numerous problems they
> have which have been hashed out on the lists several times over the
> last 12 months (hint:  to to the mail archive search engine at 
> www.freebsd.org and search for "runlevel").

Only correction here is ``over the last 7 years'' not ``12 months''.  This
will be atleast the 4th time we have been over this...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: sysinstall: is it really at the end of its lifecycle?

[Rodney W. Grimes]

> 
> > Hm, if correct, Orca would make a good codename for a sysadm tool:
> > 
> > Ordinary Ramblers Can [now] Admin [FreeBSD]
> 
> Someone pointed out that Orca was already taken  The question NOW
> is:  Can you come up with a good acronym for "SHAMU"?

Easy...

Some Help for Another Misguided User


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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