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

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

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.

Thanks again!

-- 
Guido Falsi <mad_at_madpilot.net>