With 3.10-rc5 & 3.10-rc6, internal display doesn't show a picture. From the window manager / user side, everything appears normal, in other words as if there's a picture. E.g. backlight brightness adjustment works, but no picture on X screen or console. Works with the same hardware & X server config (no xorg.conf) on e.g. stable 3.9.5, 3.9.6 and Ubuntu 3.8. Hardware: Asus Transformer Book TX300 (4005) (Intel HD4000 graphics) Software: Ubuntu 13.04
Couldn't find any significant difference in X server log, comparing 3.8 & 3.10-rc5.
To clarify, picture on external diplay is fine, and I can use gnome-control-center to control the internal display, and internal display backlight behaves as expected when turning internal display on or off. No complaints about being unable to switch the internal display on, and it switches on and windows can be moved there. It's just there's no image on the internal display.
Two things: - Can you please boot both the last working kernel and the first broken kernel with drm.debug=0xe and attach the dmesg from both? - Can you please try to bisect where this regression has been introduced?
OK, will do the debug with 3.9.6 and 3.10-rc5 which are the ones I've tested. I haven't followed kernel development & versioning too closely. On kernel.org I can see 3.10-rc1 .. rc6 - and things work for 3.9.5 & 3.9.6. Are those the published versions? So probably 3.10-rc1 is a good place to started test where the problem appeared?
Actually better to report the debug logs for the last working & first failing as you say, so I'll first find that out. 3.10-rc1 works, 3.10-rc3 fails - compiling rc2 now, after I've tested that, I'll post the messages.
Bug is exhibited with -rc2, while 3.10-rc1 works fine. I'll attach the log excerpts.
Created attachment 105261 [details] Booted with drm.debug=0xe, 3.10-rc2, display works only on external display Booted with drm.debug=0xe, 3.10-rc2, display works only on external display
Created attachment 105271 [details] debug output from 3.10-r1, both displays work debug output from 3.10-r1, both displays work
At least one difference - with rc1 which works: 43123] [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz Jun 18 21:30:38 assu kernel: [ 1.843126] [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24 Jun 18 21:30:38 assu kernel: [ 1.843127] [drm:intel_dp_compute_config], DP link bw required 333072 available 432000 Jun 18 21:30:38 assu kernel: [ 1.843128] [drm:intel_dp_compute_config], clamping display bpc (was 24) to eDP (18) 43129] [drm:intel_modeset_pipe_config], [CRTC:3] Jun 18 21:30:38 assu kernel: [ 1.843130] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1 Jun 18 21:30:38 assu kernel: [ 1.843131] [drm:__intel_set_mode], set mode pipe masks: modeset: 1, prepare: 1, disable: 4 Jun 18 21:30:38 assu kernel: [ 1.843132] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on Jun 18 21:30:38 assu kernel: [ 1.843134] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on Jun 18 21:30:38 assu kernel: [ 1.843135] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 Jun 18 21:30:38 assu kernel: [ 1.843139] [drm:ironlake_edp_backlight_off], With rc2, fails: [ 1.442933] [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz [ 1.442935] [drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18 [ 1.442935] [drm:intel_dp_compute_config], DP link bw required 249804 available 259200 [ 1.442937] [drm:intel_modeset_pipe_config], [CRTC:3] [ 1.442938] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1 [ 1.442938] [drm:__intel_set_mode], set mode pipe masks: modeset: 1, prepare: 1, disable: 4 [ 1.442940] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 1.442942] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on [ 1.442943] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 [ 1.442947] [drm:ironlake_edp_backlight_off],
Possibly related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070978/comments/9
If I use intel_dp.c from rc1, the internal screen comes up OK with rc2, so appears the issue is with changes to intel_dp.c. Changes between rc1 & rc2 include removing a code segment which has the clamping debug message. (Then fails with "Unknown symbol intel_dp_stop_link_train (err 0)")
Looks like it's a matter of code execution order, that the intention was to keep the clamping code (sans the debug message) but the different execution order breaks things at least for this computer. This patch fixes it for me with 3.10-rc2. I'll test with a later kernel. # diff -c intel_dp.c.virgin intel_dp.c *** intel_dp.c.virgin 2013-05-21 00:37:38.000000000 +0300 --- intel_dp.c 2013-06-18 22:42:44.404142315 +0300 *************** *** 702,709 **** /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = min_t(int, 8*3, pipe_config->pipe_bpp); - if (is_edp(intel_dp) && dev_priv->edp.bpp) - bpp = min_t(int, bpp, dev_priv->edp.bpp); for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(target_clock, bpp); --- 702,707 ---- *************** *** 742,748 **** intel_dp->link_bw = bws[clock]; intel_dp->lane_count = lane_count; adjusted_mode->clock = drm_dp_bw_code_to_link_rate(intel_dp->link_bw); - pipe_config->pipe_bpp = bpp; pipe_config->pixel_target_clock = target_clock; DRM_DEBUG_KMS("DP link bw %02x lane count %d clock %d bpp %d\n", --- 740,745 ---- *************** *** 755,760 **** --- 752,761 ---- target_clock, adjusted_mode->clock, &pipe_config->dp_m_n); + if (is_edp(intel_dp) && dev_priv->edp.bpp) + bpp = min_t(int, bpp, dev_priv->edp.bpp); + pipe_config->pipe_bpp = bpp; + return true; }
Created attachment 105281 [details] Here's a suggested patch against 3.10-rc6 Here's a suggested patch which fixes the bug for 3.10-rc6. Needs checking from someone familiar with kernel code. Someone should look up the rationale to changes to intel-dp.c between 3.10-rc1 and 3.10-rc2 and check that this doesn't break something which those changes might have fixed.
Patches for 3.10-rc2 and 3.10-rc6 are the same patch, no code changes. The patch keeps the exact same code as the original broken -rc2, just modifies code to be executed at a different time than in the original.
Ah, your patch makes it compute the bw/lanes/clocks required for bpp=24 and then clamps it down to 18. So in the working config, it selects 2 lanes at clock 0xa - but then fails when we believe we can downclock to 0x6. An alternative would to be to apply a small amount of fudge: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 24a44ed..3ad6bef 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -102,7 +102,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) static int intel_dp_link_required(int pixel_clock, int bpp) { - return (pixel_clock * bpp + 9) / 10; + return (pixel_clock * bpp + 9) / 10 * 40 / 39; } static int which would ensure that there was always 2.5% overprivisioning in the link.
*** Bug 59771 has been marked as a duplicate of this bug. ***
From bug 59771, the offending commit is: commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" This reverts commit 57c219633275c7e7413f8bc7be250dc092887458. It's an ugly hack for a Haswell SDV platform where the vbt doesn't seem to fully agree with the panel. Since it seems to cause issues on real eDP platform let's just kill this hack again.
fyi: the problem only occurs on my dell xps 13, when booting in uefi mode, with gummiboot. bios-mode and syslinux work fine.
(In reply to Ulf Winkelvos from comment #18) > fyi: the problem only occurs on my dell xps 13, when booting in uefi mode, > with gummiboot. bios-mode and syslinux work fine. If you boot with gummiboot instead of syslinux does the bios not light up the integrated panel per chance? We're aware of some issues with eDP that only happen when the bios hasn't lit up the panel at boot.
No, it is not like that, but there is a difference regarding the screen resolution. When i boot in legacy mode i can select linux bootloader (gummiboot) from the bootmenu and it shows up at VGA or SVGA or something like that. The kernel boots up fine from there and chooses the correct mode. When i boot in uefi only mode screen resolution in gummiboot seems to be full-hd(ish) and mode switching while the kernel boots up fails.
*** Bug 60527 has been marked as a duplicate of this bug. ***
Same issue here. Spent a couple hours doing a bisect which allowed Chris to connect this problem to mine.
@danvet: For me on my xps13 if I enable a "legacy" option in the system setup, but still use UEFI+Gummiboot then the display brightness controls don't work. I forget exactly what that option is called tho', but I've had no problems since turning it off. Ping me if you want some separate info/tests about that issue.
I only wonder why Daniel reverted commit 57c219633275c7e7413f8bc7be250dc092887458 when the hack was "fixing" a real thing rather than fixing the underlying problem. I guess that this is hardware specific and the only way to deal with it is through quirks (hence the revert, which uncovers the bug for many people that are now here to report the needed hardware details).
(In reply to Fabio Erculiani from comment #24) > I only wonder why Daniel reverted commit > 57c219633275c7e7413f8bc7be250dc092887458 when the hack was "fixing" a real > thing rather than fixing the underlying problem. I guess that this is > hardware specific and the only way to deal with it is through quirks (hence > the revert, which uncovers the bug for many people that are now here to > report the needed hardware details). Fabio, what hardware info do you need reported to get this properly quirked?
(In reply to Gabriel A. Devenyi from comment #25) > Fabio, what hardware info do you need reported to get this properly quirked? I am not working on a patch myself nor I know many details about what's going on, I just guessed that it might be a hardware specific bug (repeat: guessed).
Looks like there's no fix in 3.11-rc3, I still have no video. Is there any more information needed to support a fix?
Is this bug report perhaps the same thing? https://bugs.freedesktop.org/show_bug.cgi?id=64880
As is this one https://bugs.freedesktop.org/show_bug.cgi?id=65995
Created attachment 107087 [details] Patch against 3.11-rc3 This patch fixes graphical corruption on Dell XPS 13, but brightness controls still do not work. Test booted from EFI Grub.
Created attachment 107092 [details] new approach for the edp bpp clamping mess Please test, this hopefully fixes these regressions here without breaking other stuff. For code correctness we _must_ clamp the bpp value before the dp bandwidthc conputation code. This patch here hopefully results in a correct config on a few more machines.
[Dell XPS13 with UEFI+Gummiboot] Tried this on top of 3.11-rc4 (needed to hack back in the DRM_DEBUG_KMS() call that seems to have gone from there, before this patch applied) After that I tried a reboot but got a very dark screen, tried again and got a slightly less dark screen but still corrupt in the same way as before, so no progress from my perspective I'm afraid. Want me to try it on top of a different version (3.10.x didn't seem to give me any backlight problems last time I tried it)
(In reply to Daniel Vetter from comment #31) > Created attachment 107092 [details] > new approach for the edp bpp clamping mess > > Please test, this hopefully fixes these regressions here without breaking > other stuff. For code correctness we _must_ clamp the bpp value before the > dp bandwidthc conputation code. This patch here hopefully results in a > correct config on a few more machines. Can you make a patch for the latest stable kernel please? (3.10.5 at this time). Thanks!
0001-new-approach-for-the-edp-bpp-clamping-mess.patch does not resolve the problem for me on 3.11-rc4 with my XPS 13. Both graphical corruption as well as a very dark display, so actually worse than attachment 107087 [details] (dark display and no brightness controls but no corruption). I'm happy to try any other approach; would like to get this resolved in the 3.11 cycle, still stuck on 3.9 here.
I'd like to try the patch but I haven't gotten it to successfully apply yet. What series is it based on?
(In reply to Gabriel A. Devenyi from comment #35) > I'd like to try the patch but I haven't gotten it to successfully apply yet. > What series is it based on? Patch should apply on top of 3.11-rc kernels, maybe with a few offsets (it's based on latest drm-intel trees). But it sounds like it's the wrong approach, but confirming that can't really hurt.
Not to mention that with 3.10 (tested up to 3.10.4, I didn't test 3.10.5 yet) I get complete screen corruptions after resume from suspension, while 3.9 was working completely fine. My hardware is Asus UX32VD with IVB (I posted the full specs in the other duplicate bug).
(In reply to Daniel Vetter from comment #36) > (In reply to Gabriel A. Devenyi from comment #35) > > I'd like to try the patch but I haven't gotten it to successfully apply > yet. > > What series is it based on? > > Patch should apply on top of 3.11-rc kernels, maybe with a few offsets (it's > based on latest drm-intel trees). But it sounds like it's the wrong > approach, but confirming that can't really hurt. /storage/linux-3.11-rc4$ patch -p1 < ../intel.patch patching file drivers/gpu/drm/i915/intel_dp.c Hunk #1 FAILED at 729. 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_dp.c.rej Same issue with 3.10.5, is this perhaps relying on some other changes in drm-intel which is causing the other corruption problems as well? I can try and checkout drm-intel and see how it goes I guess.
Confirmed that applying the patch to drm-intel doesn't work, same problem of no display at all on boot.
Anything new we can try?
Created attachment 107199 [details] never use bios provided bpp, but log the value Booting 3.11-rc5 works fine from legacy mode. (see my previous comment) Booting from uefi mode triggers this bug (and the very dark screen bug that was described here too on the dell xps 13). Using the provided patch and booting once from legacy and on uefi mode, gives the following results. legacy mode - working without the patch: [ 1.570344] [drm:intel_dp_compute_config], BPPHACK - pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 24 uefi-mode - not working without the patch: [ 1.772969] [drm:intel_dp_compute_config], BPPHACK - pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 18 --- OT: brightness controls 3.11-rc5 seems to be the first kernel I tried, where brightness control work, when booting in legacy mode. It does not work in UEFI mode though, that used to work when using acpi_backlight=vendor.
(In reply to Ulf Winkelvos from comment #41) > Created attachment 107199 [details] > never use bios provided bpp, but log the value This hack allows me to boot 3.11-rc5 successfully. Thanks!
(In reply to Gabriel A. Devenyi from comment #28) > Is this bug report perhaps the same thing? This one is: https://bugs.freedesktop.org/show_bug.cgi?id=67950 HD4000 within ASUS UX31A, shim+grub2, ALT Linux, two distinct users; since 3.10.0 legacy boot or UEFI w/CSM enabled does work and UEFI w/o CSM results in blank screen (no eDP backlight and no image). We've bisected drm/i915 down to: # first bad commit: [3600836585e3fdef0a1410d63fe5ce4015007aac] drm/i915: convert DP autodither code to new infrastructure (In reply to Ulf Winkelvos from comment #41) > Created attachment 107199 [details] > never use bios provided bpp, but log the value Works for me under UEFI w/o CSM again. > --- > OT: brightness controls Might be also related (let's move to b.fd.o if xf86-video-intel is relevant): http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=ce1e0969058f8c70b624bc85bb8d6698a35794d3 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741
> Created attachment 107199 [details] > never use bios provided bpp, but log the value > > Booting 3.11-rc5 works fine from legacy mode. (see my previous comment) > Booting from uefi mode triggers this bug (and the very dark screen bug that > was described here too on the dell xps 13). Using the provided patch and > booting once from legacy and on uefi mode, gives the following results. > > legacy mode - working without the patch: > [ 1.570344] [drm:intel_dp_compute_config], BPPHACK - > pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 24 > > uefi-mode - not working without the patch: > [ 1.772969] [drm:intel_dp_compute_config], BPPHACK - > pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 18 > > --- > OT: brightness controls > 3.11-rc5 seems to be the first kernel I tried, where brightness control > work, when booting in legacy mode. It does not work in UEFI mode though, > that used to work when using acpi_backlight=vendor. I confirm the same with ASUS Zenbook ux32vd This patch https://bugzilla.kernel.org/attachment.cgi?id=107199&action=diff really works fine with 3.11 kernel allowing brightness controls with "acpi_osi="
Looks like the IPS panels that can show 24 bpp, need to be configured to use 24bpp. I have got no idea why its different for the mac book retina.
Not sure if the bug was ever fixed in the mainline kernel tree after the report (thought it was, but might be mistaken). Anyway, if it was fixed, the bug has reappeared - no image on internal display. Hardware: Asus Transformer Book TX300 (4005) (Intel HD4000 graphics) Software: Ubuntu 13.04 Kernel: 3.11.0-rc6 and 3.11.0-rc6-wl+ (wireless-testing 2013-08-23)
The patch at https://bugzilla.kernel.org/attachment.cgi?id=107199&action=diff doesn't help for the Transformer Book TXT300.
Also a quick attempt (below) to repeat my previous simple code rearrangement fix doesn't help - but the code appears to have changed meanwhile, so I'll probably have to take a closer look. --- drivers/gpu/drm/i915/intel_dp.c.orig 2013-08-25 10:30:20.874203289 +0300 +++ drivers/gpu/drm/i915/intel_dp.c 2013-08-25 11:18:34.471952195 +0300 @@ -710,8 +710,8 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) - bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + // if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + // bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp); @@ -749,7 +749,7 @@ intel_dp->link_bw = bws[clock]; intel_dp->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; + // pipe_config->pipe_bpp = bpp; pipe_config->port_clock = drm_dp_bw_code_to_link_rate(intel_dp->link_bw); DRM_DEBUG_KMS("DP link bw %02x lane count %d clock %d bpp %d\n", @@ -764,6 +764,11 @@ intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw); + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + + pipe_config->pipe_bpp = bpp; + return true; }
My last two messages about the patches might be incorrect - failed to update the initrd, just reinstalled the module, but come to think of it the i915.ko is in initrd and maybe is loaded from initrd.
Retested - attachment 107199 [details] doesn't fix the problem for the TX300, but my simple code rearrangement patch does fix the bug. Code repeated below. --- drivers/gpu/drm/i915/intel_dp.c.orig 2013-08-25 10:30:20.874203289 +0300 +++ drivers/gpu/drm/i915/intel_dp.c 2013-08-25 11:18:34.471952195 +0300 @@ -710,8 +710,8 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) - bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + // if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + // bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp); @@ -749,7 +749,7 @@ intel_dp->link_bw = bws[clock]; intel_dp->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; + // pipe_config->pipe_bpp = bpp; pipe_config->port_clock = drm_dp_bw_code_to_link_rate(intel_dp->link_bw); DRM_DEBUG_KMS("DP link bw %02x lane count %d clock %d bpp %d\n", @@ -764,6 +764,11 @@ intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw); + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + + pipe_config->pipe_bpp = bpp; + return true; }
Please retest with latest drm-intel-fixes, specifically commit 2e6efddd203c15ca5c4700511f717c0e9a3ea31a Author: Imre Deak <imre.deak@intel.com> Date: Fri Aug 23 23:50:23 2013 +0300 drm/i915: ivb: fix edp voltage swing reg val http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=2e6efddd203c15ca5c4700511f717c0e9a3ea31a
No, that does not work either. Very dark and disorted screen, when booting from uefi on dell xps 13.
(In reply to Ulf Winkelvos from comment #52) > No, that does not work either. Very dark and disorted screen, when booting > from uefi on dell xps 13. Which patch are you referring to? There's tons of them floating around ...
The one-line patch referred to below doesn't fix the issue for the TX300. drm/i915: ivb: fix edp voltage swing reg val http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=2e6efddd203c15ca5c4700511f717c0e9a3ea31a
How can I apply "latest drm-intel-fixes", are they patches somewhere, a git repo, something else?
(In reply to jkp from comment #55) > How can I apply "latest drm-intel-fixes", are they patches somewhere, a git > repo, something else? The one line patch you've tested is the one from the drm-intel-fixes branch I wanted to get tested. But looks like this isn't the right solution :(
commit ff7528fe24d3576a7472d37ebdf665ad092ba6a2 (In reply to Daniel Vetter from comment #53) > (In reply to Ulf Winkelvos from comment #52) > > No, that does not work either. Very dark and disorted screen, when booting > > from uefi on dell xps 13. > > Which patch are you referring to? There's tons of them floating around ... the post was supposed to be an answer to your last comment at that time. (comment 51) I built drm-intel-fixes from your git repo.
OK - well, things work for me with the code rearrangement above, with and without the one-line patch. But maybe the rearrangement won't work for some other machines. I can test other possible solutions. Would be nice to have the display working with the stock kernel. Maybe resort to some kind of bpp=xx module parameter if nothing else.
Привет Проверь, пожалуйста: 103104 А
A workaround to make things work on the TX300: switch CSM on in BIOS/UEFI settings, then e.g. unpatched 3.11.0-rc6 and 3.10.9 kernels work, a picture is shown on internal display.
I can confirm that the same workaround works on a Asus UX32VD (enable "Launch CSM" in BIOS) with stock kernel 3.10.9-1-ARCH.
It is true, with enabled "Launch CSM" in BIOS laptop starts with normal screen IF no another screen is connected. But the big problem is when another external screen is connected before booting. The internal screen is black in this case, and all the process of booting is displayed on the external screen and no way to switch on the internal screen even after boot. I work on ASUS Zenbook UX32VD with 2 external monitors connected through VGA and HDMI and the only way to work for me is keeping CSM disabled and patching kernel. At the moment I enjoy this patch https://aur.archlinux.org/packages/linux-ak/ which is created thanks to jkp (attachment 107199 [details] https://bugzilla.kernel.org/attachment.cgi?id=105281&action=edit). It does work perfectly. Any other workaround with CSM it's no solution at all. Another patch which worked for me also was this https://bugzilla.kernel.org/attachment.cgi?id=107199&action=diff
(with the CSM on workaround with more than one display) "The internal screen is black in this case, and all the process of booting is displayed on the external screen and no way to switch on the internal screen even after boot." Probably the same way on the TX300. I can confirm it definitely is the same way at boot with a HDMI monitor connected to the micro HDMI connector, boot process is displayed only on the external screen. Didn't try whether I could switch the internal display on after boot, but as other things look to be the same that you have, probably not.
Hmm - I wonder if I still had some testing error at my attachment 107199 [details] retest, as my experience was that attachment 107199 [details] didn't fix it for me on the TX300. Guess I'll have to test yet another time and double-check again that the module gets into initrd.
(In reply to ZeroBit from comment #62) > It is true, with enabled "Launch CSM" in BIOS laptop starts with normal > screen IF no another screen is connected. > But the big problem is when another external screen is connected before > booting. The internal screen is black in this case, and all the process of > booting is displayed on the external screen and no way to switch on the > internal screen even after boot. > > I work on ASUS Zenbook UX32VD with 2 external monitors connected through VGA > and HDMI and the only way to work for me is keeping CSM disabled and > patching kernel. > At the moment I enjoy this patch > https://aur.archlinux.org/packages/linux-ak/ which is created thanks to jkp > (attachment 107199 [details] > https://bugzilla.kernel.org/attachment.cgi?id=105281&action=edit). It does > work perfectly. Any other workaround with CSM it's no solution at all. > Another patch which worked for me also was this > https://bugzilla.kernel.org/attachment.cgi?id=107199&action=diff This is very likely a different bug, at least I've seen this one here since forever on my on ivb machine. We seem to have a really hard time to light up the eDP panel when the BIOS hasn't switched it on.
(In reply to Anton Boyarshinov from comment #59) > Check build task 103104 please "bad" (reverts a647ba030d6b93c7430df4034e82506054076c6c with conflicts). (In reply to jkp from comment #60) > A workaround to make things work on the TX300: switch CSM on See comment 43. :) (In reply to Daniel Vetter from comment #65) > We seem to have a really hard time to light up the eDP panel > when the BIOS hasn't switched it on. At least one of these bugs is not about backlight alone -- Kirill Shutemov asked to shine some external light on the panel to see whether there's image at all and there was none in my case (the same comment 43 linking to my bugreport done at his request: https://bugs.freedesktop.org/show_bug.cgi?id=67950). Seems a bpp issue indeed.
Ah, yes - guess I didn't recognize what CSM is at the time of reading that on this thread, and whether the TX300 has it. Then saw it mentioned on linlap TX300 page and had forgotten about the mention here, did recall that something like that was talked about. I've also tried to see the image with external light, can't see anything on the TX300 - at least some older computers with a broken backlight clearly show a dim image with an external light (and internal light off), so seems to me also that there's no image. (Or the tech has changed significantly but I doubt it).
Hi Guys, I have applied patch from jkp for 3.10.9 and it's running fine on asus zenbook ux21a ivb core i7. Since im using arch linux i've submitted linux-ak package to AUR. Those who are on arch may try https://aur.archlinux.org/packages/linux-ak/ Thanks, Jkp!
Hi, * Good that my patch is useful Alexey * Rechecked with attachment CSM off with patch fom attachment 107199 [details] - that doesn't fix the bug with 3.10.9 nor with 3.11-rc6. And I noticed backlight is lit as it should with this patch, there's just no image. (Don't recall for sure if it's the same without the patch) * Can someone summarize the status of what's going on with getting a fix incorporated? Is the problem that fixes, e.g. my simple code rearrangement fix, break things for some other machines? Is there something I/we could do to move things on? If the issue is intractable for now, would there be a possibility of introducing a user-specified module load parameter to have things manually, if e.g. I write code for it?
Tried this suggested patch from comment 15, doesn't help on the TX300. diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 24a44ed..3ad6bef 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -102,7 +102,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) static int intel_dp_link_required(int pixel_clock, int bpp) { - return (pixel_clock * bpp + 9) / 10; + return (pixel_clock * bpp + 9) / 10 * 40 / 39; } static int which would ensure that there was always 2.5% overprivisioning in the link.
The simple form of the "code rearrangement" patch, this is sufficient to make the display work for the TX300: --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c 2013-09-01 19:02:08.078876637 +0300 @@ -710,8 +710,8 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) - bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + //if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + // bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
.. which is functionally identical to the patch in attachment 107199 [details], so that should work, too, though according to my earlier tests it doesn't. ??
.. and yes, retesting with 3.11.0-rc7, patch in attachment 107199 [details] works for the TX300. Earlier tests where with 3.11.0-rc6 kernel. Not sure if there's a relevant difference between rc6 & rc7 or if the wlan-testing version of rc6 somehow messed the test setup or was there some other issue with the test setup.
With patch from attachment 107199 [details], booting with drm.debug=0xe: [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz [drm:intel_dp_compute_config], BPPHACK - pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 18 [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24 [drm:intel_dp_compute_config], DP link bw required 333072 available 432000 [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 24, dithering: 0
Trying to get the picture here of what's going on, please correct me if I'm wrong: 1) The offending commit (which breaks things for TX300 & many others) is this one by Daniel on 2013-05-04 (from comment 17): http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624 2) From comment 31 by Daniel, apparently on some computers, the bpp value must be clamped before the dp bandwidth computation code, thus the addition of "bpp = min_t(int, bpp, dev_priv->edp.bpp);" by Daniel, currently "bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);". Is this correct? 3) However the clamping "bpp = min_t() line breaks things for many computers, e.g. the TX300 and others. The bpp value from BIOS (intel_bios.c / dev_priv->vbt.edp_bpp) appears to be 18 on the TX300, but apparently the bpp value to be used is 24 from pipe_config-> pipe_bpp. 4) To make things work on TX300 and others as well as the computers Daniel is talking about (which one(s)?), we'll some kind of way to differentiate between computers which need the bpp = min_t line and computers which must not use it.
Wondering if the issue could be handled by fixing how intel_bios.c seems to get the panel panel bpp value wrong, I added debug output to see panel_type. Can't say that this is obviously wrong, don't know enough: [drm:parse_edp], BDB panel type: 14 --- intel_bios.c~ 2013-09-01 20:17:51.619505432 +0300 +++ intel_bios.c 2013-09-01 21:24:44.404296932 +0300 @@ -506,7 +506,9 @@ return; } + DRM_DEBUG_KMS("BDB panel type: %d \n", panel_type); + switch ((edp->color_depth >> (panel_type * 2)) & 3) { case EDP_18BPP: dev_priv->vbt.edp_bpp = 18; break;
Did some debug info output, and it appears on the TX300 that the BDB_EDP data block edp->color_depth value is zero all the way, regardless of panel_type value.
Maybe related patch: http://web.archiveorange.com/archive/v/UsR4n6eJf4qikXnBjT19
Added some debug messages to intel_bios.c: DRM_DEBUG_KMS("edp_support: %d\n", dev_priv->vbt.edp_support); DRM_DEBUG_KMS("SUPPORTS_EDP: %d\n", SUPPORTS_EDP(dev_priv->dev)); before the line: switch ((edp->color_depth >> (panel_type * 2)) & 3) { Output says the edp_support flag is not set: [drm:parse_edp], edp_support: 0 [drm:parse_edp], SUPPORTS_EDP: 0 A bug? No EDP support indicated by the device, but color_depth from edp is used anyway. Proposed fix, instead of: if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); in intel_dp.c, check also for edp_support: if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_support) bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); Will test. Maybe other bogus edp info is also set in parse_edp due to ignoring the edp support flag. (This assuming I've understood the edp support flag correctly and it works; not familiar with the code & panels, so could be I'm completely at the wrong track)
Confirmed to work. Daniel, can you check on whether you think this is a good approach, and whether this patch works for the case for which you say the clamping is needed? --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c 2013-09-02 00:44:41.580152297 +0300 @@ -710,7 +710,7 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_support) bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) {
Proposed patch (to be applied in addition to the previous one) for some debug output and disabling the use of the EDP data when info says EDP is not available. Tested to work on the Asus TX300. Hmm, on second thought, more correct would probably be just: if (!dev_priv->vbt.edp_support) { ... instead of including SUPPORTS_EDT as in the patch. --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_bios.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_bios.c 2013-09-02 00:55:30.488888674 +0300 @@ -499,6 +499,15 @@ struct edp_power_seq *edp_pps; struct edp_link_params *edp_link_params; + DRM_DEBUG_KMS("edp_support: %d\n", dev_priv->vbt.edp_support); + DRM_DEBUG_KMS("SUPPORTS_EDP: %d\n", SUPPORTS_EDP(dev_priv->dev)); + DRM_DEBUG_KMS("BDB panel type: %d \n", panel_type); + + if (!SUPPORTS_EDP(dev_priv->dev) && !dev_priv->vbt.edp_support) { + DRM_DEBUG_KMS("No eDP support, not trying to parse BDB_EDP section.\n"); + return; + } + edp = find_section(bdb, BDB_EDP); if (!edp) { if (SUPPORTS_EDP(dev_priv->dev) && dev_priv->vbt.edp_support)
Tested the above two patches also in CSM mode on the TX300. Panel type is reported as "7", and while the computer starts with only the external (HDMI) display when two monitors are connected, after starting X with "startx", I can use both the external and the internal display. A weird thing is however that keyboard & mouse clicks won't work on gdm so I can't log in normally, but have to log in at text console and then run startx. But this perhaps is related to CSM mode instead of the i915.ko changes.
The SUPPORTS_EDP macro is bullocks, it should be 1 for your machine. So using that is just another form of duct-tape.
Created attachment 107384 [details] more strict edp_bpp setting I've pushed a few patches to http://cgit.freedesktop.org/~danvet/drm/log/?h=kbz-59841 aggregate patch is also attached. Please test. Wrt testing the offending machine which seems to need this hack: I don't have it, the regression which lead to the patch causing your regression was reported externally.
@Daniel: Just tested your kbz-59841 branch. gummiboot+uefi boot on a recent Dell XPS13. Display is very dim due to the backlight control issues, but the real problem is still that the display is totally corrupted (so far, for me at least, all 3.10.* kernels have not worked on this h/w). To my uneducated eye it appears like a problem of tiling as the image is still visible, it's just all squashed up and jumps around a lot.
I applied attachment 107384 [details] (more-strict-edp_bpp.patch) to 3.11-rc7 and the result on my Dell XPS 13 is a very dark and scrambled picture with no brightness control. The two patches in comment 81 and comment 82 result in a normal picture, but very dark and no brightness control.
Created attachment 107385 [details] dmesg on xps 13 with drm.debug=0xe Sorry, comment 86 should refer to patches in comment 81 and comment 82. Furthermore, with drm.debug=0xe, the result is: [ 0.476425] [drm:parse_edp], edp_support: 0 [ 0.476426] [drm:parse_edp], SUPPORTS_EDP: 0 [ 0.476427] [drm:parse_edp], BDB panel type: 2 [ 0.476429] [drm:parse_edp], No eDP support, not trying to parse BDB_EDP section. Full dmesg attached.
Can't test patch in attachment 107384 [details] right now (will do later today), but while the changes look well and reasonable, since you say SUPPORTS_EDP should be true for TX300, I can't see how the changes would solve the bug with the TX300. Wouldn't fixing require changing the min_t (int, 24, 18) clause in intel_dp.c? Perhaps by triggering on recognizing the device? 00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics Control ler (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 15b7 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied>
From Daniel's commit message at http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624: "It's an ugly hack for a Haswell SDV platform where the vbt doesn't seem to fully agree with the panel. Since it seems to cause issues on real eDP platform let's just kill this hack again." .. this seems to confirm the issue is that some (TX300, Asus UX32VD, Dell XPS13, a Haswell SDV platform) (call them type A) give bogus info for bpp in edp vbt data in UEFI mode. To be more specific, they give 18 bpp (value of 0 in color_depth) when the value should be 24 (value 1). But for some other machine(s?) (type B), 18 given by vbt data is the value which must be used, and thus the code currently in 3.11-rc7 is needed for type B machines. So, we'd need a way to recognize either type A or type B machines (or both), and modify behaviour accordingly. If only one class can be recognized, make the default behaviour to be the one for the other class. Correct?
Here's a patch to introduce a new module load-time parameter to make i915 ignore the vbe edp bpp value. Off by default, can be added via e.g. grub by GRUB_CMDLINE_LINUX="i915.i915_ignore_edp_bpp=1 ..." in /etc/default/grub and then running update-grub. Tested to work on the Asus TX300. Hopefully something like this could be added to the kernel as an interim solution to make things work for now. Hopefully in the future a smart way can be found to recognize the hardware properties so the user won't have to handle this manually. diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.c linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.c --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.c 2013-09-02 16:07:21.720367365 +0300 @@ -132,6 +132,10 @@ module_param_named(enable_ips, i915_enable_ips, int, 0600); MODULE_PARM_DESC(enable_ips, "Enable IPS (default: true)"); +bool i915_ignore_edp_bpp __read_mostly = false; +module_param_named(i915_ignore_edp_bpp, i915_ignore_edp_bpp, bool, 0600); +MODULE_PARM_DESC(i915_ignore_edp_bpp, "Ignore BDB edp BPP value (default: false)"); + static struct drm_driver driver; extern int intel_agp_enabled; diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.h linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.h --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.h 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.h 2013-09-02 16:02:25.140359422 +0300 @@ -1543,6 +1543,7 @@ extern unsigned int i915_preliminary_hw_support __read_mostly; extern int i915_disable_power_well __read_mostly; extern int i915_enable_ips __read_mostly; +extern bool i915_ignore_edp_bpp __read_mostly; extern int i915_suspend(struct drm_device *dev, pm_message_t state); extern int i915_resume(struct drm_device *dev); diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c 2013-09-02 16:03:35.360361303 +0300 @@ -710,7 +710,7 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp && !i915_ignore_edp_bpp) bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) {
I applied attachment 107384 [details] to 3.11-rc7 and the result on the TX300 is that there's no visible difference to unpatched 3.11-rc7 - internal display is black.
jkp: your proposed patch in comment 90 solves the graphical corruption on XPS 13, but there is still no backlight/brightness control. No combination of acpi_osi=Linux and/or acpi_backlight=vendor has any effect. Unless backlight control is a separate issue, for XPS 13 proposed patch in comment 90 does not fully resolve the issue. Backlight is unchangeable, with or without Xorg.
I think backlight/brightness control is a separate issue, not sure though. I've seen variance in backlight control of different kernels on the TX300 and it's seemed to be quite separate from the issue in this bug report. I think part of it is a separate asus_nb_wmi module. Do you know of a patch or kernel version with which backlight/brightness control works on the XPS 13?
I use "acpi_osi= " with which my backlight/brightness control works, but might work with others, too, not sure.
By failing backlight / brightness control, are you referring to brightness key controls or changing via the device controls? I've noticed these to be different - sometimes when the key control doesn't work (and I think also the Ubuntu gnome control center brightness adjustment didn't work), I could adjust brightness by writing values to the appropriate device file.
Also I've seen different device files for brightness adjustment where one device file worked and the other didn't, forgot the details though.
On XPS 13, brightness controls work out of the box on 3.9.0-rc7, 3.9.5 and 3.9.11; 3.10 is when the graphical corruption started to occur, and I haven't had a fully working display since on any 3.10/3.11. And when I'm saying it's broken on 3.11, I mean that a) buttons are functioning (e.g. Xorg shows a brightness popup that changes) but have no effect, b) echo X > /sys/.../drm/card0/card0-eDP-1/intel_backlight/brightness has no effect, c) echo X > /sys/.../backlight/acpi_video0/brightness has no effect. All of this works fine on any 3.9 kernel. I am merely assuming that this was broken together with the graphical corruption problem.
Hmm - comparing 3.9.5 to 3.11-rc7, these have been introduced: /* Dell XPS13 HD Sandy Bridge */ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable }, /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable }, a comment on that: * Some machines (Dell XPS13) suffer broken backlight controls if * BLM_PCH_PWM_ENABLE is set. */ Maybe you can try disabling that to see if it helps.
The quirk influences turning on of backlight in intel_panel.c intel_panel_enable_backlight()
@jkp: thanks, that lead me to https://bugzilla.kernel.org/show_bug.cgi?id=47941 and that combined with your patch in comment 90 works with EFI GRUB and direct EFI boot.
Here's a patch which contains both the boot param (same as the previous patch) and a device-specific quirk for the TX300, so that no manual user intervention is required. Other devices could be added the same with with ids from output of lspic -nn -v. Problem with this approach might be that there may be devices with the same controller but a 18 bpp panel? # lspci -nn -v 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA contro ller]) Subsystem: ASUSTeK Computer Inc. Device [1043:15b7] diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.c linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.c --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.c 2013-09-02 16:56:09.971164152 +0300 @@ -132,6 +132,10 @@ module_param_named(enable_ips, i915_enable_ips, int, 0600); MODULE_PARM_DESC(enable_ips, "Enable IPS (default: true)"); +bool i915_ignore_edp_bpp __read_mostly = false; +module_param_named(i915_ignore_edp_bpp, i915_ignore_edp_bpp, bool, 0600); +MODULE_PARM_DESC(i915_ignore_edp_bpp, "Ignore BDB edp BPP value (default: false)"); + static struct drm_driver driver; extern int intel_agp_enabled; diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.h linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.h --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/i915_drv.h 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/i915_drv.h 2013-09-02 18:24:35.361345416 +0300 @@ -556,6 +556,7 @@ #define QUIRK_LVDS_SSC_DISABLE (1<<1) #define QUIRK_INVERT_BRIGHTNESS (1<<2) #define QUIRK_NO_PCH_PWM_ENABLE (1<<3) +#define QUIRK_INCORRECT_EDP_BPP_ENABLE (1<<4) struct intel_fbdev; struct intel_fbc_work; @@ -1543,6 +1544,7 @@ extern unsigned int i915_preliminary_hw_support __read_mostly; extern int i915_disable_power_well __read_mostly; extern int i915_enable_ips __read_mostly; +extern bool i915_ignore_edp_bpp __read_mostly; extern int i915_suspend(struct drm_device *dev, pm_message_t state); extern int i915_resume(struct drm_device *dev); diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_display.c linux-3.11-rc7/drivers/gpu/drm/i915/intel_display.c --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_display.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_display.c 2013-09-02 18:47:32.830767498 +0300 @@ -9413,6 +9413,16 @@ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n"); } +/* + * Some machines (e.g. Asus TX300) incorrectly return 18bpp in UEFI mode + * from vbe edp data + */ +static void quirk_incorrect_edp_bpp_enable(struct drm_device *dev) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + dev_priv->quirks |= QUIRK_INCORRECT_EDP_BPP_ENABLE; + DRM_INFO("applying INCORRECT_EDP_BPP_ENABLE quirk\n"); +} struct intel_quirk { int device; int subsystem_vendor; @@ -9487,6 +9497,9 @@ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable }, /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable }, + + /* Asus TX300 15b7 */ + { 0x0166, 0x1043, 0x15b7, quirk_incorrect_edp_bpp_enable }, }; static void intel_init_quirks(struct drm_device *dev) diff -ur linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c --- linux-3.11-rc7.virgin/drivers/gpu/drm/i915/intel_dp.c 2013-08-26 03:43:22.000000000 +0300 +++ linux-3.11-rc7/drivers/gpu/drm/i915/intel_dp.c 2013-09-02 18:31:36.649356698 +0300 @@ -710,7 +710,8 @@ /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp && !i915_ignore_edp_bpp + && !(dev_priv->quirks & QUIRK_INCORRECT_EDP_BPP_ENABLE)) bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); for (; bpp >= 6*3; bpp -= 2*3) {
Looking at the quirk table, appears the device id on the XPS13 is the same, so instead of: + { 0x0166, 0x1043, 0x15b7, quirk_incorrect_edp_bpp_enable }, having this in the patch: + { 0x0166, PCI_ANY_ID, PCI_ANY_ID, quirk_incorrect_edp_bpp_enable }, would cover the quirk for both the TX300 and XPS13, and perhaps also for the other ASUS mentioned in this thread.
details of the other hardware: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1507] Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at f7400000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915
So, that Asus (which model?) would also by matched by: + { 0x0166, PCI_ANY_ID, PCI_ANY_ID, quirk_incorrect_edp_bpp_enable }, or, if we want to be specific, with: + { 0x0166, 0x1043, 0x1507, quirk_incorrect_edp_bpp_enable },
Sorry that's a UX32VD revision 2 (sold as the UX32VD), there's a slightly older version denoted UX32VDA but I'm not sure of hardware differences.
Created attachment 107388 [details] Patch: add quirk and modules param for ignoring vbe edp bpp value For Dell XPS13 and ASUS TX300 & UX32VD & others with 0x0166 device.
I added a new version of the patch as attachment 107388 [details], should work for Dell XPS13 and ASUS TX300 & UX32VD & other machines with 0x0166 device.
Michael, can you show "lspci -nn -v" output for the VGA device on ASUS UX31A?
(In reply to jkp from comment #106) > Created attachment 107388 [details] > Patch: add quirk and modules param for ignoring vbe edp bpp value > > For Dell XPS13 and ASUS TX300 & UX32VD & others with 0x0166 device. Confirmed this patch applied on 3.11 works with the UX32VD.
Ah, so 3.11 is out - fixing this didn't make it to 3.11 then. Daniel, others, how best to work towards getting this merged?
(In reply to jkp from comment #108) > Michael, can you show "lspci -nn -v" output for the VGA device on ASUS UX31A? Here you are: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A [1043:1517] Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 (In reply to jkp from comment #110) > Ah, so 3.11 is out - fixing this didn't make it to 3.11 then. Hope the fix gets into 3.{10,11}.x when done and tested.
Thanks, OK, so AX31A also has the same id 0x166 for the controller so the latest patch should work for that machine, too, without modifying boot params. If we want to be more specific, the line would be: + { 0x0166, 0x1043, 0x1517, quirk_incorrect_edp_bpp_enable },
Hi Jkp! The same code rearrengment works for 3.11. As for the brightness i use acpi_osi= kernel arg and my patch which disables changin brighness by i915 driver itself via acpi calls. I prefer to controls brightness via scripts using /sys/class/backlight/intel_brightness/* $ cat i915-disable-acpi-backlight-change.patch --- drivers/gpu/drm/i915/intel_opregion.c.orig 2013-09-03 00:46:10.000000000 +0400 +++ drivers/gpu/drm/i915/intel_opregion.c 2013-09-03 18:50:33.563873398 +0400 @@ -160,6 +160,7 @@ #ifdef CONFIG_ACPI static u32 asle_set_backlight(struct drm_device *dev, u32 bclp) { + /* struct drm_i915_private *dev_priv = dev->dev_private; struct opregion_asle __iomem *asle = dev_priv->opregion.asle; @@ -174,6 +175,7 @@ intel_panel_set_backlight(dev, bclp, 255); iowrite32((bclp*0x64)/0xff | ASLE_CBLV_VALID, &asle->cblv); + */ return 0; } For Arch you may find patched kernels at https://aur.archlinux.org/packages/?SeB=m&K=alexey
Simple script for changin brighness: --- #!/bin/sh -e if [[ "$1" = "-h" ]] then echo "Use: $(basename $0) [+/-pcnt]" exit 0 fi max=$(cat /sys/class/backlight/intel_backlight/max_brightness) cur=$(cat /sys/class/backlight/intel_backlight/actual_brightness) if ( echo $1 | egrep "^[-+]{0,1}[0-9]{1,3}$" > /dev/null ) then change=$1 else echo $(($cur *100 / $max ))% exit 0 fi new=$(( $cur + $change * $max / 100)) [[ $new -gt $max ]] && new=$max [[ $new -lt 0 ]] && new=0 echo $new > /sys/class/backlight/intel_backlight/brightness notify-send -u low -h int:value:$(($new *100 / $max )) "Brightness" --- I bind it to keys in IceWM: key "XF86KbdBrightnessUp" XF86KbdBrightness.sh up key "XF86KbdBrightnessDown" XF86KbdBrightness.sh down key "XF86MonBrightnessUp" XF86MonBrightness.sh "+5" key "XF86MonBrightnessDown" XF86MonBrightness.sh "-5"
Linux 3.11.0 still broken on Asus UX32VD. As soon as X starts, the screen becomes pearl black.
Created attachment 107442 [details] Revert commit 657445fe8660100ad174600ebfa61536392b7624 for Asus UX32VD This patch is still needed (it's a revert) to get Asus UX32VD working as reported in bug #60527.
Guys, i am sorry for offtopic. I wonder - why we have lid brightness controlled dirrectly by video drivers reacting on acpi events. I think this is not that handy. Because the algorithm of incrementing brightness is not linear. I myself prefer to have linear at lowest values. Originaly it jumpst from 10% to 20% then then incremtn is 5% after 75% it jumps right to 100%. I don't care about that 75 to 100, but i most of time running on 5% (intel_brightness) and it's ok. I made a simple script which can do any of brightness - 1 , 2 , 3 , etc.. % What do you thin if we have driver parameter to disable reaction on acpi brightness keys ?
Fabio, my latest patch at attachment 107388 [details] is reported to work also on the UX32VD. Compared to the revert you posted, it may be better if you use the kernel on some other compute also which has a different kind of display.
Alexey - can't say why brightness adjustment is the way it is. But I've also noticed that on the TX300 at least the brightness jumps are not that good for my taste - I'd prefer to have more fine-grained control. I'd like to use lower brightness than what the FN keys offer. I've done in occasionally by just echoing to the device files from the shell. An option to turn off brightness key effect (and to possibly direct it to a user-space program if that's possible) would be useful in my opinion.
OK, I notice you describe a way to bind the brightness control script to keys - yes, that looks quite useful to me.
Jkp, A dirty hack, but a quick one.
Since it hasn't been noted here yet (regarding the 18/24 incorrect bpp issue), 0x18 in hex is 24 in decimal. Seems like a hex/decimal confusion issue somewhere, be it in the hardware or the kernel.
Justin, judging from the code, it doesn't seem that that's the issue - the edp_bpp value is set to (decimal) 18 in intel_bios.c from EDP_18BPP constant (0) and EDP_24BPP is constant 1, defined in intel_bios.h. So, the incorrect value in color_depth is 0 when it should be 1. My suspicion is that the root cause is that color_depth just is left empty due to hardware/firmware issue or some kind of incompatibility. switch ((edp->color_depth >> (panel_type * 2)) & 3) { case EDP_18BPP: dev_priv->vbt.edp_bpp = 18; break; case EDP_24BPP: dev_priv->vbt.edp_bpp = 24; break; case EDP_30BPP: dev_priv->vbt.edp_bpp = 30; break; }
Ah, well, that's what I get for not looking at it very closely and just recognizing a numerical coincidence. Sorry for the noise, of course. To contribute something somehat useful as an apology of sorts, this appears to have also hit at least one Toshiba Ivy Bridge ultrabook as well. http://lists.freedesktop.org/archives/intel-gfx/2013-May/028124.html
Would it be possible to only quirk the broken hardware (somehow) so that there is no need for special cmdline parameters? Is there a way to detect such hardware?
Fabio, yes there is a way to detect the hardware (with device PCI id number), and my latest patch does it that way. The kernel load/modprobe parameter is just an extra possibility for the case where there might be a device which isn't recognized properly by the kernel. It may be the detection does not work in all cases, but apparently it works for all machines mentioned in this thread except posssibly the Toshiba Kirabook (no info for that yet). Justin, thanks, I emailed Michael Marineau asking for lspci info, so that machine can be quirked, too, or checked if it's already quirked with the latest version of my patch.
jkp, thanks for the explanation, I missed that patch. Btw, why don't you create your local branch (off 3.11 perhaps), make your changes there and then use `git format-patch` ? Also: + DRM_INFO("applying IGNOE_EDP_BPP quirk\n"); there is a typo: s/IGNOE/IGNORE/.
Unmodified 3.11 also mutes master & headphones when muting the speaker.
Oops, sorry, ignore the previous comment, was meant for another tracker.
Also the Toshiba Kirabook has the same PCI id, so the latest patch should work for it, too. Fabio, a good suggestion, and thanks for the typofix, maybe I'll make a patch with git.
I have now sent patches against current Linus' git tree separately for the quirk and for the module parameter option as instructed by patch submission instructions. Hopefully they will be in a future kernel release.
For reference, patches can be seen e.g. at the following addresses. Won't apply to 3.11 without manual intervention though, there's a debug message about clamping which causes patch not to apply. http://www.spinics.net/lists/kernel/msg1598411.html http://www.spinics.net/lists/kernel/msg1598412.html
Can you attach that patch here as well? Moreover, also make sure that once merged, it will also land in the 3.10 stable queue, since this kernel is also affected.
Ulf, jkp, or anyone seeing the difference between UEFI w/o CSM vs. UEFI w/ CSM vs. legacy boot: Please attach /sys/kernel/debug/dri/0/i915_opregion in working and non-working cases. Please indicate the BIOS mode used clearly in the attachment. Thanks.
Created attachment 107851 [details] TX300 i915_opregion, CSM version
Created attachment 107861 [details] TX300 i915_opregion, UEFI version
Not sure if this is relevant or a different bug, but when booting to CSM mode with one or two external monitors (in which case there's no image in the internal monitor), occasionally I can't get past the login screen. Kernel log from the latest case of this kind of failure: [ 33.150719] ------------[ cut here ]------------ [ 33.150783] WARNING: CPU: 0 PID: 2865 at drivers/gpu/drm/i915/intel_display.c:822 intel_wait_for_pipe_off+0xf6/0x1c [ 33.150784] pipe_off wait timed out [ 33.150829] Modules linked in: parport_pc(F) ppdev(F) lp(F) parport(F) bnep(F) rfcomm(F) binfmt_misc(F) nls_iso8859 ec_hdmi(F) uvcvideo(F) ax88179_178a(F) snd_hda_codec_realtek(F) videobuf2_vmalloc(F) usbnet(F) videobuf2_memops(F) mii v(F) hid_multitouch(F) ath3k(F) snd_hda_intel(F) snd_hda_codec(F) snd_hwdep(F) btusb(F) snd_pcm(F) joydev(F) bluetooth ensor_hub(F) snd_page_alloc(F) snd_seq_midi(F) snd_seq_midi_event(F) asus_nb_wmi(F) asus_wmi(F) snd_rawmidi(F) sparse_ ath9k(F) snd_seq_device(F) ath9k_common(F) snd_timer(F) ath9k_hw(F) ath(F) mac80211(F) cfg80211(F) mac_hid(F) snd(F) p e(F) serio_raw(F) hid_generic(F) usb_storage(F) usbhid(F) hid(F) wmi(F) ahci(F) libahci(F) i915(F) video(F) i2c_algo_b ) [last unloaded: ipmi_msghandler] [ 33.150843] CPU: 0 PID: 2865 Comm: Xorg Tainted: GF W 3.11.0 #4 [ 33.150845] Hardware name: ASUSTeK COMPUTER INC. TX300CA/TX300CA, BIOS TX300CA.207 01/03/2013 [ 33.150851] 0000000000000009 ffff880114cc17b0 ffffffff816a76b9 ffff880114cc17f8 [ 33.150855] ffff880114cc17e8 ffffffff8104d2ac ffff880113980000 0000000000070008 [ 33.150858] 00000000fffefb58 ffff880114cc1fd8 ffff8801186bb470 ffff880114cc1848 [ 33.150859] Call Trace: [ 33.150870] [<ffffffff816a76b9>] dump_stack+0x45/0x56 [ 33.150877] [<ffffffff8104d2ac>] warn_slowpath_common+0x8c/0xc0 [ 33.150882] [<ffffffff8104d39c>] warn_slowpath_fmt+0x4c/0x50 [ 33.150914] [<ffffffffa0071e86>] ? i915_read32+0x66/0x140 [i915] [ 33.150948] [<ffffffffa009d1d6>] intel_wait_for_pipe_off+0xf6/0x1c0 [i915] [ 33.150977] [<ffffffffa009d33e>] intel_disable_pipe+0x9e/0xb0 [i915] [ 33.151007] [<ffffffffa009f696>] ironlake_crtc_disable+0xd6/0x8a0 [i915] [ 33.151036] [<ffffffffa00a3f50>] __intel_set_mode+0x320/0x12b0 [i915] [ 33.151072] [<ffffffffa00a6f66>] intel_set_mode+0x16/0x30 [i915] [ 33.151101] [<ffffffffa00a7732>] intel_crtc_set_config+0x7b2/0x980 [i915] [ 33.151131] [<ffffffffa001165d>] drm_mode_set_config_internal+0x5d/0xe0 [drm] [ 33.151147] [<ffffffffa0065711>] drm_fb_helper_set_par+0x71/0xf0 [drm_kms_helper] [ 33.151153] [<ffffffff81397fa5>] fb_set_var+0x1a5/0x470 [ 33.151162] [<ffffffff81255744>] ? __ext4_journal_stop+0x44/0xa0 [ 33.151169] [<ffffffff81085a39>] ? update_curr+0x99/0x180 [ 33.151176] [<ffffffff813a59d1>] fbcon_blank+0x1e1/0x2e0 [ 33.151184] [<ffffffff814119d4>] do_unblank_screen+0xb4/0x1e0 [ 33.151191] [<ffffffff814076c5>] complete_change_console+0x65/0xf0 [ 33.151197] [<ffffffff8140866a>] vt_ioctl+0xf1a/0x1120 [ 33.151204] [<ffffffff81150c94>] ? handle_mm_fault+0x264/0x5d0 [ 33.151229] [<ffffffffa000ab80>] ? drm_setmaster_ioctl+0x120/0x120 [drm] [ 33.151240] [<ffffffff813fbd58>] tty_ioctl+0x278/0xb10 [ 33.151246] [<ffffffff816b217c>] ? __do_page_fault+0x27c/0x500 [ 33.151252] [<ffffffff8119f46c>] do_vfs_ioctl+0x8c/0x4f0 [ 33.151257] [<ffffffff8118fe81>] ? __sb_end_write+0x31/0x60 [ 33.151264] [<ffffffff8118de5e>] ? vfs_write+0x17e/0x1e0 [ 33.151268] [<ffffffff8119f961>] SyS_ioctl+0x91/0xb0 [ 33.151276] [<ffffffff816b6b46>] system_call_fastpath+0x1a/0x1f [ 33.151280] ---[ end trace 6371fc90ad43927d ]--- [ 34.712112] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 35.067421] [drm:cpt_verify_modeset] *ERROR* mode set failed: pipe A stuck
Also before that: [ 14.702706] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 15.058085] [drm:cpt_verify_modeset] *ERROR* mode set failed: pipe A stuck
Created attachment 107891 [details] dell xps13 ivy bridge - i915_opregion, CSM version
Created attachment 107901 [details] dell xps13 ivy bridge - i915_opregion, UEFI version
(In reply to Ulf Winkelvos from comment #140) > Created attachment 107901 [details] > dell xps13 ivy bridge - i915_opregion, UEFI version Thanks Ulf, that's interesting. UEFI VBT has 1024x768 at 18 bpp while CSM has 1920x1080 at 24 bpp. Anyone with something other than XPS13 that could attach /sys/kernel/debug/dri/0/i915_opregion for UEFI and CSM cases?
I sent the Asus TX300 files.
*** Bug 60881 has been marked as a duplicate of this bug. ***
(In reply to jkp from comment #142) > I sent the Asus TX300 files. Ah, right, thanks. Been reading too many bugs and comments... Those also have 18 bpp in UEFI, and 24 bpp in CSM (but both have the same resolution).
Created attachment 107991 [details] Asus UX32VD IVB - i915_opregion, UEFI no CSM
Created attachment 108001 [details] Asus UX32VD IVB - i915_opregion, UEFI CSM
Created attachment 108021 [details] asus_ux21a_ivb_i915_opregion_csm asus_ux21a_ivb_i915_opregion_csm
Created attachment 108031 [details] ASUS UX31A - i915_opregion, UEFI+CSM ASUS UX31A, CSM enabled.
Created attachment 108041 [details] asus_ux21a_ivb_i915_opregion_nocsm asus_ux21a_ivb_i915_opregion_nocsm latest reboots: Sep 10 20:10:41 localhost kernel: INTEL BIOS BPP HACK: pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 18, ignoring intel bios bpp Sep 10 20:29:04 localhost kernel: INTEL BIOS BPP HACK: pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 24, ignoring intel bios bpp Sep 10 20:33:08 localhost kernel: INTEL BIOS BPP HACK: pipe_config->pipe_bpp: 24, dev_priv->vbt.edp_bpp: 18, ignoring intel bios bpp
Created attachment 108051 [details] ASUS UX31A - i915_opregion, UEFI CSM disabled.
(In reply to Jani Nikula from comment #141) > (In reply to Ulf Winkelvos from comment #140) > > Created attachment 107901 [details] > > dell xps13 ivy bridge - i915_opregion, UEFI version > > Thanks Ulf, that's interesting. UEFI VBT has 1024x768 at 18 bpp while CSM > has 1920x1080 at 24 bpp. > Hi Jani, thx for looking into this by the way. This looks a little strage to me, because I observe a higher resolution in the boot menu for uefi compared to csm. Anyways this is a firmwae bug, right? Dell sells these machiens with some kind of linux support, so they might even be willing to fix this. :)
So do we have a solution that is acceptable to mainline inclusion yet?
So, anything that could be done by me or someone else to help either one of my two patches (or some other patches) to get into mainline?
Don't think the code rearrengment patch is ok. Ignore one is a hack. Quirck is the best one.. i think.
Forget the code rearrangement, it's not a good approach. Based on current information, quirk is best for the users who have reported problems, as there's no user intervention required. Module parameter patch is useful in case there are other display adapters with different PCI ids with the same or similar problem, to confirm or rule out incorrect VBE bpp value being the culprit.
Created attachment 108741 [details] A combined patch (quirk & module param) to fix bug for 3.12-rc1 This is a patch which uses both the quirk and the module parameter approach. For 3.12-rc1. Tested to work on Asus TX300.
Potential problem with quirk is that there might be a device with id 0x0166 which actually does have correct lower than 24 value for bpp. Don't know how probable that is, probably not very probable. To cover for this possibility, module parameter could be expanded to have an option to switch the quirk off. Anyway, would be nice to have this solved. After that, there's left the problem with the unused second battery on the TX300, https://bugzilla.kernel.org/show_bug.cgi?id=61101
well i think we need a comment from guy from intel.
(In reply to Jani Nikula from comment #134) > Ulf, jkp, or anyone seeing the difference between UEFI w/o CSM vs. UEFI w/ > CSM vs. legacy boot: Please attach /sys/kernel/debug/dri/0/i915_opregion in > working and non-working cases. Please indicate the BIOS mode used clearly in > the attachment. Thanks. To verify some things, please attach dmesg with drm.debug=0xe for both cases, running drm-intel-nightly branch of git://people.freedesktop.org/~danvet/drm-intel
Created attachment 109571 [details] dell xps13 ivy bridge - dmesg intel-nightly, CSM version
Created attachment 109581 [details] dell xps13 ivy bridge - dmesg intel-nightly, uefi version
Created attachment 109591 [details] dell xps13 ivy bridge - dmesg intel-nightly, diff csm/uefi with stripped timestamps
The interesting bit in Ulf's dmesgs is that clock recovery phase of link training fails in *both* cases. We're just lucky it succeeds for the CSM/24 bpp case during channel eq.
@intel.com: is there any hope to see the quirk merged while you work out a better (if any) solution? What could possibly go wrong, in the current situation the screen is dead anyway (I hardly believe that Asus will ever release a fixed firmware).
(In reply to Fabio Erculiani from comment #164) > @intel.com: > is there any hope to see the quirk merged while you work out a better (if > any) solution? What could possibly go wrong, in the current situation the > screen is dead anyway (I hardly believe that Asus will ever release a fixed > firmware). Yeah, I'd have thought it was a major problem that Dell XPS 13's have been broken since kernel 3.10+ considering this is somewhat of a "flagship" linux laptop... Temporary solutions would be most welcome while any real fixes are tested.
(In reply to Ulf Winkelvos from comment #160) > Created attachment 109571 [details] > dell xps13 ivy bridge - dmesg intel-nightly, CSM version Ulf, please try the CSM mode running bug-59841 branch of [1], and attach dmesg. There's four link training related patches on top of -nightly. [1] git://gitorious.org/jani/drm.git
All, I'm not advertising this as a fix or a decent workaround, but is there *anyone* here for whom the CSM or legacy mode *fails*? Please tell, and preferrably attach dmesg running drm-intel-nightly, CSM, and drm.debug=0xe. Thanks.
" but is there *anyone* here for whom the CSM or legacy mode *fails*? " See comment 137, https://bugzilla.kernel.org/show_bug.cgi?id=59841#c137 - I've seen that several times, but it didn't happen always. Could be it fails on only external dislay and possibly even always on external, but not sure. I'm compiling current git://people.freedesktop.org/~danvet/drm-intel to see what happens with it.
Created attachment 109651 [details] dell xps13 ivy bridge - dmesg bug-59841, CSM version (In reply to Jani Nikula from comment #167) > All, I'm not advertising this as a fix or a decent workaround, but is there > *anyone* here for whom the CSM or legacy mode *fails*? Please tell, and > preferrably attach dmesg running drm-intel-nightly, CSM, and drm.debug=0xe. > Thanks.
(In reply to Colin Guthrie from comment #165) > (In reply to Fabio Erculiani from comment #164) > > @intel.com: > > is there any hope to see the quirk merged while you work out a better (if > > any) solution? What could possibly go wrong, in the current situation the > > screen is dead anyway (I hardly believe that Asus will ever release a fixed > > firmware). > > Yeah, I'd have thought it was a major problem that Dell XPS 13's have been > broken since kernel 3.10+ considering this is somewhat of a "flagship" linux > laptop... > > Temporary solutions would be most welcome while any real fixes are tested. Have you reported this and the other issues to dell, yet? We probably should give.
Created attachment 109801 [details] drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time The attached patch fixes some link training issues for me. Please give it a try, with or without CSM, and attach dmesg. Thanks.
Created attachment 109851 [details] Asus TX300 CSM dmesg from drm-intel git 2013-09-26
Created attachment 109861 [details] Asus TX300 UEFI dmesg from drm-intel git 2013-09-26
Created attachment 109871 [details] Asus TX300 CSM dmesg from drm-intel git 2013-09-26 with patch 109851
Asus TX300 UEFI dmesg from drm-intel git 2013-09-26 with patch 109851. Can't send as an attachment for some reason, bugzilla acting up or something, so attaching as text only the lines matching "drm". [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-rc7+ root=UUID=2531f9dd-0936-4f44-b7c8-c1327bcb72fb ro acpi_osi= pcie_aspm=force drm.debug=0xe quiet splash vt.handoff=7 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-rc7+ root=UUID=2531f9dd-0936-4f44-b7c8-c1327bcb72fb ro acpi_osi= pcie_aspm=force drm.debug=0xe quiet splash vt.handoff=7 [ 1.276587] drm: module verification failed: signature and/or required key missing - tainting kernel [ 1.277681] [drm] Initialized drm 1.1.0 20060810 [ 1.315712] [drm:i915_dump_device_info], i915 device info: gen=7, pciid=0x0166 flags=is_mobile,need_gfx_hws,is_ivybridge,has_force_wake,has_fbc,has_hotplug,has_bsd_ring,has_blt_ring,has_llc, [ 1.316880] [drm] Memory usable by graphics device = 2048M [ 1.316882] [drm:i915_gem_gtt_init], GMADR size = 256M [ 1.316884] [drm:i915_gem_gtt_init], GTT stolen size = 64M [ 1.316887] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver [ 1.376765] [drm:intel_detect_pch], Found PatherPoint PCH [ 1.376935] [drm:intel_opregion_setup], graphic opregion physical addr: 0xda8c6018 [ 1.376946] [drm:intel_opregion_setup], Public ACPI methods supported [ 1.376947] [drm:intel_opregion_setup], SWSCI supported [ 1.398182] [drm:swsci_setup], SWSCI GBDA callbacks 00000cf3, SBCB callbacks 00000241 [ 1.398191] [drm:intel_opregion_setup], ASLE supported [ 1.398256] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.398257] [drm] Driver supports precise vblank timestamp query. [ 1.398258] [drm:init_vbt_defaults], Set default to SSC at 100MHz [ 1.398260] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT SNB/IVB-MOBILE d [ 1.398262] [drm:parse_general_features], BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 120 display_clock_mode 0 fdi_rx_polarity_inverted 0 [ 1.398263] [drm:parse_general_definitions], crt_ddc_bus_pin: 2 [ 1.398266] [drm:parse_lfp_panel_data], Found panel mode in BIOS VBT tables: [ 1.398267] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 0 148500 1920 2008 2053 2200 1080 1083 1089 1125 0x8 0xa [ 1.398269] [drm:parse_lfp_panel_data], VBT initial LVDS value 300 [ 1.398271] [drm:parse_sdvo_panel_data], Found SDVO panel mode in BIOS VBT tables: [ 1.398271] [drm:drm_mode_debug_printmodeline], Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [ 1.398273] [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT [ 1.398275] [drm:parse_mipi], No MIPI BDB found [ 1.398279] [drm:intel_dsm_pci_probe], no _DSM method for intel device [ 1.398283] [drm:i915_gem_init_stolen], found 67108864 bytes of stolen memory at dbe00000 [ 1.398321] [drm:intel_print_wm_latency], Primary WM0 latency 12 (1.2 usec) [ 1.398322] [drm:intel_print_wm_latency], Primary WM1 latency 4 (2.0 usec) [ 1.398323] [drm:intel_print_wm_latency], Primary WM2 latency 16 (8.0 usec) [ 1.398324] [drm:intel_print_wm_latency], Primary WM3 latency 32 (16.0 usec) [ 1.398326] [drm:intel_print_wm_latency], Sprite WM0 latency 12 (1.2 usec) [ 1.398327] [drm:intel_print_wm_latency], Sprite WM1 latency 4 (2.0 usec) [ 1.398328] [drm:intel_print_wm_latency], Sprite WM2 latency 16 (8.0 usec) [ 1.398329] [drm:intel_print_wm_latency], Sprite WM3 latency 32 (16.0 usec) [ 1.398330] [drm:intel_print_wm_latency], Cursor WM0 latency 12 (1.2 usec) [ 1.398331] [drm:intel_print_wm_latency], Cursor WM1 latency 4 (2.0 usec) [ 1.398332] [drm:intel_print_wm_latency], Cursor WM2 latency 16 (8.0 usec) [ 1.398333] [drm:intel_print_wm_latency], Cursor WM3 latency 64 (32.0 usec) [ 1.398335] [drm:intel_modeset_init], 3 display pipes available. [ 1.398344] [drm:intel_shared_dpll_init], 2 shared PLLs initialized [ 1.398648] [drm:intel_lvds_init], LVDS is not present in VBT [ 1.398676] [drm:intel_dp_init_connector], Adding eDP connector on port A [ 1.398697] [drm:intel_dp_i2c_init], i2c_init DPDDC-A [ 1.398699] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 1.398707] [drm:ironlake_edp_panel_vdd_on], PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f [ 1.398919] [drm:intel_dp_i2c_aux_ch], aux_i2c nack [ 1.399086] [drm:intel_dp_i2c_aux_ch], aux_i2c nack [ 1.399113] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1 [ 1.399120] [drm:intel_dp_init_panel_power_sequencer], cur t1_t3 1500 t8 2000 t9 2500 t10 50 t11_t12 6000 [ 1.399123] [drm:intel_dp_init_panel_power_sequencer], vbt t1_t3 1500 t8 2000 t9 2500 t10 50 t11_t12 5500 [ 1.399125] [drm:intel_dp_init_panel_power_sequencer], panel power up delay 150, power down delay 5, power cycle delay 600 [ 1.399127] [drm:intel_dp_init_panel_power_sequencer], backlight on delay 200, off delay 250 [ 1.399128] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 1.399131] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on [ 1.399410] [drm:intel_dp_get_dpcd], DPCD: 12 0a 02 01 00 00 00 00 00 00 00 00 00 0b 00 [ 1.399579] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1 [ 1.399587] [drm:intel_dp_init_panel_power_sequencer_registers], panel power sequencer register settings: PP_ON 0x45dc07d0, PP_OFF 0x3209c4, PP_DIV 0x186906 [ 1.399589] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 1.399592] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on [ 1.400420] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [ 1.423251] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [ 1.423258] [drm:drm_edid_to_eld], ELD: no CEA Extension found [ 1.423260] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1 [ 1.423262] [drm:intel_panel_get_backlight], get backlight PWM = 4302 [ 1.423265] [drm:intel_panel_get_max_backlight], max backlight PWM = 4302 [ 1.423291] [drm:intel_gmbus_force_bit], enabling bit-banging on i915 gmbus dpb. force bit now 1 [ 1.423679] [drm:intel_sdvo_read_byte], i2c transfer returned -6 [ 1.423680] [drm:intel_sdvo_init], No SDVO device found on SDVOB [ 1.423700] [drm:intel_gmbus_force_bit], disabling bit-banging on i915 gmbus dpb. force bit now 0 [ 1.423731] [drm:intel_dp_init_connector], Adding DP connector on port B [ 1.423751] [drm:intel_dp_i2c_init], i2c_init DPDDC-B [ 1.426215] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7145003f [ 1.426221] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 1.428686] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7145003f [ 1.428692] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 1.428731] [drm:intel_dp_init_connector], Adding DP connector on port C [ 1.428749] [drm:intel_dp_i2c_init], i2c_init DPDDC-C [ 1.431215] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7145003f [ 1.431222] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 1.433684] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7145003f [ 1.433690] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 1.433713] [drm:ironlake_init_pch_refclk], has_panel 1 has_lvds 0 has_ck505 0 [ 1.434119] [drm:i915_gem_setup_global_gtt], clearing unused GTT space: [0, 7fdff000] [ 1.436512] [drm:init_status_page], render ring hws offset: 0x00000000 [ 1.442189] [drm:init_pipe_control], render ring pipe control offset: 0x00021000 [ 1.442195] [drm:init_status_page], bsd ring hws offset: 0x00022000 [ 1.442285] [drm:init_status_page], blitter ring hws offset: 0x00043000 [ 1.442382] [drm:create_default_context], Default HW context loaded [ 1.442384] [drm:i915_gem_context_init], HW context support initialized [ 1.442423] [drm:intel_modeset_readout_hw_state], [CRTC:3] hw state readout: disabled [ 1.442425] [drm:intel_modeset_readout_hw_state], [CRTC:5] hw state readout: disabled [ 1.442430] [drm:intel_modeset_readout_hw_state], [CRTC:7] hw state readout: enabled [ 1.442435] [drm:intel_modeset_readout_hw_state], PCH DPLL A hw state readout: refcount 0, on 0 [ 1.442440] [drm:intel_modeset_readout_hw_state], PCH DPLL B hw state readout: refcount 0, on 0 [ 1.442444] [drm:intel_modeset_readout_hw_state], [ENCODER:10:DAC-10] hw state readout: disabled, pipe=0 [ 1.442447] [drm:intel_modeset_readout_hw_state], [ENCODER:11:TMDS-11] hw state readout: enabled, pipe=2 [ 1.442451] [drm:intel_modeset_readout_hw_state], [ENCODER:20:TMDS-20] hw state readout: disabled, pipe=0 [ 1.442455] [drm:intel_modeset_readout_hw_state], [ENCODER:22:TMDS-22] hw state readout: disabled, pipe=0 [ 1.442459] [drm:intel_modeset_readout_hw_state], [ENCODER:24:TMDS-24] hw state readout: disabled, pipe=0 [ 1.442462] [drm:intel_modeset_readout_hw_state], [ENCODER:26:TMDS-26] hw state readout: disabled, pipe=0 [ 1.442464] [drm:intel_modeset_readout_hw_state], [CONNECTOR:12:eDP-1] hw state readout: enabled [ 1.442468] [drm:intel_modeset_readout_hw_state], [CONNECTOR:9:VGA-1] hw state readout: disabled [ 1.442471] [drm:intel_modeset_readout_hw_state], [CONNECTOR:21:HDMI-A-1] hw state readout: disabled [ 1.442475] [drm:intel_modeset_readout_hw_state], [CONNECTOR:23:DP-1] hw state readout: disabled [ 1.442479] [drm:intel_modeset_readout_hw_state], [CONNECTOR:25:HDMI-A-2] hw state readout: disabled [ 1.442482] [drm:intel_modeset_readout_hw_state], [CONNECTOR:27:DP-2] hw state readout: disabled [ 1.442485] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A [ 1.442487] [drm:intel_dump_pipe_config], cpu_transcoder: A [ 1.442488] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0 [ 1.442490] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.442492] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.442494] [drm:intel_dump_pipe_config], requested mode: [ 1.442495] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [ 1.442498] [drm:intel_dump_pipe_config], adjusted mode: [ 1.442500] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [ 1.442502] [drm:intel_dump_crtc_timings], crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0 [ 1.442505] [drm:intel_dump_pipe_config], port clock: 0 [ 1.442506] [drm:intel_dump_pipe_config], pipe src size: 0x0 [ 1.442508] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000 [ 1.442510] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x00000000, disabled [ 1.442512] [drm:intel_dump_pipe_config], ips: 0 [ 1.442513] [drm:intel_dump_pipe_config], double wide: 0 [ 1.442515] [drm:intel_dump_pipe_config], [CRTC:5][setup_hw_state] config for pipe B [ 1.442516] [drm:intel_dump_pipe_config], cpu_transcoder: B [ 1.442518] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0 [ 1.442519] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.442521] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.442523] [drm:intel_dump_pipe_config], requested mode: [ 1.442525] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [ 1.442528] [drm:intel_dump_pipe_config], adjusted mode: [ 1.442529] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [ 1.442532] [drm:intel_dump_crtc_timings], crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0 [ 1.442534] [drm:intel_dump_pipe_config], port clock: 0 [ 1.442535] [drm:intel_dump_pipe_config], pipe src size: 0x0 [ 1.442537] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000 [ 1.442539] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x00000000, disabled [ 1.442540] [drm:intel_dump_pipe_config], ips: 0 [ 1.442542] [drm:intel_dump_pipe_config], double wide: 0 [ 1.442544] [drm:intel_dump_pipe_config], [CRTC:7][setup_hw_state] config for pipe C [ 1.442545] [drm:intel_dump_pipe_config], cpu_transcoder: C [ 1.442547] [drm:intel_dump_pipe_config], pipe bpp: 24, dithering: 0 [ 1.442548] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.442550] [drm:intel_dump_pipe_config], dp: 1, gmch_m: 6467616, gmch_n: 8388608, link_m: 269484, link_n: 524288, tu: 64 [ 1.442553] [drm:intel_dump_pipe_config], requested mode: [ 1.442554] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 1920 0 0 0 1080 0 0 0 0x0 0x0 [ 1.442557] [drm:intel_dump_pipe_config], adjusted mode: [ 1.442558] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 138779 0 0 0 0 0 0 0 0 0x0 0xa [ 1.442561] [drm:intel_dump_crtc_timings], crtc timings: 138779 1920 1966 1996 2080 1080 1082 1086 1112, type: 0x0 flags: 0xa [ 1.442564] [drm:intel_dump_pipe_config], port clock: 270000 [ 1.442565] [drm:intel_dump_pipe_config], pipe src size: 1920x1080 [ 1.442567] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000 [ 1.442569] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x07800438, enabled [ 1.442570] [drm:intel_dump_pipe_config], ips: 0 [ 1.442572] [drm:intel_dump_pipe_config], double wide: 0 [ 1.442574] [drm:intel_connector_check_state], [CONNECTOR:12:eDP-1] [ 1.442581] [drm:check_encoder_state], [ENCODER:10:DAC-10] [ 1.442584] [drm:check_encoder_state], [ENCODER:11:TMDS-11] [ 1.442586] [drm:check_encoder_state], [ENCODER:20:TMDS-20] [ 1.442589] [drm:check_encoder_state], [ENCODER:22:TMDS-22] [ 1.442593] [drm:check_encoder_state], [ENCODER:24:TMDS-24] [ 1.442596] [drm:check_encoder_state], [ENCODER:26:TMDS-26] [ 1.442599] [drm:check_crtc_state], [CRTC:3] [ 1.442601] [drm:check_crtc_state], [CRTC:5] [ 1.442602] [drm:check_crtc_state], [CRTC:7] [ 1.442608] [drm:check_shared_dpll_state], PCH DPLL A [ 1.442613] [drm:check_shared_dpll_state], PCH DPLL B [ 1.442621] [drm:intel_crt_reset], pch crt adpa set to 0xf40000 [ 1.442632] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:eDP-1] [ 1.442633] [drm:intel_dp_detect], [CONNECTOR:12:eDP-1] [ 1.442641] [drm:drm_edid_to_eld], ELD: no CEA Extension found [ 1.442645] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:eDP-1] probed modes : [ 1.442647] [drm:drm_mode_debug_printmodeline], Modeline 13:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 1.442650] [drm:drm_mode_debug_printmodeline], Modeline 14:"1920x1080" 40 92520 1920 1966 1996 2080 1080 1082 1086 1112 0x40 0xa [ 1.442653] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] [ 1.442655] [drm:intel_crt_detect], [CONNECTOR:9:VGA-1] force=1 [ 1.442658] [drm:intel_ironlake_crt_detect_hotplug], trigger hotplug detect cycle: adpa=0xf40000 [ 1.458191] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40000, result 0 [ 1.458193] [drm:intel_crt_detect], CRT not detected via hotplug [ 1.514276] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 [ 1.530260] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga [ 1.530263] [drm:intel_crt_detect_ddc], CRT not detected via DDC:0x50 [no valid EDID found] [ 1.530265] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] disconnected [ 1.530267] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] [ 1.530269] [drm:intel_hdmi_detect], [CONNECTOR:21:HDMI-A-1] [ 1.530506] [drm:gmbus_xfer], GMBUS [i915 gmbus dpb] NAK for addr: 0050 r(1) [ 1.530510] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpb [ 1.530512] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] disconnected [ 1.530514] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] [ 1.530516] [drm:intel_dp_detect], [CONNECTOR:23:DP-1] [ 1.530519] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] disconnected [ 1.530521] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] [ 1.530522] [drm:intel_hdmi_detect], [CONNECTOR:25:HDMI-A-2] [ 1.530756] [drm:gmbus_xfer], GMBUS [i915 gmbus dpc] NAK for addr: 0050 r(1) [ 1.530761] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc [ 1.530763] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] disconnected [ 1.530765] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] [ 1.530767] [drm:intel_dp_detect], [CONNECTOR:27:DP-2] [ 1.530770] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] disconnected [ 1.530771] [drm:drm_setup_crtcs], [ 1.530773] [drm:drm_enable_connectors], connector 12 enabled? yes [ 1.530774] [drm:drm_enable_connectors], connector 9 enabled? no [ 1.530775] [drm:drm_enable_connectors], connector 21 enabled? no [ 1.530777] [drm:drm_enable_connectors], connector 23 enabled? no [ 1.530778] [drm:drm_enable_connectors], connector 25 enabled? no [ 1.530779] [drm:drm_enable_connectors], connector 27 enabled? no [ 1.530780] [drm:drm_target_preferred], looking for cmdline mode on connector 12 [ 1.530782] [drm:drm_target_preferred], looking for preferred mode on connector 12 [ 1.530783] [drm:drm_target_preferred], found mode 1920x1080 [ 1.530784] [drm:drm_setup_crtcs], picking CRTCs for 8192x8192 config [ 1.530787] [drm:drm_setup_crtcs], desired mode 1920x1080 set on crtc 3 [ 1.530790] [drm:i915_gem_object_create_stolen], creating stolen object: size=7e9000 [ 1.530794] [drm:i915_pages_create_for_stolen], offset=0x0, size=8294400 [ 1.533649] [drm:intelfb_create], allocated 1920x1080 fb: 0x00072000, bo ffff8801116b6000 [ 1.533802] fbcon: inteldrmfb (fb0) is primary device [ 1.533843] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 1.533845] [drm:intel_set_config_compute_mode_changes], inactive crtc, full mode set [ 1.533845] [drm:intel_set_config_compute_mode_changes], modes are different, full mode set [ 1.533847] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [ 1.533849] [drm:drm_mode_debug_printmodeline], Modeline 28:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 1.533849] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=1, fb_changed=0 [ 1.533851] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 1.533852] [drm:intel_modeset_stage_output_state], crtc changed, full mode switch [ 1.533853] [drm:intel_modeset_affected_pipes], set mode pipe masks: modeset: 1, prepare: 1, disable: 4 [ 1.533854] [drm:connected_sink_compute_bpp], [CONNECTOR:12:eDP-1] checking for sink bpp constrains [ 1.533856] [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz [ 1.533857] [drm:intel_dp_compute_config], clamping bpp for eDP panel to BIOS-provided 18 [ 1.533858] [drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18 [ 1.533858] [drm:intel_dp_compute_config], DP link bw required 249804 available 259200 [ 1.533859] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1 [ 1.533860] [drm:intel_dump_pipe_config], [CRTC:3][modeset] config for pipe A [ 1.533861] [drm:intel_dump_pipe_config], cpu_transcoder: A [ 1.533862] [drm:intel_dump_pipe_config], pipe bpp: 18, dithering: 1 [ 1.533863] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 1.533864] [drm:intel_dump_pipe_config], dp: 1, gmch_m: 4042260, gmch_n: 4194304, link_m: 224570, link_n: 262144, tu: 64 [ 1.533864] [drm:intel_dump_pipe_config], requested mode: [ 1.533866] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 1.533866] [drm:intel_dump_pipe_config], adjusted mode: [ 1.533868] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 1.533869] [drm:intel_dump_crtc_timings], crtc timings: 138780 1920 1966 1996 2080 1080 1082 1086 1112, type: 0x48 flags: 0xa [ 1.533869] [drm:intel_dump_pipe_config], port clock: 162000 [ 1.533870] [drm:intel_dump_pipe_config], pipe src size: 1920x1080 [ 1.533871] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000 [ 1.533872] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x00000000, disabled [ 1.533872] [drm:intel_dump_pipe_config], ips: 0 [ 1.533873] [drm:intel_dump_pipe_config], double wide: 0 [ 1.533874] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 1.533876] [drm:ironlake_edp_panel_vdd_on], eDP VDD already on [ 1.533877] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 [ 1.533880] [drm:ironlake_edp_backlight_off], [ 1.786819] [drm:ironlake_edp_panel_off], Turn eDP power off [ 1.786824] [drm:ironlake_wait_panel_off], Wait for panel power off time [ 1.786828] [drm:ironlake_wait_panel_status], mask b000000f value 00000000 status 80000008 control abcd0000 [ 2.643245] [drm:intel_dp_link_down], [ 2.707300] [drm:ironlake_wait_for_vblank], vblank wait timed out [ 2.719510] [drm:intel_update_fbc], no output, disabling [ 2.719517] [drm:ivb_modeset_global_resources], disabling fdi C rx [ 2.719531] [drm:ironlake_update_plane], Writing base 00072000 00000000 0 0 7680 [ 2.719533] [drm:intel_crtc_mode_set], [ENCODER:11:TMDS-11] set [MODE:0:1920x1080] [ 2.719534] [drm:ironlake_set_pll_cpu_edp], eDP PLL enable for clock 162000 [ 2.719535] [drm:ironlake_set_pll_cpu_edp], 160MHz cpu eDP clock, might need ilk devA w/a [ 2.720033] [drm:ironlake_edp_pll_on], [ 2.720260] [drm:ivybridge_update_wm], FIFO watermarks For pipe A - plane 13, cursor: 6 [ 2.720261] [drm:ironlake_check_srwm], watermark 1: display plane 20, fbc lines 3, cursor 6 [ 2.720262] [drm:ironlake_check_srwm], watermark 2: display plane 72, fbc lines 3, cursor 6 [ 2.720263] [drm:ironlake_check_srwm], watermark 3: display plane 141, fbc lines 4, cursor 10 [ 2.720264] [drm:ironlake_check_srwm], watermark 3: display plane 280, fbc lines 5, cursor 14 [ 2.783366] [drm:ironlake_wait_for_vblank], vblank wait timed out [ 2.847423] [drm:ironlake_wait_for_vblank], vblank wait timed out [ 2.847430] [drm:intel_update_fbc], disabled per chip default [ 2.847436] [drm:ironlake_edp_panel_vdd_on], Turn eDP VDD on [ 2.847443] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle [ 2.847470] [drm:ironlake_wait_panel_status], mask b800000f value 00000000 status 00000000 control abcd0000 [ 2.847475] [drm:ironlake_edp_panel_vdd_on], PP_STATUS: 0x00000000 PP_CONTROL: 0xabcd0008 [ 2.847490] [drm:ironlake_edp_panel_vdd_on], eDP was not running [ 2.863452] [drm:intel_enable_rc6], RC6 and deep RC6 enabled [ 2.863454] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [ 2.879447] [drm:gen6_enable_rps], Overclocking supported. Max: 1150MHz, Overclock max: 1150MHz [ 3.003998] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.004601] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.005052] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.005504] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.005954] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.006404] [drm:intel_dp_set_signal_levels], Using signal levels 09000000 [ 3.006851] [drm:intel_dp_start_link_train], too many voltage retries, give up [ 3.006852] [drm:ironlake_edp_panel_on], Turn eDP power on [ 3.006855] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle [ 3.006859] [drm:ironlake_wait_panel_status], mask b800000f value 00000000 status 00000000 control abcd0008 [ 3.006862] [drm:ironlake_wait_panel_on], Wait for panel power on [ 3.006866] [drm:ironlake_wait_panel_status], mask b000000f value 80000008 status 0000000a control abcd000b [ 3.371908] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1 [ 3.371930] [drm:ironlake_panel_vdd_off_sync], PP_STATUS: 0xabcd000b PP_CONTROL: 0x80000008 [ 3.384872] [drm:intel_dp_complete_link_train], Channel EQ done. DP Training successful [ 3.385025] [drm:ironlake_edp_backlight_on], [ 3.588150] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4302 [ 3.604135] [drm:intel_connector_check_state], [CONNECTOR:12:eDP-1] [ 3.604143] [drm:check_encoder_state], [ENCODER:10:DAC-10] [ 3.604145] [drm:check_encoder_state], [ENCODER:11:TMDS-11] [ 3.604146] [drm:check_encoder_state], [ENCODER:20:TMDS-20] [ 3.604148] [drm:check_encoder_state], [ENCODER:22:TMDS-22] [ 3.604150] [drm:check_encoder_state], [ENCODER:24:TMDS-24] [ 3.604152] [drm:check_encoder_state], [ENCODER:26:TMDS-26] [ 3.604154] [drm:check_crtc_state], [CRTC:3] [ 3.604159] [drm:check_crtc_state], [CRTC:5] [ 3.604160] [drm:check_crtc_state], [CRTC:7] [ 3.604161] [drm:check_shared_dpll_state], PCH DPLL A [ 3.604165] [drm:check_shared_dpll_state], PCH DPLL B [ 3.604171] [drm:intel_crtc_set_config], [CRTC:5] [NOFB] [ 3.604173] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:5], mode_changed=0, fb_changed=0 [ 3.604174] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 3.604175] [drm:intel_crtc_set_config], [CRTC:7] [NOFB] [ 3.604176] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:7], mode_changed=0, fb_changed=0 [ 3.604177] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 3.604190] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 3.604192] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 3.604193] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 3.608604] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 3.628844] [drm:asle_set_pwm_freq], PWM freq is not supported [ 3.629284] [drm:asle_set_backlight], bclp = 0x8000002d [ 3.629289] [drm:intel_panel_get_max_backlight], max backlight PWM = 4302 [ 3.629291] [drm:intel_panel_actually_set_backlight], set backlight PWM = 720 [ 3.629486] [drm:asle_set_backlight], bclp = 0x800000ff [ 3.629490] [drm:intel_panel_get_max_backlight], max backlight PWM = 4302 [ 3.629491] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4080 [ 3.664514] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.000242] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 4.000245] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 4.000247] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062565] [drm:i915_driver_open], [ 4.062581] [drm:intel_crtc_cursor_set], cursor off [ 4.062583] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 4.062587] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 4.062588] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062590] [drm:intel_crtc_cursor_set], cursor off [ 4.062591] [drm:intel_crtc_set_config], [CRTC:5] [NOFB] [ 4.062593] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:5], mode_changed=0, fb_changed=0 [ 4.062594] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062595] [drm:intel_crtc_cursor_set], cursor off [ 4.062596] [drm:intel_crtc_set_config], [CRTC:7] [NOFB] [ 4.062597] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:7], mode_changed=0, fb_changed=0 [ 4.062598] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062608] [drm:i915_driver_open], [ 4.062613] [drm:intel_crtc_cursor_set], cursor off [ 4.062614] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 4.062616] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 4.062617] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062618] [drm:intel_crtc_cursor_set], cursor off [ 4.062619] [drm:intel_crtc_set_config], [CRTC:5] [NOFB] [ 4.062620] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:5], mode_changed=0, fb_changed=0 [ 4.062622] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062623] [drm:intel_crtc_cursor_set], cursor off [ 4.062623] [drm:intel_crtc_set_config], [CRTC:7] [NOFB] [ 4.062625] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:7], mode_changed=0, fb_changed=0 [ 4.062626] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.062632] [drm:i915_driver_open], [ 4.062679] [drm:drm_mode_getresources], CRTC[3] CONNECTORS[6] ENCODERS[6] [ 4.062681] [drm:drm_mode_getresources], CRTC[3] CONNECTORS[6] ENCODERS[6] [ 4.062686] [drm:drm_mode_getconnector], [CONNECTOR:12:?] [ 4.062688] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:eDP-1] [ 4.062690] [drm:intel_dp_detect], [CONNECTOR:12:eDP-1] [ 4.062698] [drm:drm_edid_to_eld], ELD: no CEA Extension found [ 4.062701] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:eDP-1] probed modes : [ 4.062703] [drm:drm_mode_debug_printmodeline], Modeline 13:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 4.062705] [drm:drm_mode_debug_printmodeline], Modeline 14:"1920x1080" 40 92520 1920 1966 1996 2080 1080 1082 1086 1112 0x40 0xa [ 4.062707] [drm:drm_mode_getconnector], [CONNECTOR:12:?] [ 4.066715] [drm:drm_mode_getconnector], [CONNECTOR:9:?] [ 4.066718] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] [ 4.066720] [drm:intel_crt_detect], [CONNECTOR:9:VGA-1] force=1 [ 4.066723] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40000, result 0 [ 4.066724] [drm:intel_crt_detect], CRT not detected via hotplug [ 4.080430] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga [ 4.080432] [drm:intel_crt_detect_ddc], CRT not detected via DDC:0x50 [no valid EDID found] [ 4.080434] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] disconnected [ 4.080447] [drm:drm_mode_getconnector], [CONNECTOR:9:?] [ 4.080448] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] [ 4.080450] [drm:intel_crt_detect], [CONNECTOR:9:VGA-1] force=1 [ 4.080452] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40000, result 0 [ 4.080453] [drm:intel_crt_detect], CRT not detected via hotplug [ 4.096443] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga [ 4.096445] [drm:intel_crt_detect_ddc], CRT not detected via DDC:0x50 [no valid EDID found] [ 4.096446] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] disconnected [ 4.096449] [drm:drm_mode_getconnector], [CONNECTOR:21:?] [ 4.096451] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] [ 4.096461] [drm:intel_hdmi_detect], [CONNECTOR:21:HDMI-A-1] [ 4.096684] [drm:gmbus_xfer], GMBUS [i915 gmbus dpb] NAK for addr: 0050 r(1) [ 4.096696] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpb [ 4.096702] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] disconnected [ 4.096715] [drm:drm_mode_getconnector], [CONNECTOR:21:?] [ 4.096719] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] [ 4.096724] [drm:intel_hdmi_detect], [CONNECTOR:21:HDMI-A-1] [ 4.096957] [drm:gmbus_xfer], GMBUS [i915 gmbus dpb] NAK for addr: 0050 r(1) [ 4.096969] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpb [ 4.096975] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:21:HDMI-A-1] disconnected [ 4.096992] [drm:drm_mode_getconnector], [CONNECTOR:23:?] [ 4.096997] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] [ 4.097002] [drm:intel_dp_detect], [CONNECTOR:23:DP-1] [ 4.097016] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] disconnected [ 4.097018] [drm:drm_mode_getconnector], [CONNECTOR:23:?] [ 4.097019] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] [ 4.097020] [drm:intel_dp_detect], [CONNECTOR:23:DP-1] [ 4.097022] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:DP-1] disconnected [ 4.097024] [drm:drm_mode_getconnector], [CONNECTOR:25:?] [ 4.097025] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] [ 4.097026] [drm:intel_hdmi_detect], [CONNECTOR:25:HDMI-A-2] [ 4.097247] [drm:gmbus_xfer], GMBUS [i915 gmbus dpc] NAK for addr: 0050 r(1) [ 4.097259] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc [ 4.097265] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] disconnected [ 4.097277] [drm:drm_mode_getconnector], [CONNECTOR:25:?] [ 4.097282] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] [ 4.097286] [drm:intel_hdmi_detect], [CONNECTOR:25:HDMI-A-2] [ 4.097512] [drm:gmbus_xfer], GMBUS [i915 gmbus dpc] NAK for addr: 0050 r(1) [ 4.097524] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc [ 4.097530] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:25:HDMI-A-2] disconnected [ 4.097547] [drm:drm_mode_getconnector], [CONNECTOR:27:?] [ 4.097552] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] [ 4.097556] [drm:intel_dp_detect], [CONNECTOR:27:DP-2] [ 4.097571] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] disconnected [ 4.097572] [drm:drm_mode_getconnector], [CONNECTOR:27:?] [ 4.097573] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] [ 4.097574] [drm:intel_dp_detect], [CONNECTOR:27:DP-2] [ 4.097577] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:27:DP-2] disconnected [ 4.097589] [drm:drm_mode_addfb], [FB:30] [ 4.404708] [drm:ironlake_panel_vdd_off_sync], PP_STATUS: 0xabcd000f PP_CONTROL: 0x80000008 [ 4.893829] [drm:drm_mode_addfb], [FB:30] [ 4.893863] [drm:intel_crtc_set_config], [CRTC:3] [FB:29] #connectors=1 (x y) (0 0) [ 4.893865] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 4.893867] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.898411] [drm:drm_mode_setcrtc], [CRTC:3] [ 4.898415] [drm:drm_mode_setcrtc], [CONNECTOR:12:eDP-1] [ 4.898416] [drm:intel_crtc_set_config], [CRTC:3] [FB:30] #connectors=1 (x y) (0 0) [ 4.898418] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=1 [ 4.898420] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 4.902553] [drm:ironlake_update_plane], Writing base 0085B000 00000000 0 0 7680 [ 4.914156] [drm:drm_mode_setcrtc], [CRTC:3] [ 4.914161] [drm:drm_mode_setcrtc], [CONNECTOR:12:eDP-1] [ 4.914163] [drm:intel_crtc_set_config], [CRTC:3] [FB:30] #connectors=1 (x y) (0 0) [ 4.914166] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:3], mode_changed=0, fb_changed=0 [ 4.914168] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3]
With previous messages, display is shown with CSM and not shown with UEFI, the same as with other unpatched kernels.
Created attachment 110051 [details] drm/i915/dp: prefer fast & narrow to wide & slow in DP per the spec Another patch to try on top of drm-intel-nightly and "drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the time". Please attach dmesg with drm.debug=0xe.
Are the DP_TRAINING_PATTERN_SET patches related to the reported bug or are they related to something else? +1 to comment 164 quoted below "Fabio Erculiani 2013-09-25 11:52:48 UTC @intel.com: is there any hope to see the quirk merged while you work out a better (if any) solution? What could possibly go wrong, in the current situation the screen is dead anyway (I hardly believe that Asus will ever release a fixed firmware)."
(In reply to jkp from comment #178) > Are the DP_TRAINING_PATTERN_SET patches related to the reported bug or are > they related to something else? In *all* dmesgs here, and in the duplicate bugs, the clock recovery part of the display port link training fails. Always. Regardless of UEFI vs. CSM, regardless of 18 vs. 24 bpp, regardless of whether you get something on screen eventually or not. It just so happens the use of 24 bpp affects the link parameters so that the channel equalization phase (which we try even though clock recovery failed) succeeds by chance. Fixing the link training should have priority, and "drm/i915/dp: do not write DP_TRAINING_PATTERN_SET all the", now merged to drm-intel-nightly, does fix a real issue with the link training. "drm/i915/dp: prefer fast & narrow to wide & slow in DP per the spec" complies with the display port spec. > +1 to comment 164 quoted below > > "Fabio Erculiani 2013-09-25 11:52:48 UTC > > @intel.com: > is there any hope to see the quirk merged while you work out a better (if > any) solution? What could possibly go wrong, in the current situation the > screen is dead anyway (I hardly believe that Asus will ever release a fixed > firmware)." The quirk hides the real issue (link training) under the carpet.
OK, will test the newest patch, naturally must fix the real issue. A question though about EDP bpp - even after the link training issue fixed, if the quirk is not applied, isn't the result that an incorrect 18 bpp value will be used instead of the desired 24 bpp, due to the incorrect EDP bpp value? Or is the conclusion about edp bpp value being invalid not true?
(In reply to jkp from comment #180) > A question though about EDP bpp - even after the link training issue fixed, > if the quirk is not applied, isn't the result that an incorrect 18 bpp value > will be used instead of the desired 24 bpp, due to the incorrect EDP bpp > value? Or is the conclusion about edp bpp value being invalid not true? We'll need to deal with that too once we get the link training fixed first.
Created attachment 110101 [details] drm/i915/dp: enable power power sequencing before starting link training Another day, another patch to try.
Created attachment 110111 [details] CSM dmesg drm-intel 131001 w/ patches 110051 and 110101
Created attachment 110121 [details] UEFI dmesg drm-intel 131001 w/ patches 110051 and 110101 No picture with CSM off, picture on internal display with CSM on.
Created attachment 110131 [details] CSM dmesg drm-intel-nightly 131002 w/ patches 110051 and 110101
Created attachment 110141 [details] UEFI dmesg drm-intel-nightly 131002 w/ patches 110051 and 110101
Comment on attachment 110141 [details] UEFI dmesg drm-intel-nightly 131002 w/ patches 110051 and 110101 No picture with CSM off, picture on internal display with CSM on. On the bpp issue. I would like to see atleast the kernel paramter patch accepted into mainline. This would definitly help for the time beeing.
jkp, Ulf, thanks for testing. With patches 110051 and 110101 the link training succeeds on first attempt in all cases. I'm going to have to ask you to try the patches separately to see which one helps. I know it's tedious but we *are* making progress here. Thanks. It is slightly disappointing this doesn't fix the display yet, but we'll get there.
Jani, is it need(In reply to Jani Nikula from comment #188) > jkp, Ulf, thanks for testing. With patches 110051 and 110101 the link > training succeeds on first attempt in all cases. I'm going to have to ask > you to try the patches separately to see which one helps. Jani, is testing on ASUS UX31A required? My understanding is that your fellows have this particular one around (but don't know whether it's handy).
(In reply to Michael Shigorin from comment #189) > Jani, is testing on ASUS UX31A required? My understanding is that your > fellows have this particular one around (but don't know whether it's handy). If you can spare a few kernel compilations and reboots, I'd appreciate you trying 110051 and 110101 separately on drm-intel-nightly. Attach dmesg with drm.debug=0xe. Thanks.
Created attachment 110151 [details] drm-intel-nightly-20131002 + 110051 patch on Asus UX32VD
Created attachment 110161 [details] drm-intel-nightly-20131002 + 110101 patch on Asus UX32VD
Created attachment 110191 [details] Dmesg from TX300 UEFI with patch 110101 Suppose this is sufficient to see what happens on TX300, and other versions are not needed.
Created attachment 110201 [details] Dmesg Asus TX300 CSM with patch 110101 and quirk & mod param patches Here's a dmesg from drm-intel git tree with patch 110101 and my quirk & mod param patches applied. While the version works fine on UEFI, in CSM mode there's no image on the internal display when an external monitor is connecte, and I can't log in even with the external display. I reported a similar (maybe the same) issue in comment 137.
To clarify: can't log in with X with external monitor, but I can log in on text console on the external monitor.
It appears the patch from attachment 110101 [details] fixes link training for all cases. Except comment 194 which has other stuff on top. Would be interesting to see -nightly + the patch in CSM without anything extra. I'm checking some details the with the hw designers to finish off the patch, and we can tick one issue off the list. Unfortunately it looks like that is not going to fix the bug. :( The issues seen here: 1) Clock recovery part of link training fails. 2) Black screen with link computation done in 18 bpp. Works if computation is done in 24 bpp, and dithering to 18 bpp is set after that. 3) In UEFI mode of affected machines, the VBT reports 18 bpp instead of 24 bpp, triggering the above.
Well, regarding comment 194, my understanding is that my patch (the quirk or module param to ignore bpp from EDP) should be a no-op in CSM mode, as bpp in CSM mode is reported as 24 and the bpp before querying EDP is 24 as well, so ignoring EDP bpp shouldn't matter. But not 100% sure as I haven't looked at the code too closely. I can test again with current drm-intel + 110101 probably some time today.
(In reply to jkp from comment #197) > Well, regarding comment 194, my understanding is that my patch (the quirk or > module param to ignore bpp from EDP) should be a no-op in CSM mode, as bpp > in CSM mode is reported as 24 and the bpp before querying EDP is 24 as well, > so ignoring EDP bpp shouldn't matter. True. The way it fails just seems strange. Please do try it again, maybe without another display attached. For another data point, once you find a working setup in CSM first, please apply the patch below on top. The idea is to ensure our dithering code works for you, all else being equal. There are some other subtle differences between UEFI and CSM too. diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5614365..0315747 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -828,6 +828,9 @@ intel_dp_compute_config(struct intel_encoder *encoder, bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); } + bpp = 18; + DRM_DEBUG_KMS("clamping bpp for eDP panel to %i\n", bpp); + for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, bpp);
Well, I gather that most of the CSM dmesg reports I've posted here are the kind of test you're asking, tests with no external display connected. I've only seen the issue (where keyboard input fails with X) when an external display is connected.
(In reply to jkp from comment #199) > Well, I gather that most of the CSM dmesg reports I've posted here are the > kind of test you're asking, tests with no external display connected. I've > only seen the issue (where keyboard input fails with X) when an external > display is connected. Ok. I'd like to see CSM + the above patch forcing 18 bpp.
Do you want that with or without patch 110101?
(In reply to jkp from comment #201) > Do you want that with or without patch 110101? Preferrably with. But I'd like to be sure it works with 110101 (no need to attach dmesg for that), and then see if patch from comment 198 still works or breaks it. I think your failure earlier is because you booted with external display connected, and BIOS didn't enable the panel. For some reason some machines need to have the BIOS light up the panel at boot, or else it doesn't work. (Yes, this bug is accumulating a lot of related issues... and comments. *sigh*.)
No image in CSM mode with patch 110101 and patch from comment 198.
To be more exact - no image in CSM mode with patch 110101 and patch from comment 198 with internal display only, with current drm-intel. Other things the same, but no patch from comment 198, there's a normal image and I'm able to normally login to X on internal monitor.
With CSM and external display, current drm-intel, with patch 110101, with or without patch from comment 198, I can't log in to X. I see something about link retrain failures. >I think your failure earlier is because you booted with external display >>connected, and BIOS didn't enable the panel. Sounds like could well be that.
(In reply to Jani Nikula from comment #196) > The issues seen here: > > 1) Clock recovery part of link training fails. I've forked this part of the bug into a new one: https://bugs.freedesktop.org/show_bug.cgi?id=70117
(In reply to jkp from comment #205) > >I think your failure earlier is because you booted with external display > >connected, and BIOS didn't enable the panel. > > Sounds like could well be that. IIUC, this happens with the otherwise working drm-intel-nightly + CSM combo too? Please file a new bug about this on DRM/Intel at: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI We can't tackle all of these in one bug.
"IIUC, this happens with the otherwise working drm-intel-nightly + CSM combo" Yes.
The CSM external monitor bug is now filed at https://bugs.freedesktop.org/show_bug.cgi?id=70120 - not a big practical priority for me at least, more important would be to have the UEFI mode bug fixed.
From summary in comment 196: >1) Clock recovery part of link training fails. > >2) Black screen with link computation done in 18 bpp. Works if computation is >done in 24 bpp, and dithering to 18 bpp is set after that. > >3) In UEFI mode of affected machines, the VBT reports 18 bpp instead of 24 >bpp, >triggering the above. Then there's 4) In CSM mode, with external monitor connected, X session can't be properly started with gdm. 1) is now forked to https://bugs.freedesktop.org/show_bug.cgi?id=70117 4) is now forked to https://bugs.freedesktop.org/show_bug.cgi?id=70120 How about solving 3) with the quirk and/or kernel parameter approach now? Would leave 2) open.
Regarding "2) Black screen with link computation done in 18 bpp. Works if computation is done in 24 bpp, and dithering to 18 bpp is set after that." From comment 75 (quoted below), is there a way to check if on computers referred to in 2), the issue maybe has been fixed with the fixing of "1) Clock recovery part of link training fails" with patch 110101? In other words, is there contact to someone who could check if patch 110101 fixes the issue for these computers making it possible to revert the offending commit http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624 "Trying to get the picture here of what's going on, please correct me if I'm wrong: 1) The offending commit (which breaks things for TX300 & many others) is this one by Daniel on 2013-05-04 (from comment 17): http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624 2) From comment 31 by Daniel, apparently on some computers, the bpp value must be clamped before the dp bandwidth computation code, thus the addition of "bpp = min_t(int, bpp, dev_priv->edp.bpp);" by Daniel, currently "bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);". Is this correct? 3) However the clamping "bpp = min_t() line breaks things for many computers, e.g. the TX300 and others. The bpp value from BIOS (intel_bios.c / dev_priv->vbt.edp_bpp) appears to be 18 on the TX300, but apparently the bpp value to be used is 24 from pipe_config-> pipe_bpp. 4) To make things work on TX300 and others as well as the computers Daniel is talking about (which one(s)?), we'll some kind of way to differentiate between computers which need the bpp = min_t line and computers which must not use it."
(In reply to Jani Nikula from comment #188) > jkp, Ulf, thanks for testing. With patches 110051 and 110101 the link > training succeeds on first attempt in all cases. I'm going to have to ask > you to try the patches separately to see which one helps. I know it's > tedious but we *are* making progress here. Thanks. > > It is slightly disappointing this doesn't fix the display yet, but we'll get > there. I am going to upload both dmesgs in a minute. (csm boots of drm-intel-nightly respectivly)
Created attachment 110231 [details] CSM dmesg drm-intel-nightly 131002 w/ patches 110101
Created attachment 110241 [details] CSM dmesg drm-intel-nightly 131002 w/ patches 110051
(In reply to Ulf Winkelvos from comment #212) > I am going to upload both dmesgs in a minute. (csm boots of > drm-intel-nightly respectivly) Thanks. I finally got my hands on a machine where I can reproduce this, an Acer Aspire S7, so I'm less likely to be requesting info from now on until I have some patches towards fixing the issue.
Any progess? Anything for us to do to move things forward?
(In reply to jkp from comment #216) > Any progess? Anything for us to do to move things forward? In short, no. This appears to be more about the DP link speed than color depth. We seem to fail at 1.62 GHz DP link, which is where we end up with 18 bpp. The VBT also kindly tells us to use 1.62 GHz. The BIOS itself, on the other hand, happily boots the display at 2.7 GHz and 24 bpp...
Well, how about solving the reported bug with the quirk and/or kernel parameter approach now? Would solve the issue for everyone who's been commenting on this thread / everyone who's using the same model computers I think. Wouldn't help for people with real 18 bpp mode though.
I am using an ASUS VivoBook X202E (purchased from the Microsoft Store in Costa Mesa, CA). I installed Fedora (3.10.10-100.fc18.x86_64), and even with the "Launch CSM" option set to "Enabled" and "Secure Boot Control" option set to "Disabled", I get a blank screen after the Fedora logo finishes getting colored. I am currently running Fedora (3.9.11-200.fc18.x86_64). Thank you.
Vivobook resolution is 1366X768, so I wonder if it might be that the DP link speed is lower also in CSM mode (triggering the DP link bug). Some debug ouput should be used to verify, perhaps dmesg with drm.debug=0xe would provide the info. Also would be good to have lspci -nn -v output to get the ID for the graphics controller to see how the proposed quirk would change the situation on this computer. By incorporating the quirk patch, the wide-impact bug caused by incorrect BIOS-reported bpp value would be fixed. The hard-to-fix and lower-impact DP link issue would remain. If the link issue described in the previous paragraph is the culprit on Vivoboox X202E, the quirk wouldn't fix the problem on Vivobook, leaving at least that computer as a test case for the DP link bug.
Oct 13 07:08:25 localhost kernel: [ 316.087969] ------------[ cut here ]------------ Oct 13 07:08:25 localhost kernel: [ 316.088034] WARNING: CPU: 0 PID: 594 at drivers/gpu/drm/i915/intel_display.c:822 intel_wait_for_pipe_off+0xfb/0x1c0 [i915]() Oct 13 07:08:25 localhost kernel: [ 316.088037] pipe_off wait timed out Oct 13 07:08:25 localhost kernel: [ 316.088039] Modules linked in: ebtable_nat fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6table_security ip6table_raw ip6t_REJECT iptable_nat nf_nat_ipv4 iptable_mangle iptable_security iptable_raw nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ebtable_filter ebtables ip6table_filter ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 nf_nat nf_conntrack ip6_tables bnep iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi dell_wmi sparse_keymap snd_hda_codec_idt ppdev coretemp kvm_intel kvm crc32_pclmul crc32c_intel arc4 dell_laptop dcdbas ghash_clmulni_intel microcode iwldvm mac80211 usb_storage serio_raw intel_ips i2c_i801 uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_core snd_usbmidi_lib videodev snd_rawmidi media btusb snd_hda_intel bluetooth iwlwifi snd_hda_codec cfg80211 snd_hwdep lpc_ich snd_seq joydev rfkill snd_seq_device mfd_core sdhci_pci snd_pcm sdhci mmc_core snd_page_alloc snd_timer e1000e snd shpchp mei_me soundcore ptp mei pps_core wmi parport_pc parport tpm_tis tpm tpm_bios acpi_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc i915 i2c_algo_bit drm_kms_helper drm firewire_ohci firewire_core yenta_socket crc_itu_t i2c_core video Oct 13 07:08:25 localhost kernel: [ 316.088163] CPU: 0 PID: 594 Comm: Xorg Tainted: G W 3.11.4-301.fc20.x86_64 #1 Oct 13 07:08:25 localhost kernel: [ 316.088166] Hardware name: Dell Inc. Latitude xxx Oct 13 07:08:25 localhost kernel: [ 316.088169] 0000000000000009 ffff8801f9bf5ba8 ffffffff8164813b ffff8801f9bf5bf0 Oct 13 07:08:25 localhost kernel: [ 316.088174] ffff8801f9bf5be0 ffffffff8106715d 0000000000070008 ffff88020dfbc000 Oct 13 07:08:25 localhost kernel: [ 316.088179] 0000000100003fcd ffff8801f9bf5fd8 ffff88020dc0c470 ffff8801f9bf5c40 Oct 13 07:08:25 localhost kernel: [ 316.088184] Call Trace: Oct 13 07:08:25 localhost kernel: [ 316.088194] [<ffffffff8164813b>] dump_stack+0x45/0x56 Oct 13 07:08:25 localhost kernel: [ 316.088201] [<ffffffff8106715d>] warn_slowpath_common+0x7d/0xa0 Oct 13 07:08:25 localhost kernel: [ 316.088206] [<ffffffff810671cc>] warn_slowpath_fmt+0x4c/0x50 Oct 13 07:08:25 localhost kernel: [ 316.088228] [<ffffffffa00b9e16>] ? i915_read32+0x66/0x140 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088254] [<ffffffffa00e431b>] intel_wait_for_pipe_off+0xfb/0x1c0 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088279] [<ffffffffa00e446d>] intel_disable_pipe+0x8d/0xa0 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088304] [<ffffffffa00e6956>] ironlake_crtc_disable+0xd6/0x8c0 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088310] [<ffffffff8113c33d>] ? unlock_page+0x2d/0x50 Oct 13 07:08:25 localhost kernel: [ 316.088315] [<ffffffff81164244>] ? do_wp_page+0x3a4/0x820 Oct 13 07:08:25 localhost kernel: [ 316.088342] [<ffffffffa00eaedf>] intel_crtc_update_dpms+0x6f/0xa0 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088397] [<ffffffffa00eafaa>] intel_encoder_dpms+0x1a/0x30 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088431] [<ffffffffa00ee388>] intel_connector_dpms+0x38/0x70 [i915] Oct 13 07:08:25 localhost kernel: [ 316.088457] [<ffffffffa0065f88>] drm_mode_obj_set_property_ioctl+0x308/0x320 [drm] Oct 13 07:08:25 localhost kernel: [ 316.088477] [<ffffffffa0065fd0>] drm_mode_connector_property_set_ioctl+0x30/0x40 [drm] Oct 13 07:08:25 localhost kernel: [ 316.088493] [<ffffffffa0055142>] drm_ioctl+0x532/0x660 [drm] Oct 13 07:08:25 localhost kernel: [ 316.088507] [<ffffffff811b9dfd>] do_vfs_ioctl+0x2dd/0x4b0 Oct 13 07:08:25 localhost kernel: [ 316.088513] [<ffffffff811ba051>] SyS_ioctl+0x81/0xa0 Oct 13 07:08:25 localhost kernel: [ 316.088520] [<ffffffff81657319>] system_call_fastpath+0x16/0x1b Oct 13 07:08:25 localhost kernel: [ 316.088524] ---[ end trace 6c2b9788447106c5 ]--- Is this the same bug ? [root@localhost log]# uname --all Linux localhost.localdomain 3.11.4-301.fc20.x86_64 #1 SMP Thu Oct 10 15:09:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@localhost log]#
Created attachment 110821 [details] drm.debug=0xe from lid closed drm.debug=0xe from lid closed
Created attachment 110831 [details] drm.debug=0xe from lid open drm.debug=0xe from lid open
Upped the importance to blocking, as the bug blocks normal use of Linux in UEFI mode, and use of normal use with external monitor in CSM mode, thus there's no way to use Linux with a typical internal+external monitor combo. This is due to BIOS giving incorrect info on bpp. My suggested fixes for the bug are the two patches submitted 7 Sep 2013, a bit more than a month ago, to add ignoring of the buggy bpp info based on a) a quirk for known affected machines b) a kernel parameter for unknown affected machines. http://www.spinics.net/lists/kernel/msg1598411.html http://www.spinics.net/lists/kernel/msg1598412.html The bug remains unsolved for months. Things have been moving forward and there are some other related bugs (which have been isolated and forked) to resolve. While people are working with related bugs & fixes to tem, can't we finally move forward and resolve the primary bug (incorrect bpp value given by bios) with the patches linked to above to ignore the incorrect value? Is there a reason why the bug shouldn't be fixed with the patch(es) linked to above?
??
Created attachment 111321 [details] drm/i915/dp: workaround BIOS eDP bpp clamping issue Please try the attached patch on top of drm-intel-nightly.
With attachment 111321 [details]: * works in UEFI mode * fails in CSM mode when external monitor connected at boot * works in CSM mode with external monitor, when external monitor connected after boot
(In reply to jkp from comment #227) > * works in UEFI mode Thanks for testing. > * fails in CSM mode when external monitor connected at boot While unfortunate, this is an independent bug. https://bugs.freedesktop.org/show_bug.cgi?id=70120 > * works in CSM mode with external monitor, when external monitor connected > after boot
> >> * fails in CSM mode when external monitor connected at boot > >While unfortunate, this is an independent bug. >https://bugs.freedesktop.org/show_bug.cgi?id=70120 Yes, symptoms are the same as described there.
(In reply to Jani Nikula from comment #226) > Created attachment 111321 [details] > drm/i915/dp: workaround BIOS eDP bpp clamping issue > > Please try the attached patch on top of drm-intel-nightly. This works for both csm and uefi.
This bug, since it was not fixed or quirked promptly, has now made it into Ubuntu 13.10 (unless they did something in their own kernel source), making new installs and upgrades unbootable. This does not make Linux look good.
If a patch can be finally settled on and committed, the bug should probably be reported also directly to Ubuntu so a backport of the fix can be applied.
I've upgraded to Ubuntu 13.10. And yes, I can confirm that the kernel bug is in the kernel used by Ubuntu 13.10, pacakge version 3.11.0.12.13. Possibly even worse, something seems to have changed in userland wrt X / gdm login, with the result that even the external screen is not usable as it was with 13.04 with a buggy kernel. Possibly it could be nothing really changed with 13.10, as I did let the upgrade add defaults for some settings, so could be just that my previous settings made external X use possible. But even if that's the case, seems that with default settings external monitor login won't work in UEFI mode.
No, once merged into the latest development kernel, the patch should be sent for inclusion in the long-term stable kernels maintained by gregkh (in this case, 3.10). Ubuntu is just _one_ of the many distros out there.
Ah, yes, forgot about that, more than a month since you mentioned it. Yes, but should first get a working patch merged to be able to do that.
Any progress in merging any of the tested-to-work fixes?
Linus just pulled them into his git tree and they'll be in 3.12 (with cc: stable for backporting).
Yay, thanks to everyone involved!
Confirmed that linux-git as of today fixes the issue. Thanks.
Thanks, works for me too.
3.12 works on the Asus UX32VD as well. At last! Thank you very much.
*** Bug 63231 has been marked as a duplicate of this bug. ***
The fix appears to be reaching 3.11, but has it been submitted to 3.10 longterm? Would be good to have in 3.10 as well.
> --- Comment #243 from jkp <jkp@iki.fi> --- > The fix appears to be reaching 3.11, but has it been submitted to 3.10 > longterm? Would be good to have in 3.10 as well. > It has been, but as the original patch relied on some other changes in 3.12 it did not apply for 3.10 and 3.11. Jani backported it to 3.11 but said that the backport to 3.10 would be way harder. [1] So my guess is that it has not been done yet. Cheers, Ulf [1] http://article.gmane.org/gmane.linux.kernel.stable/69338
Works for me with ALT Linux 3.10.x kernels, can ask guys to point out the commit.