lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314752662.6411.26.camel@nimitz>
Date:	Tue, 30 Aug 2011 18:04:22 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Jonathan Nieder <jrnieder@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Kevin Tian <kevin.tian@...el.com>,
	Fengzhe Zhang <fengzhe.zhang@...el.com>, mingo@...hat.com,
	hpa@...or.com, Ian Campbell <Ian.Campbell@...citrix.com>,
	JBeulich@...ell.com, xen-devel@...ts.xensource.com,
	Lars Boegild Thomsen <lth@....dk>,
	Len Brown <len.brown@...el.com>
Subject: 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)

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@...el.com>
> > 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@...el.com>
> >    Signed-off-by: Kevin Tian <kevin.tian@...el.com>
> >    Cc: Ian Campbell <Ian.Campbell@...rix.com>
> >    Cc: Jan Beulich <JBeulich@...ell.com>
> >    Cc: "xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
> >    Link: http://lkml.kernel.org/r/%3C625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3%40shsmsx502.ccr.corp.intel.com%3
> >    Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> >
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