Mon 12 Feb 2007 06:10:30 PM UTC, comment #2:
It has been suggested already, and is certain now, that the problem actually
happens under high network load, probably if the network connection is more or
less saturated: I can reproduce it pretty reliably by running gv with a very
large PS figure ( http://dept-info.labri.fr/~thibault/tmp/graph-radial.ps ) on
a remote X server in my local network.
I also confirmed my guess that the problem is related to the gnumach BPF patch:
A kernel without the patch works, an otherwise identical kernel with the patch
(and the updated pfinet) crashes.
With the kernel debugger, I was able to find out that the crash actually
happens in the line
_last->ikm_next = (kmsg);
in ipc_kmsg_enqueue_macro() (ipc/ipc_kmsg.h), because _last has the value
IKM_BOGUS. It turns out ipc_kmsg_enqueue() is called with a broken
ipc_kmsg_queue as "queue" parameter: It's head points to an element with "next"
and "prev" pointers both set to IKM_BOGUS.
However, I was not able to find out how this broken ipc_kmsg_queue gets
created. Probably some locking issue in device/net_io.c or so, but that's just
guessing. One possibility for such a broken queue to be created could be if
ipc_kmsg_rmqueue_first_macro() or ipc_kmsg_rmqueue() is called with a "queue"
parameter which doesn't actually point to the queue in which the kmsg entry is:
In this case, the "next" and "prev" pointers of the entry would get set to
IKM_BOGUS, but the head pointer of the queue wouldn't get updated accordingly.
-antrik-
(file #11971)
|