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

From: Guido Falsi <mad_at_madpilot.net>
Date: Wed, 10 Dec 2014 09:58:54 +0100
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