Re: Remote serial gdb is broken in -CURRENT.

[Doug Rabson]

On Wed, 26 Apr 2000, Greg Lehey wrote:

> On Tuesday, 25 April 2000 at  9:39:10 +0100, Doug Rabson wrote:
> > On Tue, 25 Apr 2000, Greg Lehey wrote:
> >
> >> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote:
> >>> On Sun, 23 Apr 2000, Greg Lehey wrote:
> >>>
>  In the last few days, my remote serial gdb has almost completely
>  stopped working.  Previously I had (almost) no trouble at 38400 bps;
>  now I can barely get a response at all at 9600 bps.  Does anybody have
>  an idea where this could be coming from?
> >>>
> >>> I noticed this too but I have no idea why. I also had to move back to
> >>> 9600.
> >>
> >> I've found the problem and fixed it.  It's been broken all along, but
> >> for some reason it got worse lately.
> >>
> >> Basically, what happened was that the getpacket function, which does
> >> polled I/O, wasn't locking out interrupts, and something was
> >> interrupting long enough for characters to get lost.  Since sometimes
> >> several consecutive characters got lost, it seems likely that either
> >> something locks out interrupts for an inappropriately long time, or
> >> the sio interrupt routines steal them.  Anyway, it works nicely at
> >> 115200 bps now.
> >
> > Great, thanks Greg. Debugging at 9600bps was getting painful :-)
> 
> Even that didn't work for me.  BTW, the fix had the side effect of
> making the clock stand still.  I've changed the code (spltty instead
> of splhigh), and it seems to work OK now, so it probably was the tty
> interrupt stealing characters.  I'll commit when I'm sure all is still
> OK.

Cool.

> 
> > On a nearly unrelated subject, can you try out the new stuff I just put
> > into the kernel linker to allow it to export information to GDB. Now you
> > should be able to use GDB's "sharedlibrary" command to load symbols. Make
> > sure that the path used to load the file on the debugged machine is a
> > valid path leading to the same file on the debugger machine.
> 
> This looks like just what I'm looking for, especially if it can
> extract kld symbols.  How do I use it?

Basically, all you do is load the module on the scratch box. Use an
absolute path which also leads to the same file on the debugging box. Then
break into GDB somehow and type "sharedlibrary". The debugger should print
a message about each file which it finds and you can then use "info
sharedlibrary" to see where they were loaded. All the symbols are loaded
and relocated properly so you should be able to set breakpoints etc. as
normal.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 20 8442 9037




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

[Andrzej Bialecki]

On Wed, 26 Apr 2000, Daniel O'Connor wrote:

> Try buildworld on one machine and installworld on all of your production
> boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
> disks.

Yes, that's what I'm doing now - so far the best method. But still
requires having N+1 boxes (which is not a concern for me, but for someone
having e.g. 2 boxes in production this represents 1/3 increment), plus
topology allowing for using NFS mounts.

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

[Daniel O'Connor]

On 26-Apr-00 Andrzej Bialecki wrote:
>  Yes, that's what I'm doing now - so far the best method. But still
>  requires having N+1 boxes (which is not a concern for me, but for someone
>  having e.g. 2 boxes in production this represents 1/3 increment), plus
>  topology allowing for using NFS mounts.

True, depending on your setup you can do it ON your production machine :)

Or on your workstation etc..

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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

[David Malone]

On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote:

> > Try buildworld on one machine and installworld on all of your production
> > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
> > disks.
> 
> Yes, that's what I'm doing now - so far the best method. But still
> requires having N+1 boxes (which is not a concern for me, but for someone
> having e.g. 2 boxes in production this represents 1/3 increment), plus
> topology allowing for using NFS mounts.

Usually you can buildworld on one production machine in advance
and then schedule downtime for when you want to installworld. Then
we usually use rdist or rsync to do keep the rest of our production
machines in sync with this master machine. This procedure has worked
quite well for us since 2.something.

It also has the advantage that if something goes pear shaped during
the upgrade, you have other machines with exact copies of all the
binaries so you can restore the machine back to it's old state
without resorting to tape.

David.


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

Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility

[Andrzej Bialecki]

On Tue, 25 Apr 2000, Jim Bloom wrote:

> The RCS info stored in the binaries is insufficient for this purpose.  There is
> no record of the versions of all included files.  Changes to constants and/or
> macros would not be identifiable.

