Andrzej, setting "notsc" makes the difference (yesterday I forgot to start lilo after modifying /etc/lilo.conf to include notsc"). Now it work even with -kernel-kqemu. Not fully tested though, but much better than before.
Thanks, Werner andrzej zaborowski wrote: > Hi, > > On 17/04/07, Werner Dittmann <[EMAIL PROTECTED]> wrote: >> andrzej zaborowski wrote: >> > Hi, >> > >> > On 16/04/07, Werner Dittmann <[EMAIL PROTECTED]> wrote: >> >> During several tests with Qemu / Kqemu it seems that Qemu >> >> has problems with x86_64 host systems. My system is an >> >> AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. >> >> >> Indeed it is a dual CPU. Adding notsc as an additional parameter to >> the kernel commandline (the guest system uses Lilo). Using this >> parameter the kernel was able to start INIT and the init.d startup >> scripts (not always, but most of the time). After a short time >> the kernel starts to loop again, e.g. during hotplug handling. > > Hmm, I was thinking that it may be the same problem as I described in > http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html but > if the lockup is happening anyway then I'm not sure. On the other hand > "notsc" does make a difference, right? > >> >> Using th same technique as before (gdb) it's the same picture: >> mainly in compute_c_subl or compute_c_addl. >> >> > >> > Does your host happen to be dual-core? If so, please try adding >> > "notsc" to the guest kernel commandline and report if it makes a >> > difference. >> > >> >> >> I thought qemu's gdb server is used to debug kernels running >> inside Qemu but not to debug Qemu itself. IMHO the problem is not >> in the kernel (the kernel works perfectly on a real HW processor) >> but in Qemu. > > That's right, qemu's gdb server is for debugging the guest. However, > it's often much easier to debug qemu knowing what guest code is > causing the qemu bug, especially C code in case of opensource guests, > and especially a guest lockup or guest crash. > > Other than that I think there's only the -d. > > Regards, > Andrzej > > >