Slackware 64bit 14.1 (RC) kernel 3.10.16 and VirtualBox
1 Attachment(s)
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. |
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.
|
Quote:
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.
|
Quote:
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. |
1 Attachment(s)
Quote:
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. |
Quote:
Code:
# CONFIG_X86_INTEL_PSTATE is not set Code:
-> Power management and ACPI options |
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) Code:
intel_pstate=disable |
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.
|
Quote:
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. |
Quote:
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.
|
I can confirm this happens with VirtualBox 4.3.2 as well. But the intel_pstate=disable workaround does work !
|
Quote:
|
I just tried installing slackware64-current-install-dvd.iso (03-Nov-2013 20:19 RC3) version on XenServer 6.2.0 -- it installed with no issues and/or modifications.
|
Can't seem to get it with work around...
I passed huge.s root=/dev/sda1 rdinit=ro intel_pstate=disable , still panics :) |
Quote:
|
Quote:
|
Hmm, well I was able to boot , tried to trick virtualbox - I went and added the following to lilo.conf
Code:
# Append any additional kernel parameters: |
Quote:
|
Quote:
|
Quote:
|
I don't know if I would call this solved. I followed the suggestions and settings here and I still get the kernel panic.
In my case I'm running a VM on Windows for routing purposes only. So I simply installed the huge 3.2.29 kernel from Slackware 14.0 and left the rest of the 14.1 upgrade as is. It's working fine for SSH and routing so I'm not going to burn anymore time on it. |
<deleted this post>
|
Seems to be fixed in VirtualBox 4.3.6
|
I hereby confirm that the intel_pstate problem is resolved with VB 4.3.6 r91406.
:D |
Thank you dr.s, burdi01, I also confirm with VB 4.3.6 r91406.
|
Quote:
Here's the full list of the modifications: https://www.virtualbox.org/wiki/Changelog |
All times are GMT -5. The time now is 01:06 AM. |