Yes, you're right, I'm afraid. This could theoretically be solved by
adding an ELF section at the build stage, containing the RCS versions from
files reported by 'make depend'. But at this point the things get ugly and
complicated very quickly... :-(

The simple approach could be as follows: start with the official version
of the RELEASE (which takes care of having one common version, with known
MD5 cksums). The patchkits would contain only the whole files, not diffs.
The patch installer would have to examine the target files before doing
anything, and if the MD5 checksums (relative to the last patchkit) don't
match - present a choice, in a way similar to mergemaster.

This way, we can push the responsibility for tracking dependencies to the
user... :-/

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: make buildworld failed...

[Vallo Kallaste]

On Tue, Apr 25, 2000 at 10:55:36AM -0500, Robert Small <[EMAIL PROTECTED]> wrote:

> Ok, I got the buildworld to finih up this morning, but when I try
> installworld, I get:
> m/vm_zone.h -> vm/vm_zone.ph
> vm/vnode_pager.h -> vm/vnode_pager.ph
> *** Error code 1
> 
> Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph.
> *** Error code 1
> 
> Stop in /usr/src/gnu/usr.bin/perl/utils.
> *** Error code 1
> 
> Stop in /usr/src/gnu/usr.bin/perl.
> *** Error code 1

I've got this trap for several times and I really want to know what's
causing this. The first time was about a year ago and after no answer
I've not bothered to send out more questions about it. Anyway, several
people report it time-to-time, so it's something general going on.
-- 

Vallo Kallaste
[EMAIL PROTECTED]


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

Re: Archive pruning

[Richard Wackerbarth]

On Wed, 26 Apr 2000, you wrote:

>   Any further discussion from you on this point that doesn't include code
> is totally and completely without value. You haven't proven the value of
> your suggestion to _anyone's_ satisfaction, so no one is going to do it
> for you. So if you're not willing to actually do it, please let it drop.

You are correct that I "haven't proven" yet. Much of this is because the 
audience doesn't relate to the problem because they don't see themselves 
directly impacted by it. However, they are paying for it every time they use 
cvsup or cvs.

That's the trouble with this developer community. They see EVERYTHING as 
WRITING CODE and "adding on". This is not about writing code. The code 
already exists. I am just advocating using it in a different way.

As for the actual "doing", I'm quite willing to do to actual "legwork" that 
results from the change. But the change is a fundamental change in the way 
the organization "does business". Unless the organization makes a change,
there is nothing to do.

I think that it is just a matter of time until the matter gets raised by yet 
another person as the underlying problem gets more acute. 

I'll sit back and wait...


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

PATCH: Removal of unneeded

[Poul-Henning Kamp]

New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch

This patch removes 67 unneeded instances of #include 

Comments, tests and reviews please.


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Re: Archive pruning

[Brad Knowles]

At 2:22 PM -0600 2000/4/25, Nate Williams wrote:

>  I consider you a very small minority.  A user who is not a developer,
>  but who could be a developer.  The amount of work it would take to
>  support your needs is way too much work, and it would only benefit <
>  1-2% of the user base.  Does this mean we don't care about all our
>  users?  Of course not, but when the same amount of time/effort can
>  positively effect > 50% of the user base, then it makes more sense to
>  spend the time more wisely.

Not that I really want to be seen as being on the same side of 
the argument as Richard, but there is an issue I think you've ignored 
-- current versus potential future customers.

When you look at current customers (at least, the ones that are 
vocal enough to express an opinion), you get the sorts of numbers you 
have expressed.  However, when you compare this against potential 
future customers, I think you could very quickly find that the people 
who currently appear to be the vocal majority instead find themselves 
to be a vocal minority.


I see this as being the same sort of problem that is faced by the 
"Moral Majority" crowd.  IMO, they are neither moral nor a majority, 
but they are exceptionally vocal, and quite good at shouting down 
people who oppose them, and making sure that most of the real 
majority never even thinks of stepping into the debate simply because 
they don't want to have to deal with these bozos.


Not that I want to equate the people who have taken the opposite 
view as being a "Moral Majority" or anything, just that there is a 
similar problem that I think has to be recognized, and we have to try 
to find some way to address it.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Archive pruning

[Brad Knowles]

At 1:32 PM -0700 2000/4/25, Matthew Hunt wrote:

>  Maintaining a CVS repository is necessary only if you are working
>  on the code, so your proposal would only affect devlopers, not Joe
>  User.  Normal users do not maintain copies of the repository and do
>  not have a frequent need to examine history.

True enough.  However, how many "normal users" would you expect 
to be subscribing to the freebsd-current mailing list?  If this is a 
current versus stable versus release issue, I think we can all agree 
that most users are clueless enough that they can't even figure out 
how to send e-mail to the freebsd-questions mailing list, much less 
anything else.

So, you are either forced to change your definition of "normal 
users" to be people who would be subscribing to this list (and 
hopefully contributing in some way) and you have to acknowledge that 
change in definition, or you have to change the term that you use.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Archive pruning

[Brad Knowles]

At 1:36 PM -0700 2000/4/25, Kris Kennaway wrote:

>  Why would "The Project" have to do anything? We've already established
>  this is of minority appeal,

Have we?  Really?  We have established that this is of minority 
appeal to the people who have spoken up on this mailing list, but 
does this mailing list really reflect accurately the opinions of the 
entire user base and potential future user base?

I don't want to claim that you are wrong, I just would like to 
accurately establish just what it is we've really determined and why, 
and where this is going to take us.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

[Jesper Skriver]

On Wed, Apr 26, 2000 at 09:33:46AM +0200, Andrzej Bialecki wrote:
> On Wed, 26 Apr 2000, Daniel O'Connor wrote:
> 
> > Try buildworld on one machine and installworld on all of your production
> > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE
> > disks.
> 
> Yes, that's what I'm doing now - so far the best method. But still
> requires having N+1 boxes (which is not a concern for me, but for someone
> having e.g. 2 boxes in production this represents 1/3 increment), plus
> topology allowing for using NFS mounts.

Or burning /usr/src/ and /usr/obj/ onto a CD after buildworld, and using
that for installworlds ...

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


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

vn.ko load/unload/mount = panic

[Maxim Sobolev]

Hi,

I've already submitted this crash report earlier but it seems that developers
in -current list are too busy discussing whether Matt allowed to commit his SMP
work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
slightly simplified course of actions which is known to produce kernel panic on
both 4.0 and 5.0:

