Hi Ben, On Samstag, 4. Dezember 2010, you wrote: > Module loading is serialised by a lock. Because the 'oops' occurs > during module loading, the locks is never released and no more modules > can be loaded. So we don't need to worry about that - it's just a > symptom of the initial 'oops'. > > The 'oops' itself appears to be due to using ACPI to get CPU > information. This is incorrect behaviour because even for dom0 the CPUs > are virtualised by Xen. This might be the same as bug #603632; please > try the workarounds listed there.
I tried the following combinations without any success: kernel /boot/xen-4.0-i386.gz com1=115200 dom0_mem=1024M numa=noacpi module /boot/vmlinuz-2.6.32-bpo.5-xen-686 root=UUID=cf1e2d0a-1785-478e-a59e-d4f3452be98c ro console=tty0 module /boot/initrd.img-2.6.32-bpo.5-xen-686 kernel /boot/xen-4.0-i386.gz com1=115200 dom0_mem=1024M numa=fake=1 module /boot/vmlinuz-2.6.32-bpo.5-xen-686 root=UUID=cf1e2d0a-1785-478e-a59e-d4f3452be98c ro console=tty0 module /boot/initrd.img-2.6.32-bpo.5-xen-686 > > I also noticed, that with latest bpo kernel the system doesn't reboot ... > > there is just a "restarting system ... " printed but it's not really > > rebooting ... just a hit on the reset button helps. > > I think this is bug #605448. I will keep an eye on this bug. Many thanks, Jan. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012042222.03161.w...@cyconet.org
