FS#33061 - x86_64 does not boot under Xen with vcpus greater than 1
Attached to Project:
Arch Linux
Opened by Daniel Shub (daniel_shub) - Wednesday, 12 December 2012, 10:30 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 15 December 2012, 19:47 GMT
Opened by Daniel Shub (daniel_shub) - Wednesday, 12 December 2012, 10:30 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 15 December 2012, 19:47 GMT
|
Details
Description:
The Arch cd iso installer does not load the x86_64 system when trying to create a Xen HVM domU when the vcpus is greater than 1. I cannot copy the error, but it basically says: Cannot get hvm parameter 18: -22! BUG: scheduling while atomic: swapper/1/0/0x000000002 bad: scheduling from the idle thread! I described the problem on the forum and someone else has experienced the same problem: https://bbs.archlinux.org/viewtopic.php?pid=1205074#p1205074 Additional info: * package version(s) * config and/or log files etc. I am using the 2012.12.01 cd iso, and my dom0 is running 64-bit Debian Squeeze, Xen version 4.0, and Linux Kernel 2.6.32. I am using an Intel i7 processor. Steps to reproduce: Create a Xen dom0. Create an HVM domU with the following configuration file kernel = '/usr/lib/xen-4.1/boot/hvmloader' builder = 'hvm' memory = '2048' device_model='/usr/lib/xen-4.1/bin/qemu-dm' name = 'arch' boot='cd' vcpus=2 disk = [ 'phy:/dev/vm/arch-root,hda,w', 'file:/images/archlinux-2012.12.01-dual.iso,hdc:cdrom,w', ] Click on the x86_64 installer from the iso. Everything works if vcpus is equal to 1. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 15 December 2012, 19:47 GMT
Reason for closing: Upstream
Additional comments about closing: Upstream problem with Xen (and perhaps less likely, linux itself).
Saturday, 15 December 2012, 19:47 GMT
Reason for closing: Upstream
Additional comments about closing: Upstream problem with Xen (and perhaps less likely, linux itself).
Daniel, please report the bug upstream to the Xen developers: http://wiki.xen.org/wiki/ReportingBugs
Thanks for reporting.
So far, Arch is the only OS i encountered that exposes this problem. All other distro's i've tried so far (successfully), have had kerenels <= 3.5,
and usually their own set of patches.
I suggest giving a vanilla 3.6 kernel a try, if that runs fine, then it is at least related to Arch patches, if not, then it is an upstream kernel and/or xen problem.
Note that passing 'debug' on the kernel command line also fixes the problem (kernel boots fine then with 8 vcpus)
Ok, sure. Let's take a look at what Arch patches 3.6 with:
- https://projects.archlinux.org/svntogit/packages.git/tree/trunk/change-default-console-loglevel.patch?h=packages/linux&id=69cf4b896ee185945c1365c59405637ad4f1f3b4
A Kconfig change. Has zero structural effect on the resulting binary.
- https://projects.archlinux.org/svntogit/packages.git/tree/trunk/fat-3.6.x.patch?h=packages/linux&id=69cf4b896ee185945c1365c59405637ad4f1f3b4
Relegated to the vfat module. No effect on the kernel. Currently sitting in linus-next for the 3.8 merge window.
- https://projects.archlinux.org/svntogit/packages.git/tree/trunk/irq_cfg_pointer-3.6.6.patch?h=packages/linux&id=69cf4b896ee185945c1365c59405637ad4f1f3b4
Backport from Linus' tree.
- https://projects.archlinux.org/svntogit/packages.git/tree/trunk/module-init-wait-3.6.patch?h=packages/linux&id=69cf4b896ee185945c1365c59405637ad4f1f3b4
Backport from Linus' tree.
- https://projects.archlinux.org/svntogit/packages.git/tree/trunk/module-symbol-waiting-3.6.patch?h=packages/linux&id=69cf4b896ee185945c1365c59405637ad4f1f3b4
Backport from Linus' tree.
Again, there is nothing for Arch to fix.