root@notebook# kldstat
Id Refs AddressSize Name
 12 0xc010 1c2f48   kernel
 21 0xc02c3000 30c8 splash_bmp.ko
root@notebook# mount /dev/vn0c /mnt
mount: Device not configured
root@notebook# kldload /modules/vn.ko
root@notebook# kldstat
Id Refs AddressSize Name
 13 0xc010 1c2f48   kernel
 21 0xc02c3000 30c8 splash_bmp.ko
 31 0xc0823000 3000 vn.ko
root@notebook# kldunload -i 3
root@notebook# mount /dev/vn0c /mnt
[BINGO]
Fatal trap 12: page fault while in kernel mode
[...]

-Maxim



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

NAT tutorial?

[Jason Mitchell]

Does anyone know of a tutorial or more detailed instructions on how to use
NAT and IP masquerading in 3.4?  I can configure it so that it is running
and working with IP firewall within the box no problem, but as far as
dolling out local IPs to the rest of the workstations or even building a
natd.conf file, I'm lost.  The closest I've found is the tutorial at
http://freebsd.peon.net, but that doesn't quite cover enough.

Thanks in advance,

Jason Mitchell



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

Re: vn.ko load/unload/mount = panic

[Peter Edwards (local)]

Hi,
After a (very) quick look at the source it looks like there's a missing
cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
I haven't time to test it, but try this:

*** vn.c.oldWed Apr 26 16:23:03 2000
--- vn.cWed Apr 26 16:24:06 2000
***
*** 762,767 
--- 762,768 
case MOD_UNLOAD:
/* fall through */
case MOD_SHUTDOWN:
+   cdevsw_remove(&vn_cdevsw);
for (;;) {
vn = SLIST_FIRST(&vn_list);
if (!vn)


Maxim Sobolev wrote:
> 
> Hi,
> 
> I've already submitted this crash report earlier but it seems that developers
> in -current list are too busy discussing whether Matt allowed to commit his SMP
> work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> slightly simplified course of actions which is known to produce kernel panic on
> both 4.0 and 5.0:
> 
> root@notebook# kldstat
> Id Refs AddressSize Name
>  12 0xc010 1c2f48   kernel
>  21 0xc02c3000 30c8 splash_bmp.ko
> root@notebook# mount /dev/vn0c /mnt
> mount: Device not configured
> root@notebook# kldload /modules/vn.ko
> root@notebook# kldstat
> Id Refs AddressSize Name
>  13 0xc010 1c2f48   kernel
>  21 0xc02c3000 30c8 splash_bmp.ko
>  31 0xc0823000 3000 vn.ko
> root@notebook# kldunload -i 3
> root@notebook# mount /dev/vn0c /mnt
> [BINGO]
> Fatal trap 12: page fault while in kernel mode
> [...]
> 
> -Maxim
> 
> 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

Re: Archive pruning

[Matthew Hunt]

On Wed, Apr 26, 2000 at 12:24:59PM +0200, Brad Knowles wrote:

> >  Maintaining a CVS repository is necessary only if you are working
> >  on the code, so your proposal would only affect devlopers, not Joe
> >  User.  Normal users do not maintain copies of the repository and do
> >  not have a frequent need to examine history.
> 
>   True enough.  However, how many "normal users" would you expect 
> to be subscribing to the freebsd-current mailing list?  If this is a 

[...]

>   So, you are either forced to change your definition of "normal 
> users" to be people who would be subscribing to this list (and 
> hopefully contributing in some way) and you have to acknowledge that 
> change in definition, or you have to change the term that you use.

Perhaps I am missing your point, but in terms of deciding whether
Richard's proposal has merit, the fact that we're discussing this
on -CURRENT does not seem to me to be an issue.

In any case where somebody says "Y'all should do such-and-such"
without ponying up the code himself, we should be thinking about
whether the benefit to the users will "pay for" the time it takes
us to do it.  If 10% of the people who run -CURRENT would find a
pruned-history repository useful, but only 10% of our user-base
runs -CURRENT, then it seems to me that the fact that it benefits
1% of the user population is the relevant figure.

(This is different from the usual case of only putting new features
in -CURRENT, because that code will eventually become -STABLE; the
people benefitting from Richard's proposal, according to the arguments
I've seen so far, are the ones who keep running -CURRENT, whatever
that happens to be at the moment.)

Does this address your criticism?

Matt

-- 
Matthew Hunt <[EMAIL PROTECTED]> * UNIX is a lever for the
http://www.pobox.com/~mph/   * intellect. -J.R. Mashey


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

Re: Archive pruning

[Frank Mayhar]

Richard Wackerbarth wrote:
> You are correct that I "haven't proven" yet. Much of this is because the 
> audience doesn't relate to the problem because they don't see themselves 
> directly impacted by it. However, they are paying for it every time they use 
> cvsup or cvs.

"Frankly, my dear, I don't give a damn."

> That's the trouble with this developer community. They see EVERYTHING as 
> WRITING CODE and "adding on". This is not about writing code. The code 
> already exists. I am just advocating using it in a different way.

_What_ code, Richard?  All you've done in this whole ridiculous thread is
spout generalities and generally attack -core.

> As for the actual "doing", I'm quite willing to do to actual "legwork" that 
> results from the change. But the change is a fundamental change in the way 
> the organization "does business". Unless the organization makes a change,
> there is nothing to do.

This is a cop-out.  Define your "different way."  If it takes code to do
it, write the code, even if that's just shell scripts.  Set up a prototype
that's publically visible.  Prove your point, don't just argue.

