public inbox for linux-acpi@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox