>> There's no attachment in this mail. I can try to help you resolving it
>> if you provide more information.
>
>  Sorry about that, see the attachment please. What kind of information you 
> want
> to know?

If your code is available online I can try it myself, the question is
where is it hosted then.
If not, then link to kernel binary and qemu exec trace would help me to start.

>> > ?..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>> >
>> > which turns out should be function check_timer 
>> > (arch/i386/kernel/io_apic.c). I
>>
>> If it hangs inside QEMU itself then you may try to backport commit
>> 4f61927a41a098d06e642ffdea5fc285dc3a0e6b that fixes
>> infinite loop caused by hpet interrupt probing.
>
>  I don't understand. What "it hangs inside QEMU itself" supposed to mean?

QEMU doesn't execute guest code doing something for itself vs. QEMU
executes guest code in loop checking for something that doesn't
happen.

I'm talking about the first case. They may be distinguished from e.g.
guest debugger connected to QEMU's gdbstub -- in the former case it
cannot break guest execution by ^C.

-- 
Thanks.
-- Max

Reply via email to