Bug 22674 - [855GM KMS] Screen powers down w/i915 as module and DRM_I915_KMS since commit e4a5d54f
Summary: [855GM KMS] Screen powers down w/i915 as module and DRM_I915_KMS since commit...
Status: CLOSED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Jesse Barnes
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2009-07-08 09:01 UTC by Andre
Modified: 2017-07-24 23:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg from last good commit (15.08 KB, text/plain)
2009-07-08 09:01 UTC, Andre
no flags Details
dmesg from first bad commit (15.08 KB, text/plain)
2009-07-08 09:03 UTC, Andre
no flags Details
lspci -nn -vv (10.25 KB, text/plain)
2009-07-08 09:04 UTC, Andre
no flags Details
Regdump of last good commit 619ac3b75a1e9 (9.82 KB, text/plain)
2009-07-10 03:14 UTC, Andre
no flags Details
Regdump of first bad commit e4a5d54f924ea (9.85 KB, text/plain)
2009-07-10 03:19 UTC, Andre
no flags Details
dmesg from current git (linus), i915 built-in, working case. (15.08 KB, text/plain)
2009-07-16 13:39 UTC, Andre
no flags Details
Regdump of the working case, drm built-in. (9.77 KB, text/plain)
2009-07-16 13:41 UTC, Andre
no flags Details
dmidecode output for this Thinkpad R50e (11.57 KB, text/plain)
2009-07-16 13:44 UTC, Andre
no flags Details
The .config I use to reproduce this. (49.16 KB, text/plain)
2009-07-27 16:33 UTC, Andre
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andre 2009-07-08 09:01:13 UTC
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
Comment 1 Andre 2009-07-08 09:03:56 UTC
Created attachment 27500 [details]
dmesg from first bad commit
Comment 2 Andre 2009-07-08 09:04:50 UTC
Created attachment 27501 [details]
lspci -nn -vv
Comment 3 Gordon Jin 2009-07-08 19:23:26 UTC
not sure if this is related to #22150
Comment 4 MaLing 2009-07-09 08:20:21 UTC
hi  Andre  

Could you please attach register dump for good and bad case respectively.

Thanks
Ma Ling
Comment 5 Michael Fu 2009-07-10 02:24:48 UTC
And, what's your kernel version?
Comment 6 Andre 2009-07-10 03:14:38 UTC
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.
Comment 7 Andre 2009-07-10 03:19:32 UTC
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.
Comment 8 MaLing 2009-07-14 20:27:09 UTC
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
 
Comment 9 Andre 2009-07-15 00:18:59 UTC
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.
Comment 10 MaLing 2009-07-15 20:18:24 UTC
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
Comment 11 Andre 2009-07-16 13:36:21 UTC
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?
Comment 12 Andre 2009-07-16 13:39:05 UTC
Created attachment 27774 [details]
dmesg from current git (linus), i915 built-in, working case.
Comment 13 Andre 2009-07-16 13:41:18 UTC
Created attachment 27775 [details]
Regdump of the working case, drm built-in.
Comment 14 Andre 2009-07-16 13:44:03 UTC
Created attachment 27777 [details]
dmidecode output for this Thinkpad R50e
Comment 15 MaLing 2009-07-17 02:02:14 UTC
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

Comment 16 Andre 2009-07-17 08:46:51 UTC
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?


Comment 17 ykzhao 2009-07-20 01:19:35 UTC
(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?
> 

Comment 18 Andre 2009-07-21 02:12:29 UTC
(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
Comment 19 Andre 2009-07-22 04:39:27 UTC
Updated subject line to reflect the findings from comment #16
Comment 20 MaLing 2009-07-23 21:29:07 UTC
(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
Comment 21 Andre 2009-07-27 16:31:13 UTC
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


Comment 22 Andre 2009-07-27 16:33:04 UTC
Created attachment 28056 [details]
The .config I use to reproduce this.
Comment 23 Michael Fu 2009-07-29 18:25:38 UTC
jesse might have some hints of why...
Comment 24 Jesse Barnes 2009-08-06 15:44:15 UTC
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?
Comment 25 Andre 2009-08-10 17:54:45 UTC
(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.
Comment 26 Jesse Barnes 2009-08-10 18:28:05 UTC
Ok, thanks for confirming.
Comment 27 Joachim Metz 2010-08-13 04:06:32 UTC
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.