Date: Wed, 15 Feb 2012 13:04:23 +0300 From: Sergey Kandaurov <pluknet@gmail.com> To: Markiyan Kushnir <markiyan.kushnir@gmail.com> Cc: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? Message-ID: <CAE-mSO%2B-6nUfY8031SbJiY37kNHPWsKArZUWwhUty8pxBo-g5Q@mail.gmail.com> In-Reply-To: <4F3B745A.4010509@gmail.com> References: <4F3B745A.4010509@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 February 2012 13:01, Markiyan Kushnir <markiyan.kushnir@gmail.com> wr=
ote:
> Hello,
>
> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, bot=
h
> 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@mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK =A0amd64
>
>
> Below are the panic info and the full dmesg preceding the panic. Please l=
et
> 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 behavi=
or
> would probably be to not attach at all.]
>
>
> crash info:
> -----------
>
> Fatal trap 12: page fault while in kernel mode
> cpuid =3D 0; apic id =3D 00
> fault virtual address =A0 =3D 0x28
> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not =
present
> instruction pointer =A0 =A0 =3D 0x20:0xffffffff803eff25
> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08950
> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08980
> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1=
b
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,=
def32 0, gran 1
> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0
> current process =A0 =A0 =A0 =A0 =3D 14 (usbus3)
> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12
> panic: page fault
> cpuid =3D 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 =3D 0xffffffff803eff25, rsp =3D 0xffffff807df08950, rbp=
=3D
> 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 =3D 0, rsp =3D 0xffffff807df08d00, rbp =3D 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 =3D 1; idx <=3D V_if_index; idx++) {
284 if (V_ifindex_table[idx].ife_ifnet =3D=3D NULL)
285 break;
286 }
287
]
--=20
wbr,
pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSO%2B-6nUfY8031SbJiY37kNHPWsKArZUWwhUty8pxBo-g5Q>