RELENG_8 panic caused by urtw?

[Sergey Kandaurov]

On 15 February 2012 13:01, Markiyan Kushnir <markiyan.kushnir at gmail.com> wrote:
> Hello,
>
> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both
> csup'ed around Feb. 10.
>
> Now worked around by turning the RTL8187L off in the BIOS.
>
> %uname -a
> FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11
> 19:39:29 EET 2012
> root at mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK  amd64
>
>
> Below are the panic info and the full dmesg preceding the panic. Please let
> me know if there is anything more I could provide.
>
> [From my quick source code analysis, it looks like the driver fails to
> recognize the device in if_urtw.c, urtw_get_rfchip(), although later
> proceeds with the attach, which seems not quite logical... Correct behavior
> would probably be to not attach at all.]
>
>
> crash info:
> -----------
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x28
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff803eff25
> stack pointer           = 0x28:0xffffff807df08950
> frame pointer           = 0x28:0xffffff807df08980
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 14 (usbus3)
> trap number             = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> kdb_backtrace() at kdb_backtrace+0x37
> panic() at panic+0x187
> trap_fatal() at trap_fatal+0x290
> trap_pfault() at trap_pfault+0x201
> trap() at trap+0x3df
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0xffffffff803eff25, rsp = 0xffffff807df08950, rbp =
> 0xffffff807df08980 ---
> ifindex_alloc_locked() at ifindex_alloc_locked+0x25
> if_alloc() at if_alloc+0x71
> urtw_attach() at urtw_attach+0x63e
> device_attach() at device_attach+0x69
> usb_probe_and_attach() at usb_probe_and_attach+0x1f9
> uhub_explore() at uhub_explore+0x4a1
> usb_bus_explore() at usb_bus_explore+0xdc
> usb_process() at usb_process+0xd5
> fork_exit() at fork_exit+0x11f
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff807df08d00, rbp = 0 ---
> Uptime: 9s
> Dumping 441 out of 8179 MB:..4%..11%..22%..33%..44%..51%..62%..73%..84%..91%
>
[..]
> WARNING: VIMAGE (virtualized network stack) is a highly experimental
[..]
> savecore: reboot after panic: page fault
> Feb 10 22:33:21 mkushnir savecore: reboot after panic: page fault
> savecore: writing core to vmcore.7

Something tells me that the problem may lie in VIMAGE.

Can you issue the following command: kgdb -n 7
then in gdb menu run this command: bt
to resolve source lines.

[ anticipating hte response, I will try to lookup if_alloc+0x71
for my system built around the same date (w/o vimage though):
0xffffffff80698211 is in if_alloc (/usr/src/sys/net/if.c:283).
278     retry:
279             /*
280              * Try to find an empty slot below V_if_index.  If we
fail, take the
281              * next slot.
282              */
283             for (idx = 1; idx <= V_if_index; idx++) {
284                     if (V_ifindex_table[idx].ife_ifnet == NULL)
285                             break;
286             }
287
]

-- 
wbr,
pluknet