Fedora 14 freezes up.

[Perryg]

And both of those are completely new. can they be a problem? Sure they can. Is it inherent to VirtualBox? IMHO I don't think so. Read bugtracker and you will see that Fedora on metal is having the exact same problems. I know that the new xorg that Fedora (and others) switched to caused a major headache on both native and virtual. I also read the new kernel that Fedora is using is causing them problems, again on native and virtual.

[WBryan]

Did you have the cores active when you installed? Or did you add them after the fact?
I always install with what it is I intend to use. Probably why I don't see the issues other do.

The way I see it changing things after the install is exactly the same as what would happen if you changed something on metal. While it may be possible to go down in processor count easily, going up is just a problem waiting to happen.

It being a fairly slow day... and I'm really curious... I'm going to test out this hypothesis. I'm hoping for the best.

Thanks again for your comments and responses with this.

[WBryan]

It being a fairly slow day... and I'm really curious... I'm going to test out this hypothesis. I'm hoping for the best.

No dice. Same freeze occurred a couple hours after I left for the vacation weekend. For reference (for later posts, perhaps), I'm running with (uname -a):

Code: Select all

Linux fed14 2.6.35.6-48.fc14.i686 #1 SMP Fri Oct 22 15:34:36 UTC 2010 i686 i686 i386 GNU/Linux

[natron]

I don't think it has anything to do with the number of processors enabled during the initial install. I recently updated Vbox in preparation for an install of Fedora. I am a fan of Ubuntu, but I wanted to install Fedora to prepare for an upcoming internship. I have a Ubuntu 10.10 guest that worked perfectly until the latest update to version 3.2. My new Fedora install is also seizing randomly.

I have also tried the new version 4 of Vbox with no luck (actually version 4 is worse for me as it hangs almost immediately and the log files are not appended to show me what happened). I am having the same issue with Fedora (13, 14 and 14-64bit). From the log files it appears to be a problem accessing the hard disks, but trying different controllers has not helped. I have also tried various iterations with and without nested paging, processor numbers, AHCI caching... No real change.

Again, I have not changed any BIOS settings or changed anything other than my version of VBox. It used to work, now it doesn't. I'm not sure what hardware controller was changed or corrupted (pretty sure is HDD though).

My situation is the same as several other posts. Plenty of RAM and processing power for my VM settings. The host OS appears totally unaffected.

Windows 7 Pro 64, Q6700

[natron]

BTW Fedora 14 x86 is very happy running with no VT-x.

Not sure how this jives with the hdd access errors. Like I said before, VT-x was working fine with Ubuntu 10.10 in previous versions of Vbox.

I have an XP Pro guest that is using VT-x in Vbox 4.0 without a problem.

[Peter-42]

Hi,

Had similar problems with SuSE 11.3. For SMP, the TSC or ACPI virtualization seems to have issues. For me worked switching the kernel's clock source from TSC to jiffies: Edit /boot/grub/menu.lst and add 'clocksource=jiffies' to the kernel line.

--., peter

[natron]

So far so good!

Thanks so much for the tip!! I wonder if this was default in earlier Vbox editions and therefore no problems. From my superficial understanding from reading about jiffles, it seems the underling timing problems caused by multi-core processors should be the norm, not the exception and therefore a unified counter would be required.

[bogdan4521]

Hi
'clocksource=jiffies' solves the problem for me.
Thanks.

[xaoslaad]

You probably don't need this since that's working but I had this problem and found a post that suggested noapictimer and this also seems to do the trick nicely.

[che5ari]

Thanks for this tip. This has saved me from a lot of digging around.

With clocksource=jiffies, my Fedora 14 gues is rock solid.

Thanks.

[WBryan]

Wow. Using

Code: Select all

  clocksource=jiffies

in the kernel command line of the VB client, my fedora 14 install has been up for an entire day (using 8 processors). I had tried turning off nested paging, with no luck.

If this keeps up, I'll mod my original post with the solution.

Thanks.

[wotan]

FWIW, I have had nagging issues since coming back to VBOX with my guests locking (I documented this as far back as the Betas). This is using Sabayon (and also I was able to recreate it on Ubuntu, but I don't use Ubuntu so I haven't kept that guest). I am trying this fix now and seeing if there is a difference.

By locking, I mean time comes to a standstill, but I can still interact to a limited extent with the guest before it completely dies and I have to reset.

[WBryan]

My lockups were strange. I could still open windows, but they would just be blank windows... as if they were waiting for something to happen.

I could also switch to different virtual desktops. In doing so.. I noticed my clock app behaving strangely. Normally, when this occurs, it's stopped. But when switching desktops, it would go back a few seconds and start up again... just to stop at the same point in time.

The clock issue seemed right in line with the fix mentioned in this thread.

I hope this info is helpful.

[wotan]

When the lockups would happen while I was in virtual terminals, I could go to F12 (in Sabayon, at least, syslog and dmesg are echoed there) I could actually see that certain events would show up a few seconds earlier than the final entry before it froze.

Unfortunately, we had a minor crisis at work and I wasnt able to test today.

[dkeefe3773]

Well, I'm one more that can confirm the placement of clocksource=jiffies at the end of the kernel line in /boot/grub/menu.1st solved all my problems. I was 'this close' to uninstalling VB and just going to a dual boot solution, so I'm happy (ecstatic even) that I found this thread. I've been running solidly now for about 15 hours. Before the fix I averaged about an hour or so.

My symptoms were that my USB keyboard would become unresponsive in terminal windows but still operable in open applications, like a web browser or text editor. However, even in open applications, key repeats (where you hold down a key) stopped working. The mouse was still responsive. I have a four core machine and set up VB to work with four cores before guest OS installation.

These symptoms are quite similar to what people experience with PowerManagement issues, especially because it seemed highly correlated with idle time, so I went down that path first, to no avail. Anyway. thanks to whomever figured this out! This solution is far from obvious.

Interestingly, after a cursory google search, it seems this was a problem in Fedora 10 just running natively. It was a bug report that, it seems, was never resolved during 10's lifespan but wasn't a problem in the next release. I wonder if people running Fedora14 natively are having these issues?