> I think that it is just a matter of time until the matter gets raised by yet 
> another person as the underlying problem gets more acute. 

You haven't even proven that there _is_ an "underlying problem."  As far as
_I'm_ concerned, there _isn't_, and I keep a full repository just for the
convenience of having it local.

> I'll sit back and wait...

Uh, huh.  Cop out.  Business as usual for you, Richard, from what I have
seen in the past.

It's simple:  Put up or shut up.
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/


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

Re: Archive pruning

[Brad Knowles]

At 8:50 AM -0700 2000/4/26, Matthew Hunt wrote:

>  In any case where somebody says "Y'all should do such-and-such"
>  without ponying up the code himself, we should be thinking about
>  whether the benefit to the users will "pay for" the time it takes
>  us to do it.

Sounds like a reasonable cost-benefit analysis, as far as it goes.

>If 10% of the people who run -CURRENT would find a
>  pruned-history repository useful, but only 10% of our user-base
>  runs -CURRENT, then it seems to me that the fact that it benefits
>  1% of the user population is the relevant figure.

I am only guessing, but the way I read the original proposal 
(which Richard has been advocating much more strongly than the person 
who originally proposed it) sounded to me like it would benefit 
anyone and everyone that installed the sources, and therefore is a 
much broader issue that really should be discussed on something like 
a -POLICY mailing list, as opposed to here on -CURRENT.


Assuming it were relevant to just the users of -CURRENT, how can 
you be sure that only 10% of them would benefit?  To be fair and 
honest, you'd have to take a statistical sample of a large enough 
group of users of -CURRENT, and not just rely on the self-selecting 
responses by a vocal subset.

Assuming you could take a statistically valid sample and prove 
that it really would benefit just 10% of the users of -CURRENT, how 
could you prove that only 10% of the people run -CURRENT as opposed 
to -STABLE?

>  Does this address your criticism?

I think there are a number of issues to be resolved.  Probably 
the most important is the issue of scope of the change, and who all 
would potentially benefit (or be harmed) by such a change.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Archive pruning

[Doug Barton]

Richard Wackerbarth wrote:
> 
> On Wed, 26 Apr 2000, you wrote:
> 
> >   Any further discussion from you on this point that doesn't include code
> > is totally and completely without value. 

> You are correct that I "haven't proven" yet. 

. . . 

> I'll sit back and wait...


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

Re: Archive pruning

[Matthew Hunt]

On Wed, Apr 26, 2000 at 06:11:23PM +0200, Brad Knowles wrote:

>   I am only guessing, but the way I read the original proposal 
> (which Richard has been advocating much more strongly than the person 
> who originally proposed it) sounded to me like it would benefit 
> anyone and everyone that installed the sources, and therefore is a 

My impression was that it would benefit the people who installed
the repository, not just the sources.  If I'm mistaken, I'm sure
someone will correct me.  But that's why I perceive the propasal
as mostly affecting developers (in the sense of people who do any
code-tinkering, not just committers).

>   Assuming it were relevant to just the users of -CURRENT, how can 
> you be sure that only 10% of them would benefit?  To be fair and 

The 10% figures were hypotheticals to demonstrate which figure I
believed to be relevant.  They weren't meant to be accurate, aside
from both being smaller than unity.

IMHO, though, I generally find it reasonable that those who have
an opinion on a propsal should take it upon themselves to speak up,
rather than waiting to be polled.  But as you say, the proposal must
be set forth in an appropriate venue.

-- 
Matthew Hunt <[EMAIL PROTECTED]> * UNIX is a lever for the
http://www.pobox.com/~mph/   * intellect. -J.R. Mashey


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

Re: vn.ko load/unload/mount = panic

[Peter Edwards (local)]

Sorry, I think that fix is incomplete (though it'll prolly stop the
crashes). I think there should be a destroy_dev() call for each created
device in the MOD_UNLOAD case also.
I'll make a patch and send-pr it once I get back to my home machine,
unless someone more experienced feels the need to do it.
--
Peter.


