diff mbox

[for,1.2] qemu-timer: properly arm alarm timer for timers set by device initialization

Message ID 1346686472-23999-1-git-send-email-pbonzini@redhat.com
State New
Headers show

Commit Message

Paolo Bonzini Sept. 3, 2012, 3:34 p.m. UTC
QEMU will hang when fed the following command-line

  qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none

The -net none is important otherwise it seems some events are generated
causing the things to work. When it doesn't work, the guest hangs when
measuring the CPU frequency, after the following line:

  [    0.000000] NR_IRQS:256

Pressing a key on the serial port unblocks it, hinting that the problem
is due to the recent elimination of the 1 second timeout in the main
loop.

The problem is that because init_timer_alarm sets the timer's pending
flag to true, the alarm timer is never armed until after the first time
through the main loop.  Thus the bug started when QEMU started testing
the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
cleanup, 2010-03-10).

But actually, it isn't true at all that a timer is pending when the
alarm timer is created, and the real bug has been latent forever: the
fix is to remove the bogus setting of pending flag.

Reported-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 qemu-timer.c | 3 ---
 1 file modificato, 3 rimozioni(-)

Comments

Jan Kiszka Sept. 3, 2012, 3:43 p.m. UTC | #1
On 2012-09-03 17:34, Paolo Bonzini wrote:
> QEMU will hang when fed the following command-line
> 
>   qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none
> 
> The -net none is important otherwise it seems some events are generated
> causing the things to work. When it doesn't work, the guest hangs when
> measuring the CPU frequency, after the following line:
> 
>   [    0.000000] NR_IRQS:256
> 
> Pressing a key on the serial port unblocks it, hinting that the problem
> is due to the recent elimination of the 1 second timeout in the main
> loop.
> 
> The problem is that because init_timer_alarm sets the timer's pending
> flag to true, the alarm timer is never armed until after the first time
> through the main loop.  Thus the bug started when QEMU started testing
> the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
> cleanup, 2010-03-10).
> 
> But actually, it isn't true at all that a timer is pending when the
> alarm timer is created, and the real bug has been latent forever: the
> fix is to remove the bogus setting of pending flag.
> 
> Reported-by: Aurelien Jarno <aurelien@aurel32.net>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  qemu-timer.c | 3 ---
>  1 file modificato, 3 rimozioni(-)
> 
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 5aea94e..c7a1551 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -759,11 +759,8 @@ int init_timer_alarm(void)
>          goto fail;
>      }
>  
> -    /* first event is at time 0 */
>      atexit(quit_timers);
> -    t->pending = true;
>      alarm_timer = t;
> -
>      return 0;
>  
>  fail:
> 

Funnily, I just create the same problem with my "run timer handlers in
signal handler" patch (*). Same solution there.

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>

Jan


(*) I will go for select-based timers once I have time for the necessary
refactorings.
Aurelien Jarno Sept. 3, 2012, 3:45 p.m. UTC | #2
On Mon, Sep 03, 2012 at 05:34:32PM +0200, Paolo Bonzini wrote:
> QEMU will hang when fed the following command-line
> 
>   qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none
> 
> The -net none is important otherwise it seems some events are generated
> causing the things to work. When it doesn't work, the guest hangs when
> measuring the CPU frequency, after the following line:
> 
>   [    0.000000] NR_IRQS:256
> 
> Pressing a key on the serial port unblocks it, hinting that the problem
> is due to the recent elimination of the 1 second timeout in the main
> loop.
> 
> The problem is that because init_timer_alarm sets the timer's pending
> flag to true, the alarm timer is never armed until after the first time
> through the main loop.  Thus the bug started when QEMU started testing
> the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
> cleanup, 2010-03-10).
> 
> But actually, it isn't true at all that a timer is pending when the
> alarm timer is created, and the real bug has been latent forever: the
> fix is to remove the bogus setting of pending flag.
> 
> Reported-by: Aurelien Jarno <aurelien@aurel32.net>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  qemu-timer.c | 3 ---
>  1 file modificato, 3 rimozioni(-)
> 
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 5aea94e..c7a1551 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -759,11 +759,8 @@ int init_timer_alarm(void)
>          goto fail;
>      }
>  
> -    /* first event is at time 0 */
>      atexit(quit_timers);
> -    t->pending = true;
>      alarm_timer = t;
> -
>      return 0;
>  
>  fail:
>

