After upgrade to kernel 2.6.32.32.38 ubuntu don't start in Xenserver

[Victor Hugo dos Santos]

Today I installed tun the auto-upgrade in my systems and after the upgrade of kernel linux-generic-pae 2.6.32.32.38 I restarted the server and the server don't start again !!! :-(

this server is a guest in a virtual server with XenServer 5.6 FP1 and this error already reported in this direction:
http://forums.citrix.com/thread.jspa?messageID=1558603#1558603

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-generic-pae 2.6.32.32.38
Regression: Yes
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.32-31.61-generic-pae 2.6.32.32+drm33.14
Uname: Linux 2.6.32-31-generic-pae i686
AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory
AplayDevices: Error: [Errno 2] No such file or directory
Architecture: i386
ArecordDevices: Error: [Errno 2] No such file or directory
CurrentDmesg: [ 546.039375] JBD: barrier-based sync failed on xvdb1-8 - disabling barriers
Date: Wed Jun 1 15:11:03 2011
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1:
ProcCmdLine: root=UUID=951d4eda-2677-47a8-82d3-8a48eba9fcc0 ro console=hvc0 splash quiet -- quiet console=hvc0 partman/default_filesystem=ext3
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcModules:
 xenfs 4812 1 - Live 0xeda68000
 xen_netfront 14919 0 - Live 0xeda22000
 lp 7028 0 - Live 0xeda27000
 parport 32635 1 lp, Live 0xeda72000
 xen_blkfront 8991 5 - Live 0xeda2a000
SourcePackage: linux

[Malcolm Scott (malcscott)]

This is a serious regression.

My testing suggests that this issue affects any guest which is assigned more than 578MB of RAM. (A guest configured in XenCenter with 579MB of RAM exhibits the fault, whereas the same guest reconfigured with 578MB boots fine.)

Victor, can you check whether reducing its RAM allocation allows your guest to boot?

The failure mode is that the guest spins on 100% CPU on the first core, before any kernel messages are printed (even without the "quiet" option).

[Malcolm Scott (malcscott)]

Incidentally, the kernel I'm running is actually linux-image-2.6.32-32-generic-pae 2.6.32-32.62

[Malcolm Scott (malcscott)]

Additionally, this bug only applies to the 32-bit kernel (-generic-pae), not 64-bit (-server).

[sv (linux-party)]

Is this regression could have a link with the regression introduced in Linux Kernel 2.6.32.36 and corrected in 2.6.32.37 ?

See <https://lkml.org/lkml/2011/4/14/605>

[Victor Hugo dos Santos (victorhugops)]

On Tue, Jun 7, 2011 at 2:34 PM, Malcolm Scott <email address hidden> wrote:
> This is a serious regression.
>
> My testing suggests that this issue affects any guest which is assigned
> more than 578MB of RAM.  (A guest configured in XenCenter with 579MB of
> RAM exhibits the fault, whereas the same guest reconfigured with 578MB
> boots fine.)
>
> Victor, can you check whether reducing its RAM allocation allows your
> guest to boot?
>
> The failure mode is that the guest spins on 100% CPU on the first core,
> before any kernel messages are printed (even without the "quiet"
> option).

HI....

I install other VMs to test.. and with 578 or less I don't have problem...
but, after change the memory to 579 or more I can't boot this VMs

thanks

--
--
Victor Hugo dos Santos
Linux Counter #224399

[Malcolm Scott (malcscott)]

Also, this bug is not XenServer-specific; I've reproduced it on Xen 4.0.

[Malcolm Scott (malcscott)]

Reverting "xen: set max_pfn_mapped to the last pfn mapped" (https://patchwork.kernel.org/patch/646251/) fixes this.

[styro (anton-list)]

I've also reproduced this problem on Xen 4.0.1.

Lucid VMs running 2.6.32-31-generic-pae (installed by linux-image-virtual) and earlier work, but stopped booting with the update to 2.6.32-32-generic-pae.

I also downloaded and manually installed 2.6.32-33 from lucid-proposed which (I think) reverted the "xen: set max_pfn_mapped to the last pfn mapped" patch and 2.6.32-33 worked again.

[Malcolm Scott (malcscott)]

This is fixed in 2.6.32-33 as published recently in lucid-security.