"Peter Edwards (local)" wrote:
> 
> Hi,
> After a (very) quick look at the source it looks like there's a missing
> cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> I haven't time to test it, but try this:
> 
> *** vn.c.oldWed Apr 26 16:23:03 2000
> --- vn.cWed Apr 26 16:24:06 2000
> ***
> *** 762,767 
> --- 762,768 
> case MOD_UNLOAD:
> /* fall through */
> case MOD_SHUTDOWN:
> +   cdevsw_remove(&vn_cdevsw);
> for (;;) {
> vn = SLIST_FIRST(&vn_list);
> if (!vn)
> 
> Maxim Sobolev wrote:
> >
> > Hi,
> >
> > I've already submitted this crash report earlier but it seems that developers
> > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > slightly simplified course of actions which is known to produce kernel panic on
> > both 4.0 and 5.0:
> >
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  12 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> > root@notebook# mount /dev/vn0c /mnt
> > mount: Device not configured
> > root@notebook# kldload /modules/vn.ko
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  13 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> >  31 0xc0823000 3000 vn.ko
> > root@notebook# kldunload -i 3
> > root@notebook# mount /dev/vn0c /mnt
> > [BINGO]
> > Fatal trap 12: page fault while in kernel mode
> > [...]
> >
> > -Maxim
> >
> > 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


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

Re: cc1 sig 11'ing recently?

[Brian Somers]

> 
> Any getting these too?
> 
> ild-tools
> cd /usr/src/bin/sh; make build-tools
> cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat   -c
> /usr/src/bin/sh/mkinit.c
> cc: Internal compiler error: program cc1 got fatal signal 11

Only people with dodgy memory or cache (probably memory).
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




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

Re: cc1 sig 11'ing recently?

[Matthew Jacob]

Umm- doubt it, but I'll check. This system has been fine for the last 18
months and runs everything else just peachy.

On Wed, 26 Apr 2000, Brian Somers wrote:

> > 
> > Any getting these too?
> > 
> > ild-tools
> > cd /usr/src/bin/sh; make build-tools
> > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat   -c
> > /usr/src/bin/sh/mkinit.c
> > cc: Internal compiler error: program cc1 got fatal signal 11
> 
> Only people with dodgy memory or cache (probably memory).
> -- 
> Brian <[EMAIL PROTECTED]>
>      
> Don't _EVER_ lose your sense of humour !
> 
> 



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

Re: make buildworld failed...

[Kris Kennaway]

On Wed, 26 Apr 2000, Vallo Kallaste wrote:

> I've got this trap for several times and I really want to know what's
> causing this. The first time was about a year ago and after no answer
> I've not bothered to send out more questions about it. Anyway, several
> people report it time-to-time, so it's something general going on.

Check the archives - I've answered the question several times in the past
month or two.

Kris


In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



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

Re: vn.ko load/unload/mount = panic

[Wilko Bulte]

On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote:

How about send-pr ing this stuff? 

Wilko

> Hi,
> After a (very) quick look at the source it looks like there's a missing
> cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> I haven't time to test it, but try this:
> 
> *** vn.c.oldWed Apr 26 16:23:03 2000
> --- vn.cWed Apr 26 16:24:06 2000
> ***
> *** 762,767 
> --- 762,768 
> case MOD_UNLOAD:
> /* fall through */
> case MOD_SHUTDOWN:
> +   cdevsw_remove(&vn_cdevsw);
> for (;;) {
> vn = SLIST_FIRST(&vn_list);
> if (!vn)
> 
> 
> Maxim Sobolev wrote:
> > 
> > Hi,
> > 
> > I've already submitted this crash report earlier but it seems that developers
> > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > slightly simplified course of actions which is known to produce kernel panic on
> > both 4.0 and 5.0:
> > 
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  12 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> > root@notebook# mount /dev/vn0c /mnt
> > mount: Device not configured
> > root@notebook# kldload /modules/vn.ko
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  13 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> >  31 0xc0823000 3000 vn.ko
> > root@notebook# kldunload -i 3
> > root@notebook# mount /dev/vn0c /mnt
> > [BINGO]
> > Fatal trap 12: page fault while in kernel mode
> > [...]
> > 
> > -Maxim

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


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

Re: cc1 sig 11'ing recently?

[David Scheidt]

On Wed, 26 Apr 2000, Matthew Jacob wrote:

> 
> Umm- doubt it, but I'll check. This system has been fine for the last 18
> months and runs everything else just peachy.
> 

Sudden SIGSEGVs are almost always the result of failed memory.  The fact
that the machine worked fine for 18 months doesn't mean anything.  Replace
the memory and your problems will likely go away.  If they don't, it's
likely that the problem is cooling, processor cache, or a bad motherboard
memory bus.

David



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

Re: cc1 sig 11'ing recently?

[Ron Klinkien]

> > Any getting these too?
> >
> > ild-tools
> > cd /usr/src/bin/sh; make build-tools
> > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat   -c
> > /usr/src/bin/sh/mkinit.c
> > cc: Internal compiler error: program cc1 got fatal signal 11
>
> Only people with dodgy memory or cache (probably memory).

Or dodgy CPU's like some of the AMD K6/233 ones, when you install more than
32Mb memory.

I myself got bitten by this bug yesterday ;(

Didn't know this bug exists until I runned a Linux kernel ones, it warned me
for this...
Something for the FreeBSD kernel too?

Ron Klinkien.




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

linux emulation patch committed to -current - recompile linux module

[Matthew Dillon]

The linux emulation patch has been committed to -current, you must
recompile your linux emulation kld.

This patch will be MFC'd to 4.x on Friday.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Workaround for hanging on exit: patch for review

[Andrey A. Chernov]

I often notice processes hanging forever on exit's ttywait when TCP
connection dropped. Here is a patch I plan to commit which restrict
waiting for output drain by 3 minutes. Any comments, improvements or
objections?

--- kern_exit.c.bak Sun Apr 16 23:35:55 2000
+++ kern_exit.c Thu Apr 27 00:56:02 2000
@@ -230,6 +230,9 @@
if (sp->s_ttyp && (sp->s_ttyp->t_session == sp)) {
if (sp->s_ttyp->t_pgrp)
pgsignal(sp->s_ttyp->t_pgrp, SIGHUP, 1);
+   /* XXX don't hang forever */
+   if (sp->s_ttyp->t_timeout == 0)
+   sp->s_ttyp->t_timeout = 180 * hz;
(void) ttywait(sp->s_ttyp);
/*
 * The tty could have been revoked

-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://nagual.pp.ru/~ache/


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

Re: Workaround for hanging on exit: patch for review

[Matthew Dillon]

:I often notice processes hanging forever on exit's ttywait when TCP
:connection dropped. Here is a patch I plan to commit which restrict
:waiting for output drain by 3 minutes. Any comments, improvements or
:objections?
:
:--- kern_exit.c.bakSun Apr 16 23:35:55 2000
:+++ kern_exit.cThu Apr 27 00:56:02 2000
:@@ -230,6 +230,9 @@
:   if (sp->s_ttyp && (sp->s_ttyp->t_session == sp)) {
:   if (sp->s_ttyp->t_pgrp)
:   pgsignal(sp->s_ttyp->t_pgrp, SIGHUP, 1);
:+  /* XXX don't hang forever */
:+  if (sp->s_ttyp->t_timeout == 0)
:+  sp->s_ttyp->t_timeout = 180 * hz;
:   (void) ttywait(sp->s_ttyp);
:   /*
:* The tty could have been revoked
:
:-- 
:Andrey A. Chernov

I think this is a good idea.  I've seen processes stuck in ttywait
forever too, usually when I'm using cu and the remote end is spewing
all sorts of junk my way.

p.s. (on a different topic) I am also seeing serial stream corruption 
for serial console output.  If I add a kernel printf() that generates
a lot of output, I get most of it on the serial console plus a lot 
of other random garbage.  Very weird.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: NAT tutorial?

[Joe Abley]

Hi Jason,

This is really a -questions question, not a -current question.

On Wed, 26 Apr 2000, Jason Mitchell wrote:

> Does anyone know of a tutorial or more detailed instructions on how to use
> NAT and IP masquerading in 3.4?

"IP masquerading" is what the linux people call NAT. They are the same
thing.

> I can configure it so that it is running
> and working with IP firewall within the box no problem, but as far as
> dolling out local IPs to the rest of the workstations

Dynamic allocation of IP addresses to workstations doesn't have much to do
with NAT -- try hunting for information on dhcp or bootp. There are two
DHCP servers in the ports tree (net/isc-dhcp2 and net/wide-dhcp).

If I'm barking up the wrong tree, and you're actually talking about static
NAT maps, then see natd(8).

> or even building a
> natd.conf file, I'm lost.

You have read natd(8), right?

> The closest I've found is the tutorial at
> http://freebsd.peon.net, but that doesn't quite cover enough.

Try describing exactly what you're trying to achieve, rather than guessing
at components that might provide solutions -- then post the question to
the -questions list. There are lots of helpful people there that will give
you ideas.

Oh -- also, check out Dan's list of NAT articles at

  http://www.freebsddiary.org/topics.php3#nat

Joe



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

Re: cc1 sig 11'ing recently?

[Matthew Jacob]

Thanks to all who mentioned failing memory- I don't think this was the case.

Installing a new source tree on a local directory instead of building on 
top of NFS mounted /usr/src worked for me.

It's not clear what to make of this.









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

Re: Workaround for hanging on exit: patch for review

[Andrey A. Chernov]

On Wed, Apr 26, 2000 at 02:22:47PM -0700, Matthew Dillon wrote:
> :I often notice processes hanging forever on exit's ttywait when TCP
> 
> I think this is a good idea.  I've seen processes stuck in ttywait
> forever too, usually when I'm using cu and the remote end is spewing
> all sorts of junk my way.

There is a number of places this may occurse and all of them have no timeout 
by default.  F.e.  if some terminal shell hangs in exit's ttywait, comsat 
hangs on ttywrite and lots of comsats appearse after several hours. Alternative
solution will be adding

tp->t_timeout = 180 * hz;

while initializing tp struct, but it is more radical than I suggest initially.
Any ideas?

-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://nagual.pp.ru/~ache/


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

Re: Workaround for hanging on exit: patch for review

[Andrey A. Chernov]

> There is a number of places this may occurse and all of them have no timeout 
> by default.  F.e.  if some terminal shell hangs in exit's ttywait, comsat 
> hangs on ttywrite and lots of comsats appearse after several hours. Alternative
> solution will be adding
> 
>   tp->t_timeout = 180 * hz;
> 
> while initializing tp struct, but it is more radical than I suggest initially.
> Any ideas?

I mean following patch here:

--- tty.c.bak   Thu Apr  6 19:20:22 2000
+++ tty.c   Thu Apr 27 03:27:42 2000
@@ -218,6 +218,7 @@
SET(tp->t_state, TS_CONNECTED);
bzero(&tp->t_winsize, sizeof(tp->t_winsize));
}
+   tp->t_timeout = 180 * hz;   /* XXX don't hang forever */
ttsetwater(tp);
splx(s);
return (0);


-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://nagual.pp.ru/~ache/


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

Re: PATCH: Removal of unneeded

[Greg Lehey]

On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote:
>
> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch
>
> This patch removes 67 unneeded instances of #include 
>
> Comments, tests and reviews please.

Have you checked that there are no references which are #ifdefed out?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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

Re: Archive pruning

[Will Andrews]

On Wed, Apr 26, 2000 at 12:27:22PM +0200, Brad Knowles wrote:
> >  Why would "The Project" have to do anything? We've already established
> >  this is of minority appeal,
> 
>   Have we?  Really?  We have established that this is of minority 

It seems to me that the typical assumption is that if someone doesn't speak
up, they abstain their vote, for whatever value it might have. Thus, given
the number of people who have said they don't think it worth it, and given
the number who said they would like this feature, I think we've established
that this is a minority issue, quite clearly.

Since this is a volunteer project, people are NOT going to be polled on
their opinion about X, Y, or Z. They'll either speak up if they care enough
or they'll be quiet about the whole proceeding.

It does seem that this mailing list is entirely inappropriate for this
particular topic; perhaps this thread should be moved to freebsd-arch. Or,
as Chuck said about 10 messages ago, it should just die. Either way, I
don't honestly care. I'm just not going to be convinced to do any of the
coding necessary to prune our repository. I have better things to do with
my time than something like that. :-)

-- 
Will Andrews <[EMAIL PROTECTED]>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ 
G++>+++ e-> h! r-->+++ y?


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

Re: Archive pruning

[John Baldwin]

On 26-Apr-00 Richard Wackerbarth wrote:
> On Wed, 26 Apr 2000, you wrote:
> 
>>  Any further discussion from you on this point that doesn't include code
>> is totally and completely without value. You haven't proven the value of
>> your suggestion to _anyone's_ satisfaction, so no one is going to do it
>> for you. So if you're not willing to actually do it, please let it drop.
> 
> You are correct that I "haven't proven" yet. Much of this is because the 
> audience doesn't relate to the problem because they don't see themselves 
> directly impacted by it. However, they are paying for it every time they use 
> cvsup or cvs.

*Bzzzt*.  Wrong.  You only get the old history during the intial cvsup.  And
since the most recent revisions are stored at the beginning of an RCS file,
you don't pay for this on cvs operations except for 'cvs log' and other
operations dealing with the history.  Good grief, at least get your facts
straight before blathering on.

> That's the trouble with this developer community. They see EVERYTHING as 
> WRITING CODE and "adding on". This is not about writing code. The code 
> already exists. I am just advocating using it in a different way.

No, we just don't do things that we feel are beneficial just because one
person is jumping up and down yelling for it.  If you want it done, do it
yourself, basically.  That's why the ports I have committed so far are in
the tree.  I wanted a port of some program, it wasn't in the tree, so I
made it myself, and when I was done I committed it so everyone else could
have the option of playing with it.  Welcome to a volunteer project.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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

Re: Archive pruning

[Richard Wackerbarth]

On Wed, 26 Apr 2000, you wrote:

> *Bzzzt*.  Wrong.  You only get the old history during the intial cvsup. 
> And since the most recent revisions are stored at the beginning of an RCS
> file, you don't pay for this on cvs operations except for 'cvs log' and
> other operations dealing with the history.  Good grief, at least get your
> facts straight before blathering on.

I suggest that YOU get your facts straight.

1) Only the head changes are written at the top of the file. For other 
branches, cvs has to track down to the branch point and then back out the 
branch. At each step, it must apply the "patch" that represents the 
difference in the two versions.
2) I have seen routines that append to the end of a file. However, if I 
insert at the front, I must copy the entire file.


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

Re: Archive pruning

[John Baldwin]

On 27-Apr-00 Richard Wackerbarth wrote:
> On Wed, 26 Apr 2000, you wrote:
> 
>> *Bzzzt*.  Wrong.  You only get the old history during the intial cvsup. 
>> And since the most recent revisions are stored at the beginning of an RCS
>> file, you don't pay for this on cvs operations except for 'cvs log' and
>> other operations dealing with the history.  Good grief, at least get your
>> facts straight before blathering on.
> 
> I suggest that YOU get your facts straight.
> 
> 1) Only the head changes are written at the top of the file. For other 
> branches, cvs has to track down to the branch point and then back out the 
> branch. At each step, it must apply the "patch" that represents the 
> difference in the two versions.