Thanks a lot that was quite fast!

Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Michael Tokarev Sept. 4, 2012, 7:06 a.m. UTC | #3
On 03.09.2012 19:34, Paolo Bonzini wrote:
> QEMU will hang when fed the following command-line
> 
>   qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none
> 
> The -net none is important otherwise it seems some events are generated
> causing the things to work. When it doesn't work, the guest hangs when
> measuring the CPU frequency, after the following line:
> 
>   [    0.000000] NR_IRQS:256
> 
> Pressing a key on the serial port unblocks it, hinting that the problem
> is due to the recent elimination of the 1 second timeout in the main
> loop.
> 
> The problem is that because init_timer_alarm sets the timer's pending
> flag to true, the alarm timer is never armed until after the first time
> through the main loop.  Thus the bug started when QEMU started testing
> the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
> cleanup, 2010-03-10).
> 
> But actually, it isn't true at all that a timer is pending when the
> alarm timer is created, and the real bug has been latent forever: the
> fix is to remove the bogus setting of pending flag.
> 
> Reported-by: Aurelien Jarno <aurelien@aurel32.net>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  qemu-timer.c | 3 ---
>  1 file modificato, 3 rimozioni(-)
> 
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 5aea94e..c7a1551 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -759,11 +759,8 @@ int init_timer_alarm(void)
>          goto fail;
>      }
>  
> -    /* first event is at time 0 */
>      atexit(quit_timers);
> -    t->pending = true;
>      alarm_timer = t;
> -
>      return 0;
>  
>  fail:

This also fixes the pty-char hang I reported yesterday
in thread "apparently missing yet another notify_event()".

Tested-By: Michael Tokarev <mjt@tls.msk.ru>

This should go to 1.1-stable too, as this problem exists
there, with both -net none and -serial pty being reproducers.
Cc'ing -stable.

Thanks!

/mjt
Aurelien Jarno Sept. 4, 2012, 10:32 a.m. UTC | #4
On Mon, Sep 03, 2012 at 05:34:32PM +0200, Paolo Bonzini wrote:
> QEMU will hang when fed the following command-line
> 
>   qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none
> 
> The -net none is important otherwise it seems some events are generated
> causing the things to work. When it doesn't work, the guest hangs when
> measuring the CPU frequency, after the following line:
> 
>   [    0.000000] NR_IRQS:256
> 
> Pressing a key on the serial port unblocks it, hinting that the problem
> is due to the recent elimination of the 1 second timeout in the main
> loop.
> 
> The problem is that because init_timer_alarm sets the timer's pending
> flag to true, the alarm timer is never armed until after the first time
> through the main loop.  Thus the bug started when QEMU started testing
> the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
> cleanup, 2010-03-10).
> 
> But actually, it isn't true at all that a timer is pending when the
> alarm timer is created, and the real bug has been latent forever: the
> fix is to remove the bogus setting of pending flag.
> 
> Reported-by: Aurelien Jarno <aurelien@aurel32.net>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  qemu-timer.c | 3 ---
>  1 file modificato, 3 rimozioni(-)
> 
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 5aea94e..c7a1551 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -759,11 +759,8 @@ int init_timer_alarm(void)
>          goto fail;
>      }
>  
> -    /* first event is at time 0 */
>      atexit(quit_timers);
> -    t->pending = true;
>      alarm_timer = t;
> -
>      return 0;
>  
>  fail:

Thanks, I have applied it.
diff mbox

Patch

diff --git a/qemu-timer.c b/qemu-timer.c
index 5aea94e..c7a1551 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -759,11 +759,8 @@  int init_timer_alarm(void)
         goto fail;
     }
 
-    /* first event is at time 0 */
     atexit(quit_timers);
-    t->pending = true;
     alarm_timer = t;
-
     return 0;
 
 fail: