[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1312021145190.30673@ionos.tec.linutronix.de>
Date: Mon, 2 Dec 2013 11:49:21 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Francis Moreau <francis.moro@...il.com>
cc: Jingoo Han <jg1.han@...sung.com>,
'Wei WANG' <wei_wang@...lsil.com.cn>,
'Samuel Ortiz' <sameo@...ux.intel.com>,
'Chris Ball' <cjb@...top.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
'Borislav Petkov' <bp@...en8.de>,
'LKML' <linux-kernel@...r.kernel.org>
Subject: Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)
On Sat, 30 Nov 2013, Francis Moreau wrote:
> Hello Thomas,
>
> Sorry for the delay.
>
> On 11/29/2013 10:02 AM, Thomas Gleixner wrote:
> > On Fri, 29 Nov 2013, Francis Moreau wrote:
> >> Since it seems to be related to rtsx driver or its upper layer, could
> >> the folks involved in this area have a look to this issue please ?
> >
> > I'm not involved, but looking at the debug objects backtrace it's
> > related to the delayed work in rtsx.
> >
> > Does the untested patch below cure the issue?
> >
>
> It seems it does since I can't see the debug object trace anymore
> however Ican see this now:
<SNIP>
> So I don't think it completely solve the problem but it's a good start.
I kinda expected that, but I wanted to confirm my suspicion, that the
interrupt hits after the delayed work is canceled and just requeues it
again, which then leads to an armed timer being freed further down.
I'm not familiar with that driver and I leave the final fixup to the
driver maintainers. It's enough data for them to figure out the real
solution.
Thanks,
tglx
--
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