Bug 75791
| Summary: | i915: backlight turns off during boot | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Matteo Cypriani (mcy) |
| Component: | Video(DRI - Intel) | Assignee: | Jani Nikula (jani.nikula) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | daniel, intel-gfx-bugs |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 3.14.3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Output of dmesg
Output of lspci -vvv kern.log with drm.debug=0xe kern.log with drm-intel-nightly kernel Full kern.log (drm-intel-nightly) Full kern.log (3.14.3) |
||
Created attachment 135531 [details]
Output of lspci -vvv
Please attach dmesg from early boot with drm.debug=0xe module parameter. Please try drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel, also attach dmesg. Created attachment 135551 [details]
kern.log with drm.debug=0xe
Here are the kernel messages with drm.debug=0xe from my vanilla 3.14.3 (first 10 seconds). I took that from kern.log because I didn't have everything in dmesg and it seems there is more detail anyway.
I'll look into patching ASAP.
Created attachment 135581 [details]
kern.log with drm-intel-nightly kernel
So I built the kernel from the drm-intel-nightly branch, and here is the kern.log excerpt, still with drm.debug=0xe. The behaviour with this kernel is the same as when I booted 3.14 with nomodeset, i.e. the backlight doesn't turn off but stays at the maximum and /sys/class/backlight is empty.
(In reply to mcy from comment #3) > Created attachment 135551 [details] > kern.log with drm.debug=0xe (In reply to mcy from comment #4) > Created attachment 135581 [details] > kern.log with drm-intel-nightly kernel Neither of these have any signs of drm or i915. Please check your kernel config, make sure you installed the modules properly, etc. Also please check that you have loglevel=8 or something so that debug messages get actually logged in dmesg. Created attachment 135891 [details]
Full kern.log (drm-intel-nightly)
Sorry but I don't see what can be wrong with my installation. The i915 and drm modules are installed and even loaded at boot time, although indeed there is no mention of them in the first 10 seconds of the log. The following is with drm-intel-nightly (same version as the other day, i.e. commit dd28119c31cf06fc4c3bb548699018a91e45a676). I'm also attaching the full kern.log (not just the first 10 seconds) with loglevel=8 and drm.debug=0xe; i915 and drm appear, but I think it is just once X is started, not before.
$ lsmod | grep i915
i915 772969 2
drm_kms_helper 44730 1 i915
drm 233070 4 i915,drm_kms_helper
video 17804 1 i915
i2c_algo_bit 12751 1 i915
i2c_core 41916 6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev
button 12944 1 i915
$ ls /sys/class/backlight
$ find /lib/modules/$(uname -r) -name i915.ko
/lib/modules/3.15.0-rc3+/kernel/drivers/gpu/drm/i915/i915.ko
$ grep I915 /boot/config-3.15.0-rc3+
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_I915_FBDEV=y
# CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
CONFIG_SND_HDA_I915=y
Created attachment 135901 [details]
Full kern.log (3.14.3)
Same thing with 3.14.3, kern.log and:
$ lsmod | grep i915
i915 713670 2
drm_kms_helper 39892 1 i915
drm 232465 3 i915,drm_kms_helper
video 17804 1 i915
i2c_algo_bit 12751 1 i915
i2c_core 24228 6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev
button 12944 1 i915
$ ls /sys/class/backlight
intel_backlight
$ find /lib/modules/$(uname -r) -name i915.ko
/lib/modules/3.14.3/kernel/drivers/gpu/drm/i915/i915.ko
$ grep I915 /boot/config-3.14.3
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_I915_FBDEV=y
# CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
# CONFIG_DRM_I915_UMS is not set
CONFIG_SND_HDA_I915=y
If you still think there is something wrong with my install, please give me a hint (I just did the usual make && make modules_install && make install for both kernels).
Please attach /sys/kernel/debug/dri/0/i915_opregion What do you have in /sys/class/backlight in the working 3.13 kernel? (In reply to Jani Nikula from comment #8) > Please attach /sys/kernel/debug/dri/0/i915_opregion Hum, /sys/kernel/debug is empty. Do I have to add another boot parameter to the kernel or something? I tried adding "debug" but then it won't boot (it stays blocked right before the moment it should ask for my LUKS passphrase). > What do you have in /sys/class/backlight in the working 3.13 kernel? $ ls -l /sys/class/backlight total 0 lrwxrwxrwx 1 root root 0 mai 12 13:14 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight $ tree /sys/class/backlight/intel_backlight /sys/class/backlight/intel_backlight ├── actual_brightness ├── bl_power ├── brightness ├── device -> ../../card0-LVDS-1 ├── max_brightness ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── subsystem -> ../../../../../../../class/backlight ├── type └── uevent 3 directories, 15 files (It is the exact same output with 3.14.3.) (In reply to mcy from comment #9) > (In reply to Jani Nikula from comment #8) > > Please attach /sys/kernel/debug/dri/0/i915_opregion > > Hum, /sys/kernel/debug is empty. Do I have to add another boot parameter to > the kernel or something? I tried adding "debug" but then it won't boot (it > stays blocked right before the moment it should ask for my LUKS passphrase). Either debugfs is not mounted (fixed by 'sudo mount -t debugfs none /sys/kernel/debug') or you don't have permissions. > $ ls -l /sys/class/backlight > total 0 > lrwxrwxrwx 1 root root 0 mai 12 13:14 intel_backlight -> > ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight > > (It is the exact same output with 3.14.3.) Apparently it's not there from 3.15-rc2 onwards, because: [drm:intel_panel_setup_backlight] native backlight control not available per VBT Oh yes, debugfs wasn't mounted indeed. /sys/kernel/debug/dri/0/i915_opregion is empty on all three kernels (nightly, 3.14.3 and the working 3.13). /sys/kernel/debug/dri/64/i915_opregion too, for that matters. Other files from /sys/kernel/debug/dri/0/ contain something, so I guess the debugfs is working properly. (In reply to mcy from comment #11) > /sys/kernel/debug/dri/0/i915_opregion is empty on all three kernels > (nightly, 3.14.3 and the working 3.13). Doubt it. Don't look at the size, just cp the file elsewhere. Yes, I noticed the size of all the files is 0, but I used cat to see the content. For most of the files it printed something, but not for i915_opregion. (In reply to mcy from comment #13) > Yes, I noticed the size of all the files is 0, but I used cat to see the > content. For most of the files it printed something, but not for > i915_opregion. Ah. It's a binary file. Please just cp it somewhere, and attach. Run hexdump on it if you want to double check there's something. If you insist :-)
# hexdump /sys/kernel/debug/dri/0/i915_opregion
# cp /sys/kernel/debug/dri/0/{i915_capabilities,i915_opregion} .
# ls -l i915_*
-r--r--r-- 1 root root 404 mai 14 09:32 i915_capabilities
-r--r--r-- 1 root root 0 mai 14 09:32 i915_opregion
# hexdump i915_opregion
#
(In reply to mcy from comment #15) > If you insist :-) My apologies for being so stubborn! It's the first machine I encounter with: [ 34.657996] [drm:intel_opregion_setup], graphic opregion physical addr: 0x0 [ 34.658000] [drm:intel_opregion_setup], ACPI OpRegion not supported! Back to the drawing board. I don't see the bisect result anywhere, I guess we need that to move this bug forward. Please do that, thanks. (In reply to Jani Nikula from comment #16) > My apologies for being so stubborn! No worry, you have to be sure than there is no PEBKAC involved :-) (In reply to Daniel Vetter from comment #17) > I don't see the bisect result anywhere, I guess we need that to move this > bug forward. Please do that, thanks. I don't have access to this machine this week, but I can work on it next week. What bisect do you want me to do? From Linux 3.13.10 to 3.14.3? Hi there, I just finished bisecting between v3.13 and v3.14 from Linus' repository (15 kernel builds, phew!), and the faulty commit seems to be this one: b35684b drm/i915: do full backlight setup at enable time https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b35684b8fa94e04f55fd38bf672b737741d2f9e2 Assigning to Jani as per Signed-off-by of that commit. Same bisect result as [1] but I like to keep both of these open as one as opregion and the other doesn't. [1] https://bugs.freedesktop.org/show_bug.cgi?id=79423 (In reply to Jani Nikula from comment #21) > Same bisect result as [1] but I like to keep both of these open as one as > opregion and the other doesn't. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=79423 Please try the patch I attached there on top of the bad commit: https://bugs.freedesktop.org/show_bug.cgi?id=79423#c8 It works! Do you need any complementary information from my machine? In any case, many thanks for your work! (In reply to mcy from comment #23) > It works! Do you need any complementary information from my machine? > In any case, many thanks for your work! This is enough, thanks for the report and testing. Patch submitted, I'll close when we get it merged. commit 6d0cfd569ff908336cbf312e6a211793db843d5a Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Jun 9 18:24:34 2014 +0300 drm/i915: set backlight duty cycle after backlight enable for gen4 |
Created attachment 135521 [details] Output of dmesg Hello, Since I upgraded from Linux 3.13 (Debian package) to Linux 3.14 (Debian package 3.14.2-1, confirmed by compiling a 3.14.3 from kernel.org with the same options), the backlight of my laptop (MacBook4,1) turns completely off when booting, right after “Waiting for /dev to be fully populated” is printed on the console. If I wait for the computer to fully boot, I can log in to KDE (via KDM), and then the brightness is set to my default level, and can be adjusted with the dedicated keys on the keyboard (Fn + F1/F2 in my case). I'm guessing the problem is simply that the brightness is set to the minimum, but on this machine the minimum possible brightness disables the backlight completely. For information: $ cat /sys/class/backlight/intel_backlight/max_brightness 494 It's a bit tricky to get the minimal visible brightness, because setting various values in /sys/class/backlight/intel_backlight/brightness doesn't always give the same result, but it seems that a good minimum would be 99 (20% in KDE). Unfortunately, I can't seem to find a kernel parameter that would allow to set the base brightness. I did found two work-arounds: 1. If I pass i915.invert_brightness=1 to the kernel, brightness stays at the maximum during the boot time, but (obviously) the brightness level is reversed (so I have to push the “brightness +” button to lower the brightness, KDE sets a higher brightness when idle, etc.), so that's not ideal. 2. If I pass nomodeset or i915.modeset=0 to the kernel, brightness stays at the maximum but can't be adjusted; /sys/class/backlight is empty. I also tried a bunch of other parameters without noticeable effect (video.use_native_backlight=1, acpi_backlight=vendor, etc.). Re-compiling the kernel with CONFIG_DRM_I915_UMS=y and CONFIG_DRM_I915_KMS disabled to force user mode setting instead of kernel mode setting makes the display work at boot-time, but when launching KDM it starts being all glitchy, and it stays buggy when switching to a console. The brightness is set at the maximum and can't be adjusted, and /sys/class/backlight is empty. Not sure this is relevant, but as you can guess from the machine type, it's an EFI boot. I'm attaching the output of dmesg right after booting the computer, and the output of lspci -vvv. I'm at your service if you need any other information or testing. Cheers, Matteo