Steve Thompson
2012-Oct-02 20:12 UTC
Notes on upgrading to xen-4.2.0 and linux-3.6.0 under OpenSuse 12.1
I recently undertook to install xen-4.2.0 and to update the kernel to something resembling the current release. Previously, I had installed xen with the openSUSE package manager, but I had not done much with it, and anyways the kernel version was something like 3.1.10, with various openSUSE patches originating as far back as 2.6.18. Current kernels are reported to support xen without patching. I previously had xen working solidly on a small Thinkpad back in 2009, but the hardware died and other things got in the way of making xen work again. The first serious attempt I made was with kernel version 3.5.4, which seemingly booted ok, however the graphics driver (i915) failed to work properly and the video RAM was not initialized, leaving characteristic random noise all over the root window. FVWM2 started, however on loading the Gnome desktop something killed gnome-settings-daemon and gnome-shell. There also seemed to be problems with gcc. Much as I hate Gnome, it works with my HDTV and switching to a more basic desktop was not what I wanted. That said, LXDE worked. The offending message: [ 61.963639] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 61.963646] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 62.483674] [drm:i915_reset] *ERROR* Failed to reset chip. Networking was AFU; I saw the following in the system logs: [ 80.931659] IPv4: martian source 10.xx.xx.xx from 10.232.60.3, on dev eth0 [ 80.931666] ll header: 00000000: ff ff ff ff ff ff 00 09 6b bf d7 93 08 06 ........k..... [ 81.922691] IPv4: martian source 10.xx.xx.xx from 10.232.60.3, on dev eth0 [ 81.922697] ll header: 00000000: ff ff ff ff ff ff 00 09 6b bf d7 93 08 06 ........k..... which I believe should have been DNS requests from local hosts coming in over ethernet, a "RTL8111/8168B P 106353 CI Express Gigabit Ethernet controller (rev 06)". The same kernel running standalone worked fine, but under xen it was hopeless. On one occasion I noticed that the CPU microcode was not being updated while booting xen dom0. Noting that xen 4.2.0 has the capability of updating the microcode, I thought I could cure the problem by making xen do it. The microcode.dat file supplied with openSUSE lives in /lib/firmware and is a tar archive containing the microcode.dat file presumably obtained from Intel. I found that Xen expects a binary blob, so I quickly wrote a conversion utility, which I have attached to this message. See the README file for instructions. Updating the CPU microcode didn''t help at all, so I set out to try every major kernel version to see if anything worked. I compiled unpatched kernels for 3.4.9, 3.2.30, and 3.1.10 each using the .config generated for 3.5.4 as a starting point. All of these kernels booted as dom0, and standalone, but none of them worked correctly, with earlier kernels locking up solid. 3.4-series kernels worked, however graphics were still a problem. Final attempt was with the just-released 3.6.0 kernel, which also exhibited the same behavior as 3.4-series kernels, however networking worked properly. I decided to try a different video driver, so I added ''intelfb'' to the /etc/sysconfig/kernel and then rebuilt the initrds. I added "video=intelfb" to the kernel parameters in the grub2 menu entry and rebooted. Everything works fine, although I was prepared to fall back to the VESA framebuffer (video=vesafb). This has saved me from attempting to forward-port openSUSE i915 changes in an attempt to resolve video framebuffer issues. Note that the openSUSE installation process selected the i915 driver as suitable for the shipped 3.1.0-1.2 version kernel. So, xen-4.2 with linux-3.6 is a success as dom0. Hardware: HP ProBook 4530s, i3-2230M 2200Mhz, 8G RAM Now the fun begins. I''d like to torture the bastard who wrote the networking scripts to rename interfaces, it is completely unnecessary. There are dynamic interactions with other interfaces if eth0 (sorry, peth0) is is taken down such as the immediate renaming of the wlan interface. This all might work with NetworkManager if it were not for all of this extra complexity. Bridging is dead simple to configure, for example: ifconfig eth0 xx.xx.xx.xx netmask 255.255.255.0 brctl addbr xenbr1 brctl addif xenbr1 eth0 That''s all there is to it. From there, as xen domU instances are created, the virtual network interface can be added to the bridge with the single command "brctl addbr xenbr1 vifxx. Furthermore, there''s a better way to do it. The default kernels don''t tend to include the dummy network devices, which I had used previously with xen and vif-bridge. NetworkManager doesn''t seem to notice the dummy network interfaces, so coexistence might be trivial -- IF the scripts didn''t muck about with renaming network interfaces. It is such a PITA. Even specifying a previously configured bridge on dummy0 in the xl.conf file results in automatic mucking about with eth0. Once I''ve resolved the issues with the xen scripts taking-over the network configuration, I''ll hopefully be able to post instructions on how this can be avoided. Then I''ll be able to see what happens when I start a domU. Regards, Steve Thompson _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users