Bug#703640: src:linux: [3.8 -> 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework
#forgot to tag this bug, sorry!
fixed 703640 3.8.5-1~experimental.1
thanks
Le 25/03/2013 13:33, Vincent Blut a écrit :
> Le samedi 23 mars 2013 à 22:10 +0100, Vincent Blut a écrit :
>> Le 23/03/2013 18:58, Ben Hutchings a écrit :
>>> On Fri, 2013-03-22 at 14:28 +0100, Vincent Blut wrote:
>>>> Le jeudi 21 mars 2013 à 21:56 +0100, Vincent Blut a écrit :
>>>>> Le jeudi 21 mars 2013 à 19:28 +0100, Vincent Blut a écrit :
>>>>>> Package: src:linux
>>>>>> Version: 3.8.3-1~experimental.1
>>>>>> Severity: important
>>>>>> Tags: upstream
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As mentioned in the subject, the following commit prevents me to resume from
>>>>>> suspend in kernel ≥ 3.8.1:
>>>>>>
>>>>>> commit cace7c323ddde7358ab2f2390ece964c55f30330
>>>>>> Author: Alan Cox <alan@linux.intel.com>
>>>>>> Date: Fri Jan 25 10:28:15 2013 +1000
>>>>>>
>>>>>> fb: rework locking to fix lock ordering on takeover
>>>>>>
>>>>>> commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.
>>>>>>
>>>>>> Adjust the console layer to allow a take over call where the caller
>>>>>> already holds the locks. Make the fb layer lock in order.
>>>>>>
>>>>>> This is partly a band aid, the fb layer is terminally confused about the
>>>>>> locking rules it uses for its notifiers it seems.
>>>>>>
>>>>>> [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
>>>>>> [akpm@linux-foundation.org: export do_take_over_console()]
>>>>>> [airlied: cleanup another non-ascii char]
>>>>>> Signed-off-by: Alan Cox <alan@linux.intel.com>
>>>>>> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>>>>>> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>> Cc: Jiri Kosina <jkosina@suse.cz>
>>>>>> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
>>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>>> Signed-off-by: Dave Airlie <airlied@redhat.com>
>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>
>>>>>> I didn't try to boot with this commit reverted, and looking at its size,
>>>>>> I fear there will be some conflict to solve before attempting to do so.
>>>>>>
>>>>>> I guess it could be interesting to try 3.9-rc. to see how it
>>>>>> behaves (I didn't see what have been merged in this area in the last
>>>>>> merge window). I might try to connect through ssh to see if I get a
>>>>>> trace.
>>>>> Same issue with 3.9-rc3, I'll try to find some time tomorrow in order to
>>>>> get eventual stack traces.
>>>> Some news here, the suspend/resume process is doing fine (I checked
>>>> while connected via ssh), but what I didn't notice because I was in a
>>>> dark room is that there is just no backlight.
>>>>
>>>> But I find a workaround, setting acpi_osi="!Windows 2012" in the kernel
>>>> command line seems to inhibit the issue. I found this workaround
>>>> accidentally because I need this parameter to make my brightness control
>>>> working again (I reported this in #702188 btw).
>>> So are these the same bug or two different bugs?
>>
>> Well they both touch the backlight area, have the same workaround, but
>> the latter appears in a specific case: resume from suspend. I still have
>> 3 revisions to test, hope that will give some clue.
>
> Ok, my laptop is back to the business, I finished the bisection and I
> have a completely different result from the first time:
>
> commit 719429a54d9c: "drm/i915: write backlight harder"
>
> I reverted it on top of 3.8.1, as expected that fixed the issue.
> By the way it is reverted in the last drm pull request sent by Dave
> Airlie.
> I guess it'll be spread in stable‽
>
>
>>>
>>> In any case, please do not use the reportbug --no-bug-script option, as
>>> the kernel bug script provides lots of useful information. You can get
>>> that now by running:
>>>
>>> /usr/share/reportbug/handle_bugscript /usr/share/bug/linux-image-3.8-trunk-amd64/script $FILE
>>>
>>> and sending us that output file.
>>
>> Hmm, I didn't use the '--no-bug-script' option explicitly, is that due
>> to the fact I use the 'advanced' mode?
>> Anyway I'll provide the output but that will have to wait a little bit
>> because my power adapter
>> died this afternoon :-(
>
> Attached!
>
> Thanks for your time,
> Vincent
>
Reply to: