Bug #2032

iwn panic: assertion: !IS_SERIALIZED((s)) in lwkt_serialize_enter

Added by pavalos about 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:
Priority:UrgentDue date:
Assignee:josepht% Done:

0%

Category:-
Target version:-

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

core.txt.10 (68.3 KB) chirag, 04/14/2011 03:27 PM

History

#1 Updated by josepht about 3 years ago

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

#2 Updated by sepherosa about 3 years ago

On Tue, Mar 22, 2011 at 6:39 PM, Joe Talbott (via DragonFly issue
tracker) <> wrote:
>
> Joe Talbott <> 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

#3 Updated by pavalos about 3 years ago

I'm considering this a release blocker since it happens every boot.

#4 Updated by pavalos about 3 years ago

Fixed in 949fd82681fcca253fde8a071a7be88664a6a3ea.

#5 Updated by chirag about 3 years ago

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

#6 Updated by josepht about 3 years ago

On Thu, Apr 14, 2011 at 03:27:09PM +0000, Chirag Kantharia (via DragonFly issue tracker) wrote:
>
> Chirag Kantharia <> 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 <>
> <http://bugs.dragonflybsd.org/issue2032>
> _____________________________________________________

#7 Updated by chirag about 3 years ago

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