Created attachment 83890 [details]
dmesg from UX31A running under 3.10.5 with drm.debug=0xe
This has been reported in ALT Linux bugzilla (in Russian), posting here at Kirill's request as I've confirmed a report by another user on the same hardware I happen to use.
3.10.x kernels up to and including 3.10.5 result in turning off the backlight at i915 module load time on ASUS UX31A (i7-3517U); dmesg with drm.debug=0xe and late module load (not in initrd) is attached; external VGA monitor works fine (dmesg and Xorg.1.log available if needed).
Here's a transcript of sysfs knob fiddling over ssh:
root@ux class/backlight/intel_backlight # cat actual_brightness
root@ux class/backlight/intel_backlight # cat max_brightness
root@ux class/backlight/intel_backlight # echo 800 > brightness
root@ux class/backlight/intel_backlight # cat actual_brightness
and corresponding bits of dmesg (including further attempts at putting 100 and 80 values into brightness; both resulted in actual_brightness reading the same values but the screen backlight is still off):
[ 877.052934] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4302
[ 881.868818] [drm:intel_panel_get_backlight], get backlight PWM = 4302
[ 974.670199] [drm:intel_panel_get_backlight], get backlight PWM = 4302
[ 978.469350] [drm:intel_panel_actually_set_backlight], set backlight PWM = 100
[ 981.176898] [drm:intel_panel_get_backlight], get backlight PWM = 100
[ 990.186065] [drm:intel_panel_actually_set_backlight], set backlight PWM = 80
acpi_video0 doesn't have any effect either.
This bug hasn't manifested itself on 3.9.7 with very similar configuration on the same hardware.
I've skimmed over bug #51394 and bug #66462 which might be related; #54687 and #65652 seem rather not.
I have the same machine and it seems to still work here. So no idea what's gone boink. Can you please try to bisect this regression?
Will try next week, thanks. In the mean time could you please verify any of http://en.altlinux.org/Regular#main live images which happen to use the same 3.10.5 by now?
3.11-rc4 misbehaves the same way here, just in case. And even worse -- four tuxen with windows flags!!1
(In reply to comment #1)
> I have the same machine and it seems to still work here. So no idea what's
> gone boink.
Do you run it in BIOS or UEFI mode?
efifb gets initialized first here as mentioned in dmesg attached.
> Can you please try to bisect this regression?
Yup (thanks boyarsh@altlinux); git bisect log:
# bad: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10
# good: [c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1] Linux 3.9
git bisect start 'v3.10' 'v3.9' '--' 'drivers/gpu/drm/i915/'
# bad: [8a5c2ae753c588bcb2a4e38d1c6a39865dbf1ff3] drm/i915: fix ILK GPU reset for render
git bisect bad 8a5c2ae753c588bcb2a4e38d1c6a39865dbf1ff3
# good: [ed5de3995f9cdff997613f240e41033463703121] drm/i915: add media well to VLV force wake routines v2
git bisect good ed5de3995f9cdff997613f240e41033463703121
# good: [fa00abe00e379a0e9b070616baee58692576f29e] DRM/i915: Remove valleyview_hpd_irq_setup.
git bisect good fa00abe00e379a0e9b070616baee58692576f29e
# good: [460da91617d870972a7ae300fad3e13731b67757] drm/i915: compute pipe_config earlier
git bisect good 460da91617d870972a7ae300fad3e13731b67757
# bad: [3600836585e3fdef0a1410d63fe5ce4015007aac] drm/i915: convert DP autodither code to new infrastructure
git bisect bad 3600836585e3fdef0a1410d63fe5ce4015007aac
# good: [5bfe2ac00395ca37219b7187299cd9d23ae06682] drm/i915: add pipe_config->has_pch_encoder
git bisect good 5bfe2ac00395ca37219b7187299cd9d23ae06682
# good: [965e0c489f360df1beeb567e4540777a09b8896e] drm/i915: introduce pipe_config->dither|pipe_bpp
git bisect good 965e0c489f360df1beeb567e4540777a09b8896e
# good: [4e53c2e010e531b4a014692199e978482d471c7e] drm/i915: precompute pipe bpp before touching the hw
git bisect good 4e53c2e010e531b4a014692199e978482d471c7e
# first bad commit: [3600836585e3fdef0a1410d63fe5ce4015007aac] drm/i915: convert DP autodither code to new
Seems that there's no image (kas@ advised to shine a flashlight upon the display, there were no signs of display manager upon boot when the network was up already).
(In reply to comment #2)
> could you please verify any of http://en.altlinux.org/Regular#main
> live images which happen to use the same 3.10.5 by now?
Maybe this helps: today's snapshot including 3.10.6 just works on my UX31A in both BIOS and UEFI modes *if* CSM is enabled in firmware; disabling Boot > Launch CSM triggers the bug.
The images are UEFI/BIOS, CD/Flash hybrid (just dd it onto a stick).
(In reply to comment #5)
> [...] 3.10.6 just works on my UX31A [...] *if* CSM is enabled in firmware
Confirmed by the original (ALT) bug poster too.
3.10.7 plus the hack from https://bugzilla.kernel.org/show_bug.cgi?id=59841#c41 works on UX31A with CSM disabled.
Please retest with latest drm-intel-fixes, specifically
Author: Imre Deak <firstname.lastname@example.org>
Date: Fri Aug 23 23:50:23 2013 +0300
drm/i915: ivb: fix edp voltage swing reg val
Michael, just to verify what's seen on  and , please attach /sys/kernel/debug/dri/0/i915_opregion for non-working and working setting of the BIOS option. Thanks.
(In reply to comment #9)
> please attach /sys/kernel/debug/dri/0/i915_opregion for non-working
> and working setting of the BIOS option
OK, I'll have to get to the office so another console with ssh is handy.
Jani, I've posted /sys/kernel/debug/dri/0/i915_opregion for UX31A (both UEFI and UEFI+CSM) at kernel bugzilla so as to keep all dumps to one bug:
https://bugzilla.kernel.org/show_bug.cgi?id=59841#c148 (heh, got striped)
I'll repost these here if you tell me to of course.
Daniel, I haven't had a chance to retest with latest drm-intel-fixes so far, sorry. Should I try this week?
Yes, as I wonder if this is something like
Author: Chris Wilson <email@example.com>
Date: Tue Aug 27 17:04:17 2013 +0100
drm/i915: Track pfit enable state separately from size
instead of the usual issues.
(In reply to comment #12)
> Yes, as I wonder if this is something like
> commit fd4daa9cea025ddf8623db289e79d264e9fa66f6
> Author: Chris Wilson <firstname.lastname@example.org>
> Date: Tue Aug 27 17:04:17 2013 +0100
> drm/i915: Track pfit enable state separately from size
> instead of the usual issues.
Chris, the VBT reports different bpp for CSM vs. no-CSM. One works, the other doesn't. How would that commit be relevant here?
Less likely in that case... Still worth checking if it is.
Author: Jani Nikula <email@example.com>
Date: Mon Oct 21 10:52:07 2013 +0300
drm/i915/dp: workaround BIOS eDP bpp clamping issue