Bug #2032
closed
iwn panic: assertion: !IS_SERIALIZED((s)) in lwkt_serialize_enter
Added by pavalos almost 14 years ago.
Updated over 13 years ago.
Description
I continously get this panic on a recent master (after the recent
iwn changes) on every boot:
panic: assertion: !IS_SERIALIZED((s)) in lwkt_serialize_enter
(kgdb) bt
#0 _get_mycpu (di=0xc0778260) at ./machine/thread.h:79
#1 md_dumpsys (di=0xc0778260) at /usr/src/sys/platform/pc32/i386/dump_machdep.c:264
#2 0xc01bb858 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:893
#3 0xc01bbe69 in boot (howto=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:388
#4 0xc01bc0d3 in panic (fmt=0xc048cc9c "assertion: %s in %s") at /usr/src/sys/kern/kern_shutdown.c:799
#5 0xc01cad77 in lwkt_serialize_enter (s=0xc07a51cc) at /usr/src/sys/kern/lwkt_serialize.c:153
#6 0xc025935b in _wlan_serialize_enter (funcname=0xc04211a4 "iwn_init") at /usr/src/sys/netproto/802_11/wlan/ieee80211_dragonfly.c:174
#7 0xc017d6f2 in iwn_init (arg=0xd9340000) at /usr/src/sys/dev/netif/iwn/if_iwn.c:6185
#8 0xc017d77c in iwn_ioctl (ifp=0x0, cmd=0, data=0x0, ucred=0x0) at /usr/src/sys/dev/netif/iwn/if_iwn.c:3422
#9 0xc0276a5d in parent_updown_task (arg=0xd7a59568, npending=1) at /usr/src/sys/netproto/802_11/wlan/ieee80211_proto.c:1088
#10 0xc01e6561 in taskqueue_run (queue=0xc74644c0, lock_held=<value optimized out>) at /usr/src/sys/kern/subr_taskqueue.c:271
#11 0xc01e6667 in taskqueue_thread_loop (arg=0xd947d494) at /usr/src/sys/kern/subr_taskqueue.c:375
#12 0xc01c5f8e in lwkt_deschedule_self (td=Cannot access memory at address 0x8
) at /usr/src/sys/kern/lwkt_thread.c:282
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
--Peter
Files
I'm working on a solution to this. Iwn_ioctl() is serialized when called from
parent_updown_task() but not from other entry points. I'm thinking I should
just remove the serialization from parent_updown_task(), but I'll need to do a
bit of research first.
Thanks,
Joe
On Tue, Mar 22, 2011 at 6:39 PM, Joe Talbott (via DragonFly issue
tracker) <sinknull@leaf.dragonflybsd.org> wrote:
Joe Talbott <josepht@cstone.net> added the comment:
I'm working on a solution to this. Iwn_ioctl() is serialized when called from
parent_updown_task() but not from other entry points. I'm thinking I should
just remove the serialization from parent_updown_task(), but I'll need to do a
bit of research first.
No, all ifnet.if_xxx function pointers should be serialized by the
callers. You could take a look at any wired driver for example.
Actually we do not use the xxx_locked() style functions.
Best Regards,
sephe
I'm considering this a release blocker since it happens every boot.
Fixed in 949fd82681fcca253fde8a071a7be88664a6a3ea.
After updating my sources, I'm running into the following panic upon loading the
iwn kernel module.
...
iwn0: <Intel(R) PRO/Wireless 4965BGN> mem 0xdf2fe000-0xdf2fffff irq 17 at device
0.0 on pci3
iwn0: MIMO 2T3R, MoW1, address 00:21:5c:8f:ca:11
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
wlan0: MAC address: 00:21:5c:8f:ca:11
panic: vm_object_deallocate: object deallocated too many times: 0
cpuid = 0
Trace beginning at frame 0xffffffe01d3dfa70
...
I'm attaching the generated core.txt. Let me know if you need the vmcore/kern,
as well.
Arch: x86_64
Kernel config: X86_64_GENERIC_SMP
On Thu, Apr 14, 2011 at 03:27:09PM +0000, Chirag Kantharia (via DragonFly issue tracker) wrote:
Chirag Kantharia <chirag@kantharia.in> added the comment:
After updating my sources, I'm running into the following panic upon loading the
iwn kernel module.
...
iwn0: <Intel(R) PRO/Wireless 4965BGN> mem 0xdf2fe000-0xdf2fffff irq 17 at device
0.0 on pci3
iwn0: MIMO 2T3R, MoW1, address 00:21:5c:8f:ca:11
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
wlan0: MAC address: 00:21:5c:8f:ca:11
panic: vm_object_deallocate: object deallocated too many times: 0
cpuid = 0
Trace beginning at frame 0xffffffe01d3dfa70
...
Do you have the firmware module properly built? It's failing trying to
unload the firmware it seems. Please upload the core and kernel to leaf.
Thanks,
Joe
I'm attaching the generated core.txt. Let me know if you need the vmcore/kern,
as well.
Arch: x86_64
Kernel config: X86_64_GENERIC_SMP
_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue2032>
_____________________________________________
On Thu, Apr 14, 2011 at 11:54:45AM -0400, Joe Talbott wrote:
| > iwn0: <Intel(R) PRO/Wireless 4965BGN> mem 0xdf2fe000-0xdf2fffff irq 17 at device
| > 0.0 on pci3
| > iwn0: MIMO 2T3R, MoW1, address 00:21:5c:8f:ca:11
| > iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
| > iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
| > iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
| > 36Mbps 48Mbps 54Mbps
| > wlan0: MAC address: 00:21:5c:8f:ca:11
| > panic: vm_object_deallocate: object deallocated too many times: 0
| > cpuid = 0
| > Trace beginning at frame 0xffffffe01d3dfa70
| > ...
|
| Do you have the firmware module properly built?
| It's failing trying to
| unload the firmware it seems.
Can you tell me how I can verify this? I've always built my kernels
with make buildkernel (that is, I have not used quickkernel).
| Please upload the core and kernel to leaf.
I don't have a leaf account as yet. But the new issue looks very
similar to issue 2044 [*]. The submitter of issue 2044 has uploaded
the kernel/dump files (kern.18, vmcore.18) to ~mh/crash.
Thanks,
[*] - http://bugs.dragonflybsd.org/issue2044
Also available in: Atom
PDF