Mike Smith <[EMAIL PROTECTED]> writes:
> > Terry Lambert <[EMAIL PROTECTED]> writes:
> > > There is so much "goo" around the module loading these days; there
> > > are incursions into "mount" and all sorts of other programs that
> > > should not know about module loading.
> >
> > The kldload(2) i
On Mon, Dec 31, 2001 at 03:48:07AM -0500, Mike Barcroft wrote:
> Mike Smith <[EMAIL PROTECTED]> writes:
> > > Terry Lambert <[EMAIL PROTECTED]> writes:
> > > > There is so much "goo" around the module loading these days; there
> > > > are incursions into "mount" and all sorts of other programs tha
On Mon, Dec 31, 2001 at 10:59:40AM +0200, Peter Pentchev wrote:
>
> Okay, so it's not documented in the manual, but one look at the source
> should suffice :)
>
> As Mike said, there is a search path. However, the current directory
> is tried first. If a file by that name is not found in the c
[Moved to -arch, BCC'd to -hackers.]
Peter Pentchev <[EMAIL PROTECTED]> writes:
> Okay, so it's not documented in the manual, but one look at the source
> should suffice :)
:(
> As Mike said, there is a search path. However, the current directory
> is tried first. If a file by that name is no
) and the numeric field next to it.The dialog symbol is the name your COBOL program
uses to refer to the dialog box. The numeric field shows the number that will be
assigned to that name via a 78-level XE "78-level" XE "level 78" , which the Resource
Manager automatically generates in mfres.
It seems Nils Holland wrote:
> root@poison> pciconf -r -b pci0:0:0 0x0:0xff
Thanks! this was a kernel without the corruption fix, and it shows
that you need it, the MWQ bug has been fixed in your BIOS...
I have a new improved patch in the works that covers more chipset
comboes, it'll go into -cu
On 2001-12-18 15:29 -0500, Michael Scheidell <[EMAIL PROTECTED]> wrote:
> I have a userland program that canpanic/reboot a freebsd 4.3 system.
> Hardware is Intel isp1100 (mbx440 motherboard) 850MHZ pIII, 256mb ram, 640mb
> swapfile
> software is 'nessusd' (network security scanner) hits the ether
>
> I've had similar problems running nessus against a range of 32 class B
> networks (i.e. 2mio addresses) with some 1 hosts expected to be
> found. Since I need to complete the scan during the next two weeks
> (it's running in batch mode right now; but I had trouble with hanging
> nessusd
On 2001-12-31 10:29 -0500, Michael Scheidell <[EMAIL PROTECTED]> wrote:
> as for hanging processes, this is probaly due to the bug in the FBSD
> distributer libpcap, hanging on pcap_next().
IIRC, most processes were sleeping in select(). But truss revealed,
that some processes were running in a l
>
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32681
>
> The cause is a NULL pointer dereference in that fstatfs system
> call, where some pointer hanging off a vnode is cleared. Nessusd
> tries to read from /proc/PID (for PID = process IDs of plugins
> spawned) in order to see whether so
Anjali Kulkarni wrote:
> I have tried this too, it makes absoutely no difference at all. My mallocs
> fail after a certain no. of runs of my code(and there is no memory leak),
> and there was no difference by increasing MAXDSIZ/DFLDSIZ.
You were asking how to increase your VM space.
What you sho
Matthew Dillon wrote:
> new-reno was artifically limiting the max number of in-transit
> packets to 4. This is probably why the USB ethernet worked
> with 4.3, but it destroyed TCP performance for everything else
> and was removed.
>
> I don't think there is kernel solution t
Matthew Dillon wrote:
> KVM is only 1G, and a lot of is used-up. You cannot allocate
> (directly map) hundreds of megabytes of kernel memory.
You can crank up the KVA space, though the handbook is wrong for
-release, and woefully out of date for -current.
You can also do big allocations
:Cap the window size via the driver. This will probably require
:another attribute on all drivers, indicating "max allowable window
:size" ("0" could mean "any", and be used as the default so that we
:don't end up flaking out someone talking to Mars).
:
:-- Terry
It won't help. The problem
Matthew Dillon wrote:
> :Cap the window size via the driver. This will probably require
> :another attribute on all drivers, indicating "max allowable window
> :size" ("0" could mean "any", and be used as the default so that we
> :don't end up flaking out someone talking to Mars).
>
> It won
:I'm talking about capping the maximum negotiable window size
:over the USB adapter...
:
:How can this cause problems, since (1) the only thing we are talking
:about is window size, not packet size (MTU), and (2) the only thing
:it will effect is the TCP stream post negotiation, so it should not
:
the driver should return ENOBUFS
and TCP should repect that..
I think it already does in fact..
On Mon, 31 Dec 2001, Matthew Dillon wrote:
> :I'm talking about capping the maximum negotiable window size
> :over the USB adapter...
> :
> :How can this cause problems, since (1) the only thing we
:
:the driver should return ENOBUFS
:and TCP should repect that..
:I think it already does in fact..
How does the client's driver returning ENOBUFS prevent the server from
sending too many packets?
-Matt
To Unsubscribe: send mail to
:Matt: make up your mind.
:
:Either:
:
:1) The server is sending too many packets
:
:OR
:
:2) The server is NOT sending too many packets
:
:The correct way to deal with #1 is to negotiate a smaller window size
:so that "too many packets are not sent".
:
:Actually, the PSC rate-halving algo
my stupid :-)
On Mon, 31 Dec 2001, Matthew Dillon wrote:
>
> :
> :the driver should return ENOBUFS
> :and TCP should repect that..
> :I think it already does in fact..
>
> How does the client's driver returning ENOBUFS prevent the server from
> sending too many packets?
>
>
On Mon, 31 Dec 2001, Terry Lambert wrote:
> Matthew Dillon wrote:
> > :the driver should return ENOBUFS
> > :and TCP should repect that..
> > :I think it already does in fact..
> >
> > How does the client's driver returning ENOBUFS prevent the server from
> > sending too many packets?
Title: $10K in 30 Days!!
I'll
Show YOU How To Make At Least
$10,000
In 30 Days or Less Every Month... NO RISK!!!
Would you like to make at least
$10,000
(in 30 days or less) every month?
Here's how you can make that money
(and more... ) every month, and make
your first
Does anyone have a feel for how the PRO/1000 XT card/driver compares to the
eepro100/fxp driver as a 100Mb/s solution?
Thanks,
Dennis
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Matthew Dillon wrote:
> Terry, I don't think you quite understand the problem. From the server's
> point of view NOTHING IS WRONG. Any non-USB-ethernet client would have
> no problem whatsoever with the large number of small packets that the
> server is sending, nor can the serve
Terry, I give up. Maybe if you actually tried to go in and fix it
you would see what I'm talking about. For your information:
* Julian's work has nothing to do with this particular problem. It
has to do with constricted bandwidth. This issue has nothing to do
with USB'
> > What part of searching a path for a matching file is "black magic"?
> >
> > Shells have been doing this for decades...
>
> %%%
> /*
> * Load /boot/kernel/procfs.ko
> * XXX: why does this work?
> */
> chdir("/");
> kldload("procfs");
You should only need the last kldload call. Any othe
Matthew Dillon wrote:
>
> Terry, I give up. Maybe if you actually tried to go in and fix it
> you would see what I'm talking about. For your information:
I don't have a USB/Ethernet adapter.
> * Julian's work has nothing to do with this particular problem. It
> has to do w
An underlying issue here is why applications decide to set TCP_NODELAY
options on sockets, rather than just letting Nagle's algorithm do
the right thing. I recall some handwaving about this in the X server
some years ago to make mouse movements "smoother".
For the problem at hand, if both the c
In a message written on Mon, Dec 31, 2001 at 02:44:42PM -0800, Matthew Dillon wrote:
> * I never said the server was the problem. To the contrary, I've
> been saying that the client is the problem.. USB ethernet is
> broken, period.
I think several people are trying to say the sa
"Louis A. Mamakos" wrote:
>
> An underlying issue here is why applications decide to set TCP_NODELAY
> options on sockets, rather than just letting Nagle's algorithm do
> the right thing. I recall some handwaving about this in the X server
> some years ago to make mouse movements "smoother".
OK
:An underlying issue here is why applications decide to set TCP_NODELAY
:options on sockets, rather than just letting Nagle's algorithm do
:the right thing. I recall some handwaving about this in the X server
:some years ago to make mouse movements "smoother".
:
:For the problem at hand, if both
Matthew Dillon wrote:
> Yes, you are correct. There is no real reason for ssh to set
> TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to.
> We should just turn it off.
FWIW, I agree that it should not be set. Setting socket options
has the unfortunate side effect of g
Disabling Nagle's algorithm for no good reason has very poor
scaling behavior. This is what happens when TCP_NODELAY is
enabled on a socket.
If you look at the work function for most network elements, the part
that runs out of gas first is per-packet forwarding performance. Sure,
you need to h
Hi,
First of all happy new year, etc. =)
My problem: I'm writing a device driver kernel module that uses kernel
level sosend() from the d_write write() function. But it runs out of
bufferspace (error 55) when I really stress it (sending 15 megs in 3-4 secs
over UDP with 32 or 60K packets).
Th
>Yes, you are correct. There is no real reason for ssh to set
>TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to.
>We should just turn it off.
Nagle + delayed acks don't really get along all that well, and often
result in character echoes lagging .25-.5 seconds be
:>TCP_NODELAY on FreeBSD and, in fact, I believe it didn't used to.
:>We should just turn it off.
:
: Nagle + delayed acks don't really get along all that well, and often
:result in character echoes lagging .25-.5 seconds behind the keystrokes (due
:to round trip + 200ms). This really
36 matches
Mail list logo
