Re: [RFC PATCHv3] drivers: power: Detect device suspend/resume lockupand log event in pstore.

From: John Stultz
Date: Thu Aug 29 2013 - 14:43:43 EST


On 08/29/2013 11:23 AM, Pavel Machek wrote:
> On Wed 2013-08-28 15:43:42, Colin Cross wrote:
>> On Wed, Aug 28, 2013 at 3:36 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>>> On 08/28/2013 01:52 PM, Rafael J. Wysocki wrote:
>>>> On Wednesday, August 28, 2013 10:45:45 AM Zoran Markovic wrote:
>>>>> Hi Rafael,
>>>>>> It doesn't look too bad from a quick look, but there's a couple of things
>>>>>> I don't like in it still (relatively minor).
>>>>> If there are things you would like changed in this patch, please let
>>>>> me know. It would be nice to catch the 3.12 merge window.
>>>> Well, it's not in my queue to be honest.
>>>>
>>>> Is there any practical reason why it should go into the next release?
>>> I wouldn't say its critical for the next release, but I feel like this
>>> was the same response last cycle. Zoran's since investigated the various
>>> alternative approaches you've suggested, and continues to be interested
>>> in resolving your remaining objections.
>>>
>>> Its a useful feature the Android devs use, which could also help
>>> non-android developers debug suspend issues on their systems.
>>>
>>> If you really just feel its something best left out of tree, that's hard
>>> to argue against. Its just a debug tool and the android guys don't have
>>> an issue carrying their own tree, after all. But the cost of leaving it
>>> out is just the potential of others having to re-implement similar hacks
>>> on their own instead of collaborating on shared infrastructure.
>> And the benefit is that you are more likely to get bugreports that
>> have a stack trace of the offending suspend callback instead of "my
>> laptop doesn't suspend any more".
> Laptops do not have persistent store for dmesg. So... are you sure?

I pstore has support for EFI, so some laptops do.

thanks
-john


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