Bug 24021

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..