[Xen-users] Notes on upgrading to xen-4.2.0 and linux-3.6.0 under OpenSuse 12.1

[Steve Thompson <steve49152@xxxxxxxx>]

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

Attachment: cvt_ucode-20121002.tar.gz
Description: GNU Zip compressed data

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users