On Fri, 2010-12-03 at 18:57 +0100, Jan Wagner wrote: > Hi Ben, > > On Friday, 3. December 2010, Ben Hutchings wrote: > > It is probably filtered out of syslog because it has a low priority > > level. 'dmesg' should show you all the kernel log buffer. > > attached you can find the corresponding part of the modprobes of the sysreq > show state and the part of the boot dmesg where the oops occures. Please > notice, that there is a huge time gap before mounting the swap. That's likely > the part of booting, where i have the troubles ... I have also attached a > screenshot of that part. Like you can see, there is a ^C needed to proceed at > that part. 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 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. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part