On 12/10/14 09:52, Konstantin Belousov wrote: > On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: > >> >> Lock order reversal: (sleepable after non-sleepable) >> 1st 0xfffff8000874da90 so_snd (so_snd) _at_ >> /usr/src/sys/kern/uipc_sockbuf.c:666 >> 2nd 0xfffff80057ff20a0 drmslk (drmslk) _at_ >> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:2317 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe022ed8eff0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022ed8f0a0 >> witness_checkorder() at witness_checkorder+x0dad/frame 0xfffffe022ed8f130 >> _sx_xlock() at _sx_xlock+0x71/frame 0xfffffe022ed8f170 >> intel_pipe_set_base() at intel_pipe_set_base+0x77/frame 0xfffffe022ed8f1d8 >> drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x7c0/frame >> 0xfffffe022ed8f290 >> vt_kms_postswitch() at vt_kms_postswitch+0x5c/frame 0xfffffe022ed8f2c0 >> vt_window_switch() at vt_window_switch+0xc3/frame 0xfffffe022ed8f300 >> vtterm_cngrab() at vtterm_cngrab+0x23/frame 0xfffffe022ed8f320 >> cngrab() at cngrab+0x35/frame 0xfffffe022ed8f340 >> kdb_trap() at kdb_trap+0x183/frame 0xfffffe022ed8f3e0 >> trap_fatal() at ytap_fatal+0x34c/frame 0xfffffe022ed8f440 >> trap_pfault() at trap_pfault+0x262/frame 0xfffffe022ed8f4a0 >> trap() at trap+0x44c/frame 0xfffffe022ed8f5f0 >> calltrap() at calltrap+0x8/frame 0xfffffe022ed8f5f0 >> --- trap 0xc, tip = 0xffffffff8056834d, rsp = 0xfffffe022ed8f6b0, rbp = >> 0xfffffe022ed8f6e0 --- >> sbappendstream_locked() at sbappendstream_locked+0x2d/frame >> 0xfffffe022ed8f6e0 >> sbappendstream() at sbappendstream+0x3c/frame 0xfffffe022ed8f710 >> tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfffffe022ed8f790 >> sosend_generic() at sosend_generic+0x40b/frame 0xfffffe022ed8f850 >> kern_sendit() at kern_sendit+0x19e/frame 0xfffffe022ed8f900 >> sendit() at sendit+0x129/frame 0xfffffe022ed8f950 >> sys_sendto() at sys_sendto+0x4d/frame 0xfffffe022ed8f9a0 >> amd64_syscall() at amd64_syscall+0x211/frame 0xfffffe022ed8fab0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022ed8fab0 >> --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = >> 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- >> >> Please note that this is the last one, but at least another one, almost >> identical to this one, was scrolled up. I've been unable to recover >> their data, since, as I said the system is hard locked and did not even >> write them to any system log. > This is plain fault, in network stack, in the tcp send path. It has > nothing to do with sound at all, and the LOR between DRM device lock and > send buffer socket lock is a consequence of drm activated when panic > occured in the locked region. > > That said, first thing to do when you experience panic with vbox or fuse > modules loaded, is to remove the modules and see if it happens still. > If it is persistent, contact net_at_. > I see. Problem with removing the virtualbox module is I have been able to trigger the panic only by starting the VBox VM. I have no idea how to trigger it some other way. I'll try though. Thanks for the insight! -- Guido Falsi <mad_at_madpilot.net>Received on Wed Dec 10 2014 - 07:59:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC