On Fri, 1 Nov 2002, Bill Fenner wrote:
sonewconn() hands sofree() a self-inconsistent socket -- so-so_head is
set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
Please try this patch.
Bill
Index: uipc_socket2.c
On Fri, 1 Nov 2002, Terry Lambert wrote:
Bill Fenner wrote:
I think this can still crash (just like my patch); the problem is in
what happens when it fails to allocate memory. Unless you set one of
the flags, it's still going to panic in the same place, I think, when
you run out of
Michal Mertl wrote:
This patch fixes the panics for me. Thanks a lot. I believe it should be
commited.
I agree (Mark Murray -- this was the patch I was talking about).
BTW: I get about 850 fetches pers second on UP an 600 SMP (the same
machine and settings). Don't know if it's expected in
Michal Mertl wrote:
Do I read you correctly that Bill's patch is probably better than yours
(I tested both, both fix the problem)?
That's a hard question, and it takes a longer answer. 8-(.
They fix the problem different ways. The problem is actually
a secondary effect. There are several
Terry,
I think most of your 9k of reasoning is based on the thought that
soreserve() allocates memory. It doesn't, and never has.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Michal,
Alan Cox pointed out to me that backing out to using sodealloc()
instead of sotryfree() is probably a better fix anyway - it solves
the panic in more or less the same way as mine, but it backs the code
out to be the same as it's been for years -- a much more well-tested
fix =) He
Hi
--- Terry Lambert [EMAIL PROTECTED] wrote:
With proper tuning, and some minor patches, 7000/second isn't hard
to get.
If you add the Duke University version of the Rice University patches
for LRP, modify the mbuf allocator for static freelisting and then
pre-populate it, and tune the
From: Galen Sampson [mailto:galen_sampson;yahoo.com]
Out of pure curiosity what is the reason that the Duke and
Rice patches were
never incorporated into the base system. If it really
enables the same machine
to provide 4 times the number of connections this seems like
it would be a
Bill Fenner wrote:
I think most of your 9k of reasoning is based on the thought that
soreserve() allocates memory. It doesn't, and never has.
The real problem is the in_pcballoc() in tcp_attach(), which calls
uma_zalloc().
But for mbufs, soreserve allocates space, for potential mbufs, even
Galen Sampson wrote:
With proper tuning, and some minor patches, 7000/second isn't hard
to get.
If you add the Duke University version of the Rice University patches
for LRP, modify the mbuf allocator for static freelisting and then
pre-populate it, and tune the kernel properly, you
Don Bowman wrote:
I suspect because of the copyright:
http://www.cs.rice.edu/CS/Systems/ScalaServer/code/rescon-lrp/README.html
This code is copyrighted software and can NOT be redistributed
That explains why the new code was integrate, not why the old code
wasn't, when it was initially
I really don't understand why you keep claiming that the SYN cache
changes anything. Without the SYN cache, tcp_input() calls
sonewconn(so, 0) on receipt of a SYN; with the SYN cache, tcp_input()
calls some syncache function which calls sonewconn(so, SS_ISCONNECTED)
on receipt of a SYN/ACK. In
Michal Mertl wrote:
I'm getting panics on SMP -CURRENT while running apachebench (binary ab
from apache distribution, not the Perl one) against httpd on the machine.
The panics don't occur when I have WITNESS and INVARIANTS turned on.
[ ... ]
#10 0xc01bd46f in panic (fmt=0x0) at
sonewconn() hands sofree() a self-inconsistent socket -- so-so_head is
set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
Please try this patch.
Bill
Index: uipc_socket2.c
===
RCS file:
Bill Fenner wrote:
sonewconn() hands sofree() a self-inconsistent socket -- so-so_head is
set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
Please try this patch.
I think this can still crash (just like my patch); the problem is in
what happens when it fails to
I think this can still crash (just like my patch); the problem is in
what happens when it fails to allocate memory. Unless you set one of
the flags, it's still going to panic in the same place, I think, when
you run out of memory.
No. The flags are only checked when so_head is not NULL.
Bill Fenner wrote:
I think this can still crash (just like my patch); the problem is in
what happens when it fails to allocate memory. Unless you set one of
the flags, it's still going to panic in the same place, I think, when
you run out of memory.
No. The flags are only checked when
17 matches
Mail list logo