And since these will need to be kept for the branches to be useful, this
is irrelevant to the discussion at hand.

> 2) I have seen routines that append to the end of a file. However, if I 
> insert at the front, I must copy the entire file.

Yes, I suppose your nightly cvsup might take an extra 1 s longer to
complete, but I can't really tell since I'm usually sleeping through it.
Seriously, do you sit there during the day with a stopwatch and time how
long each cvsup takes every five minutes?  Besides, this only comes in to
play during cvsup, not during any cvs operations since users aren't
committing changes.

Anyways, one thing that Alfred Perlstein said he might like would be to
have another cvsup server that a lite version of the repo could be cvsup'ed
from.  If, as you say, this can all be truly automated, then setup a cvsup
server that cvsups every so often, and automatically expires old history
and then serves up the new repo via cvsup.  Even if you just generate a
proof of concept and don't have the resources to provide the mirror, someone
might be interested in running a mirror with your patches.

--

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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

Re: Problems configuring Vadem VG-469 PCMCIA controller.

[Warner Losh]

In message  Dave Belfer-Shevett 
writes:
: Vendor ID AEI0218 (0x1802a904), Serial Number 0x01234567

You'll have to add this ID to the list of IDs in the pcic driver for
4.0.  I'll try to do this when I get back if you can wait.  And if you
can't then you'll have to do it yourself :-)

