qemu-ppc
[Top][All Lists]
Advanced

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

Re: Does latest qemu (from git) still works with -M g3beige machine?


From: Laurent Vivier
Subject: Re: Does latest qemu (from git) still works with -M g3beige machine?
Date: Sun, 24 Nov 2019 17:12:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

Le 24/11/2019 à 16:22, Laurent Vivier a écrit :
> Le 23/11/2019 à 20:20, Andrew Randrianasulu a écrit :
>> I tried qemu git (up to commit  2061735ff09f9d5e67c501a96227b470e7de69b1) 
>> and finnix-ppc-110.iso.
>>
>> qemu-system-ppc -cdrom ~/finnix-ppc-110.iso -M g3beige -boot d
>> It doesn't boot past initial bootloader messages. If I use 'debug' kernel it 
>> shows some
>> messages and then freezes.
>>
>> qemu-system-ppc -cdrom ~/finnix-ppc-110.iso -boot d -M mac99,via=pmu-adb
>> works, also with just  -M mac99 
>>
>> Host is 32-bit Slackware distribution, with gcc 5.5.0
>> Any ideas how to debug this?
>>
> 
> I'm able to reproduce it with finix111 on an x86_64 host too.
> 
> If I add "-nographic -serial stdio" I can see more (unhelpful) logs:
>   NMI watchdog: BUG: soft lockup - CPU#0 stuck for 40s! [kworker/u2:0:6]
>   NMI watchdog: BUG: soft lockup - CPU#0 stuck for 41s! [kdevtmpfs:9]
> 
> I'm going to search where is the problem.
> 
> Thanks,
> Laurent
> 

Quick workaround: don't destroy the timer if T1MODE_CONT is set:

diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index aa3bfe1afddd..715d60cf6447 100644
--- a/hw/misc/mos6522.c
+++ b/hw/misc/mos6522.c
@@ -149,7 +149,7 @@ static void mos6522_timer1_update(MOS6522State *s,
MOS6522Timer *ti,
     if (!ti->timer) {
         return;
     }
-    if ((s->ier & T1_INT) == 0 || (s->acr & T1MODE) != T1MODE_CONT) {
+    if ((s->ier & T1_INT) == 0 && (s->acr & T1MODE) != T1MODE_CONT) {
         timer_del(ti->timer);
     } else {
         ti->next_irq_time = get_next_irq_time(s, ti, current_time);

I need to check why we need that whereas the interrupt is disabled (I
think this because we don't update correctly the counter otherwise) and
if we can't find a better solution it doesn't degrade performance.

Thank you for the report!

Thanks,
Laurent



reply via email to

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