Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Dec 2014 12:03:34 +0100
From:      Guido Falsi <mad@madpilot.net>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org, glebius@freebsd.org
Subject:   Re: LOR on head using virtualbox between intel kms and sound, with system lockup
Message-ID:  <548C1D06.9060900@madpilot.net>
In-Reply-To: <20141213102614.GT2148@kib.kiev.ua>
References:  <54877A3D.7010706@madpilot.net> <20141210085245.GD97072@kib.kiev.ua> <54880B4E.3050902@madpilot.net> <548B8490.2010007@madpilot.net> <20141213102614.GT2148@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/13/14 11:26, Konstantin Belousov wrote:
> On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote:
>> On 12/10/14 09:58, Guido Falsi wrote:
>>> On 12/10/14 09:52, Konstantin Belousov wrote:
>>>> On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
>>>>
>> [...]
>>>>> --- 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 ---
>>
>>>> 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!
>>>
>>
>> Quick followup, for any interested party, I isolated the commit in
>> r274712, reverting this one the problem disappears.
>>
>> If anyone has some ideas about this please reply to me or followup in
>> bug 195822 on bugzilla.
> I suspect that the issue is vbox and not the revision itself.
> 

It's quite possible. Just to clarify, I did not mean that commit is
wrong or anything like that. In fact I'm unable to tell not having a
clear understanding of that code.

I just thought this bit of information could help the diagnosis.

> Anyway, your best route is to ask Gleb.
> 

I did. He sad he's taking a look.

-- 
Guido Falsi <mad@madpilot.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?548C1D06.9060900>