[Xen-devel] Re: [regression] Ideapad S10-3 does not wake up from suspend (Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them)

[Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>]

On Sun, 2011-08-28 at 23:15 -0500, Jonathan Nieder wrote:
> Lars Boegild Thomsen writes[1]:
> > After update from 2.6 kernel to 3.0 my Idepad S10-3 will not wake up after 
> > sleep.  Back to latest 2.6 kernel works fine.
> [...]
> > Upon wakeup, the power light go from slow flashing to on, the battery light 
> > goes from off to on, the hdd light blink once and then everything is dead.  
> > Nothing happens on the screen, all keys dead.  The fan/hdd switch on 
> > physically (very hard to hear on this model or I am getting deaf).  
> > Ctrl+alt+del or the alt+sysreq is non-responsive.  The only LED that show 
> > keyboard status is CAPS lock and that is unresponsive too.  Only way I have 
> > found to get it rebooted is holding down the power button a few secs until 
> > it 
> > switch physically off and then switch it on again.
> [...]
> > Here's the result of the final bisect:
> >
> > 983bbf1af0664b78689612b247acb514300f62c7 is the first bad commit
> [...]
> > I also tried to go back to HEAD and manually change arch/x86/irq.c revert 
> > this 
> > particular commit and it works.
> 
> For reference:
> 
> > commit 983bbf1af0664b78689612b247acb514300f62c7
> > Author: Tian, Kevin <kevin.tian@xxxxxxxxx>
> > Date:   Fri May 6 14:43:56 2011 +0800
> >
> >    x86: Don't unmask disabled irqs when migrating them
> >
> >    It doesn't make sense to unconditionally unmask a disabled irq when
> >    migrating it from offlined cpu to another. If the irq triggers then it
> >    will be disabled in the interrupt handler anyway. So we can just avoid
> >    unmasking it.
> > 
> >    [ tglx: Made masking unconditional again and fixed the changelog ]
> > 
> >    Signed-off-by: Fengzhe Zhang <fengzhe.zhang@xxxxxxxxx>
> >    Signed-off-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >    Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> >    Cc: Jan Beulich <JBeulich@xxxxxxxxxx>
> >    Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
> >    Link: 
> > http://lkml.kernel.org/r/%3C625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3%40shsmsx502.ccr.corp.intel.com%3
> >    Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> >
> > diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> > index 544efe2741be..6c0802eb2f7f 100644
> > --- a/arch/x86/kernel/irq.c
> > +++ b/arch/x86/kernel/irq.c
> > @@ -276,7 +276,8 @@ void fixup_irqs(void)
> >             else if (!(warned++))
> >                     set_affinity = 0;
> >  
> > -           if (!irqd_can_move_in_process_context(data) && chip->irq_unmask)
> > +           if (!irqd_can_move_in_process_context(data) &&
> > +               !irqd_irq_disabled(data) && chip->irq_unmask)
> >                     chip->irq_unmask(data);
> >  
> >             raw_spin_unlock(&desc->lock);
> 
> Known problem?  Ideas?
> [1] http://bugs.debian.org/635575

cc'ing Len Brown who tried to fix this, but in different code:

http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4731fdcf6f7bdab3e369a3f844d4ea4d4017284d

I'm seeing the exact same symptoms on my S10-3, fwiw.  They definitely
don't happen when intel_idle is compiled out or when
intel_idle.max_cstate=0 is specified on the kernel command-line.

-- Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel