Pedro Bulach Gapski a écrit : > We have been trying to better isolate this issue. > > First test was to use taskset to bind the qemu process to a single > CPU, following advice found on qemu mailing lists. This proved > insufficient, as the image locked up during the night. > > Next we tried to run qemu without VNC and tap options. After a few > hours qemu hang and froze X (both keyboard and mouse dead), in a > similar condition to that described in this bug's submission. A remote > ssh connection was used to kill the qemu process, and that released X. > > It seems that the lockups happen during high load on the guest, and > the locked qemu process goes on eating 100% CPU. The problem now seems > fairly straighforward to reproduce. Is a core image usefull? >
A core image or at least a backtrace would indeed be useful. Also if possible could you please try to do that with a few lockups to see if they matches? -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
