virtualbox.org

Hi I'm new to virtualbox and an issue i have been trying to solve is multiple distros freezing, arch,fedora and aptosid it usually happens within the first hour or so i have tried nohz=off nolapic highres=off all to no avail today I have been up - 20:50:20 up 8:07, 2 users, load average: 1.30, 1.26, 1.03 I disabled cpu scaling on the host which is debian squeeze and previous issues with sound breaking up is also almost 100% improved. So I guess my point is, is there some kind of issue with cpu scaling and virtualbox. My VB version is 4.0.0beta4 All guest addition logs are perfect on all machines. Also checking interrups show cpu 0 handling all of them. This is a dual core turion tl-60. with 2gig of ram. And this VB is from the oracle site not from my repos along with the GA's. Thanks for your thoughts ,in advance.

Hi,

My VB version is 4.0.0beta4

4.0.0 was released on 22 Dec, please update and see if the pronlem persists

Still freezing Hard lock unable to do anything. Arch with kde ,aptosid with kde all using multi processor with 3d enabled. Unable to do any real work. One core taking all cpu interrupts, and maxing out host core. Now I guess my question is.. Is VB ready for production type work or am I beta testing? I have been working several weeks with this and still the same issues. So Im willing to bet this is not on my end. I would like to hear from some other Arch users to see if this is a common issue. And BTW im now using 4.0.0 and again guest addition logs are perfect.

Still freezing Hard lock unable to do anything. Arch with kde ,aptosid with kde all using multi processor with 3d enabled. Unable to do any real work.

post a failing guests VBox.log (as attachment)

Now I guess my question is.. Is VB ready for production type work or am I beta testing?

the last version digit .0 implies there has been no maintenance fix yet. For production use consider using ver. 3.2 maintenance release 12 => http://www.virtualbox.org/wiki/Download_Old_Builds_3_2 ... or wait until next bugfix release 4.0.2

OTOH 4.0.0 works for me on a Debian Squeeze host, but there is a lot of different hardware and OS around so you never know ...

sorry will send as attachment

http://pastebin.com/Bxq9i6Sq

the 2.6.32-trunk your host is running was IIRC the first 2.6.32 available in Debian repositories, and IIRC i had some minor problems so i stayed with 2.6.30 in those days

anyway, there have been some transitions in Squeeze since then and i guess the VBox package may have been built against a more recent level of Squeeze than the one you are running... please update your host first

Yeah still freezes user@debian:~$ uname -a
Linux debian 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux. Just hangs with 100% host cpu useage unable to replicate. It either hangs after 30 minutes or 8 hours. I will wait for this to be corrected in a future release. Its plain for me to see that I will be unable to correct this issue and VB is no where near ready for my needs.

Code: Select all

00:00:00.915   NumCPUs         <integer> = 0x0000000000000002 (2)
...
00:00:00.918 Logical host processors: 2 present, 2 max, 2 online, online mask: 0000000000000003

giving 2 CPUs to the guest on a 2 core host IMHO is calling for trouble: sometimes the host has work to do for itself and this may be while the guest is running full load, i guess one of the guest CPU threads then may get locked

Posting this from Ubuntu 10.10 using both cores Amd-v, compiz checking cat /proc/interrupts shows BOTH cores handling interrupts. Unlike Arch and fedora which only shows cpu 0 taking all interrupts and eventually freezing.

particleman wrote:... checking cat /proc/interrupts shows BOTH cores handling interrupts. Unlike Arch and fedora ...

AFAIK that depends on how the guest kernel was compiled, VBox has no correlation to this.

again: giving 2 CPUs (remember this are simply 2 threads in the host context) to one guest on a 2 core host is calling for trouble, the guest may see a "CPU" hang when the host itself has load and thus SMP code in the guest kernel may be confused. Looks like the distributed interrupts Ubuntu guest kernel is more robust...