Warner


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

DEVFS - what's happening with it?

[Stephen Hocking-Senior Programmer PGS SPS Perth]

Haven't seen any discussion for quite some time. The Linux people seem to be 
getting into a lather about it as well. Rehashing the issues like device 
persistence, et cetera.

Is anyone doodling around with a sysctlfs?



Stephen
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




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

Re: PATCH: Removal of unneeded

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Greg Lehey writes:
>On Wednesday, 26 April 2000 at 11:50:11 +0200, Poul-Henning Kamp wrote:
>>
>> New patch at: http://phk.freebsd.dk/misc/sys_kernel_h.patch
>>
>> This patch removes 67 unneeded instances of #include 
>>
>> Comments, tests and reviews please.
>
>Have you checked that there are no references which are #ifdefed out?

Yes, the src/tools/tools/kerninclude script first renames the include
and if the source file still compiles it declares a "no-read" and
leaves the #include intact.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

Archive pruning - some #s

[John W. DeBoskey]

Hi,

   I've been idly watching this thread and decided to check
a few numbers Is it truly worth pruning?

   I mirror the freebsd repository, mail archives, and
www site locally:

size 1.9Gig.
time 4:48minabout 2/5 gig per minute
   

   ie: it takes about 5 minutes for the update to run. Most of that
   time is due to the mediocre link I live behind.

   Internally, we maintain a CVS repository which we use cvsup to
