I've come across a couple of Lenovo X201 laptops with Ironlake where KMS is failing to set the video mode for the LVDS. This results in a blank display, although the device works when hooked up to an external monitor. Kernel tested: 2.6.33-rc2 The error message seen in the kernel logs is: [drm:intel_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! I've narrowed it down to drivers/gpu/drm/i915/intel_display.c:intel_g4x_find_best_PLL The "found" variable ends up as "false". If I increase the "err_most" variable (err_most += 50) then the routine is able to find a clock and the display mode is set properly and everything works. In fact it comes up with the same clock value as an x201 that works without my hack. I added some printk's to dump the values of many of the variables in that routine to help debug. Here are the values from the "broken" x201. Note that "err_most" is the original computed value and "new_err_most" is the one that I have it use in order to get a working clock: ------------------- clock.p2=14, limit->dot.min=25000, limit->dot.max=350000, limit->vco.min=1760000, limit->vco.max=3510000 limit->n.min=1, limit->n.max=3, limit->m.min=79, limit->m.max=118 limit->m1.min=12, limit->m1.max=22, limit->m2.min=5, limit->m2.max=9 limit->p.min=28, limit->p.max=112, limit->p1.min=2, limit->p1.max=8 limit->p2.dot_limit=225000, limit->p2.p2_slow=14, limit->p2.p2_fast=14 target: 68940, err_most=336, refclk=120000, new_err_most=386 Clock found: 1, dot: 69285, vco: 2910000, m:97, p:42, n:2, m1:16, m2:5, p1:3, p2:14 -------------------- Here are the values for an x201 that works without the hack: -------------------- clock.p2=14, limit->dot.min=25000, limit->dot.max=350000, limit->vco.min=1760000, limit->vco.max=3510000 limit->n.min=1, limit->n.max=3, limit->m.min=79, limit->m.max=118 limit->m1.min=12, limit->m1.max=22, limit->m2.min=5, limit->m2.max=9 limit->p.min=28, limit->p.max=112, limit->p1.min=2, limit->p1.max=8 limit->p2.dot_limit=225000, limit->p2.p2_slow=14, limit->p2.p2_fast=14 target: 69300, err_most=337, refclk=120000 Clock found: 1, dot: 69285, vco: 2910000, m:97, p:42, n:2, m1:16, m2:5, p1:3, p2:14 -------------------- Let me know if you'd like me to post hexdumps of the edid values as well.
Zhenyu, can you take a look?
This should be fixed by commit b91ad0ec52770dcb622b94fc1f57e076686f427a Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Fri Feb 5 09:14:17 2010 +0800 drm/i915: Rework DPLL calculation parameters for Ironlake Got Ironlake DPLL parameter table, which reflects the hardware optimized values. So this one trys to list DPLL parameters for different output types, should potential fix clock issue seen on new Arrandale CPUs. This fixes DPLL setting failure on one 1920x1080 dual channel LVDS for Ironlake. Test has also been made on LVDS panels with smaller size and CRT/HDMI/DP ports for different monitors on their all supported modes. Update: - Change name of double LVDS to dual LVDS. - Fix SSC 120M reference clock to use the right range. Could you try recent kernels? recent .33 stable or .34-rc.
I'm sorry. I meant to write that I had tested with 2.6.34-rc2, not 2.6.33-rc2. In addition to 2.6.34-rc2, the kernel that I'm typically using has the "drm/i915: Rework DPLL calculation parameters for Ironlake" (b91ad0ec52770dcb622b94fc1f57e076686f427a) commit that you mention so I don't think that is the fix. Thanks for looking at this.
KMS fails for me too, Lenovo x201s (i7 L620) with 2.6.34rc5 upon KMS init the screen goes all vertical colored stripes please advice.... need X working... :-/
Created attachment 35263 [details] KMS activation results in garbled screen
was able to remote login, kernel boot messages contain nothing suspicious: [ 1.134431] [drm] Initialized drm 1.1.0 20060810 [ 3.598317] i915 0000:00:02.0: power state changed by ACPI to D0 [ 3.598325] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 3.598328] i915 0000:00:02.0: setting latency timer to 64 [ 3.686552] i915 0000:00:02.0: irq 32 for MSI/MSI-X [ 3.686560] [drm] set up 31M of stolen space [ 4.354350] Console: switching to colour frame buffer device 180x56 [ 4.357430] fb0: inteldrmfb frame buffer device [ 4.363654] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 4.363698] alloc irq_desc for 17 on node -1 [ 4.363702] alloc kstat_irqs on node -1 further I was able to login blindly, intel driver 2.11, vertical stripes remain, however I see a lighter mouse cursor square moving then machine crashed hard :-/
Hello, I can confirm this bug on a Lenovo x201s (QM57) too. I'm running gentoo linux with gentoo-sources-2.6.33-r1. (System uname: Linux-2.6.33-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7_CPU_L_620_@_2.00GHz-with-gentoo-2.0.1) With KMS enabled, from time to time, the LVDS does not get detected correctly and the screen stays black right after grub. I can ssh to the machine, as well as logon as root and reboot the machine blindly. greetings, Johannes
Hello fellow Gentoo friend... My case is not "time to time", it is always. I was able to blindly start X. Login per SSH, gives: kernel log messages - don't know if this at KMS activation or X startup: [ 41.730004] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 41.738227] render error detected, EIR: 0x00000000 [ 41.738254] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1 at 0) xrandr output: Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1440x900 50.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) X log: (II) LoadModule: "intel" (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.7.6, module version = 2.11.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale (II) Primary Device is: PCI 00@00:02:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) intel(0): Creating default Display subsection in Screen section "Builtin Default intel Screen 0" for depth/fbbpp 24/32 (==) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale (--) intel(0): Chipset: "Arrandale" (==) intel(0): video overlay key set to 0x101fe (II) intel(0): Output VGA1 has no monitor section (II) intel(0): Output LVDS1 has no monitor section (II) intel(0): found backlight control interface /sys/class/backlight/acpi_video0 (II) intel(0): Output HDMI1 has no monitor section (II) intel(0): Output DP1 has no monitor section (II) intel(0): Output VGA1 disconnected (II) intel(0): Output LVDS1 connected (II) intel(0): Output HDMI1 disconnected (II) intel(0): Output DP1 disconnected (II) intel(0): Using exact sizes for initial modes (II) intel(0): Output LVDS1 using initial mode 1440x900 (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. (II) intel(0): Kernel page flipping support detected, enabling (==) intel(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib64/xorg/modules/libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.7.6, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) Depth 24 pixmap format is 32 bpp (II) intel(0): [DRI2] Setup complete (**) intel(0): Tiling enabled (**) intel(0): SwapBuffers wait enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) (II) put_image (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (==) intel(0): DPMS enabled (==) intel(0): Intel XvMC decoder enabled (II) intel(0): Set up textured video (II) intel(0): [XvMC] xvmc_vld driver initialized. (II) intel(0): direct rendering: DRI2 Enabled (--) RandR disabled [...] (II) intel(0): Setting screen physical size to 381 x 238 (II) intel(0): EDID vendor "LEN", prod id 16404 (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1440x900"x0.0 74.08 1440 1464 1480 1600 900 903 909 926 -hsync -vsync (46.3 kHz)
Ubuntu 10.04 RC seems to have a heavily patched 2.6.32 kernel and intel 2.9.1 driver and this combination works, no vertical lines - I cannot reproduce this here on Gentoo with upstream vanilla packages. I don't know what Ubuntu patches are in there :-( Someone on http://www.thinkwiki.org/wiki/Installing_Debian_Sid_on_a_ThinkPad_X201s noted "I often had a black screen after I booted the machine up. Updating BIOS to 1.12-1.07/1.07 and disabling Intel AMT solved the issue." I have the newest BIOS and disabled AMT and it doesn't help.
The vertical stripes disappear when I add intel_iommu=igfx_off as kernel parameter Then trying various kernels from 2.6.32 to 2.6.34rc6, all boot with a black console upon KMS init. One has to login blindly and startx, then X works. I'm staying at the 2.6.32 from Ubuntu 10.04 now because ondemand cpufreq governor does not work with 2.6.33 and 2.6.34rc :-(
I also have a Lenovo X201 for which KMS results in a blank screen. Incrementing err_most by 50 fixes it, as described by ted bonkenburg. Linux getafix 2.6.33-tuxonice-r2 #14 SMP PREEMPT Mon May 10 08:45:54 MDT 2010 x86_64 Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz GenuineIntel GNU/Linux
patching 2.6.34-rc7 with... --- intel_display.c.orig 2010-05-13 16:34:55.839505251 +0200 +++ intel_display.c 2010-05-13 16:35:59.199500916 +0200 @@ -882,6 +882,7 @@ bool found; /* approximately equals target * 0.00488 */ int err_most = (target >> 8) + (target >> 10); + err_most += 50; found = false; if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) { ...does NOT solve the black screen problem on X201s :-(
(In reply to comment #9) > Ubuntu 10.04 RC seems to have a heavily patched 2.6.32 kernel and intel 2.9.1 > driver and this combination works, no vertical lines - I cannot reproduce this > here on Gentoo with upstream vanilla packages. I don't know what Ubuntu patches > are in there :-( > > Someone on > http://www.thinkwiki.org/wiki/Installing_Debian_Sid_on_a_ThinkPad_X201s > noted > "I often had a black screen after I booted the machine up. Updating BIOS to > 1.12-1.07/1.07 and disabling Intel AMT solved the issue." > > I have the newest BIOS and disabled AMT and it doesn't help. The problem seems to be gone since the BIOS update for me too.
> The problem seems to be gone since the BIOS update for me too. I guess all of you have X201 while I have an X201s which has a higher resolution. Guess it's better I'll open a separate bug report for this...
(In reply to comment #14) > > The problem seems to be gone since the BIOS update for me too. > > I guess all of you have X201 while I have an X201s which has a higher > resolution. > Guess it's better I'll open a separate bug report for this... I do have a X201s with a resolution 0f 1440x900. Updating the BIOS, disabling AMT and using the drivers from GIT (live ebuild) works for me. greetings, Johannes
BIOS update didn't fix my X201 (3249-CTO) but the patch to intel_display.c did fix it for me.
It looks the failure is actually with x201? and x201s with 1440x900 panel has no problem. So people with x201s please try with new BIOS. The reason for that is I tried to use optimized PLL parameter in noted commit above, which make difference with SSC freq from BIOS table. So broken BIOS might not have right flag setting. For x201, please attach kernel boot dmesg with drm.debug=7, intel_reg_dump output and VBIOS dump. thanks.
x201s and 2.6.34 works Device Drivers -> Graphics Support -> Console display driver support -> Framebuffer Console support ...needs to be compiled in static, instead of a module. You can all call me stupid now.... :-/
(In reply to comment #17) > For x201, please attach kernel boot dmesg with drm.debug=7, intel_reg_dump > output and VBIOS dump. How do I dump the VBIOS? Google results in conflicting advice.
Created attachment 35841 [details] VBIOS from Lenovo ThinkPad X201
Created attachment 35842 [details] dmesg from Lenovo ThinkPad X201 with drm.debug=7
Note that the dmesg I attached above was created *after* I applied the patch from this thread.
ThinkPad BIOS 1.05 Lenovo ThinkPad X201, model 3626W16 Kernel 2.6.34.1 with Patch from Comment 12 => works fine here Before I applied the patch: always a black screen & crash Many people get hit by this, see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569 Adjusting severity to "major" (one could call total loss of functionality a major issue, I guess).
Normally you should not adjust the priority of a task unless it's assigned to you.
I have a i5 based x201 that can reliably reproduce this bug running Ubuntu 10.04: """ Linux reptar 2.6.32-23-generic #38 SMP Wed Jun 23 12:13:26 CST 2010 i686 GNU/Linux System Information Manufacturer: LENOVO Product Name: 3626R3U Version: ThinkPad X201 BIOS Information Vendor: LENOVO Version: 6QET46WW (1.16 ) Release Date: 06/07/2010 """ I booted up with drm.debug=7, and reproduced the issue. If you would like the same data from a kernel running with the patch in Comment #12 please let me know. --chris
Created attachment 36480 [details] drm.debug=7 when reproducing the issue (without patch from Comment #12)
Also just to note, graphics work as expected (even with compiz enabled) when booting into a kernel with the patch in Comment #12. I've not seen a single DRM error since booting into the patched kernel, and I've done things like cycle through different resolutions, and switch my display back and forth to an external monitor. --chris
> Normally you should not adjust the priority of a task unless it's assigned to > you. Sorry, I thought if I wasn't supposed to change it, I wouldn't be able to do it with my normal rights. It would be really nice if the patch made it upstream to 2.6.35, as .32, .33 and .34 already didn't work, which is quite a large number of users based on the fact that ubuntu (and probably debian?) is unusable with an i5 x201.
Created attachment 36483 [details] [review] Try to fix PLL calculation Thanks. Although I'm still not very clear about intel_g4x_find_best_pll(), which is created by others referencing internal PLL number sheet, I think on this 1280x800 panel, the calculation just failed with limited error most value...So my proposal here is to mark the minimal error clock too, which will be used as a fallback if no optimal value was found.
(In reply to comment #29) > Created an attachment (id=36483) [details] > Try to fix PLL calculation > > Thanks. Although I'm still not very clear about intel_g4x_find_best_pll(), > which is created by others referencing internal PLL number sheet, I think on > this 1280x800 panel, the calculation just failed with limited error most > value...So my proposal here is to mark the minimal error clock too, which will > be used as a fallback if no optimal value was found. Just tested on my i5 x201 w/ this patch and everything is working properly. --chris
the attached patch fixed the blank screen booting on X201. (bios upgrade had no direct change) Applied said " Try to fix PLL calculation" on top of Debian 2.6.32 linux-2.6 (It has 2.6.33 drm) and KMS booted just fine with bog standard Debian Squeeze userspace. any hints where this patch will go? Didn't see it in linux-next nor posted to intel-gfx? thanks
(In reply to comment #29) > Created an attachment (id=36483) [details] > Try to fix PLL calculation > > Thanks. Although I'm still not very clear about intel_g4x_find_best_pll(), > which is created by others referencing internal PLL number sheet, I think on > this 1280x800 panel, the calculation just failed with limited error most > value...So my proposal here is to mark the minimal error clock too, which will > be used as a fallback if no optimal value was found. Hi, Zhengyu, the following bug looks pretty similar with this one https://patchwork.kernel.org/patch/108282/ and we've test on X201, it will working fine after applied with Dave Airlie's PATCH - i915: fix ironlake edp panel setup (v2) BTW: still not sure about why a edp bug will affect lvds output as well?
(In reply to comment #32) > Hi, Zhengyu, the following bug looks pretty similar with this one > https://patchwork.kernel.org/patch/108282/ > > and we've test on X201, it will working fine after applied with Dave Airlie's > PATCH - i915: fix ironlake edp panel setup (v2) > > BTW: still not sure about why a edp bug will affect lvds output as well? v1 of the patch did not fix the i5 x201 I tested with, can retest both together tomorrow. which x201 did you test against?
I can confirm that the patch in Comment #29 works on my x201 i7 on the latest Ubuntu lucid kernel.
Please test ajax's patch at http://lists.freedesktop.org/archives/intel-gfx/2010-July/007328.html
*** Bug 28180 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > Please test ajax's patch at > http://lists.freedesktop.org/archives/intel-gfx/2010-July/007328.html workforme
Patch from Comment #35 works fine here, thanks. I hope to see it upstream soon - it's really about time. ThinkPad BIOS 1.05 Lenovo ThinkPad X201, model 3626W16 (i5) Kernel 2.6.34.1
Will this be merged in 2.6.35?
(In reply to comment #29) > Created an attachment (id=36483) [details] > Try to fix PLL calculation > > Thanks. Although I'm still not very clear about intel_g4x_find_best_pll(), > which is created by others referencing internal PLL number sheet, I think on > this 1280x800 panel, the calculation just failed with limited error most > value...So my proposal here is to mark the minimal error clock too, which will > be used as a fallback if no optimal value was found. This patch doesnt work on my Thinkpad x201 with latest bios and disabled iAMT I tested this patch both with 2.6.34 and 2.6.35-rc5 kernels HW info Vendor: LENOVO Version: 6QET46WW (1.16 ) Release Date: 06/07/2010 Product Name: 3626W6E
Actualy both patches from comment #29 and #35 with 2.6.34 and 2.6.35-rc5 kernels leads to similar issues as on attachment (id=35263)
Created attachment 37260 [details] VBIOS from x201 3626W6E
Created attachment 37261 [details] dmesg from X201 3626W6E Dmesg with enabled drm debug on 2.6.34 kernel without patches
Created attachment 37262 [details] GPU reg dump from x201_3626W6E
Also if i add patch for kernel from comment #29 and add intel_iommu=igfx_off to kernel cmdline then i get normal boot working on my x201
The proposed fixed for find_best_PLL is http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=fair-eviction&id=87ed8379211348e77832faeed9d13101075bea45 Can you please test that?
(In reply to comment #46) > The proposed fixed for find_best_PLL is > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=fair-eviction&id=87ed8379211348e77832faeed9d13101075bea45 > > Can you please test that? This patch works only with intel_iommu=igfx_off for me. without it it gives me same effect as previos patch (at least with 2.6.34 and 2.6.35-rc5)
(In reply to comment #46) > The proposed fixed for find_best_PLL is > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=fair-eviction&id=87ed8379211348e77832faeed9d13101075bea45 > > Can you please test that? I cherry-picked the referenced commit on top of v2.6.35-rc6 and booted successfully; that is, it fixes the problem for me. Thank you!
Alexy, yes the iommu on the x201 is full of fail at the moment. The last I heard implied that the hardware was not working as designed, but they had found a workaround. The fix has been applied to anholt/for-linus [2.6.35]: commit 6ba770dc5c334aff1c055c8728d34656e0f091e2 Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 2 16:43:30 2010 -0400 drm/i915: Make G4X-style PLL search more permissive Fixes an Ironlake laptop with a 68.940MHz 1280x800 panel and 120MHz SSC reference clock. More generally, the 0.488% tolerance used before is just too tight to reliably find a PLL setting. I extracted the search algorithm and modified it to find the dot clocks with maximum error over the valid range for the given output type: http://people.freedesktop.org/~ajax/intel_g4x_find_best_pll.c This gave: Worst dotclock for Ironlake DAC refclk is 350000kHz (error 0.00571) Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524) Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488) Worst dotclock for Ironlake SL-LVDS SSC refclk is 84374kHz (error 0.00529) Worst dotclock for Ironlake DL-LVDS SSC refclk is 183035kHz (error 0.00488) Worst dotclock for G4X SDVO refclk is 267600kHz (error 0.00448) Worst dotclock for G4X HDMI refclk is 334400kHz (error 0.00478) Worst dotclock for G4X SL-LVDS refclk is 95571kHz (error 0.00449) Worst dotclock for G4X DL-LVDS refclk is 224000kHz (error 0.00510) Signed-off-by: Adam Jackson <ajax@redhat.com> Cc: stable@kernel.org Signed-off-by: Eric Anholt <eric@anholt.net>
2.6.35 works for me. Thanks everyone!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.