Bug#602109: Acknowledgement ([linux-2.6] 1 multicall(s) failed: cpu 0)
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.
Reply to: