From: Lan Tianyu <tianyu.lan@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Knut Petersen <Knut_Petersen@t-online.de>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Thomas Renninger <trenn@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Bug 3.14.17] inconsistent lock state
Date: Mon, 25 Aug 2014 11:43:05 +0800 [thread overview]
Message-ID: <53FAB0C9.3070907@intel.com> (raw)
In-Reply-To: <CA+55aFzaHF=S3QQ6M-+JBdWVRCSHKs-jjKo==8OS7q90cUyHBw@mail.gmail.com>
On 2014年08月25日 11:13, Linus Torvalds wrote:
> On Sun, Aug 24, 2014 at 7:53 PM, Lan Tianyu <tianyu.lan@intel.com> wrote:
>>
>> Sorry about this. We are resolving the issue in the other bug
>> report(https://lkml.org/lkml/2014/8/21/606) and I have proposed a fix
>> patch(http://marc.info/?l=linux-acpi&m=140869309231199&w=2).
>
> Ahh. Good. That patch looks fine to me, and while it makes me worry a
> bit that some codepath expects the power/sleep button to be handled
> immediately in interrupt context, I guess the actual callbacks have
> never actually done anything but schedule other things to happen (ie
> add events to some queue), and making the context be the same as the
> other notify callbacks would seem to be a good thing regardless of
> this particular bug.
Yes, I have the same opinion and the callback just reports power/sleep
button event to user space via input layer or ACPI netlink routines.
The button devices enumerated from ACPI namespace and FADT table share
the same notify callback and do the same things while they are running
different context. This seems not make sense.
>
> Knut - can you please test the patch Lan pointed at? I realize it
> doesn't seem to be entirely consistent for you (which is a bit
> surprising, I wonder why lockdep doesn't trigger it consistently), but
> it would be good to have more testing. Even if that patch looks
> "obviously good" (tm) at a quick glance.
BTW, this bug only takes place on the machines with fixed button device.
This can be identified via check whether there are LNXPWRBN:00 or
LNXSLPBN:00 device nodes under /sys/bus/acpi/devices.
>
> Linus
>
--
Best regards
Tianyu Lan
next prev parent reply other threads:[~2014-08-25 3:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53F9CC77.70009@t-online.de>
2014-08-24 17:50 ` [Bug 3.14.17] inconsistent lock state Linus Torvalds
2014-08-24 18:13 ` Arkadiusz Miskiewicz
2014-08-24 18:49 ` Linus Torvalds
2014-08-24 19:04 ` David Miller
2014-08-25 2:53 ` Lan Tianyu
2014-08-25 3:13 ` Linus Torvalds
2014-08-25 3:43 ` Lan Tianyu [this message]
[not found] ` <53FAE383.6050308@t-online.de>
2014-08-25 16:36 ` Linus Torvalds
[not found] ` <53FBA94E.2080405@t-online.de>
[not found] ` <53FBBC26.2030501@oracle.com>
2014-08-26 4:10 ` [REGRESSION] pci: power off broken by commit 4fc9bbf98 / stable 2ab0ff9b Bjorn Helgaas
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=53FAB0C9.3070907@intel.com \
--to=tianyu.lan@intel.com \
--cc=Knut_Petersen@t-online.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=trenn@suse.de \
/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