From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 08:59:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76E7719B for ; Wed, 10 Dec 2014 08:59:10 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F4048E2F for ; Wed, 10 Dec 2014 08:59:09 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jyBy91VJ7zZrn; Wed, 10 Dec 2014 09:58:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1418201935; x=1420016336; bh=tDxIzJgd1ikIeRvfSOFPxGuhYgi4I9+oSJLj+3wvqy4=; b= mcIVXmJHBPtXBgbIgmc1a75b6emVddyxmqjmksSGI0QBKza3EWt4LwMSb6XWg/u0 uAKWS8XZWVaYnsiW3T1sFe8VShEGJvh6kPyFsW4fmqYV5syxLnd1FcLfl/ACJNfE eKL9TD9TUyYKss4ohkjsCM48IffO4NVja31JWGWeMAo= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id Tv9QIRG5FCKn; Wed, 10 Dec 2014 09:58:55 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Wed, 10 Dec 2014 09:58:55 +0100 (CET) Message-ID: <54880B4E.3050902@madpilot.net> Date: Wed, 10 Dec 2014 09:58:54 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: LOR on head using virtualbox between intel kms and sound, with system lockup References: <54877A3D.7010706@madpilot.net> <20141210085245.GD97072@kib.kiev.ua> In-Reply-To: <20141210085245.GD97072@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 08:59:10 -0000 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) @ >> /usr/src/sys/kern/uipc_sockbuf.c:666 >> 2nd 0xfffff80057ff20a0 drmslk (drmslk) @ >> /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@. > 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