RELENG_8 panic caused by urtw?
Markiyan Kushnir
markiyan.kushnir at gmail.com
Wed Feb 15 10:34:11 UTC 2012
Here it is:
(kgdb) bt
#0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263
#1 0xffffffff8036da50 in boot (howto=260) at
/usr/RELENG_8/src/sys/kern/kern_shutdown.c:441
#2 0xffffffff8036def1 in panic (fmt=Variable "fmt" is not available.
) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:614
#3 0xffffffff80567240 in trap_fatal (frame=0xc, eva=Variable "eva" is
not available.
) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:825
#4 0xffffffff80567591 in trap_pfault (frame=0xffffff807dd4b8a0,
usermode=0) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:741
#5 0xffffffff80567a4f in trap (frame=0xffffff807dd4b8a0) at
/usr/RELENG_8/src/sys/amd64/amd64/trap.c:478
#6 0xffffffff8054e584 in calltrap () at
/usr/RELENG_8/src/sys/amd64/amd64/exception.S:228
#7 0xffffffff804237f5 in ifindex_alloc_locked
(idxp=0xffffff807dd4b99e) at /usr/RELENG_8/src/sys/net/if.c:285
#8 0xffffffff804286e1 in if_alloc (type=71 'G') at
/usr/RELENG_8/src/sys/net/if.c:453
#9 0xffffffff81e2f07e in urtw_attach (dev=Variable "dev" is not available.
) at /usr/RELENG_8/src/sys/modules/usb/urtw/../../../dev/usb/wlan/if_urtw.c:856
#10 0xffffffff8039aef9 in device_attach (dev=0xffffff0016fca600) at
device_if.h:178
#11 0xffffffff80272649 in usb_probe_and_attach
(udev=0xffffff0016e3c800, iface_index=Variable "iface_index" is not
available.
) at /usr/RELENG_8/src/sys/dev/usb/usb_device.c:1195
#12 0xffffffff8027aaa1 in uhub_explore (udev=0xffffff0016d98000) at
/usr/RELENG_8/src/sys/dev/usb/usb_hub.c:269
#13 0xffffffff802653ec in usb_bus_explore (pm=Variable "pm" is not available.
) at /usr/RELENG_8/src/sys/dev/usb/controller/usb_controller.c:349
#14 0xffffffff8027ead5 in usb_process (arg=Variable "arg" is not available.
) at /usr/RELENG_8/src/sys/dev/usb/usb_process.c:174
#15 0xffffffff803413af in fork_exit (callout=0xffffffff8027ea00
<usb_process>, arg=0xffffff80003f7db0, frame=0xffffff807dd4bc50) at
/usr/RELENG_8/src/sys/kern/kern_fork.c:876
#16 0xffffffff8054eace in fork_trampoline () at
/usr/RELENG_8/src/sys/amd64/amd64/exception.S:602
#17 0x0000000000000000 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000001 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000000000 in ?? ()
#39 0x0000000000000000 in ?? ()
#40 0x0000000000000000 in ?? ()
#41 0xffffffff808287e8 in sleepq_chains ()
#42 0xffffff0002904cf0 in ?? ()
#43 0x0000000000000000 in ?? ()
#44 0xffffff00029048c0 in ?? ()
#45 0xffffff807dd4b730 in ?? ()
#46 0xffffff807dd4b6d8 in ?? ()
#47 0xffffff000252e000 in ?? ()
#48 0xffffffff80394462 in sched_switch (td=0xffffffff8027ea00,
newtd=0xffffff80003f7db0, flags=dwarf2_read_address: Corrupted DWARF
expression.
) at /usr/RELENG_8/src/sys/kern/sched_ule.c:1861
Previous frame inner to this frame (corrupt stack?)
(kgdb)
2012/2/15 Sergey Kandaurov <pluknet at gmail.com>:
> 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
More information about the freebsd-stable
mailing list