Re: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831

From: Paul B. Mahol <onemda_at_gmail.com>
Date: Sun, 18 Jan 2009 00:02:24 +0100
On 1/16/09, Yuriy Tsibizov <Yuriy.Tsibizov_at_gfk.com> wrote:
>> > On 1/14/09, Yuriy Tsibizov <Yuriy.Tsibizov_at_gfk.com> wrote:
>> >>
>> >>> On 1/14/09, Yuriy Tsibizov <Yuriy.Tsibizov_at_gfk.com> wrote:
>> >>> > Kip,
>> >>> >
>> >>> > this happens on fresh -CURRENT, with configuration
>> similar to one
>> >>> > described in
>> >>> >
>> >>> http://docs.freebsd.org/cgi/mid.cgi?3a142e750812080658r645dc1c
>> >>> 4sdd612585
>> >>> > fe9ad7d6 (wpa_supplicant is main suspect in triggering this
>> >>> panic). No
>> >>> > crashdump / backtrace available.
>> >>> >
>> >>> > Somehow needlock!=0, and rnh is already locked.
>> >>> >
>> >>> > HW is Intel Atom D945GCLF2 (2core + HT enabled) + D-Link
>> >>> Atheros-based
>> >>> > card with WPA and static ip.
>> >>
>> >>> And bt is completly the same as was mine?
>> >>
>> >> I don't have backtrace -- swap was tooo small.
>> >
>> I need a full backtrace in order to fix.
>
> I have a textdumps enabled now (with default script that calls bt), will
> it be enough or full memory dump (for kgdb analysis) is a must?

bt is necessarily for even starting to look at panic source when there
is no known way how to reproduce panic itself.
When textdump is enabled memory dumps are by default not created.

Memory dumps are useful if you plan to debug big file yourself, and
you already said that your dumb dev is too small for it.

-- 
Paul
Received on Sat Jan 17 2009 - 22:02:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:40 UTC