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 incompe
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?
--
: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
c
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 */
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
>>
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 up
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.
>
>Hav
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
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 t
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 l
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 hist
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 goin
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
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 #ifdefe
> 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 *
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 so
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 "un
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 s
: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.cT
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:5
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
> > 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
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 me
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 t
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 i
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/s
>
> 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).
--
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
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 tha
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:
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 reason
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 d
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 fre
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,76
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.c
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 pr
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
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
do
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
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 t
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.
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
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/
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 s
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 sti
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 moun
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 (wh
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 day
48 matches
Mail list logo