Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 23/02/2012 04:19 Doug Barton said the following: This gives much better results. :) I can kldload the module, and get this on the command line: vboxdrv: fAsync=0 offMin=0x3596 offMax=0xa897 Thank you for reporting and testing! -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 23/02/2012 08:26 Cy Schubert said the following: In message 4f457ae8.4090...@freebsd.org, Andriy Gapon writes: on 22/02/2012 12:48 Doug Barton said the following: On 02/22/2012 02:23, Andriy Gapon wrote: The attached patched should try to grab the memory harder. Same result, different memory address: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12 OK, now that, thanks to more testers, I realize that this issue is entirely i386-specific, I think that I might have been barking at the wrong trees. Now something very i386-ish to try to deal with the problem - the usual patch file is attached. The patch tests out OK on 8.2 and 9.0. No panic. Fedora 16 runs nicely under vbox. Thank you for testing! -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 22/02/2012 05:40 Doug Barton said the following: On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 Yeah, I kind of expected something like this, because the original panic was in a memory allocation failure path. As to why the memory allocation fails I have no immediate insights. Maybe you genuinely don't have enough contiguous pages below 4GB boundary... Perhaps you can add a printf in src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c right after the vm_phys_alloc_contig() call to examine/validate its input parameters and return value. and although kldstat shows the module as loaded, and the control panel starts, when I try to launch a vm I get this: It's a long standing general FreeBSD issue that there is a disconnect between module loading and module initialization errors. Kernel driver not installed (rc=-1908) Make sure the kernel module has been loaded successfully. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/22/2012 01:20, Andriy Gapon wrote: on 22/02/2012 05:40 Doug Barton said the following: On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 Yeah, I kind of expected something like this, because the original panic was in a memory allocation failure path. As to why the memory allocation fails I have no immediate insights. Maybe you genuinely don't have enough contiguous pages below 4GB boundary... It's i386, no PAE, so you could be on to something. I do have more than 4G in the box though: real memory = 6442450944 (6144 MB) avail memory = 3148255232 (3002 MB) Meanwhile, the 4.0 version worked on this same system ... Perhaps you can add a printf in src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c right after the vm_phys_alloc_contig() call to examine/validate its input parameters and return value. patch? I am sort of short on time atm. Either way, thanks again for looking into it. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 22.02.2012 10:26, Doug Barton wrote: On 02/22/2012 01:20, Andriy Gapon wrote: on 22/02/2012 05:40 Doug Barton said the following: On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 Yeah, I kind of expected something like this, because the original panic was in a memory allocation failure path. As to why the memory allocation fails I have no immediate insights. Maybe you genuinely don't have enough contiguous pages below 4GB boundary... It's i386, no PAE, so you could be on to something. I do have more than 4G in the box though: real memory = 6442450944 (6144 MB) avail memory = 3148255232 (3002 MB) Meanwhile, the 4.0 version worked on this same system ... The 4.0.16 version is still available as emulators/virtualbox-ose-legacy and doesn't include the memobj r0 patch so it should still work. (you will need to switch to devel/kBuild for that) -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/22/2012 01:41, Bernhard Froehlich wrote: The 4.0.16 version is still available as emulators/virtualbox-ose-legacy I know, that, but kind of beside the point, right? -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 22.02.2012 10:46, Doug Barton wrote: On 02/22/2012 01:41, Bernhard Froehlich wrote: The 4.0.16 version is still available as emulators/virtualbox-ose-legacy I know, that, but kind of beside the point, right? Yes, but some people depend on a working virtualbox and that is their safety net until the problem is sorted out. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 22/02/2012 11:26 Doug Barton said the following:
Meanwhile, the 4.0 version worked on this same system ...
The attached patched should try to grab the memory harder.
--
Andriy Gapon
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig 2011-12-19
15:01:31.0 +0200
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2012-02-22
12:21:05.833875547 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (c) 2007 knut st. osmundsen bird-src-s...@anduin.net
+ * Copyright (c) 2011 Andriy Gapon a...@freebsd.org
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
@@ -54,23 +55,8 @@
/** The core structure. */
RTR0MEMOBJINTERNAL Core;
/** Type dependent data */
-union
-{
-/** Non physical memory allocations */
-struct
-{
-/** The VM object associated with the allocation. */
-vm_object_t pObject;
-} NonPhys;
-/** Physical memory allocations */
-struct
-{
-/** Number of pages */
-uint32_tcPages;
-/** Array of pages - variable */
-vm_page_t apPages[1];
-} Phys;
-} u;
+/** The VM object associated with the allocation. */
+vm_object_t pObject;
} RTR0MEMOBJFREEBSD, *PRTR0MEMOBJFREEBSD;
@@ -125,25 +111,14 @@
switch (pMemFreeBSD-Core.enmType)
{
-case RTR0MEMOBJTYPE_CONT:
-contigfree(pMemFreeBSD-Core.pv, pMemFreeBSD-Core.cb, M_IPRTMOBJ);
-break;
-
case RTR0MEMOBJTYPE_PAGE:
+case RTR0MEMOBJTYPE_LOW:
+case RTR0MEMOBJTYPE_CONT:
{
rc = vm_map_remove(kernel_map,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
AssertMsg(rc == KERN_SUCCESS, (%#x, rc));
-
-vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
-{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
-vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
-}
-vm_page_unlock_queues();
break;
}
@@ -165,8 +140,8 @@
case RTR0MEMOBJTYPE_RES_VIRT:
{
vm_map_t pMap = kernel_map;
-if (pMemFreeBSD-Core.u.Lock.R0Process != NIL_RTR0PROCESS)
-pMap = ((struct proc
*)pMemFreeBSD-Core.u.Lock.R0Process)-p_vmspace-vm_map;
+if (pMemFreeBSD-Core.u.ResVirt.R0Process != NIL_RTR0PROCESS)
+pMap = ((struct proc
*)pMemFreeBSD-Core.u.ResVirt.R0Process)-p_vmspace-vm_map;
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -180,7 +155,6 @@
if (pMemFreeBSD-Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
pMap = ((struct proc
*)pMemFreeBSD-Core.u.Mapping.R0Process)-p_vmspace-vm_map;
-
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -191,26 +165,21 @@
case RTR0MEMOBJTYPE_PHYS:
case RTR0MEMOBJTYPE_PHYS_NC:
{
+VM_OBJECT_LOCK(pMemFreeBSD-pObject);
+vm_page_t pPage = vm_page_find_least(pMemFreeBSD-pObject, 0);
vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
+for (vm_page_t pPage = vm_page_find_least(pMemFreeBSD-pObject, 0);
+ pPage != NULL;
+ pPage = vm_page_next(pPage))
{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
}
vm_page_unlock_queues();
+VM_OBJECT_UNLOCK(pMemFreeBSD-pObject);
+vm_object_deallocate(pMemFreeBSD-pObject);
break;
}
-#ifdef USE_KMEM_ALLOC_ATTR
-case RTR0MEMOBJTYPE_LOW:
-{
-kmem_free(kernel_map, (vm_offset_t)pMemFreeBSD-Core.pv,
pMemFreeBSD-Core.cb);
-break;
-}
-#else
-case RTR0MEMOBJTYPE_LOW: /* unused */
-#endif
default:
AssertMsgFailed((enmType=%d\n, pMemFreeBSD-Core.enmType));
return VERR_INTERNAL_ERROR;
@@ -220,183 +189,183 @@
}
-DECLHIDDEN(int) rtR0MemObjNativeAllocPage(PPRTR0MEMOBJINTERNAL ppMem, size_t
cb, bool fExecutable)
-{
-int rc;
-size_t cPages = cb PAGE_SHIFT;
-
-/* create the object. */
-PRTR0MEMOBJFREEBSD pMemFreeBSD =
(PRTR0MEMOBJFREEBSD)rtR0MemObjNew(RT_OFFSETOF(RTR0MEMOBJFREEBSD,
u.Phys.apPages[cPages]),
-
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/22/2012 02:23, Andriy Gapon wrote: The attached patched should try to grab the memory harder. Same result, different memory address: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12 ... and not sure it's relevant, but both times I've tried loading these modules it has killed my sound. /dev/mixer goes away, and I have to reboot to get it back. This has never happened before, so I'm pretty sure it's connected. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On Wed, 22 Feb 2012, Doug Barton wrote: On 02/22/2012 01:20, Andriy Gapon wrote: on 22/02/2012 05:40 Doug Barton said the following: On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 Yeah, I kind of expected something like this, because the original panic was in a memory allocation failure path. As to why the memory allocation fails I have no immediate insights. Maybe you genuinely don't have enough contiguous pages below 4GB boundary... It's i386, no PAE, so you could be on to something. I do have more than 4G in the box though: real memory = 6442450944 (6144 MB) avail memory = 3148255232 (3002 MB) Same error here on i386 with only 2G memory. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On Wed, 22 Feb 2012, Andriy Gapon wrote: on 22/02/2012 11:26 Doug Barton said the following: Meanwhile, the 4.0 version worked on this same system ... The attached patched should try to grab the memory harder. No visible difference here, sorry. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
In message alpine.bsf.2.00.1202220806270.77...@wonkity.com, Warren Block writ es: On Wed, 22 Feb 2012, Andriy Gapon wrote: on 22/02/2012 11:26 Doug Barton said the following: Meanwhile, the 4.0 version worked on this same system ... The attached patched should try to grab the memory harder. No visible difference here, sorry. Same on my systems (8.2 and 9.0). My main server (9.0 dual core AMD X2) panics with a kernel page fault and hangs. My laptop (9.0 Penium-M) and my testbed (8.2 and 9.0 single core AMD X2) panic like my laptop, no messages, just an immediate reboot. (Something does flash up on the screen but it's there for milliseconds. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 22.02.2012 21:07, Cy Schubert wrote: In message alpine.bsf.2.00.1202220806270.77...@wonkity.com, Warren Block writ es: On Wed, 22 Feb 2012, Andriy Gapon wrote: on 22/02/2012 11:26 Doug Barton said the following: Meanwhile, the 4.0 version worked on this same system ... The attached patched should try to grab the memory harder. No visible difference here, sorry. Same on my systems (8.2 and 9.0). My main server (9.0 dual core AMD X2) panics with a kernel page fault and hangs. My laptop (9.0 Penium-M) and my testbed (8.2 and 9.0 single core AMD X2) panic like my laptop, no messages, just an immediate reboot. (Something does flash up on the screen but it's there for milliseconds. We decided to backout the patch until this problem is solved. Commit was done a few minutes ago. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
In message c2d3b2f1ef0b4e345605623702f5b...@bluelife.at, Bernhard Froehlich w rites: On 22.02.2012 21:07, Cy Schubert wrote: In message alpine.bsf.2.00.1202220806270.77...@wonkity.com, Warren Block writ es: On Wed, 22 Feb 2012, Andriy Gapon wrote: on 22/02/2012 11:26 Doug Barton said the following: Meanwhile, the 4.0 version worked on this same system ... The attached patched should try to grab the memory harder. No visible difference here, sorry. Same on my systems (8.2 and 9.0). My main server (9.0 dual core AMD X2) panics with a kernel page fault and hangs. My laptop (9.0 Penium-M) and my testbed (8.2 and 9.0 single core AMD X2) panic like my laptop, no messages, just an immediate reboot. (Something does flash up on the screen but it's there for milliseconds. We decided to backout the patch until this problem is solved. Commit was done a few minutes ago. Thanks. That fixed it. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 22/02/2012 12:48 Doug Barton said the following:
On 02/22/2012 02:23, Andriy Gapon wrote:
The attached patched should try to grab the memory harder.
Same result, different memory address:
supdrvGipCreate: failed to allocate the GIP page. rc=-8
vboxdrv: supdrvInitDevExt failed, rc=-8
module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12
OK, now that, thanks to more testers, I realize that this issue is entirely
i386-specific, I think that I might have been barking at the wrong trees.
Now something very i386-ish to try to deal with the problem - the usual patch
file is attached.
... and not sure it's relevant, but both times I've tried loading these
modules it has killed my sound. /dev/mixer goes away, and I have to
reboot to get it back. This has never happened before, so I'm pretty
sure it's connected.
No ideas whatsoever at this front.
--
Andriy Gapon
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig 2011-12-19
15:01:31.0 +0200
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2012-02-23
01:24:32.111859551 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (c) 2007 knut st. osmundsen bird-src-s...@anduin.net
+ * Copyright (c) 2011 Andriy Gapon a...@freebsd.org
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
@@ -54,23 +55,8 @@
/** The core structure. */
RTR0MEMOBJINTERNAL Core;
/** Type dependent data */
-union
-{
-/** Non physical memory allocations */
-struct
-{
-/** The VM object associated with the allocation. */
-vm_object_t pObject;
-} NonPhys;
-/** Physical memory allocations */
-struct
-{
-/** Number of pages */
-uint32_tcPages;
-/** Array of pages - variable */
-vm_page_t apPages[1];
-} Phys;
-} u;
+/** The VM object associated with the allocation. */
+vm_object_t pObject;
} RTR0MEMOBJFREEBSD, *PRTR0MEMOBJFREEBSD;
@@ -125,25 +111,14 @@
switch (pMemFreeBSD-Core.enmType)
{
-case RTR0MEMOBJTYPE_CONT:
-contigfree(pMemFreeBSD-Core.pv, pMemFreeBSD-Core.cb, M_IPRTMOBJ);
-break;
-
case RTR0MEMOBJTYPE_PAGE:
+case RTR0MEMOBJTYPE_LOW:
+case RTR0MEMOBJTYPE_CONT:
{
rc = vm_map_remove(kernel_map,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
AssertMsg(rc == KERN_SUCCESS, (%#x, rc));
-
-vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
-{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
-vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
-}
-vm_page_unlock_queues();
break;
}
@@ -165,8 +140,8 @@
case RTR0MEMOBJTYPE_RES_VIRT:
{
vm_map_t pMap = kernel_map;
-if (pMemFreeBSD-Core.u.Lock.R0Process != NIL_RTR0PROCESS)
-pMap = ((struct proc
*)pMemFreeBSD-Core.u.Lock.R0Process)-p_vmspace-vm_map;
+if (pMemFreeBSD-Core.u.ResVirt.R0Process != NIL_RTR0PROCESS)
+pMap = ((struct proc
*)pMemFreeBSD-Core.u.ResVirt.R0Process)-p_vmspace-vm_map;
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -180,7 +155,6 @@
if (pMemFreeBSD-Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
pMap = ((struct proc
*)pMemFreeBSD-Core.u.Mapping.R0Process)-p_vmspace-vm_map;
-
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -191,26 +165,21 @@
case RTR0MEMOBJTYPE_PHYS:
case RTR0MEMOBJTYPE_PHYS_NC:
{
+VM_OBJECT_LOCK(pMemFreeBSD-pObject);
+vm_page_t pPage = vm_page_find_least(pMemFreeBSD-pObject, 0);
vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
+for (vm_page_t pPage = vm_page_find_least(pMemFreeBSD-pObject, 0);
+ pPage != NULL;
+ pPage = vm_page_next(pPage))
{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
}
vm_page_unlock_queues();
+VM_OBJECT_UNLOCK(pMemFreeBSD-pObject);
+vm_object_deallocate(pMemFreeBSD-pObject);
break;
}
-#ifdef USE_KMEM_ALLOC_ATTR
-
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
I'll give it a try on my testbed (which runs 9.0 and 8.2 -- my 7 partitions
don't have the ports to test it without taking a lot of time to build
prereqs).. If not tonight (PST) then I'll have some time Saturday evening.
--
Cheers,
Cy Schubert cy.schub...@komquats.com
FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
In message 4f457ae8.4090...@freebsd.org, Andriy Gapon writes:
This is a multi-part message in MIME format.
--080309080104030002060603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
on 22/02/2012 12:48 Doug Barton said the following:
On 02/22/2012 02:23, Andriy Gapon wrote:
The attached patched should try to grab the memory harder.
Same result, different memory address:
supdrvGipCreate: failed to allocate the GIP page. rc=-8
vboxdrv: supdrvInitDevExt failed, rc=-8
module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12
OK, now that, thanks to more testers, I realize that this issue is entirely
i386-specific, I think that I might have been barking at the wrong trees.
Now something very i386-ish to try to deal with the problem - the usual patch
file is attached.
... and not sure it's relevant, but both times I've tried loading these
modules it has killed my sound. /dev/mixer goes away, and I have to
reboot to get it back. This has never happened before, so I'm pretty
sure it's connected.
No ideas whatsoever at this front.
--
Andriy Gapon
--080309080104030002060603
Content-Type: text/plain;
name=patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0=patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig2011-12
-19 15:01:31.0 +0200
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2012-02-23 01:2
4:32.111859551 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (c) 2007 knut st. osmundsen bird-src-s...@anduin.net
+ * Copyright (c) 2011 Andriy Gapon a...@freebsd.org
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
@@ -54,23 +55,8 @@
/** The core structure. */
RTR0MEMOBJINTERNAL Core;
/** Type dependent data */
-union
-{
-/** Non physical memory allocations */
-struct
-{
-/** The VM object associated with the allocation. */
-vm_object_t pObject;
-} NonPhys;
-/** Physical memory allocations */
-struct
-{
-/** Number of pages */
-uint32_tcPages;
-/** Array of pages - variable */
-vm_page_t apPages[1];
-} Phys;
-} u;
+/** The VM object associated with the allocation. */
+vm_object_t pObject;
} RTR0MEMOBJFREEBSD, *PRTR0MEMOBJFREEBSD;
@@ -125,25 +111,14 @@
switch (pMemFreeBSD-Core.enmType)
{
-case RTR0MEMOBJTYPE_CONT:
-contigfree(pMemFreeBSD-Core.pv, pMemFreeBSD-Core.cb, M_IPRTMOB
J);
-break;
-
case RTR0MEMOBJTYPE_PAGE:
+case RTR0MEMOBJTYPE_LOW:
+case RTR0MEMOBJTYPE_CONT:
{
rc = vm_map_remove(kernel_map,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv + pMemFree
BSD-Core.cb);
AssertMsg(rc == KERN_SUCCESS, (%#x, rc));
-
-vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages; iPa
ge++)
-{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
-vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
-}
-vm_page_unlock_queues();
break;
}
@@ -165,8 +140,8 @@
case RTR0MEMOBJTYPE_RES_VIRT:
{
vm_map_t pMap = kernel_map;
-if (pMemFreeBSD-Core.u.Lock.R0Process != NIL_RTR0PROCESS)
-pMap = ((struct proc *)pMemFreeBSD-Core.u.Lock.R0Process)-
p_vmspace-vm_map;
+if (pMemFreeBSD-Core.u.ResVirt.R0Process != NIL_RTR0PROCESS)
+pMap = ((struct proc *)pMemFreeBSD-Core.u.ResVirt.R0Proces
s)-p_vmspace-vm_map;
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv + pMemFreeB
SD-Core.cb);
@@ -180,7 +155,6 @@
if (pMemFreeBSD-Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
pMap = ((struct proc *)pMemFreeBSD-Core.u.Mapping.R0Proces
s)-p_vmspace-vm_map;
-
rc = vm_map_remove(pMap,
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/22/2012 15:31, Andriy Gapon wrote: on 22/02/2012 12:48 Doug Barton said the following: On 02/22/2012 02:23, Andriy Gapon wrote: The attached patched should try to grab the memory harder. Same result, different memory address: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12 OK, now that, thanks to more testers, I realize that this issue is entirely i386-specific, I think that I might have been barking at the wrong trees. Now something very i386-ish to try to deal with the problem - the usual patch file is attached. This gives much better results. :) I can kldload the module, and get this on the command line: vboxdrv: fAsync=0 offMin=0x3596 offMax=0xa897 VirtualBox works, and I can start win xp (my only 32-bit guest). In 4.0 trying to do 'restart' with XP would hang the XP window forever I tried it with 4.1 and it not only hung the XP guest window, it hung my X session. Fortunately I was able to Ctrl-Alt-F1 and kill it from the outside, and didn't have any problems after that. Start/Stop from within XP worked as expected. ... and not sure it's relevant, but both times I've tried loading these modules it has killed my sound. /dev/mixer goes away, and I have to reboot to get it back. This has never happened before, so I'm pretty sure it's connected. No ideas whatsoever at this front. Didn't happen this time, so I'm guessing some sort of memory corruption from the failed module load was wiping out the mixer device. Thanks again, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
In message 4f457ae8.4090...@freebsd.org, Andriy Gapon writes: on 22/02/2012 12:48 Doug Barton said the following: On 02/22/2012 02:23, Andriy Gapon wrote: The attached patched should try to grab the memory harder. Same result, different memory address: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12 OK, now that, thanks to more testers, I realize that this issue is entirely i386-specific, I think that I might have been barking at the wrong trees. Now something very i386-ish to try to deal with the problem - the usual patch file is attached. The patch tests out OK on 8.2 and 9.0. No panic. Fedora 16 runs nicely under vbox. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
Howdy, I had the previous version of virtualbox working just fine on my up-to-date 8-stable i386 system, and upgraded to 4.1.8 today. When I attempt to load vboxdrv it instantly panics my system: panic: vm_object_deallocate: object deallocated too many times: 4 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c08f2883,1,c118de58,1,c7c08e58,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0918c49,1,c091164e,eacfb8ac,1,...) at kdb_backtrace+0x2a panic(c091164e,4,c09112d7,1e9,0,...) at panic+0x117 vm_object_deallocate(c7c08e58,e8ba3000,e8ba5000,0,eacfb918,...) at vm_object_deallocate+0x347 FreeBSDAllocHelper(1,3,0,2000,0,...) at FreeBSDAllocHelper+0x11e rtR0MemObjNativeAllocCont(c6731b20,2000,0,c672a5b2,1,...) at rtR0MemObjNativeAllocCont+0x56 supdrvInitDevExt(c6731ae0,33c,7a,c740b380,c67315e8,...) at supdrvInitDevExt+0xdd VBoxDrvFreeBSDModuleEvent(c740b380,0,0,75,0,...) at VBoxDrvFreeBSDModuleEvent+0x46 module_register_init(c67315e8,0,c08ebecc,e7,0,...) at module_register_init+0xa7 linker_load_module(0,eacfbc34,c08ebecc,3fa,0,...) at linker_load_module+0xa05 kern_kldload(c7bd3580,c62e4800,eacfbc5c,0,c7befac0,...) at kern_kldload+0xca kldload(c7bd3580,eacfbcec,0,c,246,...) at kldload+0x74 syscall(eacfbd28) at syscall+0x270 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d69fb, esp = 0xbfbfe70c, ebp = 0xbfbfebf8 --- KDB: enter: panic Full core.text.2 is at freefall:~dougb/ -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 22/02/2012 00:02 Doug Barton said the following:
Howdy,
I had the previous version of virtualbox working just fine on my
up-to-date 8-stable i386 system, and upgraded to 4.1.8 today. When I
attempt to load vboxdrv it instantly panics my system:
panic: vm_object_deallocate: object deallocated too many times: 4
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c08f2883,1,c118de58,1,c7c08e58,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c0918c49,1,c091164e,eacfb8ac,1,...) at kdb_backtrace+0x2a
panic(c091164e,4,c09112d7,1e9,0,...) at panic+0x117
vm_object_deallocate(c7c08e58,e8ba3000,e8ba5000,0,eacfb918,...) at
vm_object_deallocate+0x347
FreeBSDAllocHelper(1,3,0,2000,0,...) at FreeBSDAllocHelper+0x11e
rtR0MemObjNativeAllocCont(c6731b20,2000,0,c672a5b2,1,...) at
rtR0MemObjNativeAllocCont+0x56
Ah, embarrassing.
Could you please substitute the attached patch file for the corresponding file
in the port and re-test the port?
supdrvInitDevExt(c6731ae0,33c,7a,c740b380,c67315e8,...) at
supdrvInitDevExt+0xdd
VBoxDrvFreeBSDModuleEvent(c740b380,0,0,75,0,...) at
VBoxDrvFreeBSDModuleEvent+0x46
module_register_init(c67315e8,0,c08ebecc,e7,0,...) at
module_register_init+0xa7
linker_load_module(0,eacfbc34,c08ebecc,3fa,0,...) at
linker_load_module+0xa05
kern_kldload(c7bd3580,c62e4800,eacfbc5c,0,c7befac0,...) at kern_kldload+0xca
kldload(c7bd3580,eacfbcec,0,c,246,...) at kldload+0x74
syscall(eacfbd28) at syscall+0x270
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d69fb, esp =
0xbfbfe70c, ebp = 0xbfbfebf8 ---
KDB: enter: panic
Full core.text.2 is at freefall:~dougb/
--
Andriy Gapon
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig 2011-12-19
15:01:31.0 +0200
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2012-02-22
01:48:41.528856970 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (c) 2007 knut st. osmundsen bird-src-s...@anduin.net
+ * Copyright (c) 2011 Andriy Gapon a...@freebsd.org
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
@@ -54,23 +55,8 @@
/** The core structure. */
RTR0MEMOBJINTERNAL Core;
/** Type dependent data */
-union
-{
-/** Non physical memory allocations */
-struct
-{
-/** The VM object associated with the allocation. */
-vm_object_t pObject;
-} NonPhys;
-/** Physical memory allocations */
-struct
-{
-/** Number of pages */
-uint32_tcPages;
-/** Array of pages - variable */
-vm_page_t apPages[1];
-} Phys;
-} u;
+/** The VM object associated with the allocation. */
+vm_object_t pObject;
} RTR0MEMOBJFREEBSD, *PRTR0MEMOBJFREEBSD;
@@ -125,25 +111,14 @@
switch (pMemFreeBSD-Core.enmType)
{
-case RTR0MEMOBJTYPE_CONT:
-contigfree(pMemFreeBSD-Core.pv, pMemFreeBSD-Core.cb, M_IPRTMOBJ);
-break;
-
case RTR0MEMOBJTYPE_PAGE:
+case RTR0MEMOBJTYPE_LOW:
+case RTR0MEMOBJTYPE_CONT:
{
rc = vm_map_remove(kernel_map,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
AssertMsg(rc == KERN_SUCCESS, (%#x, rc));
-
-vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
-{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
-vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
-}
-vm_page_unlock_queues();
break;
}
@@ -165,8 +140,8 @@
case RTR0MEMOBJTYPE_RES_VIRT:
{
vm_map_t pMap = kernel_map;
-if (pMemFreeBSD-Core.u.Lock.R0Process != NIL_RTR0PROCESS)
-pMap = ((struct proc
*)pMemFreeBSD-Core.u.Lock.R0Process)-p_vmspace-vm_map;
+if (pMemFreeBSD-Core.u.ResVirt.R0Process != NIL_RTR0PROCESS)
+pMap = ((struct proc
*)pMemFreeBSD-Core.u.ResVirt.R0Process)-p_vmspace-vm_map;
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -180,7 +155,6 @@
if (pMemFreeBSD-Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
pMap = ((struct proc
*)pMemFreeBSD-Core.u.Mapping.R0Process)-p_vmspace-vm_map;
-
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -191,26 +165,21 @@
case RTR0MEMOBJTYPE_PHYS:
case RTR0MEMOBJTYPE_PHYS_NC:
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 and although kldstat shows the module as loaded, and the control panel starts, when I try to launch a vm I get this: Kernel driver not installed (rc=-1908) Make sure the kernel module has been loaded successfully. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
