Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

2 views
Skip to first unread message

Andriy Gapon

unread,
Nov 26, 2011, 7:44:15 AM11/26/11
to Gustau Pérez, FreeBSD current, freebsd-...@freebsd.org, Michael Butler
on 26/11/2011 14:19 Gustau P�rez said the following:
>
> Starting Virtualbox in the console in headless mode allows to see what happens
> and get a dump of the panic.
>
> The messages I got were not the cause problem. The panic I was able to get
> shows this:
>
> http://pastebin.com/dHnB3Xh0
>
> I can't get any further with core although I compiled virtualbox-ose-kmod with
> debug symbols (I used make config to enable them, because I think -DWITH_DEBUG
> does not work because kmk is used in the build process).
>
> Any help will be appreciated.

vm_phys_alloc_contig implementation has been recently changed and now it seems
to require that vm_page_queue_free_mtx is held.

--
Andriy Gapon
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Michael Butler

unread,
Nov 26, 2011, 8:36:58 PM11/26/11
to Gleb Kurtsou, FreeBSD current, freebsd-...@freebsd.org, Gustau Pérez, Andriy Gapon
On 11/26/11 11:33, Gleb Kurtsou wrote:

> On (26/11/2011 14:44), Andriy Gapon wrote:
>> vm_phys_alloc_contig implementation has been recently changed and now it seems
>> to require that vm_page_queue_free_mtx is held.
>
> Using new vm_page_alloc_contig() may be a better option here. Can't help
> with patch, stuck with pre Nov 15 CURRENT myself.

If I understand the change in locking semantics (post SVN r227568?), a
good number of chunks of
src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c need updating to
follow this :-(.

It is now insufficient to hold only the queue lock when calling
vm_page_unwire or vm_page_free (and maybe others). The page itself must
now also be locked,

imb

Andriy Gapon

unread,
Nov 27, 2011, 3:41:18 AM11/27/11
to Michael Butler, freebsd-...@freebsd.org, FreeBSD current
on 27/11/2011 03:36 Michael Butler said the following:

> On 11/26/11 11:33, Gleb Kurtsou wrote:
>> On (26/11/2011 14:44), Andriy Gapon wrote:
>>> vm_phys_alloc_contig implementation has been recently changed and now it seems
>>> to require that vm_page_queue_free_mtx is held.
>>
>> Using new vm_page_alloc_contig() may be a better option here. Can't help
>> with patch, stuck with pre Nov 15 CURRENT myself.
>
> If I understand the change in locking semantics (post SVN r227568?), a good
> number of chunks of src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c need
> updating to follow this :-(.
> It is now insufficient to hold only the queue lock when calling vm_page_unwire
> or vm_page_free (and maybe others). The page itself must now also be locked,

Not "also", but instead. And only for managed pages. For unmanaged pages a
caller doesn't have to acquire anything.
The relevant change in head has happened much much earlier than r227568.

And this is a totally different issue from the vm_phys_alloc_contig issue.
Let's not mix them.

--
Andriy Gapon

Gustau Pérez

unread,
Nov 27, 2011, 6:56:51 AM11/27/11
to Andriy Gapon, gleb.k...@gmail.com, Michael Butler, freebsd-...@freebsd.org, freebsd...@freebsd.org

>>>
>>> Using new vm_page_alloc_contig() may be a better option here. Can't help
>>> with patch, stuck with pre Nov 15 CURRENT myself.
>>

Ok. The third parameter of vm_page_alloc_contig says the caller has
to specify an allocation class. Which one should we use?

Also the vm_object_t and the vm_memattr_t are are beyond my
knowledge. I'm checking Arch Book but I have no clue. Here I'm lost.

> Not "also", but instead. And only for managed pages. For unmanaged pages a
> caller doesn't have to acquire anything.
> The relevant change in head has happened much much earlier than r227568.
>
> And this is a totally different issue from the vm_phys_alloc_contig issue.
> Let's not mix them.
>

I changed the code hold the lock of vm_page_queue_free_mtx. The
machine them panic because of a page not present.

http://pastebin.com/hGHCJqEP

I don't understand why the bt doesn't contain the complete trace of
the vbox kmod. That would give us a complete clue of what is going on.

OTOH this bt makes me think that Gleb's suggestion is correct and
vm_page_alloc_contig would appear to be a better option. However I'm not
sure, what do you think?

Alan Cox

unread,
Nov 27, 2011, 12:09:46 PM11/27/11
to Andriy Gapon, FreeBSD current, freebsd-...@freebsd.org, Gustau Pérez, Michael Butler
On 11/26/2011 06:44, Andriy Gapon wrote:
> on 26/11/2011 14:19 Gustau P�rez said the following:
>> Starting Virtualbox in the console in headless mode allows to see what happens
>> and get a dump of the panic.
>>
>> The messages I got were not the cause problem. The panic I was able to get
>> shows this:
>>
>> http://pastebin.com/dHnB3Xh0
>>
>> I can't get any further with core although I compiled virtualbox-ose-kmod with
>> debug symbols (I used make config to enable them, because I think -DWITH_DEBUG
>> does not work because kmk is used in the build process).
>>
>> Any help will be appreciated.
> vm_phys_alloc_contig implementation has been recently changed and now it seems
> to require that vm_page_queue_free_mtx is held.
>

vm_page_alloc_contig() should be used instead.

Alan

Reply all
Reply to author
Forward
0 new messages