Custom Query (16363 matches)
Results (1912 - 1914 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #6683 | fixed | existance of render-dev is not checked by configure script. | ||
| Description |
title says it all |
|||
| #2314 | duplicate | excessive syslogging (pgmPoolTracDerefGCPhys) VM halts | ||
| Description |
I've noticed that certain machines seem to freeze, and the syslog gets filled very quickly. I have an AMD Turion 64 bit dual core cpu, but all of my OS's are running i386 (host and all guests). The OS's (or iso's, rather) that display this behavior are the ubuntu-8.04.1-desktop-i386.iso image and some of the recent daily builds of the debian-testing-netinst.iso images. I tried the daily build for 23Sept2008, and that one seems to be ok, but the problem exists in the 16Sept2008 version of the daily build. I'm letting you know this in case you need something to test with, and don't feel like getting the larger ubuntu image. AFAICT, this problem only appears when VT is enabled. I really don't want to go back to disabling VT. Now that I'm used to it, going back makes things seem like they're moving at a snail's pace. Also, why is it that I have to disable VT for all machines, when I only need to disable it for one? It seems that if each machine has an option for using VT, that each one should run according to that setting. I think that if VT has to be enabled/disabled for all machines, then the configuation option should stay with the global preferences, and not be a per machine option. here is a snipped from /var/log/syslog: Sep 23 16:31:07 bard kernel: [15242.263109] !!R0-Assertion Failed!! Sep 23 16:31:07 bard kernel: [15242.263109] Expression: <NULL> Sep 23 16:31:07 bard kernel: [15242.263109] Location : /home/michael/technik/s\ ources/archive/pkg-virtualbox/build-area/virtualbox-ose-1.6.6-dfsg/src/VBox/VMM\ /VMMAll/PGMAllPool.cpp(2738) void pgmPoolTracDerefGCPhys(PGMPOOL*, PGMPOOLPAGE*\ , RTHCPHYS, RTGCPHYS) Sep 23 16:31:07 bard kernel: [15242.263109] Sep 23 16:31:07 bard kernel: [15242.263109] !!R0-Assertion Failed!! Sep 23 16:31:07 bard kernel: [15242.263109] Expression: <NULL> Sep 23 16:31:07 bard kernel: [15242.263109] Location : /home/michael/technik/s\ ources/archive/pkg-virtualbox/build-area/virtualbox-ose-1.6.6-dfsg/src/VBox/VMM\ /VMMAll/PGMAllPool.cpp(2738) void pgmPoolTracDerefGCPhys(PGMPOOL*, PGMPOOLPAGE*\ , RTHCPHYS, RTGCPHYS) Sep 23 16:31:07 bard kernel: [15242.263109] Sep 23 16:31:07 bard kernel: [15242.263109] !!R0-Assertion Failed!! Sep 23 16:31:07 bard kernel: [15242.263109] Expression: <NULL> Sep 23 16:31:07 bard kernel: [15242.263109] Location : /home/michael/technik/s\ ources/archive/pkg-virtualbox/build-area/virtualbox-ose-1.6.6-dfsg/src/VBox/VMM\ /VMMAll/PGMAllPool.cpp(2738) void pgmPoolTracDerefGCPhys(PGMPOOL*, PGMPOOLPAGE*\ , RTHCPHYS, RTGCPHYS) I'm getting about 1900-2000 entries like this per second. This problem doesn't occur consistenly every time the VM is booted, but it occurs probably about 75% of the time, in my experience. At least that's with the ubuntu VM. Running the netinst build from 16Sept2008 will freeze the VM and deluge the syslog every time. |
|||
| #7097 | fixed | excessive memory allocated by VirtualBox on host | ||
| Description |
Host: Ubuntu 10.04, VirtualBox 3.2.6, 16 cores, 32GB 13 guests: single cores, several Linux flavors (RHEL5 clones, Ubuntu, 32 and 64 bit), all running GA 3.2.6 The problem is that the processes on the host are allocating up to 2x more memory than what is specified in the configuration. There is no correlation between the guest OS or 32/64bit. But also it doesn't seem to grow to more than exactly twice the guest size. Below is the "top" line for a machine that has 2GB allocated: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8698 vms 20 0 4349m 4.0g 4.0g S 33 12.8 938:31.41 VBoxHeadless I still have a couple of servers running VB 3.0 and by comparison their memory allocation is very close to what is defined in the guest configuration (RES part of course). And SHR is close to zero there. The worst part is that while the sum of the guests' memory allocations is quite far from the server's physical memory, the processes allocate in fact so much more that they are killed by the kernel with out of memory messages in dmesg... There is nothing funny in the VB logs, but I can attach them if needed. I first noticed this after upgrading to 3.2.6, previous 3.2.x didn't cause any noticeable problems, but I can't guarantee that the problem was not present even then. |
|||

