I've seen in Patrick's ChangeLog that he uses VirtualBox for testing and appreciates feedback for that VM.

I just now upgraded my 14.0 VirtualBox to 14.1 (RC) via -current. All went without any mishap until boot time. The kernel from both kernel-generic-3.10.16-x86_64-2.txz and kernel-huge-3.10.16-x86_64-2.txz both GPF with the fault at intel_pstate_init.

Being fairly familiar with VirtualBox (I'm using the newly-release 4.3.0 r89960) and building custom kernels, I was able to resolve it by using a kernel config that I use for 3.10.16 on my Linux from Scratch platforms. Likewise, the older as-shipped 3.2.45 kernel from 14.0 works fine on 14.1 (RC).

Here's a screenshot of the panic. Meanwhile I'm going to twiddle the knobs in the as-shipped 3.10.16 kernel config to see if I can identify the cause. My primary intent with this posting (since I do have a perfectly running new Slackware with my custom kernel) is to determine if anyone else encounters this problem with VBOX-4.3.0 and the 64-bit Slackware build of the 3.10.16 kernel.

Attached Thumbnails

 

I can confirm there are problems using VirtualBox 4.3.0 and Slackware64 3.10.16 kernels (both huge and generic). Using VirtualBox 4.2.18 allows Slackware to work again.

Aha! Thanks -- so evidently Slackware's kernel is the victim and not the culprit.

OTHO since my custom kernel works flawlessly, there's not a compelling need for me to roll back to the prior VBOX version. So to satisfy my curiosity, I'll further explore the kernel config to find what triggers the panic. FWIW, my host for the VBOX system is
ASUSTeK COMPUTER INC. P8Z77-V LX (Quad-Core Hyper-Threaded Intel(R) Core(TM) i7-3770K @ 3.50GHz).

I've had no problems of any kind running VirtualBox-4.3.0 with -current and the stock 3.10.16 kernel.

1). Is your guest Slackware platform 64bit?

2). What's the CPU type shown on the guest?

On mine, per dmesg, it shows:

smpboot: CPU0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz (fam: 06, model: 3a, stepping: 09)

The kernel panic message seems to suggest that it's the Intel cpufreq P-states driver not getting along with VirtualBox, I had the same RIP: intel_pstate_init message.

My host is a MacBook Pro 2011 8.3 (I think it's i7-2720QM 2.2GHz, quad-core + hyperthreading, sandy bridge).

It's also been reported here several times that VirtualBox has been having issues with some Linux distributions in various ways.

I'd recommend using an alternative VM until this situation is remedied by Oracle, if that ever happens. Qemu and VMWare are good proper alternatives.

At the risk of a vi/emacs holy war, I really like VirtualBox since the source is available. I have 18 (count 'em...18) different guests systems -- Fedora19, GentooAMD64, NetBSD, OpenBSD, Solaris, Ubuntu and a laundry list of others (including four variants of LFS) hosted on VBOX-4.3.0. The only one producing a kernel fault is the stock Slackware-64-current 3.10.16-2 kernel. Still, I don't blame Slackware since the problem only arose when VBOX-4.3.0 arrived. And, from a practical standpoint, it's a non-issue since my 3.10.16 custom kernel works perfectly.

For me qemu is a close second since I have the source and it affords a great deal of granularity with the dizzying array of command line options. And, thanks to your qemu suggestion, I'll turn my attention to that and it bring me a tad closer to the problem.

The screenshot shows a panic when using 3.10.16 built with the Slackware-supplied "generic-config" on qemu-1.6.1. This time the GPU is with intel_pmu_init as opposed to intel_pstate_init on VBOX. Here's where I'm on the threshold of finding the buried treasure.

When qemu is invoked with either -cpu host or -cpu SandyBridge, the panic happens. Omitting that cpu flag specification allows the generic 3.10.16 to boot cleanly. I'm now in the process of iterating through the various CPU emulators to nail down which ones panic. And meanwhile, I'm still going to fiddle with the stock generic kernel config settings to identity which lead to the panic.

Attached Thumbnails

 

And that's precisely what led to the remedy. Using Patrick's default 64-bit "generic" configuration for kernel 3.10.16, it was just a matter of turning this parameter off:

That setting is found here in make menuconfig:

The result is that both VirtualBox-4.3.0 and qemu-1.6.1 (using -cpu SandyBridge) now boot without error using the stock kernel with the one modification.

I guess that virtual implementations of Intel's pstate don't work very well yet...

I think it's pretty common that virtualizers cannot cleanly emulate all the features of present cpus and so you're forced to select a lower one for emulation.

you can also try booting with the standard kernel but passing this parameter at the lilo boot screen (you can also add it later to /etc/lilo.conf, in the append line - then relaunch lilo)
see /usr/src/linux-*/Documentation/kernel-parameters.txt

2 members found this post helpful.

I am seeing this exact same behavior booting a Slackware64 14.1 RC2 iso guest in Virtualbox 4.3 that is also on Slackware64 14.1 RC2 host machine.

Thanks...I don't know how I missed that boot time flag. I guess I was too busy grepping Google instead of the docs and/or source.

And now here's the verdict on the three VMs I have handy using kernel-huge-3.10.17-x86_64-2, unaltered from Pat's build:

1). VMware-Player-6.0.0-1295980.x86_64 - boots with or without that flag.

2). VirtualBox-4.3.0-89960-Linux_amd64 - requires that flag or else the panic cited initially in this thread.

3). QEMU emulator version 1.6.1

a). -cpu SandyBridge or -cpu host (since I have a SandyBridge), that flag is required or else a panic.

b). -cpu Haswell - boots with or without that flag.

BTW, and veering off topic, I was toying with the idea of advancing to a Haswell for my actual working platform, but my reading of numerous sites indicates that there's little bang for the buck afforded to we desktop users. So being able to emulate it is good enough for me.

It's interesting that two of the three VMs can't handle Intel's PSTATE. A cursory check of my 18 (!!!) other Linux distros reveals that Slackware-14.1 (RC), Arch and Fedora-19 are building their kernels with this enabled. Yet, neither Arch nor Fedora-19 fail to boot. I surmise (WAG) that both of them fiddle with the kernel in some way as opposed to using a pristine source.

There are some instances where the generic kernel does have issues, hence why I still use the Huge kernel.

I'm still having issues with VBox mis-detecting peripherals.

Being most accustomed to LFS, my personal preference is to use the huge Slackware kernel only as a last resort if I botch the creation of the initial RAM disk system. I do deviate somewhat from the Slackware custom of using the packaged mkinitrd since I've long used my own script to haul in the kernel modules. Other than the occasional typo during the process that I fail to catch, I've never had a problem with the generic kernel and my custom initramfs whether it be on a virtualized system or the real thing. And I can usually fix it as boot time since my initramfs is chock full of utilities and all drive hardware and filesystem-related modules.

Actually, most of the time, I just roll my own kernel because it's a familiar process. I only use the as-shipped Slackware kernels when Pat pushes out a new one when I run slackpg. Such was the case that triggered my posting of this thread.

And to make the matter clear, both the stock generic and stock huge kernels (3.10.17) boot fine when intel_pstate=disabled for the appropriate VM platform(s).

@ReaperX7: I get the kernel panic described above when booting the Slackware64 14.1 RC2 iso with the default huge kernel in VirtualBox 4.3.