qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems


From: Werner Dittmann
Subject: Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Date: Wed, 18 Apr 2007 21:44:04 +0200
User-agent: Thunderbird 1.5.0.10 (X11/20060911)

Andrzej,

just another remark: after setting the kernel parameter to "notsc"
the kernel now detects the CPU correctly. Without this setting the
CPU detetion was wrong (displays the wrong CPU type, frequency, etc).
Are there any know side-effects if notsc (no time stamp counter) is
set?

Regards,
Werner

andrzej zaborowski wrote:
> Hi,
> 
> On 17/04/07, Werner Dittmann <address@hidden> wrote:
>> andrzej zaborowski wrote:
>> > Hi,
>> >
>> > On 16/04/07, Werner Dittmann <address@hidden> 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
> 
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]