backup (100T x-over direct between machines).

size 57Gig   (no, that isn't a typo).
time 41:36  about 1.3 gig per minute
   
   In the above case, the network is not the bottle-neck. We simply
can't read the data off the disk(s) fast enough (currently a
dpt raid, moving to amr with more than twice the performance).

   I guess I don't see why it's worth pruning. The network connection
in my case seems to be the bigger problem. Pruning the tree isn't
going to buy me anything. And, we lose information...

   Comments?

Later,
John


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

Re: cc1 sig 11'ing recently?

[Adam]

On Wed, 26 Apr 2000, Ron Klinkien wrote:

>> > Any getting these too?
>> >
>> > ild-tools
>> > cd /usr/src/bin/sh; make build-tools
>> > cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat   -c
>> > /usr/src/bin/sh/mkinit.c
>> > cc: Internal compiler error: program cc1 got fatal signal 11
>>
>> Only people with dodgy memory or cache (probably memory).
>
>Or dodgy CPU's like some of the AMD K6/233 ones, when you install more than
>32Mb memory.
>
>I myself got bitten by this bug yesterday ;(
>
I have also seem bad cyrix chips cause this - it drove me nuts because I
happened to grab a spare cpu which happened to be faulty in the same way
from the spare tray and it lead me to building an almost complete clone of
the misbehaving computer before I decided to try another cpu :/  Ended up
with the original bad and TWO bad cpu's from the spare tray before I found
one that worked :)



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

Support for large mfs

[John W. DeBoskey]

Hi,

   Today, we tried to create a 5Gig mfs. It turns out this is
not such a good idea. It turns out that support is basically
limited to an int. Extracts from some of the appropriate files
show some of the problems...

newfs.c:

int fssize; /* file system size */   

case 's':
if ((fssize = atoi(optarg)) <= 0)



ufs/ufs/ufsmount.h

/*
 * Arguments to mount MFS
 */
struct mfs_args {
char*fspec; /* name to export for statfs */
struct  export_args export; /* if exported MFSes are supported */
caddr_t base;   /* base of file system in memory */
u_long  size;   /* size of file system */
};


ufs/mfs/mfsnode.h

struct mfsnode {struct  vnode *mfs_vnode;   /* vnode associated with this 
mfsnode */
caddr_t mfs_baseoff;/* base of file system in memory */
longmfs_size;   /* size of memory file system */
pid_t   mfs_pid;/* supporting process pid */
struct buf_queue_head buf_queue;/* list of I/O requests */
int mfs_active;
longmfs_spare[1];
};


   As can be seen above, the only constant we have is that the size is
atleast a 4 byte entity.


   Before we start changing the size from an int/long/u_long to a
quad_t, is there a better way to do this? How does md fit into the
picture?


Thanks!
John

ps: On a side note, what is the correct way to create a quad_t constant
in the config file? The following works, but seems dirty:

options MAXDSIZ="((__int64_t)5*1024*1024*1024)"



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

Re: Support for large mfs

[Matthew Dillon]

:Hi,
:
:   Today, we tried to create a 5Gig mfs. It turns out this is
:not such a good idea. It turns out that support is basically
:limited to an int. Extracts from some of the appropriate files
:show some of the problems...

More then just a few MFS uses an mmap()'d segment, so you
can't create an MFS partition larger then what a process can mmap()
anyway.  The max is going to be around 2-3 GB.

You should be able to create a large virtual VN device.  man
vnconfig for more information - you have the choice of making it
file-backed, swap-backed, or swap-backed with the swap pre-reserved.
file-backed VN devices have a sector size of 512 bytes (which is 
standard).  Swap-backed VN devices have a sector size of a page (4K on
PC's).

vnconfig up a VN device, disklabel it, and newfs away.  You can also
turn softupdates on in the VN filesystem partitions.  I've tested VN
all the way to a terrabyte - and just managed to newfs it before I ran
out of swap :-)

-Matt



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

Re: Workaround for hanging on exit: patch for review

[Michael C . Wu]

On Thu, Apr 27, 2000 at 01:14:02AM +0400, Andrey A. Chernov scribbled:
| I often notice processes hanging forever on exit's ttywait when TCP
| connection dropped. Here is a patch I plan to commit which restrict
| waiting for output drain by 3 minutes. Any comments, improvements or
| objections?
---end quoted text---

This sounds really absurd and "bike shed"ish.
Please make that 5 minutes.  I frequently connect
to places that have 2~3 minute lag. :)

-- 
[EMAIL PROTECTED] - Is this a stupid host?


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

PATCH: http://phk.freebsd/dk/misc/vm_vm_zone_h.patch

[Poul-Henning Kamp]

Removes 43 unneeded #include  includes.

Comments, tests and reviews please

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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