From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Sebastian Parschauer <sebastian.riemer@profitbricks.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org
Subject: Re: cpuidle: Kernel panics with AMD Opteron 6300 entering C2 - clock related
Date: Thu, 18 Jun 2015 15:28:01 +0200 [thread overview]
Message-ID: <5582C761.7070302@linaro.org> (raw)
In-Reply-To: <5582A9C8.8050200@profitbricks.com>
On 06/18/2015 01:21 PM, Sebastian Parschauer wrote:
> On 18.06.2015 12:52, Sebastian Parschauer wrote:
>> On 18.06.2015 11:22, Daniel Lezcano wrote:
>>> On 06/17/2015 12:06 PM, Sebastian Parschauer wrote:
>>>> Hi cpuidle maintainers,
>>>>
>>>> we notice kernel panics with CPUs from the AMD Opteron 6300 series and
>>>> kernel 3.12 when entering C2. In that C-state the clock is shut down but
>>>> the flag CPUIDLE_FLAG_TIMER_STOP isn't set. We use the TSC clock source
>>>> for performance as our servers host KVM VMs. During the panics
>>>> interrupts are enabled again and the timer interrupt corrupts the
>>>> instruction pointer and/or the stack pointer.
>>>>
>>>> Would it help to set the flag CPUIDLE_FLAG_TIMER_STOP for C2?
>>>> Or how to fix this?
>>>
>>> Did you try the flag ? Does it fix it ?
>>
>> Thanks for your reply. Unfortunately we can't roll out new kernels fast
>> (VMs have to be migrated). But we've disabled the C2 state via sysfs for
>> all CPU cores and all servers and had one more kernel panic with the
>> same call trace although C2 was (or should have been) disabled. We use
>> the menu governor and a v3.12.40 kernel.
>>
>> It's strange to me coming into the same code path with state index 2 as
>> parameter again. I think I'll prepare a kernel with some debug messages
>> when transitioning from one state to another and deploy it to a test system.
>>
>> Is there any better method to debug the cpuidle driver?
>>
>> How do you guys test it?
>>
>> Can we provide any missing additional information?
>>
>> Maybe something else corrupts the memory in an interrupt and the cpuidle
>> driver is just the one noticing an unrelated problem.
>
> Sorry, I had a closer look at the most recent crash again. It happened
> at entering C1 with disabled C2. So maybe our problem is not cpuidle
> related.
As mentioned in the previous email, disabling the idle state index 2 in
the kernel does not prevent the firmware to auto-promote to this state.
By the way, I am not sure this is really the C2 state but the idle state
index 2. Could you give the C state name you have in the sysfs directory ?
--
<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
next prev parent reply other threads:[~2015-06-18 13:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 10:06 cpuidle: Kernel panics with AMD Opteron 6300 entering C2 - clock related Sebastian Parschauer
2015-06-18 9:22 ` Daniel Lezcano
2015-06-18 10:52 ` Sebastian Parschauer
2015-06-18 11:21 ` Sebastian Parschauer
2015-06-18 13:28 ` Daniel Lezcano [this message]
2015-06-18 14:09 ` Sebastian Parschauer
2015-06-18 13:23 ` Daniel Lezcano
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=5582C761.7070302@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sebastian.riemer@profitbricks.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.