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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.