Created attachment 33778 [details]
xorg.conf generated

Created attachment 33779 [details]
xorg log

Will you please add the boot option of "drm.debug=0x04" on the 2.6.33 stable kernel and attach the output of dmesg? (It will be better that the i915 is compiled as built-in kernel).

Please also attach the output of intel_reg_dumper on your box. The intel_reg_dumper tool is included in intel_gpu_tool, which can be downloaded from:
   >http://xorg.freedesktop.org/archive/individual/app/ or the latest code at git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools

Please also attach the output of vbios.dump on your box, which can be obtained by using the following command:
    1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
    2. cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump
    3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom

Thanks.

Hi Yakui, I'll make available the required information as soon as possible. In the meantime do you think this might be related to Bug 25787?

(In reply to comment #4)
> Hi Yakui, I'll make available the required information as soon as possible. In
> the meantime do you think this might be related to Bug 25787?
> 
It seems that this is a laptop based on 915GM chipset. It is not related with the bug 25787.

Anyway, you can attach the info mentioned in comment #3.

Thanks.

I'm having problems with the .33 stable kernel right now. Will attach the info as soon as I manage to get it up and running.

(In reply to comment #6)
> I'm having problems with the .33 stable kernel right now. Will attach the info
> as soon as I manage to get it up and running.

It will also be ok if you can try the 2.6.33-rcX kernel (for example: rc6/rc7) and attach the output of dmesg.(the boot option of "drm.debug=0x04" should be added).

thanks.
> 

X loads with the .33 stable kernel. It seems to be working fine ..

Created attachment 33906 [details]
dmesg with drm.debug=0x04 kernel param

Created attachment 33907 [details]
vbios

Thanks for the testing.

From the vbios info in comment #10 it seems that the VBT signature is missing, which causes that incorrect DDC bus is used by VGA on 2.6.31/32 kernel. And this issue is fixed by the following commit, which is already shipped in the 2.6.33 kernel. 
    >commit 29874f44fbcbc24b231b42c9956f8f9de9407231
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Wed Nov 18 15:15:02 2009 +0800

    drm/i915: fix gpio register detection logic for BIOS without VBT

As the system can work well on 2.6.33 stable kernel, this bug will be marked as resolved.

Thanks.

I tested this with a SLE-11-SP1 2.6.32.11 KoTD and I'm still getting a blank screen with the same error in the Xorg log.

The 2.6.32.11 changelog indicates that the fix in comment #11 has been included. Could the problem lie somewhere else?

Xorg.0.log excerpt :

...
(**) 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) 915GM
(--) intel(0): Chipset: "915GM"
(==) intel(0): video overlay key set to 0x101fe
(II) intel(0): Output VGA1 using monitor section Monitor[0]
(**) intel(0): Option "PreferredMode" "1024x768"
(II) intel(0): Output VGA1 has no monitor section
(II) intel(0): Output VGA1 disconnected
(WW) intel(0): No outputs definitely connected, trying again...
(II) intel(0): Output VGA1 disconnected
(WW) intel(0): Unable to find initial modes
(==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
(EE) intel(0): No modes.
(II) UnloadModule: "intel"
(EE) Screen(s) found, but none have a usable configuration.
...

Can you add the boot option of "drm.debug=0x04" and attach the output of dmesg?

thanks.
   Yakui

Created attachment 34809 [details]
dmesg with drm.debug=0x04, on suse 2.6.32.11 KoTD kernel, no display

(In reply to comment #14)
> Created an attachment (id=34809) [details]
> dmesg with drm.debug=0x04, on suse 2.6.32.11 KoTD kernel, no display

From the dmesg log it seems that the incorrect DDC is used for VGA. Will you double check whether the fix in comment #11 is included?

Thanks.

From http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.11 , i see that the fix in comment #11 has been included in 2.6.32.11.

From Novell :

"The 2.6.32.11 kernel is now checked in, and should be in RC3.
If this still fails in RC3, then something else must be the matter."

(In reply to comment #16)
> From http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.11 , i see
> that the fix in comment #11 has been included in 2.6.32.11.
> 
> From Novell :
> 
> "The 2.6.32.11 kernel is now checked in, and should be in RC3.
> If this still fails in RC3, then something else must be the matter."

Sorry that I am confused by the info that VGA is disconnected.

Just now I rechecked the dmesg log in comment #9 and it seems that the VGA is still disconnected.

In fact it seems that the issue on this box is the black screen on the integrated LVDS panel. Right?
   It seems that the LVDS is detected as connected on 2.6.33 kernel. But it is skipped on 2.6.32.xx kernel.

If so, it will be related with the different LVDS detection mechansim on 2.6.32.x and 2.6.33 kernel.
   >On 2.6.32 kernel: the LID is used to indicate whether the LVDS should be initialized. And this is removed on 2.6.33 kernel. It seems that there is no LID on this laptop. 
   >On 2.6.33 kernel: The LVDS info in VBT is used to decide whether the LVDS should be initialized. If the VBT is incorrect, it is assumed that the LVDS should be initialized.

If we want 2.6.32x kernel to work well on this laptop, maybe the following commit should also backported to 2.6.32.xx kernel.
    >commit 6363ee6f496eb7e3b3f78dc105e522c7b496089b
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Nov 24 09:48:44 2009 +0800

    drm/i915: parse child device from VBT

    >commit 7cf4f69d3f4511f443473954456cb91d5514756d
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Nov 24 09:48:47 2009 +0800

    drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.

    >commit 38b3037ee47fbd65a36bc7c39f60a900fbbe3b8e
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Nov 24 10:07:00 2009 -0500

    drm/i915: Fix LVDS presence check

     >commit 11ba159288f1bfc1a475c994e598f5fe423fde9d
Author: Matthew Garrett <mjg@redhat.com>
Date:   Tue Dec 15 13:55:24 2009 -0500

    drm/i915: Don't check for lid presence when detecting LVDS


I only listed the required patches.   

thanks
   Yakui

(In reply to comment #17)

> In fact it seems that the issue on this box is the black screen on the
> integrated LVDS panel. Right?

Yes, that is correct.

> If so, it will be related with the different LVDS detection mechansim on
> 2.6.32.x and 2.6.33 kernel.
>    >On 2.6.32 kernel: the LID is used to indicate whether the LVDS should be
> initialized. And this is removed on 2.6.33 kernel. It seems that there is no
> LID on this laptop. 

You're correct, this is a system with an integrated panel and not a laptop. Hence there's no lid like a laptop.

From Novell :

"
And what about that one?

commit 6e6c822868f113dabe3c33bdd91e883cc28fa11b
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Mar 17 13:48:06 2010 -0700

    drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

    I've been getting more and more quirk reports about this.  It seems
    clear at this point that other OSes are not using this for determining
    whether the integrated panel should be turned on, and it is not
    reliable for doing so.  Better to light up an unintended panel than to
    not light up the only usable output on the system.

I'm afraid that's all wild guessing here ...
"

yakui, any thoughts about novell feedback?

I had tried 2.6.34-rc3 kernel, the terminal is able to boot up with display
using Intel driver.

yakui, appreciate if you could help us to identify the correct patch required. I believe novell is willing to qeue this up in the next RC or atleast as kernel update.

I am unable to directly apply the following commits to the 2.6.32.11 vanilla kernel to test their effects, probably because it requires other commits to be applied first ..

    >commit 6363ee6f496eb7e3b3f78dc105e522c7b496089b
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Nov 24 09:48:44 2009 +0800

    drm/i915: parse child device from VBT

    >commit 11ba159288f1bfc1a475c994e598f5fe423fde9d
Author: Matthew Garrett <mjg@redhat.com>
Date:   Tue Dec 15 13:55:24 2009 -0500

    drm/i915: Don't check for lid presence when detecting LVDS

The commit suggested by Novell cannot be directly applied either

    >commit 6e6c822868f113dabe3c33bdd91e883cc28fa11b
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Mar 17 13:48:06 2010 -0700

    drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

You'll need to fix up any conflicts against your kernel sources; you should just make the lvds_detect function in intel_lvds.c return true unconditionally.

I've managed to apply the following 3 patches by hand to a 2.6.32.11 kernel and the display is working fine now when using intel driver.:

drm/i915: parse child device from VBT
drm/i915: Don't check for lid presence when detecting LVDS
drm/i915: Stop trying to use ACPI lid status to determine LVDS connection. 

I also found that a fourth patch is required from:

https://patchwork.kernel.org/patch/62356/ titled drm/i915: Use the child device to decide whether the LVDS should be intialized

Yakui, can you point me to the official link to this patch?

(In reply to comment #25)
> I also found that a fourth patch is required from:
> 
> https://patchwork.kernel.org/patch/62356/ titled drm/i915: Use the child device
> to decide whether the LVDS should be intialized

So is it required for your purpose or not?

Yes it is.

Realized that this patch (https://patchwork.kernel.org/patch/62356/ titled drm/i915: Use the child device to decide whether the LVDS should be intialized) is similar to the one Yakui posted : 

>commit 7cf4f69d3f4511f443473954456cb91d5514756d
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Nov 24 09:48:47 2009 +0800

    drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.

(In reply to comment #28)
> Realized that this patch (https://patchwork.kernel.org/patch/62356/ titled
> drm/i915: Use the child device to decide whether the LVDS should be intialized)
> is similar to the one Yakui posted : 
> >commit 7cf4f69d3f4511f443473954456cb91d5514756d
> Author: Zhao Yakui <yakui.zhao@intel.com>
> Date:   Tue Nov 24 09:48:47 2009 +0800
>     drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.

Sorry for the late response. 

It seems that you have found the correct patch, right?
    I attach the corresponding commit id in comment #17. And the corresponding patch can be found on upstream kernel tree by using git.

Thanks.

this sounds like a resolved bug, isn't it?

(In reply to comment #30)
> this sounds like a resolved bug, isn't it?

Yes. The system can work well on 2.6.33 kernel. The remaining issue is only
to find the correct fix so that they can be backported to the 2.6.32.xx kernel.

thanks.

Hi Yakui, I think we can consider this issue closed. We'll have to work with Novell to integrate the required patches. Thanks.

(In reply to comment #32)
> Hi Yakui, I think we can consider this issue closed. We'll have to work with
> Novell to integrate the required patches. Thanks.

Hi, Vance
    
    The commits mentioned in comment #17 should be backported to 2.6.32.xx kernel. The corresponding patch can be found in the upstream kernel tree by using git.
    
     The following commit had better be backported to 2.6.32.xx kernel.
     >commit 6e6c822868f113dabe3c33bdd91e883cc28fa11b
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Mar 17 13:48:06 2010 -0700

    drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

    Of course the above commits can't be applied on 32.xx kernel directly. And you need to resolve the conflicts manually.

thanks.

Hi Yakui, thanks for the update. I have already included the drm/i915: Stop trying to use ACPI lid status to determine LVDS connection patch in my test as mentioned in comment 25.