> I think should have been removed when offsetof() became
> standard.
At last count, offsetof() is defined in 11 different places in the kernel:
alpha/alpha/machdep.c, line 234
dev/sym/sym_hipd.c, line 347
i386/i386/machdep.c, line 246
kern/sysv_sem.c, line 110
kern/u
Can you try upgrading to rev 1.29 of tcp_syncache.c which I committed
yesterday? I suspect that should fix this problem.
Jeffrey
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> I'm testing the patch below, which simply removes the inpcb locking
> and avoids the panic. It seems safe to me since we're running splnet,
> but I'm not sure it's correct since I suppose the locking is there
> for a reason...
It's safe to remove those inp locks. We only use the generat
Pierre, can you see if this patch fixes your problem? Thanks.
Jeffrey
Index: tcp_syncache.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v
retrieving revision 1.30
diff -u -
> 1st 0xc0384800 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151
> 2nd 0xc1886b7c radix node head (radix node head) @
> /usr/src/sys/net/route.c:549
A fix was committed on Jan 28, so if you update your source, the problem
will go away.
To Unsubscribe: send mail to [EMAIL PROTEC
> Date: Sat, 1 Mar 2003
> With my three days old 5.0-current
> panic: headlocked should be 0
Try updating to rev 1.198 of tcp_input.c which was committed on Feb 26,
around 3 days ago.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of th
Thanks for reporting these. NFS has this same problem with sowakeup().
You can find an old patch I made for this at
http://www.freebsd.org/~hsu/hammer.diff
It takes a big hammer to the problem and is less than elegant, so I
haven't committed it. I hope to have time to address this problem
> file IO using gives error messages about implicit typenames
> being deprecated, and I can't for the life of me figure out what to do
> my code to make the compiler happy
Change your /usr/include/g++/fstream as follows:
--- /usr/include/g++/fstreamSun Jun 29 09:17:46 2003
+++ fstream
> I've had to disable newreno on my machines as well.
> have a wireless link to a DSL line, and I get much better
> performance when I do that.
I would go test wireless links, but if_wi stopped working for my notebook.
There's only one outstanding bug that I know of with newreno and there's
> I'm sitting on a ISDN line right now, and I thought the newreno issues
> had been solved, but by disabling newreno I get a distinctly better
> web-surfing experience.
NewReno is a sender-side only algorithm and web-surfing is mostly a
receiver-side experience. If you gather some quantitati
> 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls
>ends up calling vm_map_entry_create(). vm_map_entry_create() calls
>uma_zalloc() with M_WAITOK.
Alan Cox and Tor Egge just fixed this in -current in rev 1.247 of vm_map.c.
To Unsubscribe: send mail to [EM
> typo in unlocking (causing recursive lock instead)
Fixed. Thanks.
> lack of inet6 support for inpcb locking, e.g. no
> handling of locks in in6_pcbdetach.
> attempts to destroy held lock in in_pcbdetach
Gurg, IPv6 isn't locked up yet! These must be the result of inadvertent
interac
> Jun 11 22:34:47 calvin kernel: lock order reversal
> Jun 11 22:34:47 calvin kernel: 1st 0xd311c2f8 inp (inp) @
> /usr/src/sys/netinet/tcp_usrreq.c:581
> Jun 11 22:34:47 calvin kernel: 2nd 0xc04a5340 Giant (Giant) @
> /usr/src/sys/kern/subr_trap.c:76
> Jun 11 22:34:47 calvin kernel: e
Duplicate inp warnings occur whenever 2 inp locks are held, even though they're
on different inps, because all the inp locks are named "inp". I've
investigated a couple of these already and they were all places where
we intended to grab two inp locks. So, for the most part, these warning are
har
> How do you define the order between teh two inp locks to ensure you don't
> end up deadlocking?
One is the listening connection and the other is the newly created connection.
The two inp locks are always acquired in the same order, so there's no
possibility of deadlock here.
Another cas
That looks like a different problem.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> Jun 14 10:36:08 calvin syslogd: kernel boot file is /boot/kernel/kernel
> Jun 14 10:36:08 calvin kernel: panic: lock (sleep mutex) inp not locked @
/usr/src/sys/netinet/tcp_subr.c:1069
Thanks for the bug report, Sid. This panic should be addressed by the
following commit:
hsu 200
Can you try this fix instead? It's based on a similar patch Jonathan Lemon
sent to me for a similar spot in tcp_subr.c.
Index: udp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.113
diff -u -r
If you compare the two approaches, the BSD/OS approach is simpler
because it is coarse. You're confusing finer grain locking with
better.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In article <[EMAIL PROTECTED]> you write:
>I am now working on locking down a socket. (I have heard that Jeffrey
>Hsu is also doing that, but I have never seen his patch. Has anyone
>seen that?)
I have. :-) I do coarse-grain locking at the inpcb and sockbuf level as
is done i
20 matches
Mail list logo
