Created attachment 27499 [details] dmesg from last good commit With KMS enabled on recent kernels, my Thinkpad R50e monitor powers down during device creation. The backlight is off, the screen itself seems to be off, too. Otherwise, the machine is running away happily as a headless system that can be rebooted properly. I bisected this down to e4a5d54f924ea5ce2913d9d0687d034004816465 is first bad commit commit e4a5d54f924ea5ce2913d9d0687d034004816465 Author: Ma Ling <ling.ma@intel.com> Date: Tue May 26 11:31:00 2009 +0800 Attached are dmesgs of first good and first bad commit, and lspci -nn -vv
Created attachment 27500 [details] dmesg from first bad commit
Created attachment 27501 [details] lspci -nn -vv
not sure if this is related to #22150
hi Andre Could you please attach register dump for good and bad case respectively. Thanks Ma Ling
And, what's your kernel version?
Created attachment 27560 [details] Regdump of last good commit 619ac3b75a1e9 Shure, here you are. Both are from newly started systems, no X. It might be worth noting that the "bad" system did not successfully shut down after I dumped the registers. I gave it another boot -> login -> sync -> halt, i.e. same as before without the regdump, it shut down cleanly as usual.
Created attachment 27561 [details] Regdump of first bad commit e4a5d54f924ea @Michael: I checked against yesterday's git (linus) before reporting, but forgot to report. Sorry.
Today I have tested our 855gm platform against our latest version, but it works fine, when we plug VGA or not plug VGA. Host: x-855gm Arch: i386 Platform: 855GM OSD: Fedora release 11 (Leonidas) Kernel_version: 2.6.31-rc2-unstable Libdrm: (master)3f3c5be6f908272199ccf53f108b1124bfe0a00e Mesa: (master)b727150b1473d8cac7a8e6ad0b5112c486d93341 Xserver: (master)cc575a3ba4a52265e410b325c2291fe900a54f33 Xf86_video_intel: (master)b74bf3f9a65af9e72921d4e9028d9d4d023f8bc6 Bench2D: c7f3c6652e9507e4303fd9ed913c593afb7447f0 Bench3D: openarena 0.8.0 Abat: 6f256196901e8b22f33d18806587293a08600eb1 Rendercheck: 1.2 Glean: Tip of CVS Oglconform: 0b24f35104d1fe4863c5314d7e2b7f26c52bd427 Mem: 35c8505fc462c02ae486ebb4a4d230b249403d14 Intel_gpu_tools: 4839ee97875d07a27c28f39021178d2cf4b5d4b8 Kernel: (drm-intel-next)ed8c754b292f02d0550596481527b7bf2b52d024
Do I get it right that it may be worthwile a. connecting an external screen, and look wether it affects pipe B as well? b. try the drm-intel-next sources? Will try both, but that will take a bit, I'm away from the machine. You gave the mesa, video-intel, libdrm etc. versions, but this got nothing to do with X. Why? As for the distro, I use Gentoo. Thanks.
pleae ensure at first (drm-intel-next)ed8c754b292f02d0550596481527b7bf2b52d024 could you pleae describe your hardware enviornment, i.e connect vga or disconnect any output, and how to reproduce your issue on your machine? thanks Ma Ling
I tested current drm-intel dff33cf which is ed8c754b292 + 1. The result isn't any better, the screen goes black. Next, I said ouch! and tried building the kernel with i915 built-in. Which works just fine. So, to reproduce the bug, you'll have to build i915 as a module. Otherwise, my hardware environment is non-existent: no external monitor, no usb ports in use, no pcmcia, just the laptop itself. I will attach dmidecode output for info. If you need something else, just ask. I also do attach a regdump of the working case (current git in linus' tree). On the downside, I do get a page table error on drm startup: [drm] Initialized drm 1.1.0 20060810 i915 0000:00:02.0: power state changed by ACPI to D0 i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 i915 0000:00:02.0: setting latency timer to 64 i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data [drm] DAC-6: set mode 640x480 0 ACPI: EC: missing confirmations, switch off interrupt mode. i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000049 [drm:i915_driver_irq_handler] *ERROR* EIR stuck: 0x00000010, masking render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000049 [drm] LVDS-8: set mode 1024x768 d Console: switching to colour frame buffer device 128x48 [drm] fb0: inteldrmfb frame buffer device [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 I can't make much of it by clueless googling -- is this a bug by itself?
Created attachment 27774 [details] dmesg from current git (linus), i915 built-in, working case.
Created attachment 27775 [details] Regdump of the working case, drm built-in.
Created attachment 27777 [details] dmidecode output for this Thinkpad R50e
Hi Andre Today I re-built our kms version: Kernel: (drm-intel-next)dff33cfcefa31c30b72c57f44586754ea9e8f3e2 as a module. After system bootup, I use modprobe i915 modeset=1 to active our i915 module, then start X, everything works fine, could you please try this version, if it doesn't work yet, upload register dump? Thanks Ma Ling
Ok, it's somewhat embarrassing not to have permutated the kernel options between bisecting and reporting :-( To reproduce this bug, I need to set CONFIG_DRM_I915_KMS in the kernel's .config When not set, I can modprobe i915 modeset=1 sucessfully. Even specifying i915.modeset=1 in the kernel commandline does not hurt. Something else: As a sad follow-up I've got another bug to report, as suspending from the console freezes the machine on its way to suspend when I echo mem > /sys/power/state It suspends fine when KMS is not enabled. Should this also go to freedesktop? Or rather to kernel bugzilla?
(In reply to comment #16) > Ok, it's somewhat embarrassing not to have permutated the kernel options > between bisecting and reporting :-( > > To reproduce this bug, I need to set CONFIG_DRM_I915_KMS in the kernel's > .config > When not set, I can modprobe i915 modeset=1 sucessfully. > Even specifying i915.modeset=1 in the kernel commandline does not hurt. > > Something else: > As a sad follow-up I've got another bug to report, as suspending from the > console freezes the machine on its way to suspend when I > echo mem > /sys/power/state Do you mean that it will freeze in course of suspend/resume when KMS is enabled? Will you please enable the "CONFIG_PM_DEBUG" in kernel configuration and do the following test? a. echo core > /sys/power/pm_test b. echo mem > /sys/power/state; dmesg >dmesg_after; c. wait for some time and see whether there exists the file of dmesg_after; Of course this can go to kernel bugzilla. Thanks. > It suspends fine when KMS is not enabled. > Should this also go to freedesktop? Or rather to kernel bugzilla? >
(In reply to comment #17) > (In reply to comment #16) > > Something else: > > As a sad follow-up I've got another bug to report, as suspending from the > > console freezes the machine on its way to suspend when I > > echo mem > /sys/power/state > Do you mean that it will freeze in course of suspend/resume when KMS is > enabled? > Will you please enable the "CONFIG_PM_DEBUG" in kernel configuration and do the > following test? > a. echo core > /sys/power/pm_test > b. echo mem > /sys/power/state; dmesg >dmesg_after; > c. wait for some time and see whether there exists the file of dmesg_after; > > Of course this can go to kernel bugzilla. > Thanks. I opened a kernel bug for it: http://bugzilla.kernel.org/show_bug.cgi?id=13805
Updated subject line to reflect the findings from comment #16
(In reply to comment #16) > Ok, it's somewhat embarrassing not to have permutated the kernel options > between bisecting and reporting :-( > To reproduce this bug, I need to set CONFIG_DRM_I915_KMS in the kernel's > .config > When not set, I can modprobe i915 modeset=1 sucessfully. > Even specifying i915.modeset=1 in the kernel commandline does not hurt. Hi Andre After comparing register dump from comments #6 and #7, the bad case is from patch: commit 5ca58282089b11f64b911618036ee7676f12735b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Mar 31 14:11:15 2009 -0700 drm/i915: add VGA hotplug support for 945+ and it has been fixe by patch commit febc7694a55277b70cd662de05ed8a957685959c Author: ling.ma@intel.com <ling.ma@intel.com> Date: Thu Jun 25 11:55:57 2009 +0800 Could you please help us the verify it ? Thanks Ma Ling
I identified another config requirement to reproduce this bug: CONFIG_FRAMEBUFFER_CONSOLE=m When compiled in, the console brings up the framebuffer all right. I do attach the failing .config As you requested, I tested commit febc7694. It does not change matters. A crosscheck of the working case with framebuffer built-in shows your suspect 5ca5828 is innocent in my case as well. I rechecked against today's git e00b95de, the framebuffer failure persists with DRM_I915=m DRM_I915_KMS=y FRAMEBUFFER_CONSOLE=m
Created attachment 28056 [details] The .config I use to reproduce this.
jesse might have some hints of why...
Sounds like a possible dupe of the fbcon issue. In this case though it sounds like i915 is loading and probing outputs, but fbcon isn't loaded yet to i915 turns everything off (there's no console after all). Does the screen come back if you immediately load the fbcon module or load it before the i915 driver?
(In reply to comment #24) > Sounds like a possible dupe of the fbcon issue. In this case though it sounds > like i915 is loading and probing outputs, but fbcon isn't loaded yet to i915 > turns everything off (there's no console after all). > > Does the screen come back if you immediately load the fbcon module or load it > before the i915 driver? > Yes, that seems to be it. When I log in to the console blindly and modprobe -v fbcon, it loads insmod /lib/modules/2.6.31-rc5-00425-gf4b9a98/kernel/drivers/video/console/softcursor.ko insmod /lib/modules/2.6.31-rc5-00425-gf4b9a98/kernel/drivers/video/console/bitblit.ko insmod /lib/modules/2.6.31-rc5-00425-gf4b9a98/kernel/drivers/video/console/font.ko insmod /lib/modules/2.6.31-rc5-00425-gf4b9a98/kernel/drivers/video/console/fbcon.ko and the screen shows up fine. lsmod tells me that i915 is loaded as well. I can also boot to init=/bin/bash and modprobe i915 manually to have the screen turning off. modprobe fbcon gives me the screen back.
Ok, thanks for confirming.
Although this is not a bug, some people might find the following info useful (at least I do) I had a similar problem with a Packard Bell core i3-330 laptop. It would boot correctly with an additional monitor, but solely booting the laptop would result in a sleeping screen. Adding "fbconf=map:1" to the kernel parameters did the trick.
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.