All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Alex Shi <alex.shi@intel.com>
Cc: Changlong Xie <changlongx.xie@intel.com>,
	Len Brown <len.brown@intel.com>,
	linux-acpi@vger.kernel.org, lkp@linux.intel.com
Subject: Re: [LKP] Commit ac3ebafa81a makes NHM EX/EP machines hung out since 3.9-rc1
Date: Tue, 26 Mar 2013 22:11:56 +0100	[thread overview]
Message-ID: <51520F1C.8070904@linaro.org> (raw)
In-Reply-To: <5151BD10.3000108@intel.com>

On 03/26/2013 04:21 PM, Alex Shi wrote:
> On 03/13/2013 10:27 AM, Changlong Xie wrote:
>> Hi Len,
>>
>> 	FYI, since 3.9-rc1 our three NHM EP/EX LKP(linux kernel performance) test servers 
>> 	except SNB/IVB/WSM hung up unexpectly. 
>>
> 
> the following draft patch can fix the panic, so it proved we still need the percpu cstate.

Alex,

I don't get the connection between the patch and "we still need the
percpu cstate" ?

Could you give more informations about how to reproduce the problem ?

How many processors has your system ?

Could you provide a small test program to trigger the issue ?

When does it appear ? At boot time ? Under load ? At idle time ? etc ...

What is the result of your investigation which lead you to propose the
patch below ?

Thanks
  -- Daniel

> but look at the struct acpi_processor_cx {
>         u8 valid;
>         u8 type;
>         u32 address;
>         u8 entry_method;
>         u8 index;
>         u32 latency;
>         u8 bm_sts_skip;
>         char desc[ACPI_CX_DESC_LEN];
> };
> 
> I have printed all members except the last one. all of them are same on all cpu.
> It's interesting. 
> 
> 
> -----------
> 
> From 5a4fc23fdf5202f8555a25a03afc4d06ac168032 Mon Sep 17 00:00:00 2001
> From: Alex Shi <alex.shi@intel.com>
> Date: Tue, 26 Mar 2013 22:57:47 +0800
> Subject: [PATCH] acpi: abc
> 
> ---
>  drivers/acpi/processor_idle.c |   16 ++++++++++------
>  1 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index fc95308..61373ab 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -66,7 +66,7 @@ module_param(latency_factor, uint, 0644);
>  
>  static DEFINE_PER_CPU(struct cpuidle_device *, acpi_cpuidle_device);
>  
> -static struct acpi_processor_cx *acpi_cstate[CPUIDLE_STATE_MAX];
> +static DEFINE_PER_CPU (struct acpi_processor_cx *[CPUIDLE_STATE_MAX], acpi_cstate);
>  
>  static int disabled_by_idle_boot_param(void)
>  {
> @@ -722,9 +722,10 @@ static int acpi_idle_enter_c1(struct cpuidle_device *dev,
>  		struct cpuidle_driver *drv, int index)
>  {
>  	struct acpi_processor *pr;
> -	struct acpi_processor_cx *cx = acpi_cstate[index];
> +	struct acpi_processor_cx *cx;
>  
>  	pr = __this_cpu_read(processors);
> + 	cx = per_cpu(acpi_cstate[index], pr->id);
>  
>  	if (unlikely(!pr))
>  		return -EINVAL;
> @@ -745,7 +746,8 @@ static int acpi_idle_enter_c1(struct cpuidle_device *dev,
>   */
>  static int acpi_idle_play_dead(struct cpuidle_device *dev, int index)
>  {
> -	struct acpi_processor_cx *cx = acpi_cstate[index];
> +	struct acpi_processor_cx *cx;
> + 	cx = per_cpu(acpi_cstate[index], dev->cpu);
>  
>  	ACPI_FLUSH_CPU_CACHE();
>  
> @@ -775,9 +777,10 @@ static int acpi_idle_enter_simple(struct cpuidle_device *dev,
>  		struct cpuidle_driver *drv, int index)
>  {
>  	struct acpi_processor *pr;
> -	struct acpi_processor_cx *cx = acpi_cstate[index];
> +	struct acpi_processor_cx *cx;
>  
>  	pr = __this_cpu_read(processors);
> + 	cx = per_cpu(acpi_cstate[index], pr->id);
>  
>  	if (unlikely(!pr))
>  		return -EINVAL;
> @@ -833,9 +836,10 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
>  		struct cpuidle_driver *drv, int index)
>  {
>  	struct acpi_processor *pr;
> -	struct acpi_processor_cx *cx = acpi_cstate[index];
> +	struct acpi_processor_cx *cx;
>  
>  	pr = __this_cpu_read(processors);
> + 	cx = per_cpu(acpi_cstate[index], pr->id);
>  
>  	if (unlikely(!pr))
>  		return -EINVAL;
> @@ -960,7 +964,7 @@ static int acpi_processor_setup_cpuidle_cx(struct acpi_processor *pr,
>  		    !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
>  			continue;
>  #endif
> -		acpi_cstate[count] = cx;
> +		per_cpu(acpi_cstate[count], dev->cpu) = cx;
>  
>  		count++;
>  		if (count == CPUIDLE_STATE_MAX)
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-03-26 21:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130313022759.GA120840@bee>
2013-03-26  1:44 ` Commit ac3ebafa81a makes NHM EX/EP machines hung out since 3.9-rc1 Brown, Len
2013-03-26  2:01   ` Xie, ChanglongX
2013-03-26 15:21 ` [LKP] " Alex Shi
2013-03-26 21:11   ` Daniel Lezcano [this message]
2013-03-27  4:39 ` Alex Shi
2013-03-27 13:11   ` Daniel Lezcano
2013-03-27 13:28     ` Alex Shi
2013-03-27 16:36   ` Yinghai Lu
2013-03-28  0:40     ` Rafael J. Wysocki
2013-03-28  1:02       ` Alex Shi
2013-04-02  0:13         ` Rafael J. Wysocki

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=51520F1C.8070904@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=alex.shi@intel.com \
    --cc=changlongx.xie@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=lkp@linux.intel.com \
    /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.