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

[Paul B. Mahol]

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