[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: