On Thu, May 12, 2016 at 1:06 AM, Lianwei Wang wrote:
> I have come up a patch to make the pm notifier called symmetrically
> and currently being tested. I will send it out after pass the test.
>
> On Fri, May 6, 2016 at 12:18 AM, Thomas Gleixner wrote:
>> On Fri, 6 May 2016, Lianwei Wang wrote:
>
I have come up a patch to make the pm notifier called symmetrically
and currently being tested. I will send it out after pass the test.
On Fri, May 6, 2016 at 12:18 AM, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Lianwei Wang wrote:
>> On Thu, May 5, 2016 at 5:13 AM, Thomas Gleixner wrote:
>> >
On Fri, 6 May 2016, Lianwei Wang wrote:
> On Thu, May 5, 2016 at 5:13 AM, Thomas Gleixner wrote:
> > Can you eventually come up with a coherent explanation of the problem down
> > to
> > the root cause or are we going to play this "move the workaround one step
> > down" game for another 10 rounds
On Thu, May 5, 2016 at 5:13 AM, Thomas Gleixner wrote:
> On Wed, 4 May 2016, Lianwei Wang wrote:
>> In this example, the unbalanced count is caused by the
>> cpu_hotplug_pm_callback pm notifier callback function.
>
> I doubt that.
>
>> We can add a variable to avoid the unbalanced call of cpu_hotp
On Wed, 4 May 2016, Lianwei Wang wrote:
> In this example, the unbalanced count is caused by the
> cpu_hotplug_pm_callback pm notifier callback function.
I doubt that.
> We can add a variable to avoid the unbalanced call of cpu_hotplug_enable
> ,e.g.
> diff --git a/kernel/cpu.c b/kernel/cpu.c
>
On Mon, May 2, 2016 at 1:11 AM, Thomas Gleixner wrote:
> On Fri, 29 Apr 2016, Lianwei Wang wrote:
>> On Thu, Apr 28, 2016 at 5:44 PM, Thomas Gleixner wrote:
>> > Wrong. This is the symptom. The root cause is in #1. Therefor you are
>> > trying
>> > to fix the symptom and not the root cause
>> >
On Fri, 29 Apr 2016, Lianwei Wang wrote:
> On Thu, Apr 28, 2016 at 5:44 PM, Thomas Gleixner wrote:
> > Wrong. This is the symptom. The root cause is in #1. Therefor you are trying
> > to fix the symptom and not the root cause
> >
> I don't understand why you keep saying that the issue is in the pm
On Thu, Apr 28, 2016 at 5:44 PM, Thomas Gleixner wrote:
> On Thu, 28 Apr 2016, Lianwei Wang wrote:
>> On Wed, Apr 27, 2016 at 11:15 PM, Thomas Gleixner wrote:
>> > On Wed, 27 Apr 2016, Lianwei Wang wrote:
>> >> Yes. In our project, there is a kernel driver which register a pm
>> >> notifier. On s
On Thu, 28 Apr 2016, Lianwei Wang wrote:
> On Wed, Apr 27, 2016 at 11:15 PM, Thomas Gleixner wrote:
> > On Wed, 27 Apr 2016, Lianwei Wang wrote:
> >> Yes. In our project, there is a kernel driver which register a pm
> >> notifier. On some conditions this pm notifier will return an error and
> >> a
On Wed, Apr 27, 2016 at 11:15 PM, Thomas Gleixner wrote:
> On Wed, 27 Apr 2016, Lianwei Wang wrote:
>> Yes. In our project, there is a kernel driver which register a pm
>> notifier. On some conditions this pm notifier will return an error and
>> abort the suspend process. The counter will be unbal
On Wed, 27 Apr 2016, Lianwei Wang wrote:
> Yes. In our project, there is a kernel driver which register a pm
> notifier. On some conditions this pm notifier will return an error and
> abort the suspend process. The counter will be unbalanced in case it
> happened.
So what? You wreckaged your drive
On Wed, Apr 27, 2016 at 3:17 AM, Thomas Gleixner wrote:
> On Mon, 25 Apr 2016, Lianwei Wang wrote:
>> On Mon, Apr 25, 2016 at 1:22 AM, Thomas Gleixner wrote:
>> >> Anyway, from a product perspective way, if we don't want to restore
>> >> the unbalanced counter to 0, then maybe a BUG_ON is more re
On Mon, 25 Apr 2016, Lianwei Wang wrote:
> On Mon, Apr 25, 2016 at 1:22 AM, Thomas Gleixner wrote:
> >> Anyway, from a product perspective way, if we don't want to restore
> >> the unbalanced counter to 0, then maybe a BUG_ON is more reasonable
> >> than WARN_ON.
> >
> > Not at all. BUG_ON is the
On Mon, Apr 25, 2016 at 1:22 AM, Thomas Gleixner wrote:
> On Fri, 22 Apr 2016, Lianwei Wang wrote:
>> Any way is Ok for debugging purpose. But think the kernel run on a
>> customer machine, such as PC, Mobile phone or other devices. How we
>> let the customer debug it but not recover it smartly?
>
On Fri, 22 Apr 2016, Lianwei Wang wrote:
> Any way is Ok for debugging purpose. But think the kernel run on a
> customer machine, such as PC, Mobile phone or other devices. How we
> let the customer debug it but not recover it smartly?
There is nothing smart here. Restoring the count is a bandaid
On Fri, Apr 22, 2016 at 9:37 AM, Thomas Gleixner wrote:
> On Fri, 22 Apr 2016, Lianwei Wang wrote:
>
>> On Thu, Apr 21, 2016 at 3:50 AM, Peter Zijlstra wrote:
>> > On Wed, Apr 20, 2016 at 09:56:07PM -0700, Lianwei Wang wrote:
>> >> Currently it just print a warning message but did not
>> >> reset
On Fri, 22 Apr 2016, Lianwei Wang wrote:
> On Thu, Apr 21, 2016 at 3:50 AM, Peter Zijlstra wrote:
> > On Wed, Apr 20, 2016 at 09:56:07PM -0700, Lianwei Wang wrote:
> >> Currently it just print a warning message but did not
> >> reset cpu_hotplug_disabled when the enable/disable is
> >> unbalanced
On Thu, Apr 21, 2016 at 3:50 AM, Peter Zijlstra wrote:
> On Wed, Apr 20, 2016 at 09:56:07PM -0700, Lianwei Wang wrote:
>> Currently it just print a warning message but did not
>> reset cpu_hotplug_disabled when the enable/disable is
>> unbalanced. The unbalanced enable/disable will lead
>> the cpu
On Wed, Apr 20, 2016 at 09:56:07PM -0700, Lianwei Wang wrote:
> Currently it just print a warning message but did not
> reset cpu_hotplug_disabled when the enable/disable is
> unbalanced. The unbalanced enable/disable will lead
> the cpu hotplug work abnormally.
>
> Reset it to 0 when an unablance
Currently it just print a warning message but did not
reset cpu_hotplug_disabled when the enable/disable is
unbalanced. The unbalanced enable/disable will lead
the cpu hotplug work abnormally.
Reset it to 0 when an unablanced enable detected.
Signed-off-by: Lianwei Wang
---
kernel/cpu.c | 21 ++
20 matches
Mail list logo
