From: Samuel Ortiz <sameo@linux.intel.com>
To: Francis Moreau <francis.moro@gmail.com>,
Wei WANG <wei_wang@realsil.com.cn>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jingoo Han <jg1.han@samsung.com>,
"'Wei WANG'" <wei_wang@realsil.com.cn>,
"'Chris Ball'" <cjb@laptop.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"'Borislav Petkov'" <bp@alien8.de>,
"'LKML'" <linux-kernel@vger.kernel.org>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)
Date: Mon, 9 Dec 2013 23:27:58 +0100 [thread overview]
Message-ID: <20131209222758.GC8612@zurbaran> (raw)
In-Reply-To: <52A61B0C.6030305@gmail.com>
Hi Francis,
On Mon, Dec 09, 2013 at 08:33:32PM +0100, Francis Moreau wrote:
> On 12/03/2013 09:14 AM, Francis Moreau wrote:
> > Hello Thomas,
> >
> > On 12/02/2013 12:20 PM, Thomas Gleixner wrote:
> >> On Mon, 2 Dec 2013, Thomas Gleixner wrote:
> >>> 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.
> >>
> >> Just had a quick look and the obvious solution is to disable the
> >> interrupts at the device level _BEFORE_ doing anything else in the
> >> teardown path. Updated patch below. That should avoid the nobody cared
> >> splat on the other irq line.
> >>
> >
> > Yes it does.
> >
> > Now that you did the hard work, I hope driver's maintainer/developper
> > will care about this issue.
> >
>
> Unfortunately he/she doesn't seem to care.
>
> Moreover I've been by this now:
>
> [ 241.003324] INFO: task kworker/u16:4:108 blocked for more than 120
> seconds.
> [ 241.003331] Not tainted 3.12.2-1-ARCH #1
> [ 241.003332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [ 241.003335] kworker/u16:4 D ffff880405bc8000 0 108 2
> 0x00000000
> [ 241.003355] Workqueue: kmemstick memstick_check [memstick]
> [ 241.003358] ffff880405bc3c90 0000000000000046 00000000000144c0
> ffff880405bc3fd8
> [ 241.003362] ffff880405bc3fd8 00000000000144c0 ffff880405bc8000
> ffff880405bc3c68
> [ 241.003366] ffffffff814ef57c ffff880405bc3fd8 0000000000000286
> 0000000000000000
> [ 241.003370] Call Trace:
> [ 241.003380] [<ffffffff814ef57c>] ? schedule_timeout+0x13c/0x290
> [ 241.003385] [<ffffffff8106f590>] ? detach_if_pending+0x120/0x120
> [ 241.003388] [<ffffffff8106f590>] ? detach_if_pending+0x120/0x120
> [ 241.003392] [<ffffffff814f2e79>] schedule+0x29/0x70
> [ 241.003396] [<ffffffff814ef659>] schedule_timeout+0x219/0x290
> [ 241.003401] [<ffffffff8129a4d1>] ? vsnprintf+0x1e1/0x680
> [ 241.003405] [<ffffffff814f2213>] wait_for_common+0xd3/0x180
> [ 241.003411] [<ffffffff81095100>] ? wake_up_process+0x40/0x40
> [ 241.003414] [<ffffffff814f22dd>] wait_for_completion+0x1d/0x20
> [ 241.003419] [<ffffffffa061334a>] memstick_set_rw_addr+0x4a/0x50
> [memstick]
> [ 241.003424] [<ffffffffa061388e>] memstick_check+0x10e/0x370 [memstick]
> [ 241.003429] [<ffffffff8107daf7>] process_one_work+0x167/0x450
> [ 241.003432] [<ffffffff8107e501>] worker_thread+0x121/0x3a0
> [ 241.003436] [<ffffffff8107e3e0>] ? manage_workers.isra.23+0x2b0/0x2b0
> [ 241.003441] [<ffffffff81084e90>] kthread+0xc0/0xd0
> [ 241.003446] [<ffffffff81084dd0>] ? kthread_create_on_node+0x120/0x120
> [ 241.003450] [<ffffffff814fc33c>] ret_from_fork+0x7c/0xb0
> [ 241.003454] [<ffffffff81084dd0>] ? kthread_create_on_node+0x120/0x120
>
> looks like a different issue.
Indeed. I assume you don't see issue that on the resume path ?
Wei, is that something you've ever seen with the rtsx memstick driver ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2013-12-09 22:28 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-17 9:42 3.12: kernel panic when resuming from suspend to RAM (x86_64) Francis Moreau
2013-11-17 13:25 ` Borislav Petkov
2013-11-17 15:50 ` Francis Moreau
2013-11-17 16:01 ` Borislav Petkov
2013-11-17 18:02 ` Francis Moreau
2013-11-17 19:53 ` Borislav Petkov
2013-11-17 20:49 ` Francis Moreau
2013-11-17 22:06 ` Borislav Petkov
2013-11-17 22:34 ` Rafael J. Wysocki
2013-11-17 22:46 ` Borislav Petkov
2013-11-18 12:21 ` Francis Moreau
2013-11-18 12:20 ` Francis Moreau
2013-11-18 0:33 ` Kevin Easton
2013-11-18 1:04 ` Borislav Petkov
2013-11-18 2:43 ` Kevin Easton
2013-11-18 12:19 ` Francis Moreau
2013-11-18 13:32 ` Borislav Petkov
2013-11-19 10:01 ` Francis Moreau
2013-11-19 10:15 ` Borislav Petkov
2013-11-20 9:45 ` Francis Moreau
2013-11-20 11:15 ` Borislav Petkov
2013-11-21 8:22 ` Francis Moreau
2013-11-21 10:12 ` Borislav Petkov
2013-11-21 11:17 ` Jingoo Han
2013-11-21 13:07 ` Francis Moreau
2013-11-22 7:43 ` Francis Moreau
2013-11-22 9:57 ` Francis Moreau
2013-11-22 12:54 ` Rafael J. Wysocki
2013-11-22 21:36 ` Francis Moreau
2013-11-22 22:08 ` Rafael J. Wysocki
2013-11-22 22:27 ` Thomas Gleixner
2013-11-24 9:39 ` Francis Moreau
2013-11-24 13:31 ` Borislav Petkov
2013-11-24 21:06 ` Rafael J. Wysocki
2013-11-25 7:42 ` Francis Moreau
2013-11-25 10:47 ` Rafael J. Wysocki
2013-11-29 8:28 ` Francis Moreau
2013-11-29 9:02 ` Thomas Gleixner
2013-11-30 15:07 ` Francis Moreau
2013-11-30 20:17 ` Rafael J. Wysocki
2013-12-01 10:11 ` Francis Moreau
2013-12-01 19:26 ` Francis Moreau
2013-12-02 10:49 ` Thomas Gleixner
2013-12-02 11:20 ` Thomas Gleixner
2013-12-03 8:14 ` Francis Moreau
2013-12-09 19:33 ` Francis Moreau
2013-12-09 22:27 ` Samuel Ortiz [this message]
2013-12-09 22:17 ` Samuel Ortiz
2013-12-10 1:39 ` wwang
2013-12-10 1:56 ` micky
2013-12-10 8:29 ` Samuel Ortiz
2014-01-10 7:26 ` Francis Moreau
2014-01-10 9:16 ` micky
2014-01-10 9:52 ` Samuel Ortiz
2014-01-10 10:07 ` Francis Moreau
2013-12-10 10:50 ` Francis Moreau
2013-12-17 8:03 ` Francis Moreau
2013-12-18 4:05 ` micky
2013-12-18 8:12 ` Francis Moreau
2013-12-20 1:30 ` micky
2013-12-20 2:28 ` Jingoo Han
2013-12-10 10:49 ` Francis Moreau
2013-11-24 9:42 ` Francis Moreau
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=20131209222758.GC8612@zurbaran \
--to=sameo@linux.intel.com \
--cc=bp@alien8.de \
--cc=cjb@laptop.org \
--cc=francis.moro@gmail.com \
--cc=jg1.han@samsung.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=wei_wang@realsil.com.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).