Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 06/12/2011 02:08 Alan Cox said the following: The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Ah, but we want to be able to run virtualbox on the past releases too. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 06.12.2011 10:08, Andriy Gapon wrote: on 06/12/2011 02:08 Alan Cox said the following: The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Ah, but we want to be able to run virtualbox on the past releases too. Which releases are we talking about here? VirtualBox was always deprecating older FreeBSD releases much faster than our Security EOL so if we focus on latest 8.x and = 9.0 I think it should be okay. We have already deprecated 7.x because of some other problems with the userland bits so we can forget about 7.x completely. What is left is 8.1 and 8.2 and both are EOL until mid 2012. So if is possible to get it merged in time for 8.3 and 9.1 (if needed) we should be fine. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 06/12/2011 11:40 Bernhard Froehlich said the following: On 06.12.2011 10:08, Andriy Gapon wrote: on 06/12/2011 02:08 Alan Cox said the following: The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Ah, but we want to be able to run virtualbox on the past releases too. Which releases are we talking about here? VirtualBox was always deprecating older FreeBSD releases much faster than our Security EOL so if we focus on latest 8.x and = 9.0 I think it should be okay. We have already deprecated 7.x because of some other problems with the userland bits so we can forget about 7.x completely. What is left is 8.1 and 8.2 and both are EOL until mid 2012. So if is possible to get it merged in time for 8.3 and 9.1 (if needed) we should be fine. So we would just say screw you to people who stick to e.g. 8.2 at the moment? :) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 06.12.2011 12:00, Andriy Gapon wrote: on 06/12/2011 11:40 Bernhard Froehlich said the following: On 06.12.2011 10:08, Andriy Gapon wrote: on 06/12/2011 02:08 Alan Cox said the following: The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Ah, but we want to be able to run virtualbox on the past releases too. Which releases are we talking about here? VirtualBox was always deprecating older FreeBSD releases much faster than our Security EOL so if we focus on latest 8.x and = 9.0 I think it should be okay. We have already deprecated 7.x because of some other problems with the userland bits so we can forget about 7.x completely. What is left is 8.1 and 8.2 and both are EOL until mid 2012. So if is possible to get it merged in time for 8.3 and 9.1 (if needed) we should be fine. So we would just say screw you to people who stick to e.g. 8.2 at the moment? :) No. We currently have the last 2 virtualbox major versions in the ports tree so if we decide to do such an incompatible change we always have the older version around for 8.2 users for about the next year. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 06/12/2011 14:51 Bernhard Froehlich said the following: No. We currently have the last 2 virtualbox major versions in the ports tree so if we decide to do such an incompatible change we always have the older version around for 8.2 users for about the next year. Oh, I missed the fact that we have port versions for virtualbox ports. Sorry for the noise, then. Anyway, in patch I tried to cover different FreeBSD versions. One greater discrepancy between stable/8 and later version is the changes in page locking that have never been MFC-ed. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 02.12.2011 12:55, Bernhard Froehlich wrote: On 01.12.2011 09:37, Bernhard Froehlich wrote: On 01.12.2011 00:07, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Once there is some positive feedback I will commit both patches to the ports tree. Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 05/12/2011 14:57 Bernhard Froehlich said the following: On 02.12.2011 12:55, Bernhard Froehlich wrote: Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that we pass to vm_phys_alloc_contig. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 05.12.2011 14:06, Andriy Gapon wrote: on 05/12/2011 14:57 Bernhard Froehlich said the following: On 02.12.2011 12:55, Bernhard Froehlich wrote: Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that we pass to vm_phys_alloc_contig. What's the difference of this? BTW you reported about the GCC 4.5 header stuff and it was also already fixed: http://lists.freebsd.org/pipermail/freebsd-emulation/2011-December/009312.html -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 05/12/2011 15:15 Bernhard Froehlich said the following: On 05.12.2011 14:06, Andriy Gapon wrote: on 05/12/2011 14:57 Bernhard Froehlich said the following: On 02.12.2011 12:55, Bernhard Froehlich wrote: Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that we pass to vm_phys_alloc_contig. What's the difference of this? Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 BTW you reported about the GCC 4.5 header stuff and it was also already fixed: http://lists.freebsd.org/pipermail/freebsd-emulation/2011-December/009312.html Thank you! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 12/05/2011 07:56, Andriy Gapon wrote: on 05/12/2011 15:15 Bernhard Froehlich said the following: On 05.12.2011 14:06, Andriy Gapon wrote: on 05/12/2011 14:57 Bernhard Froehlich said the following: On 02.12.2011 12:55, Bernhard Froehlich wrote: Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that we pass to vm_phys_alloc_contig. What's the difference of this? Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 05/12/2011 19:58 Alan Cox said the following: On 12/05/2011 07:56, Andriy Gapon wrote: Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set Ah, oops, forgot about this. With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. That's exactly what I was trying to do when I encountered a need for VM_ALLOC_NOOBJ - my object was not NULL. Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a user map (or a few of them) at the same time? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 12/5/2011 4:02 PM, Andriy Gapon wrote: on 05/12/2011 19:58 Alan Cox said the following: On 12/05/2011 07:56, Andriy Gapon wrote: Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set Ah, oops, forgot about this. With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. That's exactly what I was trying to do when I encountered a need for VM_ALLOC_NOOBJ - my object was not NULL. Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a user map (or a few of them) at the same time? Yes, it is. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 06/12/2011 00:22 Alan Cox said the following: On 12/5/2011 4:02 PM, Andriy Gapon wrote: on 05/12/2011 19:58 Alan Cox said the following: On 12/05/2011 07:56, Andriy Gapon wrote: Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set Ah, oops, forgot about this. With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. That's exactly what I was trying to do when I encountered a need for VM_ALLOC_NOOBJ - my object was not NULL. Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a user map (or a few of them) at the same time? Yes, it is. Thank you! And another question - what would you recommend as a substitute for vm_page_alloc_contig in FreeBSD versions that do not have it? All I can think of is essentially replicating kmem_alloc_contig + contigmapping and allowing a user-specified object to be used in place of kernel_object. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 12/5/2011 4:38 PM, Andriy Gapon wrote: on 06/12/2011 00:22 Alan Cox said the following: On 12/5/2011 4:02 PM, Andriy Gapon wrote: on 05/12/2011 19:58 Alan Cox said the following: On 12/05/2011 07:56, Andriy Gapon wrote: Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as page is in transit. Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set Ah, oops, forgot about this. With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. That's exactly what I was trying to do when I encountered a need for VM_ALLOC_NOOBJ - my object was not NULL. Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a user map (or a few of them) at the same time? Yes, it is. Thank you! And another question - what would you recommend as a substitute for vm_page_alloc_contig in FreeBSD versions that do not have it? All I can think of is essentially replicating kmem_alloc_contig + contigmapping and allowing a user-specified object to be used in place of kernel_object. The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 01.12.2011 09:37, Bernhard Froehlich wrote: On 01.12.2011 00:07, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Once there is some positive feedback I will commit both patches to the ports tree. Patch has been send upstream: https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 01/12/2011 00:35, Andriy Gapon wrote: on 01/12/2011 01:27 Jung-uk Kim said the following: On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Yep, me too, obviously :-) Thank you for the complete vm_page_alloc_contig patch! Thanks for the patch. I'll give it a try. OTOH yesterday I was trying to use vm_page_alloc_contig and trying to understand the allocation classes. I was able to panic the system or in the best case VBoxHeadless was getting a sig11. I was planning to ask the mailing list about them, because even I read vm-design article in the doc section there are things I don't yet understand: First question is, if you set NULL for the vm_object_t (and then VM_ALLOC_NOOBJ must be given or the kernel will panic with INVARIANTS set) how this memory is assigned to the VirtualBox process logical space? Second set of related questions are: why should the pages be wired? and why should the VM_ALLOC_INTERRUPT alloc class be given? Third question is: I see in the patch that rtR0MemObjFreeBSDPhysPageInit is not called if the veersion is less that 100, is this because vm_phys_alloc_contig doesn't set the flags on the pages and vm_page_alloc_contig does? Thanks, Gus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 01.12.2011 00:07, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Once there is some positive feedback I will commit both patches to the ports tree. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Thursday 01 December 2011 03:37 am, Bernhard Froehlich wrote: On 01.12.2011 00:07, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-free bsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Yes, as usual. :-) Once there is some positive feedback I will commit both patches to the ports tree. Thanks! Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 01/12/2011 01:27 Jung-uk Kim said the following: On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Yep, me too, obviously :-) Thank you for the complete vm_page_alloc_contig patch! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
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? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On (26/11/2011 14: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. Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
