Can you please try to bisect where the regression has been introduced in 3.14.5-7? Not that many commits so shouldn't be to onerous.

Also please boot with drm.debug=0xe added to your kernel cmdline and attach dmesg (just for system information).

Any chance you can ssh into your machine once the screen is off and check logs for error?

I don't know how to bisect, but reading 3.14.6 changelog shows 5 or 6 patches regarding i915. Should't be hard to find it.

Regarding drm.debug logs, they're posted on the original report, have you read it?

https://wiki.ubuntu.com/Kernel/KernelBisection

(In reply to comment #2)
> I don't know how to bisect, but reading 3.14.6 changelog shows 5 or 6
> patches regarding i915. Should't be hard to find it.

10 patches touching i915, but it might be acpi too. Please bisect, otherwise it's just guesswork.

> Regarding drm.debug logs, they're posted on the original report, have you
> read it?

Which original report? This bug only has a snippet; please post full dmesg all the way from boot to the problem, with drm.debug=0xe module parameter set.

Another thing to try would be xf86-video-intel version 2.99.912 or later.

(In reply to comment #4)
> Which original report? This bug only has a snippet; please post full dmesg

please _attach_ the dmesg.

Created attachment 101873 [details]
dmesg with drm.debug=0xe

Bisecting will take some time, as I'm not a developer and have to learn all that stuff.

Created attachment 103447 [details]
Kernel bisect log

OK, I could finally bisect the kernel. This is what I found:

3e873234bf01413486c9d7151dea202a7ffc6a43 is the first bad commit
commit 3e873234bf01413486c9d7151dea202a7ffc6a43
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 5 11:38:08 2014 +0200

    ACPI / video: Add use_native_backlight quirks for more systems
    
    commit 43d9490244254d2d6adb0f3c6275c7b8d032a2dd upstream.
    
    ThinkPad T430: extend the T430s entry to also cover the T430 (note we also
    have another entry for T430's with a different DMI_PRODUCT_VERSION).
    
    ThinkPad T430
    Reported-and-tested-by: edm <fuffi.il.fuffo@gmail.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=51231
    
    Thinkpad T530
    Reported-and-tested-by: Balint Szigeti <balint.szgt@gmail.com>
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545
    
    Acer Aspire 5742G
    Reported-and-tested-by: AnAkkk <anakin.cs@gmail.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=35622
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 85432e27049c051e697efaba250c8a8a9ffe7db5 73799e73b77b3ed3e00010159d460787d82f870d M	drivers

To be sure could you revert this bad commit by:

git revert 3e873234bf01413486c9d7151dea202a7ffc6a43

and test to see if it really was this one?

OK, I reverted the bad commit and can confirm the issue is gone without it, screen resumes OK

Sorry, spoke too soon. Using 3.14.6 with that commit reverted I had the issue again. Maybe I'm doing something wrong, here's what I did:

git revert 3e873234bf01413486c9d7151dea202a7ffc6a43
git checkout v3.14.6

I get a message about the reverted patch not being applied. Built the kernel and now it fails. Is it OK or should I try something else?

(In reply to comment #11)
> Sorry, spoke too soon. Using 3.14.6 with that commit reverted I had the
> issue again. Maybe I'm doing something wrong, here's what I did:
> 
> git revert 3e873234bf01413486c9d7151dea202a7ffc6a43
> git checkout v3.14.6
> 
> I get a message about the reverted patch not being applied. Built the kernel
> and now it fails. Is it OK or should I try something else?

Do the revert after checkouting the version that has the bug.

$ git checkout v3.14.6
$ git revert 3e873234bf01413486c9d7151dea202a7ffc6a43
error: could not revert 3e87323... ACPI / video: Add use_native_backlight quirks for more systems
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

:/

(In reply to comment #8)
> 3e873234bf01413486c9d7151dea202a7ffc6a43 is the first bad commit
> commit 3e873234bf01413486c9d7151dea202a7ffc6a43
> Author: Hans de Goede <hdegoede@redhat.com>
> Date:   Mon May 5 11:38:08 2014 +0200
> 
>     ACPI / video: Add use_native_backlight quirks for more systems

CC: Hans and Aaron

Any thoughts before I close this as NOTOURBUG on i915 side?

Just FYI, I tried whith "thinkpad-acpi.brightness_enable=1 acpi_backlight=vendor" boot options on kernel 3.14.5, and the bug triggers on that version, that works fine otherwise.

(In reply to comment #14)
> (In reply to comment #8)
> > 3e873234bf01413486c9d7151dea202a7ffc6a43 is the first bad commit
> > commit 3e873234bf01413486c9d7151dea202a7ffc6a43
> > Author: Hans de Goede <hdegoede@redhat.com>
> > Date:   Mon May 5 11:38:08 2014 +0200
> > 
> >     ACPI / video: Add use_native_backlight quirks for more systems
> 
> CC: Hans and Aaron
> 
> Any thoughts before I close this as NOTOURBUG on i915 side?

What the commit to which this was bisected does, is change the used backlight driver from acpi to the intel_backlight driver. So I'm not entirely sure it is fair to say NOTOURBUG on i915 side.

Clearly something is not working right on the i915 side if the backlight does not come up after suspend/resume when the acpi backlight code is not involved. Things happened to work before since the acpi code path likely poked some register which the i915 code forgets to poke ...

If you read: https://bugzilla.kernel.org/show_bug.cgi?id=51231 then you will see that there are lots of problems with the Thinkpad T?30 / X230 series and acpi-video, related to win8 support in the BIOS.

Also while the switch from acpi-video to intel as the backlight driver of choice was done with a quirk in 3.14, but in 3.16 this behavior (video.use_native_backlight) now is the default.

This also makes me wonder if there is anything special with Mariano's laptop, or if this maybe is already fixed in 3.16, otherwise we should have a lot more bug reports as the T430 is a quite popular model.

Mariano, any chance you could try with a 3.16 kernel ?

Also can you please try adding: "video.use_native_backlight=0" the the kernel commandline with 3.14.6? That should fix things if your bisect has found the right commit as the culprit.

(In reply to comment #15)
> Just FYI, I tried whith "thinkpad-acpi.brightness_enable=1
> acpi_backlight=vendor" boot options on kernel 3.14.5, and the bug triggers
> on that version, that works fine otherwise.

Hmm,

Can you do: "ls /sys/class/backlight" and copy and paste the output here both on a working kernel and on a troublesome kernel (without any special commandline arguments) ?

Thanks,

Hans

First, thanks Hans for your help!

> This also makes me wonder if there is anything special with Mariano's
> laptop, or if this maybe is already fixed in 3.16, otherwise we should have
> a lot more bug reports as the T430 is a quite popular model.
> 

Maybe BIOS version? I've upgraded original BIOS to this version:

        Vendor: LENOVO
        Version: G1ETA1WW (2.61 )
        Release Date: 12/03/2013
        BIOS Revision: 2.61
        Firmware Revision: 1.12

> Mariano, any chance you could try with a 3.16 kernel ?
> 

Yes, I tried 3.16.1 and the bug IS present

> Also can you please try adding: "video.use_native_backlight=0" the the
> kernel commandline with 3.14.6? That should fix things if your bisect has
> found the right commit as the culprit.

Adding that boot option to 3.14.6, screen resumes OK

> Can you do: "ls /sys/class/backlight" and copy and paste the output here
> both on a working kernel and on a troublesome kernel (without any special
> commandline arguments) ?
> 

3.14.5 (OK)
ls /sys/class/backlight
acpi_video0  intel_backlight

3.14.6 (BAD)
ls /sys/class/backlight
intel_backlight

Hmm, please provide intel_reg_dumper output on both the good and bad kernels. It's part of the intel-gpu-tools package.

Created attachment 105611 [details]
Intel Reg Dump 3.14.5

Created attachment 105612 [details]
Intel Reg Dump 3.14.6 (BAD)

(In reply to comment #18)
> > Also can you please try adding: "video.use_native_backlight=0" the the
> > kernel commandline with 3.14.6? That should fix things if your bisect has
> > found the right commit as the culprit.
> 
> Adding that boot option to 3.14.6, screen resumes OK

Ok, so that patch really is the culprit. I'm afraid though that reverting it for <= 3.15 may cause regressions for other T430 users, and with 3.16 we would actually need to add a quirk for your model to force video.use_native_backlight=0 there, as video.use_native_backlight=1 is the default there now.

So first lets see if Jani can make any sense of the regdumps you've attached, and then we'll go from there.

Please try setting the backlight brightness to 4335 on the non-working kernel using the intel_backlight interface.

# echo 4335 > /sys/class/backlight/intel_backlight/brightness

Also please attach /sys/kernel/debug/dri/0/i915_opregion

(In reply to comment #24)
> Please try setting the backlight brightness to 4335 on the non-working
> kernel using the intel_backlight interface.
> 
> # echo 4335 > /sys/class/backlight/intel_backlight/brightness

OK, here's what I did:

# cat /sys/class/backlight/intel_backlight/brightness
4437

# echo 4335 > /sys/class/backlight/intel_backlight/brightness

Then I closed the lid and opened again, with the screen not resuming. On secondary screen I did:

# cat /sys/class/backlight/intel_backlight/brightness
0
# echo 4335 > /sys/class/backlight/intel_backlight/brightness

And after that screen turned ON

Created attachment 105617 [details]
i915_opregion

(In reply to comment #26)
> # cat /sys/class/backlight/intel_backlight/brightness
> 0
> # echo 4335 > /sys/class/backlight/intel_backlight/brightness
> 
> And after that screen turned ON

Can you change brightness normally after that? Does max_brightness work?

(In reply to comment #28)
> (In reply to comment #26)
> > # cat /sys/class/backlight/intel_backlight/brightness
> > 0
> > # echo 4335 > /sys/class/backlight/intel_backlight/brightness
> > 
> > And after that screen turned ON
> 
> Can you change brightness normally after that? Does max_brightness work?

Yes, I can increase/decrease brightness normally, up to max_brightness (4437)

(In reply to comment #29)
> (In reply to comment #28)
> > (In reply to comment #26)
> > > # cat /sys/class/backlight/intel_backlight/brightness
> > > 0
> > > # echo 4335 > /sys/class/backlight/intel_backlight/brightness
> > > 
> > > And after that screen turned ON
> > 
> > Can you change brightness normally after that? Does max_brightness work?
> 
> Yes, I can increase/decrease brightness normally, up to max_brightness (4437)

Just found that I can also increase brightness directly after resuming. I didn't notice it before because there's a screen locker. But if I blindly put the password, then I can raise brightness with the keys.

Do you use systemd?

(In reply to comment #31)
> Do you use systemd?

Nope. Elementary Luna, Ubunu 12.04 based, no systemd.

I think that the problem is that unlike the acpi-video backlight driver, the intel driver does not restore the backlight level on a resume.

drivers/acpi/video.c has this:

static int acpi_video_resume(struct notifier_block *nb,
                                unsigned long val, void *ign)
{
<snip>
        dev_info(&video->device->dev, "Restoring backlight state\n");

        for (i = 0; i < video->attached_count; i++) {
                video_device = video->attached_array[i].bind_info;
                if (video_device && video_device->backlight)
                        acpi_video_set_brightness(video_device->backlight);
        }
}

The intel backlight code lacks similar code (AFAIK), perhaps similar code should be added to the intel-panel.c, esp. now that the intel-backlight driver has become the preferred way to control the backlight on newer machines.

(In reply to Hans de Goede from comment #33)
> I think that the problem is that unlike the acpi-video backlight driver, the
> intel driver does not restore the backlight level on a resume.

We do. intel_panel_enable_backlight() gets called on resume, and it restores the backlight setting from panel->backlight.level.

Indeed the logs have plenty of

[  873.096139] [drm:intel_backlight_device_update_status], updating intel_backlight, brightness=0/4437

indicating userspace wishing to dim the backlight.

(In reply to Jani Nikula from comment #35)
> Indeed the logs have plenty of
> 
> [  873.096139] [drm:intel_backlight_device_update_status], updating
> intel_backlight, brightness=0/4437
> 
> indicating userspace wishing to dim the backlight.

Hmm, so this may not be a kernel bug at all. Actually with this info, this sounds a lot like an xf86-video-intel bug which I fixed a while back, specifically see:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b545e10c50cbb2dd6f9fd53369667bed0d8f1b51

Without that commit when userspace does a dpms off and then a read/modify/write of the backlight level things may end up with a backlight level of 0.

Also possibly relevant is:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c6cd10f536e099277cdc46643725a5a50ea8b525

And then specifically this bit:

@@ -820,6 +949,14 @@ sna_crtc_apply(xf86CrtcPtr crtc)
for (i = 0; i < config->num_output; i++) {
xf86OutputPtr output = config->output[i];
+ /* Make sure we mark the output as off (and save the backlight)
+ * before the kernel turns it off due to changing the pipe.
+ * This is necessary as the kernel may turn off the backlight
+ * and we lose track of the user settings.
+ */
+ if (output->crtc == NULL)
+ output->funcs->dpms(output, DPMSModeOff);
+
if (output->crtc != crtc)
continue;

Marian, can you please try upgrading your intel driver to the 2.99.916 release ? (you can download the tarbal and build it from source), and please make sure you're using sna and not uxa.

Hello,

adding me in the CC. Got the same problem on Lenovo T430s, Fedora 20.

[lzap@lzapx ~]$ ls /sys/class/backlight
intel_backlight

[lzap@lzapx ~]$ uname -a
Linux lzapx.brq.redhat.com 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[lzap@lzapx ~]$ rpm -q xorg-x11-drv-intel
xorg-x11-drv-intel-2.21.15-7.fc20.x86_64

I can test the http://koji.fedoraproject.org/koji/buildinfo?buildID=576596 package if this helps.

Hi,

(In reply to Lukas Zapletal from comment #37)
> Hello,
> 
> adding me in the CC. Got the same problem on Lenovo T430s, Fedora 20.
> 
> [lzap@lzapx ~]$ ls /sys/class/backlight
> intel_backlight
> 
> [lzap@lzapx ~]$ uname -a
> Linux lzapx.brq.redhat.com 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21
> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> 
> [lzap@lzapx ~]$ rpm -q xorg-x11-drv-intel
> xorg-x11-drv-intel-2.21.15-7.fc20.x86_64
> 
> I can test the http://koji.fedoraproject.org/koji/buildinfo?buildID=576596
> package if this helps.

Hmm, the Fedora 2.21.15-7 package already has the 2 backlight fixes I mentioned, still if you could test a newer version that would be great, perhaps we will get lucky.

Not sure if it helps, but I have issues only with the laptop screen.

When I have a secondary LCD connected, it always wake-ups just fine.

It does not matter if the secondary one is connected or not. Laptop screens *sometimes* does not restore the backlight. There are few cases (I'd say 1 out of 10) when it does restore. Wasn't able to find the pattern tho.

(In reply to Hans de Goede from comment #36)
> 
> Hmm, so this may not be a kernel bug at all. Actually with this info, this
> sounds a lot like an xf86-video-intel bug which I fixed a while back,
> specifically see:
> 
...
> 
> Marian, can you please try upgrading your intel driver to the 2.99.916
> release ? (you can download the tarbal and build it from source), and please
> make sure you're using sna and not uxa.

Hmm, while I *could* try with a new driver, I don't think that's the right thing to do. Quoting Linus "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs" seems pretty clear to me that this should be fixed on kernel. I've been using almost every stable kernel release since 3.2 with the same userspace, and the problem clearly started when I upgraded from 3.14.5 to 3.14.6

I hope you're not proposing we should never ever fix bugs in the userspace?

In any case, please *try* the new driver. How it behaves will impact what should be done kernel side.

(In reply to Jani Nikula from comment #41)
> I hope you're not proposing we should never ever fix bugs in the userspace?
> 

Clearly not. 

> In any case, please *try* the new driver. How it behaves will impact what
> should be done kernel side.

I built and tried xf86-video-intel-2.99.916 as suggested, and the screen resumes OK

Thanks.

Apparently intel_backlight does what the userspace wants, mechanism not policy and all that, while acpi_backlight, for some reason, did not obey 0 backlight in this scenario. And we moved from acpi_backlight to intel_backlight on your hardware. Technically there's no regression in i915, as it works with a sane userspace, and I'm obviously reluctant to adding hacks in i915 to replicate policy in acpi.

However we've changed a few things related to backlight power sequencing and minimum backlight brightness; please see if those help with the old userspace. The branch to try is drm-intel-nightly at http://cgit.freedesktop.org/drm-intel.

(In reply to Jani Nikula from comment #43)
> Thanks.
> 
> Apparently intel_backlight does what the userspace wants, mechanism not
> policy and all that, while acpi_backlight, for some reason, did not obey 0
> backlight in this scenario. And we moved from acpi_backlight to
> intel_backlight on your hardware. Technically there's no regression in i915,
> as it works with a sane userspace, and I'm obviously reluctant to adding
> hacks in i915 to replicate policy in acpi.
> 

OK, I understand your position here, I don't like hacks either. I think I'll just stick with acpi_backlight until I can upgrade my userland.

> However we've changed a few things related to backlight power sequencing and
> minimum backlight brightness; please see if those help with the old
> userspace. The branch to try is drm-intel-nightly at
> http://cgit.freedesktop.org/drm-intel.

Maybe someone else can test this, I'm done for now

Hello,

I've tested Fedora 21 LiveCD nightly build and it seems to resume fine.

(In reply to Lukas Zapletal from comment #45)
> I've tested Fedora 21 LiveCD nightly build and it seems to resume fine.

Sounds like this has been resolved, thanks for the feedback.

In case this is still busted on latest upstream kernels please reopen.