Date: Wed, 15 Feb 2012 14:59:30 +0200 From: Markiyan Kushnir <markiyan.kushnir@gmail.com> To: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? Message-ID: <4F3BAC32.2020406@gmail.com> In-Reply-To: <CACvtUJcgDSHz1EGZJnSj8h7cMkaAQ9J_DSyf0-=tyMzQk0J5mA@mail.gmail.com> References: <4F3B745A.4010509@gmail.com> <CAE-mSO%2B-6nUfY8031SbJiY37kNHPWsKArZUWwhUty8pxBo-g5Q@mail.gmail.com> <CACvtUJeW2SKkjfCuMHDFRWZnfVksiXH5hKOnD2udGaUCukEukQ@mail.gmail.com> <CACvtUJduSEF1__55eKdOVBL7A7-KvpqxJ9a=hO7ZQ0NJGuPiag@mail.gmail.com> <CACvtUJcgDSHz1EGZJnSj8h7cMkaAQ9J_DSyf0-=tyMzQk0J5mA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tried the case w/o VIMAGE in the kernel (RTL8187L is on in the BIOS) -- no panic. Also, with the VNET_DEBUG on, got a couple of CURVNET_SET() recursion in the logs: Feb 15 14:08:03 mkushnir kernel: CURVNET_SET() recursion in unp_connect() line 1237, prev in soconnect() Feb 15 14:08:03 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:03 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:03 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:03 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:03 mkushnir kernel: unp_connect() at unp_connect+0x8f2 Feb 15 14:08:03 mkushnir kernel: uipc_connect() at uipc_connect+0x55 Feb 15 14:08:03 mkushnir kernel: soconnect() at soconnect+0x179 Feb 15 14:08:03 mkushnir kernel: kern_connect() at kern_connect+0x12e Feb 15 14:08:03 mkushnir kernel: connect() at connect+0x41 Feb 15 14:08:03 mkushnir kernel: amd64_syscall() at amd64_syscall+0x1f4 Feb 15 14:08:03 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:08:03 mkushnir kernel: --- syscall (98, FreeBSD ELF64, connect), rip = 0x80083bcbc, rsp = 0x7fffffffe888, rbp = 0x39bd --- Feb 15 14:08:04 mkushnir kernel: CURVNET_SET() recursion in soreceive() line 2296, prev in netisr_process_workstream_proto() Feb 15 14:08:04 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:04 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:04 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:04 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:04 mkushnir kernel: soreceive() at soreceive+0xbd Feb 15 14:08:04 mkushnir kernel: clnt_dg_soupcall() at clnt_dg_soupcall+0xa8 Feb 15 14:08:04 mkushnir kernel: sowakeup() at sowakeup+0x69 Feb 15 14:08:04 mkushnir kernel: udp6_append() at udp6_append+0x17b Feb 15 14:08:04 mkushnir kernel: udp6_input() at udp6_input+0x7c5 Feb 15 14:08:04 mkushnir kernel: ip6_input() at ip6_input+0xd0a Feb 15 14:08:04 mkushnir kernel: swi_net() at swi_net+0x1dd Feb 15 14:08:04 mkushnir kernel: intr_event_execute_handlers() at intr_event_execute_handlers+0x104 Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: ithread_loop() at ithread_loop+0x95 Feb 15 14:08:04 mkushnir kernel: fork_exit() at fork_exit+0x11f Feb 15 14:08:04 mkushnir kernel: fork_trampoline() at fork_trampoline+0xe Feb 15 14:08:04 mkushnir kernel: --- trap 0, rip = 0, rsp = 0xffffff800004bd00, rbp = 0 --- Feb 15 14:08:04 mkushnir kernel: CURVNET_SET() recursion in soreceive() line 2296, prev in sosend() Feb 15 14:08:04 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:04 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:04 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:04 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:04 mkushnir kernel: soreceive() at soreceive+0xbd Feb 15 14:08:04 mkushnir kernel: clnt_vc_soupcall() at clnt_vc_soupcall+0xc6 Feb 15 14:08:04 mkushnir kernel: sowakeup() at sowakeup+0x69 Feb 15 14:08:04 mkushnir kernel: uipc_send() at Feb 15 14:08:04 mkushnir kernel: uipc_send+0xca0 Feb 15 14:08:04 mkushnir kernel: sosend_generic() at sosend_generic+0x46c Feb 15 14:08:04 mkushnir kernel: sosend() at sosend+0xe8 Feb 15 14:08:04 mkushnir kernel: soo_write() at soo_write+0x62 Feb 15 14:08:04 mkushnir kernel: dofilewrite() at dofilewrite+0x8b Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: kern_writev() at kern_writev+0x60 Feb 15 14:08:04 mkushnir kernel: write() at write+0x55 Feb 15 14:08:04 mkushnir kernel: amd64_syscall() at fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8a Feb 15 14:08:04 mkushnir kernel: md64_syscall+0x1f4 Feb 15 14:08:04 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: --- syscall (4, FreeBSD ELF64, write), rip = 0x80095faac, rsp = 0x7fffffffc338, rbp = 0x800c63000 --- [...] Feb 15 14:10:00 mkushnir kernel: CURVNET_SET() recursion in tun_destroy() line 256, prev in if_clone_destroyif() Feb 15 14:10:00 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:10:00 mkushnir kernel: Feb 15 14:10:00 mkushnir kernel: KDB: stack backtrace: Feb 15 14:10:01 mkushnir kernel: Feb 15 14:10:01 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:10:01 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:10:01 mkushnir kernel: tun_destroy() at tun_destroy+0x132 Feb 15 14:10:01 mkushnir kernel: ifc_simple_destroy() at ifc_simple_destroy+0x2a Feb 15 14:10:01 mkushnir kernel: if_clone_destroyif() at if_clone_destroyif+0x147 Feb 15 14:10:01 mkushnir kernel: if_clone_destroy() at if_clone_destroy+0x15a Feb 15 14:10:01 mkushnir kernel: ifioctl() at ifioctl+0x935 Feb 15 14:10:01 mkushnir kernel: Feb 15 14:10:01 mkushnir kernel: kern_ioctl() at kern_ioctl+0x102 Feb 15 14:10:01 mkushnir kernel: ioctl() at ioctl+0xfd Feb 15 14:10:01 mkushnir kernel: amd64_syscall() at amd64_syscall+0x1f4 Feb 15 14:10:01 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:10:01 mkushnir kernel: --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86a6c, rsp = 0x7fffffffe4a8, rbp = 0x7fffffffef44 --- -- Marikyan. On 15.02.2012 12:40, Markiyan Kushnir wrote: > Any way, I'm still unsure if the urtw's logic of "ignore device > identification failure, and attach" is correct. > > > -- > Markiyan. > > 2012/2/15 Markiyan Kushnir<markiyan.kushnir@gmail.com>: >> looks like that's it ... >> >> -- >> Markiyan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3BAC32.2020406>