Re: Restarting rtwn(0)-based interface causes reproducible kernel panics

From: Otacílio <otacilio.neto_at_bsd.com.br>
Date: Mon, 27 Jun 2016 14:24:21 -0300
Em 27/06/2016 14:14, Marcus von Appen escreveu:
> Hi,
>
> restarting the network interface for my rtwn(0)-based RTL8188CE card
> causes a reproducible kernel panic:
>
> # service netif restart
> [...]
> panic: Memory modified after free 0xfffff80005c22800(2048) val=8018 _at_ 0xfffff80005c22800
> [...]
>
> Unread portion of the kernel message buffer:
> panic: Memory modified after free 0xfffff80005c22800(2048) val=8018 _at_ 0xfffff80005c22800
>
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe045362b670
> vpanic() at vpanic+0x186/frame 0xfffffe045362b6f0
> panic() at panic+0x43/frame 0xfffffe045362b750
> trash_ctor() at trash_ctor+0x4b/frame 0xfffffe045362b760
> mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfffffe045362b7a0
> uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfffffe045362b800
> ieee80211_getmgtframe() at ieee80211_getmgtframe+0x120/frame 0xfffffe045362b840
> ieee80211_send_probereq() at ieee80211_send_probereq+0x104/frame 0xfffffe045362b8e0
> ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 0xfffffe045362b920
> scan_curchan() at scan_curchan+0x68/frame 0xfffffe045362b960
> scan_curchan_task() at scan_curchan_task+0x247/frame 0xfffffe045362b9e0
> taskqueue_run_locked() at taskqueue_run_locked+0x13c/frame 0xfffffe045362ba40
> taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfffffe045362ba70
> fork_exit() at fork_exit+0x84/frame 0xfffffe045362bab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe045362bab0
> [...]
>
> and (probably) a variant:
>
> # service netif restart
> [...]
> panic: Memory modified after free 0xfffff80005c07800(2048) val=19 _at_ 0xfffff80005c07800
> [...]
> Unread portion of the kernel message buffer:
> panic: Memory modified after free 0xfffff80005c07800(2048) val=19 _at_ 0xfffff80005c07800
>
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0455213540
> vpanic() at vpanic+0x186/frame 0xfffffe04552135c0
> panic() at panic+0x43/frame 0xfffffe0455213620
> trash_ctor() at trash_ctor+0x4b/frame 0xfffffe0455213630
> mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfffffe0455213670
> uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfffffe04552136d0
> m_getm2() at m_getm2+0x12d/frame 0xfffffe0455213740
> m_uiotombuf() at m_uiotombuf+0x62/frame 0xfffffe0455213790
> sosend_generic() at sosend_generic+0x356/frame 0xfffffe0455213850
> kern_sendit() at kern_sendit+0x244/frame 0xfffffe0455213900
> sendit() at sendit+0x1af/frame 0xfffffe0455213950
> sys_sendto() at sys_sendto+0x4d/frame 0xfffffe04552139a0
> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0455213ab0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0455213ab0
> [...]
>
> Let me know how to help on getting this fixed.
>
> Cheers
> Marcus

What is the revision that you are using? I have faced a similar problem 
on APLHA4, but now, on ALPHA5 it is working fine.

[]'s

-Otacilio
Received on Mon Jun 27 2016 - 15:24:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC