All of lore.kernel.org
 help / color / mirror / Atom feed
From: poma <pomidorabelisima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Olaf Hering <olaf-QOLJcTWqO2uzQB+pC5nmwQ@public.gmane.org>,
	Stanislaw Gruszka
	<sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Mailing-List fedora-kernel
	<kernel-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A@public.gmane.org>,
	Josh Boyer <jwboyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Kernel list
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Justin M. Forbes"
	<jforbes-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190()
Date: Tue, 11 Feb 2014 21:44:44 +0100	[thread overview]
Message-ID: <52FA8BBC.5000405@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402111434180.21991-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>

On 11.02.2014 15:25, Thomas Gleixner wrote:
> On Mon, 10 Feb 2014, Thomas Gleixner wrote:
>> On Mon, 10 Feb 2014, poma wrote:
>>
>>> [   83.558551]  [<ffffffff81025b17>] amd_e400_idle+0x87/0x130
>>
>> So this seems to happen only on AMD machines which use that e400 idle
>> mode. I have no idea at the moment whats wrong there. I'll find one of
>> those machines and try to reproduce.
> 
> Found it. Patch below.
> 
> Thanks,
> 
> 	tglx
> ----
> Subject: tick: Clear broadcast pending bit when switching to oneshot
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Tue, 11 Feb 2014 14:35:40 +0100
> 
> AMD systems which use the C1E workaround in the amd_e400_idle routine
> trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU.
> 
> The reason is that the idle routine of those AMD systems switches the
> cpu into forced broadcast mode early on before the newly brought up
> CPU can switch over to high resolution / NOHZ mode. The timer related
> CPU1 bringup looks like this:
> 
>   clockevent_register_device(local_apic);
>   tick_setup(local_apic);
>   ...
>   idle()
> 	tick_broadcast_on_off(FORCE);
> 	tick_broadcast_oneshot_control(ENTER)
> 	  cpumask_set(cpu, broadcast_oneshot_mask);
> 	halt();
> 
> Now the broadcast interrupt on CPU0 sets CPU1 in the
> broadcast_pending_mask and wakes CPU1. So CPU1 continues:
> 
> 	local_apic_timer_interrupt()
> 	   tick_handle_periodic();
> 	   softirq()
> 	     tick_init_highres();
> 	       cpumask_clr(cpu, broadcast_oneshot_mask);
> 	
> 	tick_broadcast_oneshot_control(ENTER)
> 	   WARN_ON(cpumask_test(cpu, broadcast_pending_mask);
> 
> So while we remove CPU1 from the broadcast_oneshot_mask when we switch
> over to highres mode, we do not clear the pending bit, which then
> triggers the warning when we go back to idle.
> 
> The reason why this is only visible on C1E affected AMD systems is
> that the other machines enter the deep sleep states via
> acpi_idle/intel_idle and exit the broadcast mode before executing the
> remote triggered local_apic_timer_interrupt. So the pending bit is
> already cleared when the switch over to highres mode is clearing the
> oneshot mask.
> 
> The solution is simple: Clear the pending bit together with the mask
> bit when we switch over to highres mode.
> 
> Reported-by: poma <pomidorabelisima@gmail.com>
> Cc: stable@vger.kernel.org # 3.10+
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  kernel/time/tick-broadcast.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6/kernel/time/tick-broadcast.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/tick-broadcast.c
> +++ linux-2.6/kernel/time/tick-broadcast.c
> @@ -756,6 +756,7 @@ out:
>  static void tick_broadcast_clear_oneshot(int cpu)
>  {
>  	cpumask_clear_cpu(cpu, tick_broadcast_oneshot_mask);
> +	cpumask_clear_cpu(cpu, tick_broadcast_pending_mask);
>  }
>  
>  static void tick_broadcast_init_next_event(struct cpumask *mask,
> 
> 

Thanks!


poma


_______________________________________________
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

WARNING: multiple messages have this Message-ID (diff)
From: poma <pomidorabelisima@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-pm@vger.kernel.org, Olaf Hering <olaf@aepfle.de>,
	Dave Jones <davej@redhat.com>,
	"Justin M. Forbes" <jforbes@redhat.com>,
	Josh Boyer <jwboyer@redhat.com>,
	Stanislaw Gruszka <sgruszka@redhat.com>,
	Mailing-List fedora-kernel <kernel@lists.fedoraproject.org>
Subject: Re: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190()
Date: Tue, 11 Feb 2014 21:44:44 +0100	[thread overview]
Message-ID: <52FA8BBC.5000405@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402111434180.21991@ionos.tec.linutronix.de>

On 11.02.2014 15:25, Thomas Gleixner wrote:
> On Mon, 10 Feb 2014, Thomas Gleixner wrote:
>> On Mon, 10 Feb 2014, poma wrote:
>>
>>> [   83.558551]  [<ffffffff81025b17>] amd_e400_idle+0x87/0x130
>>
>> So this seems to happen only on AMD machines which use that e400 idle
>> mode. I have no idea at the moment whats wrong there. I'll find one of
>> those machines and try to reproduce.
> 
> Found it. Patch below.
> 
> Thanks,
> 
> 	tglx
> ----
> Subject: tick: Clear broadcast pending bit when switching to oneshot
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Tue, 11 Feb 2014 14:35:40 +0100
> 
> AMD systems which use the C1E workaround in the amd_e400_idle routine
> trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU.
> 
> The reason is that the idle routine of those AMD systems switches the
> cpu into forced broadcast mode early on before the newly brought up
> CPU can switch over to high resolution / NOHZ mode. The timer related
> CPU1 bringup looks like this:
> 
>   clockevent_register_device(local_apic);
>   tick_setup(local_apic);
>   ...
>   idle()
> 	tick_broadcast_on_off(FORCE);
> 	tick_broadcast_oneshot_control(ENTER)
> 	  cpumask_set(cpu, broadcast_oneshot_mask);
> 	halt();
> 
> Now the broadcast interrupt on CPU0 sets CPU1 in the
> broadcast_pending_mask and wakes CPU1. So CPU1 continues:
> 
> 	local_apic_timer_interrupt()
> 	   tick_handle_periodic();
> 	   softirq()
> 	     tick_init_highres();
> 	       cpumask_clr(cpu, broadcast_oneshot_mask);
> 	
> 	tick_broadcast_oneshot_control(ENTER)
> 	   WARN_ON(cpumask_test(cpu, broadcast_pending_mask);
> 
> So while we remove CPU1 from the broadcast_oneshot_mask when we switch
> over to highres mode, we do not clear the pending bit, which then
> triggers the warning when we go back to idle.
> 
> The reason why this is only visible on C1E affected AMD systems is
> that the other machines enter the deep sleep states via
> acpi_idle/intel_idle and exit the broadcast mode before executing the
> remote triggered local_apic_timer_interrupt. So the pending bit is
> already cleared when the switch over to highres mode is clearing the
> oneshot mask.
> 
> The solution is simple: Clear the pending bit together with the mask
> bit when we switch over to highres mode.
> 
> Reported-by: poma <pomidorabelisima@gmail.com>
> Cc: stable@vger.kernel.org # 3.10+
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  kernel/time/tick-broadcast.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6/kernel/time/tick-broadcast.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/tick-broadcast.c
> +++ linux-2.6/kernel/time/tick-broadcast.c
> @@ -756,6 +756,7 @@ out:
>  static void tick_broadcast_clear_oneshot(int cpu)
>  {
>  	cpumask_clear_cpu(cpu, tick_broadcast_oneshot_mask);
> +	cpumask_clear_cpu(cpu, tick_broadcast_pending_mask);
>  }
>  
>  static void tick_broadcast_init_next_event(struct cpumask *mask,
> 
> 

Thanks!


poma



  parent reply	other threads:[~2014-02-11 20:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10  3:42 WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190() poma
2014-02-10 10:06 ` Thomas Gleixner
     [not found]   ` <alpine.DEB.2.02.1402101056260.21991-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2014-02-10 18:59     ` poma
2014-02-10 18:59       ` poma
     [not found]       ` <52F9219B.5020003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-11  8:23         ` Stanislaw Gruszka
2014-02-11  8:23           ` Stanislaw Gruszka
2014-02-11 16:07           ` Thomas Gleixner
     [not found]             ` <alpine.DEB.2.02.1402111702090.21991-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2014-02-11 16:27               ` Stanislaw Gruszka
2014-02-11 16:27                 ` Stanislaw Gruszka
2014-02-11 14:25   ` Thomas Gleixner
     [not found]     ` <alpine.DEB.2.02.1402111434180.21991-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2014-02-11 20:44       ` poma [this message]
2014-02-11 20:44         ` poma
2014-02-13 20:57     ` [tip:timers/urgent] tick: Clear broadcast pending bit when switching to oneshot tip-bot for Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52FA8BBC.5000405@gmail.com \
    --to=pomidorabelisima-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=jforbes-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=jwboyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=kernel-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=olaf-QOLJcTWqO2uzQB+pC5nmwQ@public.gmane.org \
    --cc=sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.