Re: anoncvs down?
On Fri, Oct 26, 2001 at 10:30:04AM +0300, Peter Pentchev wrote: > On Fri, Oct 26, 2001 at 09:15:28AM +0200, Peter Wullinger wrote: > anoncvs mirrors are currently under discussion on -hubs. > > Rest assured, this problem *is* going to be fixed :) > Sorry for the crosspost ... Thanks anyway, Peter -- E Pluribus UNIX PGP signature
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In some email I received from Giorgos Keramidas, sie wrote: > On Tue, Oct 23, 2001 at 07:45:11PM +0200, Gerhard Sittig wrote: > > > > I get the feeling this - inappropriate - setting of a _program > > variable is due to my misguided suggestion in PR conf/20202 > > which verbatimly made it into the FreeBSD start scripts. If it > > doesn't fit the usual rules feel free to correct it! :) After > > all I was a newbee to FreeBSD then (and still I'm not a guru or > > seasoned hacker:) as well as I understand Darren to do his > > daytime job with SunOS / Solaris and since he might need some > > hints on how his software fits even better into FreeBSD. I guess > > he will happily accept patches improving a wrong approach. > > > > Maybe there's need for the following parts: > > - ipfilter_program > > - ipfilter_prerules_flags > > - ipfilter_rules > > - ipfilter_postrules_flags > > ? The current situation comes from the fact that I wanted to > > have a single variable with the rules file only - to check for > > its existance (if such an additional constraints check matters). > > Done. I tested on my -current (compiled on Oct 22) the patch you can > find at http://labs.gr/~charon/patches/diff.04.ipf-rc-U > It is functionally equivalent to our current rc.network behavior, but > it uses the variables you proposed, and it moves all the flags out of > all the XXX_program variables. How many of the patches at http://labs.gr/~charon/patches/ should go into FreeBSD-current ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how can i wipeout swap pages?
On Thu, 25 Oct 2001, Terry Lambert wrote: > To do what you want, which is to clean the backing pages, you Yes, i mean cleaning pages in the backing storage. > are better off doing it for all freed blocks, not just swap > blocks (if someone can read your swap, they can read other data > off your unallocated disk blocks from the FS, as well). I clean UFS freed disk blocks, but i don't know how to do it from swap_pager. :( there are some kva to phisical mapping, which i do not understand. So i thought someone could point me how can write block from swap_pager to the disk or where can i read more info (except McKusicks' book and kernel sources). PS. I can make patch, which wipes files(freed blocks) upon deletion for -current, if someone is interested. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In article <[EMAIL PROTECTED]> you write: >How many of the patches at http://labs.gr/~charon/patches/ should go into >FreeBSD-current ? > >Darren I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) trying to fix more or less the same bugs/problems. Maybe it's a good idea if Giorgos and I together come up with 1 'big' ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of both our patches? Arjan -- Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]> URL: http://www.iae.nl/users/devet/ <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In some email I received from Arjan de Vet, sie wrote: > In article <[EMAIL PROTECTED]> you write: > > >How many of the patches at http://labs.gr/~charon/patches/ should go into > >FreeBSD-current ? > > > >Darren > > I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) > trying to fix more or less the same bugs/problems. > > Maybe it's a good idea if Giorgos and I together come up with 1 'big' > ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of > both our patches? That sounds like a good plan. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Bug in FreeBSD 4.4 in su
ok if you into your freebsd box from somewhere else and type su - root and then type the root password it just hangs there and you think I'm sure I typed the password correctly. So then you u think ok the the SSH session died for some reason try to log back in via ssh and you can't and when you try to ping the machine it appears down but its actually not down because if walk over to the machine down and up the network interface and reapply the firewall rules and then try to ssh to it, it works. which currently means I've no FreeBSD computer until I go and fix it. Getting withdrawl simptons already. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Ian Dowse wrote: > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writ > es: > > Nautilus from working properly. The problem disappeared when I've replaced > > writev(2) call with appropriate loop based around ordinary write(2). Perhaps > > this should be investigated and the real source of the problem fixed instead, > > but I do not have a time for this right now. For those who interested I'm > > ready to provide a step-by step instruction on how to reproduce the bug. > > Hi, > > If you have the details handy, a post to -hackers is likely to be > quite constructive at getting the problem analysed and resolved. Ok, details are below. GNOME oaf is a CORBA-based RPC framework. It uses UNIX domain sockets to communicate between client application and oafd daemon that serves requests. Usually the communication looks like the following: 1. Client connects to the oafd daemon via domain socket and sends marshalled RPC request. 2. The daemon reads request, demarshalls it and executes either internally or by invoking external program/shared library. 3. The daemon marshalls result of the call and passes it back to the client via the same socket. On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. To check that all buffers are indeed valid I have replaced writev(2) with a simple loop based around write(2), and the problem disappeared. See http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ORBit/files/patch-src%3a%3aIIOP%3a%3agiop-msg-buffer.c for details. I suspect that there is some problem associated with the writev(2)'s handling of EAGAIN (in my write(2)-based replacement I've observed EAGAIN on some 800th element of the buffer). If the problem is confirmed, it should be either fixed, or somehow noted in the manual page. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > Ian Dowse wrote: > > > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writ > > es: > > > Nautilus from working properly. The problem disappeared when I've replaced > > > writev(2) call with appropriate loop based around ordinary write(2). Perhaps > > > this should be investigated and the real source of the problem fixed instead, > > > but I do not have a time for this right now. For those who interested I'm > > > ready to provide a step-by step instruction on how to reproduce the bug. > > > > Hi, > > > > If you have the details handy, a post to -hackers is likely to be > > quite constructive at getting the problem analysed and resolved. > > Ok, details are below. > > GNOME oaf is a CORBA-based RPC framework. It uses UNIX > domain sockets to communicate between client application and > oafd daemon that serves requests. Usually the communication > looks like the following: > > 1. Client connects to the oafd daemon via domain socket and > sends marshalled RPC request. > 2. The daemon reads request, demarshalls it and executes > either internally or by invoking external program/shared > library. > 3. The daemon marshalls result of the call and passes it > back to the client via the same socket. > > On the step 3, when marshalling results of the call, daemon > creates a large collection of small buffers (usually 5-10 > bytes long each) arranged as array of struct iovec and then > sends this whole buffer to the client using writev(2) call. > In my particular case there were some 2,800 entries in the > buffer and when the daemon tried to send it to the client > writev(2) was returning -1 and setting errno to be EINVAL, > which confused the server and the client causing RPC to > fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. G'luck, Peter -- Thit sentence is not self-referential because "thit" is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
On Fri, Oct 26, 2001 at 09:21:37PM +1000, Darren Reed wrote: > In some email I received from Arjan de Vet, sie wrote: > > In article <[EMAIL PROTECTED]> you write: > > >How many of the patches at http://labs.gr/~charon/patches/ should go into > > >FreeBSD-current ? > > > > I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) > > trying to fix more or less the same bugs/problems. > > > > Maybe it's a good idea if Giorgos and I together come up with 1 'big' > > ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of > > both our patches? > > That sounds like a good plan. Yep, it sounds very good to me too. I've already got myself a copy of Arjan's diffs since last night that I saw his PR, and we'll probably use mail, IRC or something to work out the details. I have a weekend that I want interesting things to do with, and working on this is a very good idea. Darren, sorry for flooding you in email these last few days. When Arjan and I have come up with something that works nice and smooth, we'll let you know :))) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > > Ian Dowse wrote: > > > > > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writ > > > es: > > > > Nautilus from working properly. The problem disappeared when I've replaced > > > > writev(2) call with appropriate loop based around ordinary write(2). Perhaps > > > > this should be investigated and the real source of the problem fixed instead, > > > > but I do not have a time for this right now. For those who interested I'm > > > > ready to provide a step-by step instruction on how to reproduce the bug. > > > > > > Hi, > > > > > > If you have the details handy, a post to -hackers is likely to be > > > quite constructive at getting the problem analysed and resolved. > > > > Ok, details are below. > > > > GNOME oaf is a CORBA-based RPC framework. It uses UNIX > > domain sockets to communicate between client application and > > oafd daemon that serves requests. Usually the communication > > looks like the following: > > > > 1. Client connects to the oafd daemon via domain socket and > > sends marshalled RPC request. > > 2. The daemon reads request, demarshalls it and executes > > either internally or by invoking external program/shared > > library. > > 3. The daemon marshalls result of the call and passes it > > back to the client via the same socket. > > > > On the step 3, when marshalling results of the call, daemon > > creates a large collection of small buffers (usually 5-10 > > bytes long each) arranged as array of struct iovec and then > > sends this whole buffer to the client using writev(2) call. > > In my particular case there were some 2,800 entries in the > > buffer and when the daemon tried to send it to the client > > writev(2) was returning -1 and setting errno to be EINVAL, > > which confused the server and the client causing RPC to > > fail. > > 2800 entries? Well, from the writev(2) manual page: > > In addition, writev() may return one of the following errors: > > ... > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > UIO_MAXIOV. > > And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > Peter Pentchev wrote: > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: [snip] > > > > > > On the step 3, when marshalling results of the call, daemon > > > creates a large collection of small buffers (usually 5-10 > > > bytes long each) arranged as array of struct iovec and then > > > sends this whole buffer to the client using writev(2) call. > > > In my particular case there were some 2,800 entries in the > > > buffer and when the daemon tried to send it to the client > > > writev(2) was returning -1 and setting errno to be EINVAL, > > > which confused the server and the client causing RPC to > > > fail. > > > > 2800 entries? Well, from the writev(2) manual page: > > > > In addition, writev() may return one of the following errors: > > > > ... > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > UIO_MAXIOV. > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > Ah, ok. I've overlooked it somehow. So basically, you still want a loop, but it could be a writev(2) loop, not a write(2) loop, to keep some of the writev(2) performance benefit. G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: > > On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > > Peter Pentchev wrote: > > > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > [snip] > > > > > > > > On the step 3, when marshalling results of the call, daemon > > > > creates a large collection of small buffers (usually 5-10 > > > > bytes long each) arranged as array of struct iovec and then > > > > sends this whole buffer to the client using writev(2) call. > > > > In my particular case there were some 2,800 entries in the > > > > buffer and when the daemon tried to send it to the client > > > > writev(2) was returning -1 and setting errno to be EINVAL, > > > > which confused the server and the client causing RPC to > > > > fail. > > > > > > 2800 entries? Well, from the writev(2) manual page: > > > > > > In addition, writev() may return one of the following errors: > > > > > > ... > > > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > > UIO_MAXIOV. > > > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > > > Ah, ok. I've overlooked it somehow. > > So basically, you still want a loop, but it could be a writev(2) loop, > not a write(2) loop, to keep some of the writev(2) performance benefit. Yes, I've figured it already, because doing 2,800 syscalls when you can do a 3 instead is a bad idea. :) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:31:56PM +0300, Maxim Sobolev wrote: > Peter Pentchev wrote: > > > > On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > > > Peter Pentchev wrote: > > > > > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > > [snip] > > > > > > > > > > On the step 3, when marshalling results of the call, daemon > > > > > creates a large collection of small buffers (usually 5-10 > > > > > bytes long each) arranged as array of struct iovec and then > > > > > sends this whole buffer to the client using writev(2) call. > > > > > In my particular case there were some 2,800 entries in the > > > > > buffer and when the daemon tried to send it to the client > > > > > writev(2) was returning -1 and setting errno to be EINVAL, > > > > > which confused the server and the client causing RPC to > > > > > fail. > > > > > > > > 2800 entries? Well, from the writev(2) manual page: > > > > > > > > In addition, writev() may return one of the following errors: > > > > > > > > ... > > > > > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > > > UIO_MAXIOV. > > > > > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > > > > > Ah, ok. I've overlooked it somehow. > > > > So basically, you still want a loop, but it could be a writev(2) loop, > > not a write(2) loop, to keep some of the writev(2) performance benefit. > > Yes, I've figured it already, because doing 2,800 syscalls > when you can do a 3 instead is a bad idea. :) Oh, and BTW - writev(2) can also return EINVAL if the total size exceeds some maximum value (the manual page mentions a 32-bit integer). G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in FreeBSD 4.4 in su
On Fri, Oct 26, 2001 at 12:46:00PM +0100, Bri wrote: > ok if you into your freebsd box from somewhere else and type su - root and > then type the root password it just hangs there and you think I'm sure I > typed the password correctly. Are you using a serial console? Or, a defferent question, are you letting syslogd write to /dev/console while you are using a serial console? -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dummynet stats
Hi, I seem to get inconsistent outputs from the same dummynet stat query. Following is the output from two different queries : bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 0 0 bash-2.05$ The only difference between the two dumps is that a flood ping was stopped and then restated. In both cases, the same ruleset and dummynet pipes were in effect. I am using flood pings for a data stream in both cases. The first dump is after a flush and reinstallation of the pipe rules. The data stream was running while the rules were being installed. The ping was then stopped and restarted followed by the second stat query. My question is why didn't the stats reflect the stream until it had been stopped and restarted ? Rick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dummynet stats
On Fri, Oct 26, 2001 at 10:22:48AM -0700, rick norman wrote: > Hi, > > I seem to get inconsistent outputs from the same dummynet > stat query. Following is the output from two different queries : > > bash-2.05$ > bash-2.05$ ipfw pipe 3 show > 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail > mask: 0x00 0x/0x -> 0x/0x > bash-2.05$ > bash-2.05$ ipfw pipe 3 show > 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail > mask: 0x00 0x/0x -> 0x/0x > BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes > Pkt/Byte Drp > 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 > 0 0 > bash-2.05$ > > The only difference between the two dumps is that a flood ping > was stopped and then restated. > In both cases, the same ruleset and dummynet pipes were in effect. I > am using flood pings for a data stream in both cases. The first dump > is after a flush and reinstallation of the pipe rules. The data stream > was > running while the rules were being installed. The ping was then stopped > > and restarted followed by the second stat query. My question is why > didn't > the stats reflect the stream until it had been stopped and restarted ? i actually doubt that any traffic went throught he pipe before the first "ipfw pipe show" or you would have seen it. packets are accounted for immediately as they go through. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dummynet stats
I guess my question then is why did I need to stop the stream and restart it before it would show up in the pipe? It seems that if I repeatedly flush, delete pipes, reinstall pipes, without stopping the data stream, that I get into a state where no data will register in the pipes until I stop and restart the stream. Rick Luigi Rizzo wrote: > On Fri, Oct 26, 2001 at 10:22:48AM -0700, rick norman wrote: > > Hi, > > > > I seem to get inconsistent outputs from the same dummynet > > stat query. Following is the output from two different queries : > > > > bash-2.05$ > > bash-2.05$ ipfw pipe 3 show > > 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail > > mask: 0x00 0x/0x -> 0x/0x > > bash-2.05$ > > bash-2.05$ ipfw pipe 3 show > > 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail > > mask: 0x00 0x/0x -> 0x/0x > > BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes > > Pkt/Byte Drp > > 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 > > 0 0 > > bash-2.05$ > > > > The only difference between the two dumps is that a flood ping > > was stopped and then restated. > > In both cases, the same ruleset and dummynet pipes were in effect. I > > am using flood pings for a data stream in both cases. The first dump > > is after a flush and reinstallation of the pipe rules. The data stream > > was > > running while the rules were being installed. The ping was then stopped > > > > and restarted followed by the second stat query. My question is why > > didn't > > the stats reflect the stream until it had been stopped and restarted ? > > i actually doubt that any traffic went throught he pipe before > the first "ipfw pipe show" or you would have seen it. > packets are accounted for immediately as they go through. > > cheers > luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dummynet stats
On Fri, Oct 26, 2001 at 11:48:56AM -0700, rick norman wrote: > I guess my question then is why did I need to stop the stream and restart > it before it would show up in the pipe? It seems that if I repeatedly flush, I cannot reproduce the problem from your description. If you can post the exact sequence of actions that causes the behaviour in a reproducible way, then we can try and see what is going wrong. Please include os version, the ping command and the ifconfig of relevant interfaces. cheers luigi > delete pipes, reinstall pipes, without stopping the data stream, that I get > into > a state where no data will register in the pipes until I stop and restart the > stream. > > Rick > > Luigi Rizzo wrote: > > > On Fri, Oct 26, 2001 at 10:22:48AM -0700, rick norman wrote: > > > Hi, > > > > > > I seem to get inconsistent outputs from the same dummynet > > > stat query. Following is the output from two different queries : > > > > > > bash-2.05$ > > > bash-2.05$ ipfw pipe 3 show > > > 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail > > > mask: 0x00 0x/0x -> 0x/0x > > > bash-2.05$ > > > bash-2.05$ ipfw pipe 3 show > > > 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail > > > mask: 0x00 0x/0x -> 0x/0x > > > BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes > > > Pkt/Byte Drp > > > 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 > > > 0 0 > > > bash-2.05$ > > > > > > The only difference between the two dumps is that a flood ping > > > was stopped and then restated. > > > In both cases, the same ruleset and dummynet pipes were in effect. I > > > am using flood pings for a data stream in both cases. The first dump > > > is after a flush and reinstallation of the pipe rules. The data stream > > > was > > > running while the rules were being installed. The ping was then stopped > > > > > > and restarted followed by the second stat query. My question is why > > > didn't > > > the stats reflect the stream until it had been stopped and restarted ? > > > > i actually doubt that any traffic went throught he pipe before > > the first "ipfw pipe show" or you would have seen it. > > packets are accounted for immediately as they go through. > > > > cheers > > luigi > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
system hung with runnable processes
I didn't see anything like this in the archives, so I'm sending this to the questions list and hackers list for assistance. I am running FreeBSD 4.3 on a L440GX+ motherboard with dual PCI buses: 32/33 and 32/66 dual Pentium III @ 700MHz with 256KB L2 cache. The system is running in Uniprocessor mode. Although running the tests on FreeBSD 4.1 has not caused the problem. My problem: I have an application that reads from a SCSI bus, and forwards the SCSI CDB's to another system over TCP. When running a large load the system gets SCSI bus device reset's that the application acknowledges and clears an error bit. After a period of time, in this example about 2.5 hours, the system stops processing any SCSI CDB's. In DDB the ps output show 11 runnable process, p_wchan == 0, and curproc points to one of the processes. However, when checking the run queues via gdb, none of the runnable processes is in a run queue. According to rtqueuebits, queuebits, and idqueuebits, only queue[12] has any runnable processes. Examing the proc structures for the runnable processes, their priority is 6, so they should be in queue[6]. I cannot determine anything obvious in the process scheduling code, but something is happening. I am attaching the system dmesg output from boot to taking the system dump, the ddb output on the serial console, and the output from gdb of the process' stack trace and proc structure. If anyone needs more information just ask and I'll try to get it for you. Does anyone believe upgrading to FreeBSD 4.4 would resolve the problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syslogd and kqueue
If syslogd used the kqueue interface, I believe it could open a new log file as soon as it was created, rather than waiting to receive a signal. Would this be worth doing, or would it be too big a divergence from the traditional behavior? -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anoncvs down?
On Fri, Oct 26, 2001 at 09:15:28AM +0200, Peter Wullinger wrote: > Have I just missed, that anoncvs.FreeBSD.org was shut down? > > This would be a problem for me since I do not have access to > a FreeBSD machine with good internet connection and I didn't > get cvsup (i.e. M3) to compile on the machines which I could > use to access the CVS repo, so I've at last given up to get a repo > copy (of course, if somebody can help ;-) ...). If you had searched the archives, I said: For occational personal use, you may use [EMAIL PROTECTED]:/home/ncvs CVS_RSH=ssh The "none" ssh encryption method is available. You may use it by adding the appropiate lines to ~/.ssh_config I'd prefer it if people wouldn't overuse this, otherwise I might have to take it away, as the machine has limited bandwidth/resources. The repository syncs via cvsup twice a day. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Fri, Oct 26, 2001 at 11:39:57PM +0100, void wrote: > If syslogd used the kqueue interface, I believe it could open a new log > file as soon as it was created, rather than waiting to receive a signal. > Would this be worth doing, or would it be too big a divergence from the > traditional behavior? I assume you mean "as soon as the configuration file is modified"? That would be a big violation of POLA. Kris PGP signature
Re: syslogd and kqueue
On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: > On Fri, Oct 26, 2001 at 11:39:57PM +0100, void wrote: > > If syslogd used the kqueue interface, I believe it could open a new log > > file as soon as it was created, rather than waiting to receive a signal. > > Would this be worth doing, or would it be too big a divergence from the > > traditional behavior? > > I assume you mean "as soon as the configuration file is modified"? > That would be a big violation of POLA. No ... The traditional log-rotation dance goes something like: mv log log.0 touch log kill -1 `cat /var/run/syslogd.pid` gzip log.0 I'm suggesting that the "kill" could be left out if syslogd got the same smarts as "tail -F". -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
void <[EMAIL PROTECTED]> writes: > On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: > > I assume you mean "as soon as the configuration file is modified"? > > That would be a big violation of POLA. > > No ... Yes! > The traditional log-rotation dance goes something like: > > mv log log.0 > touch log > kill -1 `cat /var/run/syslogd.pid` > gzip log.0 > > I'm suggesting that the "kill" could be left out if syslogd got the same > smarts as "tail -F". I recommend using newsyslog(8) for rotating log files. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
Mike Barcroft <[EMAIL PROTECTED]> writes: > void <[EMAIL PROTECTED]> writes: > > On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: > > > I assume you mean "as soon as the configuration file is modified"? > > > That would be a big violation of POLA. > > > > No ... > > Yes! Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. Just like one wouldn't expect it to create a new log file. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Sat, Oct 27, 2001 at 12:26:22AM -0400 I heard the voice of Mike Barcroft, and lo! it spake thus: > > Just to clarify. This is still a POLA violation. If a log file is > pulled out from underneath syslogd(8), one wouldn't expect it to start > logging again, even if the file was re-created. Just like one > wouldn't expect it to create a new log file. Actually, one would. It always takes conscious effort for me to remember that syslog won't create non-existent logfiles. That means I have to go touch a bunch of files when, for instance, I'm setting up a jail(8). It seems extremely counter-intuitive to me that I can't just say "Log to this file" and have it start logging there, without me laying out a yellow brick road. Forget kqueue. Just an O_CREAT. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
