SOFTUPDATES?
I add "options SOFTUPDATES" and my kernel won't compile make depend => [snip] ort.c ../../libkern/random.c ../../libkern/rindex.c ../../libkern/scanc.c ../../libkern/skpc.c ../../libkern/strcat.c ../../libkern/strcmp.c ../../libkern/strcpy.c ../../libkern/strlen.c ../../libkern/strncmp.c ../../libkern/strncpy.c ../../libkern/udivdi3.c ../../libkern/umoddi3.c ../../pci/ide_pci.c ioconf.c param.c vnode_if.c config.c cc: ../../ufs/ffs/ffs_softdep.c: No such file or directory cvsup current ran before recompilation :( -- Tomas TPS Ulej System Administrator t...@internet.sk, tu36-ripe TELENOR Internet, NETLAB Network, Slovakia To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
On Fri, 4 Jun 1999, Tomas TPS Ulej wrote: > I add "options SOFTUPDATES" and my kernel won't compile [snip] > cc: ../../ufs/ffs/ffs_softdep.c: No such file or directory cd /usr/src/sys/ufs/ffs ln -s /usr/src/contrib/sys/softupdates/ffs_softdep.c ffs_softdep.c ln -s /usr/src/contrib/sys/softupdates/softdep.h softdep.h then try to recompile your kernel ;-) Pascal Hofstee - dae...@shadowmere.student.utwente.nl -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS 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+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
> I add "options SOFTUPDATES" and my kernel won't compile Please don't simply turn options on without reading about them first - that is just foolish. Had you even bothered to look at LINT *before* you sent this message, you would have clearly seen the comment: # Soft updates is technique for improving file system speed and # making abrupt shutdown less risky. It is not enabled by default due # to copyright restraints on the code that implement it. # # Read ../../ufs/ffs/README.softupdates to learn what you need to # do to enable this. ../../../contrib/sys/softupdates/README gives # more details on how they actually work. # #optionsSOFTUPDATES By failing to do even this most basic of steps yourself, you only waste everyone's time with bogus failure reports. Don't. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
On Fri, 04 Jun 1999 09:45:31 +0200, "Tomas TPS Ulej" wrote: > I add "options SOFTUPDATES" and my kernel won't compile Read the section in LINT that dscribes the SOFTUPDATES option. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: SOFTUPDATES?
I waste 2 nights with this and be sure I reed manual before :( Sorry after last review I found one missing symlink: ln -s /usr/src/contrib/sys/softupdates/softdep.h softdep.h but idea for checking comes from maillist :) So it was good idea send mail here I thing. Regardz -- Tomas TPS Ulej System Administrator t...@internet.sk, tu36-ripe TELENOR Internet, NETLAB Network, Slovakia > -Original Message- > From: Jordan K. Hubbard [mailto:j...@zippy.cdrom.com] > Sent: Friday, June 04, 1999 9:52 AM > To: Tomas TPS Ulej > Cc: curr...@freebsd.org > Subject: Re: SOFTUPDATES? > By failing to do even this most basic of steps yourself, you only > waste everyone's time with bogus failure reports. Don't. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
> but idea for checking comes from maillist :) So it was good idea send mail > here I thing. No, it was not. :( If you don't know enough to check LINT when enabling new kernel features, you honestly should not be running -current and probably shouldn't even be changing your kernel. Sorry, but I'm getting more than a little fed up with people not reading the documentation. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
In all fairness, since the SOFTUPDATES comments in LINT point you to read the README, and this ask you to (paraphrased) "edit /etc/rc and disable update" I suggest that following the guidelines closely will prove challenging :-) Also, some commentary on the advisability of enabling softupdates on / for large single-partition configs would be useful: since it demands unmounted fs to apply tunefs to the device, this is "challenging" at first glance. cheers -George To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: IRQ sharing with newbus
> -Original Message- > From: Garrett Wollman [SMTP:woll...@khavrinen.lcs.mit.edu] > Sent: Wednesday, June 02, 1999 9:13 PM > To: Bruce Evans > Cc: d...@nlsystems.com; woll...@khavrinen.lcs.mit.edu; > curr...@freebsd.org; new...@atdot.dotat.org > Subject: Re: IRQ sharing with newbus > > < > said: > > >> But the sio non-multiport stuff should be able to use RF_TIMESHARE. > -- > >> If I'm not using my serial port, I should be able to use my > >> infrared > > > Preemptive timesharing would be hard to implement reasonably for > irqs. > > A uniform timeslice would have to be 86 usec to work properly for > > unbuffered sio devices at 115200 bps. > > You're talking intervals about six orders of magnitude smaller than I > am. [ML] If I understand you correctly, you want to resource track the IRQ's so if one device that uses one particular IRQ is active, another one cannot be activated? Example: I have a modem on sio1 and digicam on sio3 (both on IRQ3). I can either use my modem or download the photos, but not both at the same time. That would be nice. I don't known whether this is already supported as I don't have sio3 :) (I don't have sio1 either :) /Marino > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all > the same > woll...@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad > Irschick > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
>Hi there,
>
>Just a quick question.
>I'm about to fix the cdevsw_add(&bktr_cdevsw);
>bug in the brooktree848.c driver.
>
>Bruce wondered if this should go into bktr_attatch rather
>than bktr_probe?
>
>What do you think?
>I think _attach is better. Otherwise we will call cdevsw_add()
>even if you have the bktr driver in the kernel and have no bt848
>card fitted
Today I don't much care where you put it. In the future we may
want to think more about it though.
The way I see it is that if the driver is there, it should check
in at cdevsw[], which is why I generally put in *probe().
Of course if the hardware comes 'round later, attach will get
called too.
The next moves on my part are roughly:
1. Remove the difference between cdev/bdev dev_t's. I have a
kernel running with this now, but there are bogons lurking which
I have fumigated yes.
2. Enable doing "per dev_t" registration in the drivers. This will
look pretty much like the devfs registration in there today, only
more sane. After this the cdevsw_add() will only be kind of a
"wildcard" registration method, for pseudo devices and such.
After this point, a typical driver will probably do something like this:
struct softc {
int this;
char that;
bla
bla
bla
};
/* some kind of probe/attach routine */
somefunction()
{
struct softc *sc;
dev_t dt;
dum
di
dah
/* Aha, hardware! */
sc = MALLOC(...);
bzero(sc, sizeof *sc);
dt = mkdev(
CDEV_MAJOR, /* Char major */
BDEV_MAJOR, /* Block major */
foomble_devices * 16, /* Minor */
&foomble_cdevsw,/* The cdevsw function vector */
"foomble%d", foomble_devices); /* printf like construction of
name */
dt->driver1 = sc;
dt->driver2 = foomble_devices;
foomble_devices++;
}
foomble_open(dev_t dev, ...)
{
struct softc *sc = dev->driver1;
int unit = dev->driver2;
}
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
This should definitely go into attach IMNSHO.
Probe: Check whether hardware is there (no side effects if possible).
Attach:Get the device up and running and integrated into the kernel.
With the priority probes this is even more distinct as a priority not
equal to 0 means 'no side effects, just checking'.
Nick.
On Fri, 4 Jun 1999, Poul-Henning Kamp wrote:
> In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
> >Hi there,
> >
> >Just a quick question.
> >I'm about to fix the cdevsw_add(&bktr_cdevsw);
> >bug in the brooktree848.c driver.
> >
> >Bruce wondered if this should go into bktr_attatch rather
> >than bktr_probe?
> >
> >What do you think?
> >I think _attach is better. Otherwise we will call cdevsw_add()
> >even if you have the bktr driver in the kernel and have no bt848
> >card fitted
>
> Today I don't much care where you put it. In the future we may
> want to think more about it though.
>
> The way I see it is that if the driver is there, it should check
> in at cdevsw[], which is why I generally put in *probe().
>
> Of course if the hardware comes 'round later, attach will get
> called too.
>
> The next moves on my part are roughly:
>
> 1. Remove the difference between cdev/bdev dev_t's. I have a
> kernel running with this now, but there are bogons lurking which
> I have fumigated yes.
>
> 2. Enable doing "per dev_t" registration in the drivers. This will
> look pretty much like the devfs registration in there today, only
> more sane. After this the cdevsw_add() will only be kind of a
> "wildcard" registration method, for pseudo devices and such.
>
> After this point, a typical driver will probably do something like this:
>
> struct softc {
> int this;
> char that;
> bla
> bla
> bla
> };
>
> /* some kind of probe/attach routine */
> somefunction()
> {
> struct softc *sc;
> dev_t dt;
>
> dum
> di
> dah
> /* Aha, hardware! */
> sc = MALLOC(...);
> bzero(sc, sizeof *sc);
> dt = mkdev(
> CDEV_MAJOR, /* Char major */
> BDEV_MAJOR, /* Block major */
> foomble_devices * 16, /* Minor */
> &foomble_cdevsw,/* The cdevsw function vector */
> "foomble%d", foomble_devices); /* printf like construction of
> name */
> dt->driver1 = sc;
> dt->driver2 = foomble_devices;
> foomble_devices++;
> }
>
> foomble_open(dev_t dev, ...)
> {
> struct softc *sc = dev->driver1;
> int unit = dev->driver2;
>
>
> }
>
> --
> Poul-Henning Kamp FreeBSD coreteam member
> p...@freebsd.org "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
>
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote: > I think keepalive's could easily be turned on by default. At BEST, one > of the first things I did 5 years ago was to turn them on permanently > on all of our machines. I'd like to disagree on the "by default" part, on the following assumptions: 1. If you turn on keepalive by default, you will have to increase the keepalive timeout value well over the current 2 hours (at least that's what most people suggest to alleviate the concerns about having keepalives on) 2. Changing this default value of 2 hours will affect ALL applications. Many of them (and their users) are more or less expecting a 2 hours value. For example that's the case for Telnet: probably you don't want to wait for ONE WEEK before a connection dies if you are currently using keepalives! I don't see what this fuss is all about. If for _some_ big servers there are many dead connections around after a while (*), why don't THEY use a sysctl at boot-time to change the default state, rather than impose on the rest of us a change that might not be as innocuous as it looks? (*) In theory, for a FTP server, most such connections will be when the user does a PUT, not a GET. In a GET, the server has data to push and will timeout anyway. In the case of the control connection, there's a application timeout in most ftpds who close the connection after some configurable amount of time. > This used to be a HUGE argument in the days where networks were less > reliable and dialup lines were scarse. It is not an argument now, > however. Go explain that to my cable provider :-). Keeping a long-lived connection through them is a real challenge; keepalives on would make my life even more difficult. > Whatever we do, we should not start messing around with the internals > of the kernel trying to 'fix' a non-problem. Keepalives work just dandy > as they are currently implemented, we do not have to mess with it beyond > possibly changing the default in rc.conf. "possibly", but *only* as a last resort if there are good reasons for it, IMHO. But I haven't seen any such reason yet. I also think that having at least a kernel-wide (or better, having it configurable on a per-socket basis), dynamically configurable keepalive would be a good thing. -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Hi guys, Since this isn't something everyone agrees on, how about adding a knob to the boot time config files? This would make the keep-alive issue more visible, and encourage folks to think about what they want. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
Nick Hibma wrote: > > cdevsw_add() > This should definitely go into attach IMNSHO. > > Probe: Check whether hardware is there (no side effects if possible). > Attach:Get the device up and running and integrated into the kernel. > > With the priority probes this is even more distinct as a priority not > equal to 0 means 'no side effects, just checking'. I've just fixed the bt848 driver (bktr) where the cdevsw_add() was accidentally added to the BSDI bktr_probe() and not the FreeBSD bktr_probe. Although Bruce and Nick said this really belongs, in the _attatch() function, I've kept it in the _probe() function for consistency with all the other drivers. Roger -- Roger Hardiman| Telepresence Research Group ro...@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
> I've just fixed the bt848 driver (bktr) where the > cdevsw_add() was accidentally added to the BSDI bktr_probe() > and not the FreeBSD bktr_probe. > > Although Bruce and Nick said this really belongs, in the _attatch() > function, I've kept it in the _probe() function for consistency > with all the other drivers. Hm, I think this a bad choice. Which are 'all the other drivers'? The probe should really be as thin as possible to avoid unnecessary delays when probing in a kernel, like GENERIC, with a lot of device drivers compiled in. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
Nick > Hm, I think this a bad choice. Which are 'all the other drivers'? The > probe should really be as thin as possible to avoid unnecessary delays > when probing in a kernel, like GENERIC, with a lot of device drivers > compiled in. Well, in the PCI drivers, it is just the meteor, the brooktree848 and the Xilinx PGA driver (xrpu) In the /sys/i386/isa drivers, there were quite a few. Bye Roger -- Roger Hardiman| Telepresence Research Group ro...@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
>> Hm, I think this a bad choice. Which are 'all the other drivers'? The >> probe should really be as thin as possible to avoid unnecessary delays >> when probing in a kernel, like GENERIC, with a lot of device drivers >> compiled in. > >Well, in the PCI drivers, it is just the meteor, the brooktree848 >and the Xilinx PGA driver (xrpu) > >In the /sys/i386/isa drivers, there were quite a few. The isa drivers provide many bad examples. Most of them attached the devsw in a disgusting SYSINIT even if the device is disabled. I moved the devsw attach to the device attach function in some drivers that I worked on. This was necessary to support pcvt and syscons sharing a devsw entry. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
What is MTRR all about???
After reading /sys/boot/README, I decided to sync up my -current boxes. I began playing around with loader, kld's and the splash screens. Now I have a few queries ... #;^)
Re: net.inet.tcp.always_keepalive on as default ?
On Fri, Jun 04, 1999 at 03:32:02PM +0200, Pierre Beyssac wrote: > I don't see what this fuss is all about. If for _some_ big servers > there are many dead connections around after a while (*), why don't > THEY use a sysctl at boot-time to change the default state, rather > than impose on the rest of us a change that might not be as innocuous > as it looks? It might be nice to have two keepalive timeouts like Nate suggested. You'd have a short one, which applies if the application turns on keepalive or you have alwayskeepalive on. Then you'd have a long one, which applies to all connections regardless. Then: 1) To get the traditional behavior you set the long one to infinity and turn alwayskeepalive off. 2) To get the sort of behavior that phk is advocating, without upsetting the rest of us you leave alwayskeepalive off and then set the long one to 1 week. 3) For those of us with alwayskeepalive on, we'd get the traditional value of a few hours. Would this be a useful or a silly addition? David. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes: >It might be nice to have two keepalive timeouts like Nate suggested. >You'd have a short one, which applies if the application turns on >keepalive or you have alwayskeepalive on. Then you'd have a long >one, which applies to all connections regardless. Then: Then you might as well implement per socket adjustable keepalives. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote: :> I think keepalive's could easily be turned on by default. At BEST, one :> of the first things I did 5 years ago was to turn them on permanently :> on all of our machines. : :I'd like to disagree on the "by default" part, on the following :.. Pierre, let me make the suggestion to you that you try turning them on. I'll bet you dollars to donoughts that you will not notice the difference. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
< said: > Pierre, let me make the suggestion to you that you try turning them > on. I'll bet you dollars to donoughts that you will not notice > the difference. Except when you happen to run into one of the inventors of TCP and he tells you what an dolt you appear to be... -GAWollman To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SOFTUPDATES?
George Michaelson writes: > Also, some commentary on the advisability of enabling softupdates on / > for large single-partition configs would be useful: since it demands > unmounted fs to apply tunefs to the device, this is "challenging" at > first glance. No. Boot in single-user mode, and type 'tunefs -n enable /' *before* mounting / read-write. Then proceed into multi-user mode. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
> In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes: > > >It might be nice to have two keepalive timeouts like Nate suggested. > >You'd have a short one, which applies if the application turns on > >keepalive or you have alwayskeepalive on. Then you'd have a long > >one, which applies to all connections regardless. Then: > > Then you might as well implement per socket adjustable keepalives. While this is probably a good idea anyway, you still have the problem of setting these timeouts within applications for which you don't have source and for which the current default isn't useful. I guess this is the reason we have alwayskeepalive - if all applications set keepalive when they needed it we wouldn't have it at all. If you had per socket adjustable keepalives you'd also have to provide a tool which could set the keepalive timeout on a running process to get the sort of effect provided by alwayskeepalive. Having two timeouts would just be a compromise between these? David. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: What is MTRR all about???
On 04-Jun-99 bush doctor wrote: > Pentium Pro MTRR support enabled, default memory type is uncacheable > > What is MTRR? Using the web based cross referencing tool I came up with MTRR's are a way to tell the processor how to cache regions of memory. Its commonly used to speed up video card access by disabling caching on the linear frame buffer, this makes writes to the card faster (around 0-30%). The penalty is that reading is slower, but since that doesn't happen very often the speed increase is good. Try man memcontrol - It doesn't yet work on SMP boxes though. --- 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <199906041621.maa11...@khavrinen.lcs.mit.edu>, Garrett Wollman writes: >< said: > >> Pierre, let me make the suggestion to you that you try turning them >> on. I'll bet you dollars to donoughts that you will not notice >> the difference. > >Except when you happen to run into one of the inventors of TCP and he >tells you what an dolt you appear to be... Just tell him, (and make sure he can hear the quotes): "32bit is enought for everthing" -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
I think people just like to argue sometimes. The reality is different. For all you people complaining: Just turn them on and I guarentee you will not even notice the difference, except you will stop getting ( even the occassional ) stale internet server process. That is what keepalives were designed to deal with. Keepalives are not supposed to be a network watchdog, they are simply supposed to be a catch-all. So having per-socket adjustment is kind of silly. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
> "32bit is enought for everthing" Just mention the horrible header offset field. Lots of good TCP nits. Anyway, can't this argument be settled by separating the mechanism and policy. Adding a simple rc.conf tweak to enable them should be enough. But, consider going back to the discusssions leading up to the Host Requirements RFC (1122). The particular problem was that the original timeout value for keepalives was tiny (a few minutes). 1122 dictated the corrections for this. Here are the important points from section 4.2.3.6: 1. keepalives MUST default to off 2. the minimum timeout MUST be no less than two minutes 3. keep-alives SHOULD only be invoked in server applications This mostly says that always_keepalive should continue to default to off (but, perhaps, a easy hook in rc.conf should exist to turn them on). John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: >But, consider going back to the discusssions leading up to the Host >Requirements >RFC (1122). The particular problem was that the original timeout value for >keepalives was tiny (a few minutes). 1122 dictated the corrections for this. >Here are the important points from section 4.2.3.6: But RFC 1122 pretty much entirely predates the "modern internet user". While I fully supported the policy back then, I no longer do. I still think the right thing is: default to keepalives. set the timeout to a week. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
At 10:03 AM 6/4/99 , Matthew Dillon wrote: > I think people just like to argue sometimes. The reality is different. > > For all you people complaining: Just turn them on and I guarentee > you will not even notice the difference, except you will stop getting > ( even the occassional ) stale internet server process. That is what > keepalives were designed to deal with. Keepalives are not supposed to > be a network watchdog, they are simply supposed to be a catch-all. This seems to be rather end-user, and short sighted. TCP and the underlying Internet has survived, and been able to scale (among other things), because of the work of many to balance end-user performance and overall network performance. All the TCP congestion avoidance algorithms and work done go towards managing a shared medium without a central point of control. If this work had not been done, then the Internet would not have grown as it did today. The central issue of keepalives is that, for one machine, they don't create a significant load. Multiplied by the number of machines on the Internet, it can become a problem. If freeBSD makes it a default, then other will adopt as well. Some less experienced and clueful implementors won't do as good a job with the overall TCP implementation, and we might see keepalives being sent every TCP timeout, for every connection, as a way to deal with a protocol error. :-) KR To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote: >I still think the right thing is: > > default to keepalives. > set the timeout to a week. OpenLDAP slapd, like may other daemons, relies on timeouts being a reasonably short (a few hours) to deal with dead streams. Dead streams occur for a wide variety of reasons and erver applications need an effective mechanisms to deal with them. Changing the timeout to a week would render the SO_KEEPALIVE mechanism ineffective. Personally, I advocate using sysctl (in rc files) to set the default to on and leaving the kernel alone. Kurt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: > >>But, consider going back to the discusssions leading up to the Host >>Requirements >>RFC (1122). The particular problem was that the original timeout value for >>keepalives was tiny (a few minutes). 1122 dictated the corrections for this. >>Here are the important points from section 4.2.3.6: > >But RFC 1122 pretty much entirely predates the "modern internet user". While >I fully supported the policy back then, I no longer do. > >I still think the right thing is: > > default to keepalives. > set the timeout to a week. I don't support increasing the default timeout. That would cause problems for a lot of server systems that rely on the relatively short two hour default. The best I think you could do would be to increase it to something like 12-24 hours as a default, but even that might be problematical. Actually, I think we should leave it alone. I don't mind if people add an rc.conf variable, however. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <4.2.0.56.19990604111235.00ae3...@rowett.org>, "Kevin J. Rowett" writes: >The central issue of keepalives is that, for one machine, they don't create >a significant load. Multiplied by the number of machines on the Internet, >it can become a problem. Reality home-work assignment to Kevin: If we send a total of 8 keep alive packets per week, for TCP connections that last that long. How many FreeBSD hackers with long lived telnet/ssh sessions does it take to generate as much trafic as one users IRC session ? >If freeBSD makes it a default, then other will adopt as well. Some less >experienced and clueful implementors won't do as good a job with the >overall TCP implementation, and we might see keepalives being sent >every TCP timeout, for every connection, as a way to deal with a protocol >error. :-) ... And the users, realizing this, will flock to FreeBSD and abandon all other inferior products. There we have it! The way to kill windows NT is to make tcp keepalives the default in FreeBSD, obviously, since NT is so bloddy unstable, Mickysoft will have to use much shorter timeouts and people will notice that NT soaks up all their bandwidth whereas FreeBSD doesn't. Great! And I guess we can corner Linux the same way, they have to reboot for every security fix, so they have to have shorter timeouts as well. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <199906041824.laa29...@implode.root.com>, David Greenman writes: >>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: >> >>>But, consider going back to the discusssions leading up to the Host >>>Requirements >>>RFC (1122). The particular problem was that the original timeout value for >>>keepalives was tiny (a few minutes). 1122 dictated the corrections for >>>this. >>>Here are the important points from section 4.2.3.6: >> >>But RFC 1122 pretty much entirely predates the "modern internet user". While >>I fully supported the policy back then, I no longer do. >> >>I still think the right thing is: >> >> default to keepalives. >> set the timeout to a week. > > I don't support increasing the default timeout. That would cause problems >for a lot of server systems that rely on the relatively short two hour default. >The best I think you could do would be to increase it to something like >12-24 hours as a default, but even that might be problematical. > Actually, I think we should leave it alone. I don't mind if people add an >rc.conf variable, however. First of all, our current default is not two hours, but to kill after 4 hours idle followed by no response for 20min: net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 So anyone depending on two hours are screwed already. How about this then: net.inet.tcp.always_keepidle: 86400 /* new variable */ net.inet.tcp.always_keepintvl: 64800/* new variable */ net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.always_keepalive: 1 This will have all sockets have keepalives, but if the program specifically sets keepalives, it gets the shorter timeout. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: sysctl
In message <99jun4.143622est.40...@border.alcanet.com.au>, Peter Jeremy writes: >I notice that sysctl -d doesn't work, and I suspect it never did. right. My proposal: In the LINT kernel, the descriptions are compiled into a separate section and a small program converts this section into the sysctl(8) man page source (or maybe more correctly but less likely to be found: mib(8) man page source) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
> How about this then: > > net.inet.tcp.always_keepidle: 86400 /* new variable */ > net.inet.tcp.always_keepintvl: 64800/* new variable */ > net.inet.tcp.keepidle: 14400 > net.inet.tcp.keepintvl: 150 > net.inet.tcp.always_keepalive: 1 > > This will have all sockets have keepalives, but if the program > specifically sets keepalives, it gets the shorter timeout. That's essentially what I proposed a couple days ago. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
At 11:24 AM -0700 6/4/99, David Greenman wrote: > someone else wrote: >> >> I still think the right thing is: >> default to keepalives. >> set the timeout to a week. > > I don't support increasing the default timeout. That would cause > problems for a lot of server systems that rely on the relatively > short two hour default. The best I think you could do would be to > increase it to something like 12-24 hours as a default, but even > that might be problematical. This may be a stupid question, but I haven't shied away from asking stupid questions before... Do we have to consider this as an "on/off" switch? Could we have it an "on/off/extended" switch? (or is the value stored as a bit somewhere, so that it can only be on or off?). What I'm thinking is that anything that explicitly asks for "on" would get the current 2-hour timeout, but that the "extended" setting would result in a 7-day timeout. We'd then set the system default to "extended" instead of either on or off. Or would this break things in subtle ways? --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Bruce Evans wrote: > > The isa drivers provide many bad examples. Most of them attached the > devsw in a disgusting SYSINIT even if the device is disabled. I moved > the devsw attach to the device attach function in some drivers that > I worked on. This was necessary to support pcvt and syscons sharing a > devsw entry. Firstly, the SYSINIT code was a stopgap. It will evolve with time.. The question is one of scope. THe devsw[] entry is added at the same time that the driver is activated in the kernel. This is neither at the first probe of a particular device, nor at the attach. Both of the latter cases an occur many times, both before (for probe) and after teh first hardware is found. This is why the SYSINIT was used.. The idea was that a loadable module would have an init() routine that is called when the module is loaded and linked in. This init() should also be called in an identical way during boot for a pre-loaded module. basically the case of a preloaded module (driver) is just a special case of the more general case of a loadable module. Drivers are just a special case of the more general case of loadable modules, so a driver should have all the features of a general module. e.g. an init() routine of some sort. It therefore makes sense that if a driver module has an init() routine that is called once before any other calls to the driver, tehn this is the obvious place to do things such as installing hooks for shutdown, or timeouts etc. and for installing itself into structures such as the devsw[] arrays. It is possible to SIMULATE this by making the first probe or attach calls do the work, but it seems to me rather artificial to do so because we have the ideal place to do the work anyhow. Remember that one of the long term aims that nearly all the FreeBSD developers have expressed at one time or another is to make FreeBSD almost completely dynamic. This means that nearly all components will eventually be loadable. Including boot drivers, which can be loaded and linked in by the boot loader. Making all drivers have the 'form' required, with an separate init() routine to be called at load time is therefore a positive thing. SYSINIT is just a way of making sure that these are called early, so that the driver need not know if it was loaded or was 'preloaded'. I therefore put it to the group that the right place to do devsw[] manipulation is neither in xxx-probe, or _attach, but in xxx_init(), which is only called once, and IS called at teh right time. It should also be noted that teh devsw[] extraction code should be run from the init() code when it is run with the 'shutdown' argument. (but only when the driver arees to allow itself to be unlinked). julian > > Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Bruce Evans wrote: > >> Hm, I think this a bad choice. Which are 'all the other drivers'? The > >> probe should really be as thin as possible to avoid unnecessary delays > >> when probing in a kernel, like GENERIC, with a lot of device drivers > >> compiled in. > > > >Well, in the PCI drivers, it is just the meteor, the brooktree848 > >and the Xilinx PGA driver (xrpu) > > > >In the /sys/i386/isa drivers, there were quite a few. > > The isa drivers provide many bad examples. Most of them attached the > devsw in a disgusting SYSINIT even if the device is disabled. I moved > the devsw attach to the device attach function in some drivers that > I worked on. This was necessary to support pcvt and syscons sharing a > devsw entry. If people feel that its wrong to put the cdev registration in a sysinit, please feel free to rip out the DEV_DRIVER_MODULE stuff and replace it with whatever the 'right thing' is. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
"Kevin J. Rowett" writes: > The central issue of keepalives is that, for one machine, they don't > create a significant load. Multiplied by the number of machines on > the Internet, it can become a problem. No offense, but that is the most ludicrous assertion I've heard since Slobodan Milosevic claimed that all those bedraggled people streaming across the Albanian border were actually actors being paid $5.50 per day by NATO. Hint: If everybody turned on TCP keepalives, what percentage of the traffic on Internet backbones do you think would be keepalive packets? Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:Hint: If everybody turned on TCP keepalives, what percentage of the :traffic on Internet backbones do you think would be keepalive :packets? : :Jim Shankland :NLynx Systems, Inc. Around 0.02%, using the stats from one of BEST's busier servers. That's percent. In otherwords, nobody would notice. You wouldn't notice, the backbones wouldn't notice... nobody would notice. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:had not been done, then the Internet would not have grown as it did today. : :The central issue of keepalives is that, for one machine, they don't create :a significant load. Multiplied by the number of machines on the Internet, :it can become a problem. As I said. People are arguing about keepalives without knowing how they work. NO! I will repeat that: NO. There is NO significant bandwidth. Every single machine on the entire internet could turn on keepalives and you would not notice the difference. Someone give me a sledgehammer! No, make that two! -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
>> I don't support increasing the default timeout. That would cause problems >>for a lot of server systems that rely on the relatively short two hour >>default. >>The best I think you could do would be to increase it to something like >>12-24 hours as a default, but even that might be problematical. >> Actually, I think we should leave it alone. I don't mind if people add an >>rc.conf variable, however. > >First of all, our current default is not two hours, but to kill >after 4 hours idle followed by no response for 20min: > > net.inet.tcp.keepidle: 14400 > net.inet.tcp.keepintvl: 150 > >So anyone depending on two hours are screwed already. I believe the above numbers are in slowtimo ticks (500ms), so if you do the math, you come up with 2 hours. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
: :Around 0.02%, using the stats from one of BEST's busier servers. :That's percent. Oops, I wrong. It's actually less then that... the network counters overflowed. More around 0.001%. That's relative to outgoing traffic, not relative to network capacity. And, to be nice, I chose an administrative server instead of a web server. Web servers have even *lower* keepalive bandwidth utilization. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <199906042013.naa29...@implode.root.com>, David Greenman writes: >>> I don't support increasing the default timeout. That would cause problems >>>for a lot of server systems that rely on the relatively short two hour >>>default. >>>The best I think you could do would be to increase it to something like >>>12-24 hours as a default, but even that might be problematical. >>> Actually, I think we should leave it alone. I don't mind if people add an >>>rc.conf variable, however. >> >>First of all, our current default is not two hours, but to kill >>after 4 hours idle followed by no response for 20min: >> >> net.inet.tcp.keepidle: 14400 >> net.inet.tcp.keepintvl: 150 >> >>So anyone depending on two hours are screwed already. > > I believe the above numbers are in slowtimo ticks (500ms), so if you do >the math, you come up with 2 hours. Oops, you're right. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
>> The isa drivers provide many bad examples. Most of them attached the >> devsw in a disgusting SYSINIT even if the device is disabled. I moved >> the devsw attach to the device attach function in some drivers that >> I worked on. This was necessary to support pcvt and syscons sharing a >> devsw entry. > >Firstly, the SYSINIT code was a stopgap. It will evolve with time.. The Like most stogaps, it was there too long (3.5 years). It is mostly gone now. >... >I therefore put it to the group that the right place to do devsw[] >manipulation is neither in xxx-probe, or _attach, but in xxx_init(), >which is only called once, and IS called at teh right time. >It should also be noted that teh devsw[] extraction code should be run >from the init() code when it is run with the 'shutdown' argument. (but >only when the driver arees to allow itself to be unlinked). You're forgetting that devsw[] is another stopgap. The kernel should probably use something like devfs, where dev_t's only exist for devices that actually exist. xxx_init() is far too early to decide which hardware devices exist. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw_add
In message <199906042048.gaa25...@godzilla.zeta.org.au>, Bruce Evans writes: >You're forgetting that devsw[] is another stopgap. The kernel should >probably use something like devfs, where dev_t's only exist for devices >that actually exist. xxx_init() is far too early to decide which hardware >devices exist. Patience Bruce, I'm getting closer to that all the time... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Problems getting 3C597 up
I'm running 4.0 - current from the middle of May, approximately. I recently acquired an EISA 3COM network adapter that I'm now trying to install. Here's a snip from my dmesg output: vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0 vx0: No I/O space?! device_probe_and_attach: vx0 attach returned -1 So something is not working... :-( Anyone have any suggestions? I'm in a bind. I need a second ethernet card to get our new DSL line shared with our various household computers. Thanks very much for Any input! Bret Ford To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Review: Having aio.h include sys/time.h
How do, -hackers was silent about this, so I'm resending it to -current. Any comments before I commit this (trivial) change? N == docs/11589 says that programs that include aio.h also need to include sys/time.h. I've had a chat with Terry Lambert, who wrote the aio_read.2 manual page, who says > And here is a section from the aio.h manual page (from the > Single UNIX Specification): > > Inclusion of the header may make visible symbols > defined in the headers , , > and . > > Basically, this means that the aio.h header is *defined* as > including sys/types.h (because of off_t and size_t), and is > defined as either including the other headers as well (bad) > or as forward declaring some types as opaque: > Since the Single UNIX Specification make no note of a header > other than aio.h, I'm afraid that the answer is that the aio.h > must include these headers, or directly define the respective > types itself. > > While I dislike promiscuous headers, I believe it is better to > be able to compile and run standards compliant UNIX code. So I want to apply the following very trivial patch; Index: aio.h === RCS file: /home/ncvs/src/sys/sys/aio.h,v retrieving revision 1.9 diff -u -r1.9 aio.h --- aio.h 1999/01/17 22:33:08 1.9 +++ aio.h 1999/06/01 17:57:36 @@ -19,6 +19,7 @@ #ifndef _SYS_AIO_H_ #define_SYS_AIO_H_ +#include #include #include Any objections? I know nothing about the aio* stuff at all, which is why I'm checking first. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problems getting 3C597 up
On Fri, 4 Jun 1999, Bret Ford wrote: > vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0 > vx0: No I/O space?! > device_probe_and_attach: vx0 attach returned -1 This was fixed in version 1.45 of sys/i386/eisaconf.c -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: > > >But, consider going back to the discusssions leading up to the Host > >Requirements > >RFC (1122). The particular problem was that the original timeout value for > >keepalives was tiny (a few minutes). 1122 dictated the corrections for > >this. > >Here are the important points from section 4.2.3.6: > > But RFC 1122 pretty much entirely predates the "modern internet user". While > I fully supported the policy back then, I no longer do. > > I still think the right thing is: > > default to keepalives. > set the timeout to a week. Then lets go off a write RFC and get RFC1123 off the books, it's way over due for an overhaul anyway. -- Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
At 01:08 PM 6/4/99 , Matthew Dillon wrote: >:had not been done, then the Internet would not have grown as it did today. >: >:The central issue of keepalives is that, for one machine, they don't create >:a significant load. Multiplied by the number of machines on the Internet, >:it can become a problem. > > As I said. People are arguing about keepalives without knowing how they > work. That's an excellent point! People with less correct implementations of TCP keepalives will use freeBSD's justification as their justification for turning on TCP keepalives by default. RFC1122 was written for a reason. Before we repeal it, we should consider why it was written in the first place. BTW, I'm in favor of making keepalives on by default. It will save me one line in the boot up sequence. KR To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Nate Williams wrote: > > How about this then: > > > > net.inet.tcp.always_keepidle: 86400 /* new variable */ > > net.inet.tcp.always_keepintvl: 64800/* new variable */ > > net.inet.tcp.keepidle: 14400 > > net.inet.tcp.keepintvl: 150 > > net.inet.tcp.always_keepalive: 1 > > > > This will have all sockets have keepalives, but if the program > > specifically sets keepalives, it gets the shorter timeout. > > That's essentially what I proposed a couple days ago. I think the always_keepintvl values above are pretty over the top.. We send a grand total of 8 keepalive packets every keepintvl slowtimeouts. In the SO_KEEPALIVE case, after nothing has been received for 2 hours, we send a keepalive packet every 75 seconds for a total of 8 times. If we still get nothing after 8 * 75 = 10 minutes, we drop the connection. The example above is a bit far out because after 12 hours we'd probe and retry every 540 minutes (9 hours) if there was no response for a total of 8 times - 8 * 9 = 72 hours. ie: it would take 3 days to clean a dead connection based on a lousy sample of 8 packets over those 3 days. I'd suggest always_keepidle = 86400 (12 hours) and always_keepinvl = 300 (20 minutes), and perhaps a new variable keepcnt and always_keepcnt so that we can retry more than 8 times if you have lossy links. IMHO, even the more aggressive existing keepalive values are so close to trivially small amounts of traffic, I'd much rather use the 14400/150 values for everything. I'd be really *really* suprised if long idle tcp sessions were statistically significant. I know I have telnet sessions that can have idle times of days, but compared to ftp/http/etc traffic it's a mere drop in the ocean. I can't think of any other common case of long idle open tcp sessions other than telnet and co. > Nate > Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
subtle SIOCGIFCONF bug
I've noticed that several programs have a subtle problem when scanning
the list returned by the SIOCGIFCONF ioctl. The problem is that these
programs do this computation to increment the pointer in the list:
ifr = (struct ifreq *) ((char *) &ifr->ifr_addr + ifr->ifr_addr.sa_len);
There are cases where some elements in the list (e.g., tunnel interfaces)
have ifr->ifr_addr.sa_len set to a value LESS than sizeof(ifr->ifr_addr).
This causes these programs to fail because the kernel always enforces a
minimum length of (IFNAMSIZ + sizeof(ifr->ifr_addr)) for each entry in
the list, even if ifr->ifr_addr.sa_len < sizeof(ifr->ifr_addr)
(see net/if.c:ifconf()).
First question:
Should the kernel insure that ifr->ifr_addr.sa_len is always at
least sizeof(ifr->ifr_addr), or should the user programs adjust
their pointer increment algorithm? At first I assumed the latter
answer (patches below) but now am not so sure.
Second question:
It doesn't appear the net/if.c:ifioctl() function is protected
at all by splnet(), even though it is accessing all kinds of
networking information. Is this a race condition?
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: usr.sbin/arp/arp.c
===
RCS file: /home/ncvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.15
diff -u -r1.15 arp.c
--- arp.c 1999/03/10 10:11:43 1.15
+++ arp.c 1999/06/04 23:45:27
@@ -696,8 +696,8 @@
break;
}
nextif:
- ifr = (struct ifreq *)
- ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+ ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+ + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
}
if (ifr >= ifend) {
@@ -725,8 +725,8 @@
printf("\n");
return dla->sdl_alen;
}
- ifr = (struct ifreq *)
- ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+ ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+ + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
}
return 0;
}
Index: usr.sbin/pppd/sys-bsd.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.15
diff -u -r1.15 sys-bsd.c
--- sys-bsd.c 1998/06/21 04:47:21 1.15
+++ sys-bsd.c 1999/06/04 23:45:32
@@ -1378,8 +1378,9 @@
* address on the same subnet as `ipaddr'.
*/
ifend = (struct ifreq *) (ifc.ifc_buf + ifc.ifc_len);
-for (ifr = ifc.ifc_req; ifr < ifend; ifr = (struct ifreq *)
- ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len)) {
+for (ifr = ifc.ifc_req; ifr < ifend;
+ ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+ + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr {
if (ifr->ifr_addr.sa_family == AF_INET) {
ina = ((struct sockaddr_in *) &ifr->ifr_addr)->sin_addr.s_addr;
strncpy(ifreq.ifr_name, ifr->ifr_name, sizeof(ifreq.ifr_name));
@@ -1425,7 +1426,8 @@
BCOPY(dla, hwaddr, dla->sdl_len);
return 1;
}
- ifr = (struct ifreq *) ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+ ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+ + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
}
return 0;
@@ -1468,8 +1470,9 @@
return mask;
}
ifend = (struct ifreq *) (ifc.ifc_buf + ifc.ifc_len);
-for (ifr = ifc.ifc_req; ifr < ifend; ifr = (struct ifreq *)
- ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len)) {
+for (ifr = ifc.ifc_req; ifr < ifend;
+ ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+ + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr {
/*
* Check the interface's internet address.
*/
Index: sbin/natd/natd.c
===
RCS file: /home/ncvs/src/sbin/natd/natd.c,v
retrieving revision 1.17
diff -u -r1.17 natd.c
--- natd.c 1999/05/13 17:09:44 1.17
+++ natd.c 1999/06/04 23:54:32
@@ -762,6 +762,8 @@
}
extra = ifPtr->ifr_addr.sa_len - sizeof (struct sockaddr);
+ if (extra < 0)
+ extra = 0;
ifPtr++;
ifPtr = (struct ifreq*) ((char*) ifPtr + extra);
Index: sbin/route/route.c
===
RCS file: /home/ncvs/src/sbin/route/route.c,v
retrieving revision 1.30
diff -u -r1.30 route.c
--- route.c 1999/06/01 13:14:07 1.30
+++ route.c 1999/06/04 23:54:36
@@ -794,7 +794,8 @@
(ifconf.ifc_buf + ifconf.ifc_len);
subtle SIOCGIFCONF bug
< said: > Should the kernel insure that ifr->ifr_addr.sa_len is always at > least sizeof(ifr->ifr_addr), or should the user programs adjust > their pointer increment algorithm? At first I assumed the latter > answer (patches below) but now am not so sure. The user programs should not use SIOCGIFCONF. > It doesn't appear the net/if.c:ifioctl() function is protected > at all by splnet(), even though it is accessing all kinds of > networking information. Is this a race condition? No. ifioctl() should only be called from the ioctl syscall or other contexts where preemption is not an issue. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: subtle SIOCGIFCONF bug
Garrett Wollman writes: > > Should the kernel insure that ifr->ifr_addr.sa_len is always at > > least sizeof(ifr->ifr_addr), or should the user programs adjust > > their pointer increment algorithm? At first I assumed the latter > > answer (patches below) but now am not so sure. > > The user programs should not use SIOCGIFCONF. I was hoping for a little more information than that. OK, imagine a world where you had no choice. THEN what would the answer be? In other words, I'd like to fix the problem but I don't have time to rewrite arp, natd, route, etc. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: subtle SIOCGIFCONF bug
< said: >> [I wrote:] >> The user programs should not use SIOCGIFCONF. > I was hoping for a little more information than that. > OK, imagine a world where you had no choice. THEN what would the answer be? 1) Implement sysctl net-route-iflist. 2) The user programs should not use SIOCGIFCONF. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:At 01:08 PM 6/4/99 , Matthew Dillon wrote: :>:had not been done, then the Internet would not have grown as it did today. :>: :>:The central issue of keepalives is that, for one machine, they don't create :>:a significant load. Multiplied by the number of machines on the Internet, :>:it can become a problem. :> :> As I said. People are arguing about keepalives without knowing how they :> work. : :That's an excellent point! People with less correct implementations of TCP :keepalives will use freeBSD's justification as their justification for :turning on TCP keepalives by default. Umm... that is about as twisted a reasoning as I could imagine. I don't consider it a useful argument. The sky might be falling too, better not go outside! -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
You know, I was going to buy a pickup truck, but I was afraid my neighbors would figure that if I bought a pickup truck, they should buy one too. And maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't even know how to drive one safely. So I bought an Explorer instead. DS > :That's an excellent point! People with less correct > implementations of TCP > :keepalives will use freeBSD's justification as their justification for > :turning on TCP keepalives by default. > > Umm... that is about as twisted a reasoning as I could > imagine. I don't > consider it a useful argument. The sky might be falling too, > better not > go outside! > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
Jordan Hubbard writes: >1. Put pccardd on the mfsroot floppy and add a few things to > sysinstall (this may already be done by his patches, I haven't > had time to check) which enable its use during installation. > >2. Bring in message catalog and BIG5 support so that the standard > installer supports English, Japanese, Korean and Chinese by > default. Definitely cool! >3. Figure out why I couldn't get the isc-dhcp client to work > before 3.2's release (causing me to abandon the idea of adding > this feature for 3.2) and get DHCP support into 3.3. FreeBSD's isc-dhcp client was based on v2.0b1pl18 before May 8. It had some bugs, which were fatal in many environments. Now it is based on v2.0b1pl27, which works greatly. - nao To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
In message <199906042217.paa22...@gndrsh.aac.dev.com>, "Rodney W. Grimes" writes: >> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: >> >> >But, consider going back to the discusssions leading up to the Host >> >Requirements >> >RFC (1122). The particular problem was that the original timeout value for >> >keepalives was tiny (a few minutes). 1122 dictated the corrections for >> >this. >> >Here are the important points from section 4.2.3.6: >> >> But RFC 1122 pretty much entirely predates the "modern internet user". While >> I fully supported the policy back then, I no longer do. >> >> I still think the right thing is: >> >> default to keepalives. >> set the timeout to a week. > >Then lets go off a write RFC and get RFC1123 off the books, it's way >over due for an overhaul anyway. > I think it has been attempted, but gaining rough concensus on a document which declares N implementations "junk" is hard to get. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Well, we've heard various opinions and I think we can conclude that: 1. Even with the current timeouts, there is no significant increase in network trafic, even with the market share FreeBSD has. 2. That server applications should have keepalives enabled. 3. That the few people, for whom it could become a problem if it is enabled by default, are prefectly capable of changing a variable in /etc/rc.conf. 4. It would be desirable to have per socket timeouts, but would require application changes which are unlikely to happen. 5. Changing the timeouts would potentially mean trouble for certain applications. QED: The following patch. If you don't like this, remember to change that variable in /etc/rc.conf in the future. Poul-Henning Index: rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.44 diff -u -r1.44 rc.network --- rc.network 1999/04/12 15:26:41 1.44 +++ rc.network 1999/06/05 05:25:51 @@ -180,6 +180,11 @@ sysctl -w net.inet.ip.accept_sourceroute=1 >/dev/null 2>&1 fi +if [ "X$tcp_keepalive" = X"YES" ]; then + echo -n ' TCP keepalive=YES' + sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null 2>&1 +fi + if [ "X$ipxgateway_enable" = X"YES" ]; then echo -n ' IPX gateway=YES' sysctl -w net.ipx.ipx.ipxforwarding=1 >/dev/null 2>&1 Index: defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.9 diff -u -r1.9 rc.conf --- rc.conf 1999/05/16 09:19:44 1.9 +++ rc.conf 1999/06/05 05:26:26 @@ -41,6 +41,7 @@ natd_flags="" # Additional flags for natd. tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). +tcp_keepalive="YES"# Kill dead TCP connections (or NO). network_interfaces="lo0" # List of network interfaces (lo0 is loopback). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: net.inet.tcp.always_keepalive on as default ?
> Well, we've heard various opinions and I think we can conclude that: > > 2. That server applications should have keepalives enabled. Well, I certainly don't agree with that. Many server applications (web servers, mail servers, etcetera) already have data timeouts, which makes keepalives redundant. In my opinion, in the vast majority of cases, data timeouts are more logical than keepalives. 'telnetd' being the most obvious exception. DS To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
�����������¿���
¹ã¸æê°î¸üÃÿìµà http://www.gglb.com 1¡¢Ã«ÃÃÃóö¡°Ãâ·Ã·ÃÃà ¹ã¸æ¡°Ã¸Ã¿ http://ad.gglb.com Ãú¿ÃÃÃÃô÷¢²¼ÃúµÃûÃà ºÃ·¨Ãà ¡£ 2¡¢Ã«¹úèûµÃ¡°¹ã¸æÃÃÃÃÃìÃá±³ÃÃûÃúÃôÃÃãÃý¹ã¸æÃõÃÃÃÃù£¬½»Ã÷¹ã¸æÃõþ Ãé¡£ 3¡¢Ãá°¹ã¸æÃÃó¡±£¬Ãã¿ÃÃÃÃõ½Ã»¸ö¹ã¸æÃÃÃæÃý½»Ã÷µÃ¿Ã¼ä¡£ 4¡¢¹ã¸æê°îÃÃüÃÃë¹úÃøÃûµÃ¹ã¸æ¹«Ã¾£¬¹ã¸æ²ÃÃù«Ã¾£¬¹ã¸æÃ豸¹«Ã¾£¬²éï¸ü¿ì ½Ã£¬Ãö¼Ã¸ü·½±ã¡£ 5¡¢ÃîÃùúÃùã¸æÃÃÃà £¬¹ã¸æ¶¯Ã¬¡£ 6¡¢Ã«ÃÃÃóöû¹ûÃüþ´óÃùÃ㺶à ÃÃÃè¼Ã¡¢Ã¼ÃÃÃüþÃÃÃÃÃøÃÃÃÃÃÃᣠ7¡¢´óÿ¹úÃÃÃà Ãã¹ã¸æü¿â£¬½Ãêë¹ú¸÷µÃµÃȤÃâ¹ã¸æüÃã¬Ã°æÃùÃã¬Ã£ÃûÃøøÃú ´øôÃé¸Ã¡£ ô¹ã¸æê°î£¬Ãöê°î¹ã¸æ http://www.gglb.com ¹ã¸æê°îÃÃÃÃþµã£º http://download.gglb.com ÃîÃÃêµÃûµã£¬ÃúÃá°¹ã¸æê°î¡±ÃùÃöµÃûÃ㬶¼ÃÃÃâ·ÃµÃ¡£ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
"David Schwartz" wrote: > > > Well, we've heard various opinions and I think we can conclude that: > > > > 2. That server applications should have keepalives enabled. > > Well, I certainly don't agree with that. Many server applications (web > servers, mail servers, etcetera) already have data timeouts, which makes > keepalives redundant. Huh? The keepalive option *is* a kind of data timeout.. It's a failsafe so that if nothing has been heard for a while then it explicitly does a check to see if the network connection is still valid. Of course a server app is free to implement it's own data timeouts, but it shouldn't have to reinvent what the kernel can do very well already and is very difficult to do in userland. There are several sorts of timeouts that server apps *may* want: - Some sort of upper bound on a session time, eg: a fingerd session may not last more than 1 hour, regardless of whether it's doing something. Something like a http server might put an upper limit of something like 24 hours - if it is too small and it will interfere with large downloads. - Some sort of idle timeout, eg: a smtp server may want to time out after 10 minutes of not recieving a command. - A way of detecting a stalled or rebooted client. This is what keepalive does. It lets you detect a lost connection before some other longer timeout (eg: 24 hours) kicks in. > In my opinion, in the vast majority of cases, data timeouts are more > logical than keepalives. 'telnetd' being the most obvious exception. Telnetd is the worst example. Just because I have not typed something for two hours is no indication that the session should be closed. Only the kernel can test the validity of the network link in this case. However, of I drop a link or reboot, then I do want it cleaned up in a timely fashion. > DS Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
