Date: Mon, 15 Sep 2008 10:37:11 +0100 From: Gavin Atkinson <gavin@FreeBSD.org> To: Norbert Papke <fbsd-ml@scrapper.ca> Cc: freebsd-stable@FreeBSD.org Subject: Re: Possible UDP related deadlock in 7.1-PRERELEASE Message-ID: <1221471431.49328.5.camel@buffy.york.ac.uk> In-Reply-To: <200809141219.24943.fbsd-ml@scrapper.ca> References: <200809141219.24943.fbsd-ml@scrapper.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2008-09-14 at 12:19 -0700, Norbert Papke wrote:
> Symptoms:
>
> * I can trigger this lockup reliably by starting ktorrent. After a short
> while (one to two minutes), it locks up. Other commands, e.g., netstat, also
> lock up.
> * The console generates "nfe0: watchdog timeout" error messages.
> * The system becomes unusable and must be rebooted.
> Attempted Diagnosis:
>
> If I break into DDB, the 'ps' output shows a number of processes that seem to
> be locked related to udp.
>
> [irq18:dc0] L *udp
> ktorrent L *udpinp
> hald L *udp
> ntpd L *udp
>
> Unfortunately, I am rapidly getting out of my depth here. I have no idea how
> to go about further analyzing this problem and would appreciate help.
Can you add:
options WITNESS
options WITNESS_SKIPSPIN
to your kernel, recompile and wait for the problem to happen again?
When it does, from the debugger issue "sh alllocks" and make a note of
the output?
This will probably show that two locks are held, "Giant" and "udp",
along with the thread that holds each of them. Take the ID of the
thread that holds the "udp" lock, and enter "tr 100150" (where 100150 is
the thread ID.
This should hopefully provide enough info to figure out what is
happening.
Thanks,
Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1221471431.49328.5.camel>