Mandriva QA Team reports that 2.6.31 doesn't display anything on a i915 laptop with KMS enabled (both in 32 & 64 bit). Mandriva bug report is available at: https://qa.mandriva.com/show_bug.cgi?id=53758 2.6.31's dmesg is available at: https://bzattachment.mandriva.com/attachment.cgi?id=15016 Software used: - Mandriva Cooker - BIOS: A13 (latest one) - kernel: 2.6.31 - intel x11 driver: 2.8.1 Harware: - Dell Aptitude E5500 laptop - GMA4500M (i915) The only suspicious bits in dmesg are: mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. i915 0000:00:02.0: irq 27 for MSI/MSI-X [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-D i2c-adapter i2c-2: unable to read EDID block. i915 0000:00:02.0: DVI-D-1: no EDID data i2c-adapter i2c-4: unable to read EDID block. i915 0000:00:02.0: DVI-D-2: no EDID data
It's GM45, not i915.
Will you please confirm whether the CONFIG_FRAMEBUFFER_CONSOLE is enabled in kernel configuraion? Will you please also attach the vbios.dump? Please use the following command to get the vbios.dump. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom Thanks.
Created attachment 29836 [details] vbios.dump of the Dell Latitude E5500 (bios A13) Here it is.
I forgot: [root@localhost ~]# zgrep CONFIG_FRAMEBUFFER_CONSOLE /proc/config.gz CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set [root@localhost ~]#
could you ssh to that machine and help grab a copy of regdump? intel_reg_dumper is a tool under xf86-video-intel/src/reg_dumper in git repository. Maybe you can find it in a Mandriva debug package or something, I'm not sure... you didn't connect any external monitor, right?
Will you please also attach the output of acpidump? The latest acpidump tool(pmtools-20071116) can be found in http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Thanks.
Created attachment 29918 [details] acpidum on the Dell Latitude E5500 Here is the acpidum. Right, no monitor connected on the VGA port. The regdump output will come soon.
Created attachment 29932 [details] reg_dumper on the Dell Latitude E5500
From the reg_dump it seems that the LVDS port is still enabled. >(II): LVDS: 0xc2208300 (enabled, pipe B, 18 bit, 1 channel) Will you please confirm whether it can work well on the previous version kernel? For example: 2.6.31-rc8 It will be better that you can confirm whether it can work well under UMS mode by adding the boot option of "i915.modeset=0". Please also attach the following output under UMS mode. cat /proc/acpi/button/lid/LID/* Thanks.
I put the wrong reg_dumper output. This on was with i915.modeset=0: I'm putting a new one without this option. I will add "cat /proc/acpi/button/lid/LID/*" in the same time.
Created attachment 29934 [details] reg_dumper in UMS mode on the Dell Latitude E5500
Created attachment 29935 [details] output of /proc/acpi/button/lid/LID
Created attachment 29936 [details] output of /proc/acpi/button/lid/LID in UMS mode
Please forget (In reply to comment #12) > Created an attachment (id=29935) [details] > output of /proc/acpi/button/lid/LID I made a wrong upload, this attachment is the same than the one in "comment #13".
(In reply to comment #11) > Created an attachment (id=29934) [details] > reg_dumper in UMS mode on the Dell Latitude E5500 > confirm: i915.modeset=1 ( or without any option ) is KMS i915.modeset=0 is UMS Do you mean this one is taken under UMS or KMS now?
(In reply to comment #15) > (In reply to comment #11) > > Created an attachment (id=29934) [details] [details] > > reg_dumper in UMS mode on the Dell Latitude E5500 > > > > confirm: > > i915.modeset=1 ( or without any option ) is KMS > i915.modeset=0 is UMS > > Do you mean this one is taken under UMS or KMS now? > This one was taken under UMS (I added this in my comment on #11).
(II): HTOTAL_B: 0x053804ff (1280 active, 1337 total) (II): HBLANK_B: 0x054f04ff (1280 start, 1360 end) HTOTAL < HBLANK. we had a bug before fixed by Jesse. seems the patch didn't hit KMS version of the driver? bug# 17292.
Will you please try to add the "modedebug" option in xorg.conf and attach the xorg.0.log in UMS mode? > option "modedebug" "on" Will you please add the boot option of "drm.debug=0x7" on the Eric's drm-intel-next tree and attach the output of dmesg in KMS mode? Thanks.
(In reply to comment #17) > (II): HTOTAL_B: 0x053804ff (1280 active, 1337 total) > (II): HBLANK_B: 0x054f04ff (1280 start, 1360 end) > > HTOTAL < HBLANK. we had a bug before fixed by Jesse. seems the patch didn't hit > KMS version of the driver? bug# 17292. this issue is also fixed in KMS mode. It is fixed by the following patch: >commit 37df96736bfe6f5fd9a141d62946e1083d73e712 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Feb 23 15:36:42 2009 -0800 drm/i915: handle bogus VBT panel timing Thanks.
This report is against 2.6.31 so this fix is already included
(In reply to comment #20) > This report is against 2.6.31 so this fix is already included > Sorry for the late response. Will you please try the latest upstream kernel(2.6.32-rc4) and attach the output of dmesg? Please add the boot option of "drm.debug=0x06". thanks.
Created attachment 30616 [details] dmesg when booting with i915.modeset=0 and drm.debug=0x06 on the 2.6.32-rc5 kernel
Created attachment 30624 [details] dmesg when booting with KMS and drm.debug=0x06 on the 2.6.32-rc5 kernel
Hi, Any news for this bug? Thanks.
Sorry for the late response. Will you please try the latest linux kernel(2.6.32-rc7) and see whether the issue still exists? (Please add the boot option of "drm.debug=0x06"). thanks.
So now that the next ddx driver won't support anything but KMS, what's the fallback plan for such chips in case 2.6.32? Damien, you can test kernel-linus-2.6.32-0.rc8.1.1mdv2010.1 from contribs.
(In reply to comment #26) > So now that the next ddx driver won't support anything but KMS, what's the > fallback plan for such chips in case 2.6.32? From the dmesg log in comment #23 it seems that we get the incorrect display mode from EDID for LVDS. >[drm:drm_mode_debug_printmodeline], Modeline 39:"1280x800" 60 65000 1280 1328 1360 1337 800 803 809 810 0x48 0x9 >[drm:drm_mode_debug_printmodeline], Modeline 40:"1280x800" 40 47000 1280 1328 1360 1427 800 803 809 823 0x40 0x9 The hsync is beyond the bblank. After the following commit is applied, it will remove the invalid display mode and then we will fall back to fix panel mode. >commit fcb45611448098a36b893bda71e72bd39730a3dd Author: Zhao Yakui <yakui.zhao@intel.com> Date: Wed Oct 14 09:11:25 2009 +0800 drm: Add the basic check for the detailed timing in EDID Sometimes we will get the incorrect display modeline when parsing the detailed timing in EDID. For example: >hsync/vsync width is zero >sync is beyond the blank. the above commit is shipped in 2.6.32-rc6. Please try the latest upstream kernel(2.6.32-rc8) and see whether the issue still exists. > > Damien, you can test kernel-linus-2.6.32-0.rc8.1.1mdv2010.1 from contribs. >
Sorry for the delay, I was quite busy. The bug is well fixed on 2.6.32-1. I will add the dmesg in a few time.
Created attachment 31885 [details] dmesg when booting with KMS and drm.debug=0x06 on the 2.6.32-1 kernel
Why did you closed it? It's still not fixed. The test was about to check on 2.6.32, not the 2.6.31 (kernel of the bug).
comment# 27 has a commit which fixes this bug. that meets our bugzilla criterial. Backing porting is another thing. In fact, those who do backporting will only take commits from those have been marked as fixed to do backporting..
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.