Re: LOR on head using virtualbox between intel kms and sound, with system lockup

On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
> Hi,
> 
> I've experienced a  hard lockup on head r275563, amd64.
> 
> The hardware is a laptop with an intel graphics card.
> 
> If any further info is required just ask.
> 
> I had just launched a virtualbox VM with Windows 7, the system locked up
> just after the startup sound was played in the VM, X11 disappeared and
> the system locked hard and a LOR data on screen.
> 
> (I already tested recompiling the virtualbox kmod and the bug shows up
> with and without 3d/2d acceleration enabled in the VM)
> 
> I copied (by hand, so sorry for any typos) the LOR data:
LOR data is not interesting, there is a panic message before it, which
is interesting.

> 
> 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_.

> 
> Anyone can help? should this one be looked into? How can I try to debut
> it more?
> 
> Thanks in advance!
> 
> -- 
> Guido Falsi <mad_at_madpilot.net>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"