Intel,

  update on this? Let me know if you need other information. thks

Intel are you there?


The terminal will get display both in text mode and X with vesa driver and nomodeset option.

The screen going blank immediately after grub says that the bug is in the
kernel code, (so anything from Xorg.0.log is too late).

What kernel version is affected?

Have you tried the most recent kernel?

Can you bisect to find any functional version with kernel mode-setting?

Thanks,

-Carl

PS. I don't have ready access to an 855 machine, but I think Chris Wilson
does---and I'm also quite sure his 855 is at least working with recent
kernels, (the kernel driver may have known bugs, but it at least does more
than a blank screen).

it is still having problem in SLED11SP1RC1 with kernel 2.6.32.9-0.5-pae using intel driver.

The terminal is working with display using vesa driver and nomodeset boot option.

continue to have the same problem on kernel 2.6.32.10-0.4-default

continue to have the same problem on SLED11SP1RC2 - kernel 2.6.32.10-0.4-default

More LVDS fun. Given that Xorg.log is simply reporting that no connections are found, then it is a likely continuation of bugs #18462 and #20826. And might even be due to incorrect reporting of lid state, so common that we now [2.6.34] completely ignore it.

(In reply to comment #6)
> continue to have the same problem on SLED11SP1RC2 - kernel
> 2.6.32.10-0.4-default

What Chris wilson said in comment #7 sounds reasonable.

Can you try the 2.6.34-rcX kernel and see whether the issue still exists?

thanks.

we need dmesg output with drm.debug=7. Yakui, do you like to take this?

(In reply to comment#9)
>we need dmesg output with drm.debug=7.

do you mean i put the drm.bebug=7 at the kernel boot parameter?
using intel driver?
with which kernel version?

(In reply to comment #8)

>What Chris wilson said in comment #7 sounds reasonable.
>Can you try the 2.6.34-rcX kernel and see whether the issue still exists?

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

Created attachment 34900 [details]
dmesg collected with drm.debug=7

> More LVDS fun. Given that Xorg.log is simply reporting that no connections are
> found, then it is a likely continuation of bugs #18462 and #20826. And might
> even be due to incorrect reporting of lid state, so common that we now 
> [2.6.34] completely ignore it.

Chris, you mean the folloging commits?

commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Feb 12 09:30:00 2010 -0800

    drm/i915: give up on 8xx lid status
    
    These old machines more often than not lie about their lid state.  So
    don't use it to detect LVDS presence, but leave the event handler to
    deal with lid open/close, when we might need to reset the mode.
    
    Fixes kernel bug #15248


In between IS_I8XX(dev) changed to IS_GEN2(dev) with commit #bad720ff3e8e47a04bd88d9bbc8317e7d7e049d3 ...


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.


Are my assumptions correct?

Please see my question in comment above. Thanks.

Yes, those look like the right commits.

(In reply to comment #15)
> Yes, those look like the right commits.

Finally we figured out that the patches didn't help. We already had this one in place, which does exactly the same.

From: Takashi Iwai <tiwai@suse.de>
Subject: drm/i915: Disable ACPI lid detection as an ad hoc workaround
Patch-mainline: Never
References: bnc#577937

On 2.6.32 and later kernels, the backlight of 945GM/965GM doesn't recover
after the lid is reopened.  This is a regression from 2.6.31, and a
workaround is to disable the dynamic lid-detection.

NOTE: this fix is NOT THE RIGHT THING.  Remove this patch once when the
better and correct fix is done in the upstream (and backported).

Signed-off-by: Takashi Iwai <tiwai@suse.de>

---
 drivers/gpu/drm/i915/intel_lvds.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,8 @@ static enum drm_connector_status intel_l
 {
        enum drm_connector_status status = connector_status_connected;
 
+       return status; /* XXX AD-HOC WORKAROUND!! (bnc#577937) */
+
        if (!acpi_lid_open() && !dmi_check_system(bad_lid_status))
                status = connector_status_disconnected;
 
@@ -702,6 +704,8 @@ static int intel_lid_notify(struct notif
        struct drm_device *dev = dev_priv->dev;
        struct drm_connector *connector = dev_priv->int_lvds_connector;
 
+       return NOTIFY_OK; /* XXX AD-HOC WORKAROUND!! (bnc#577937) */
+
        /*
         * check and update the status of LVDS connector after receiving
         * the LID nofication event.

by the way i tried the patches mentioned in intelbug26899 comment#25

>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. 
drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.

Does not see whitescreen anymore but still not able to startX

"(EE) intel (0): No kernel modesetting driver detected
(II) UnloadModeul:"intel"
(EE) Screen(s) found, but none have a usable configuration

Fatal server error;
no screen found"

intel, any advice here, until now we still do not know the correct patch for this chipset.

So the problem is still KMS wrongly thinks no panel is connected or lid closed on this 855GM? I think this should be fixed in 2.6.34.

(In reply to comment#19)
>Wang Zhenyu 2010-05-19 20:21:16 PDT 
>So the problem is still KMS wrongly thinks no panel is connected or lid closed
>on this 855GM? I think this should be fixed in 2.6.34.

We tried and confirmed we do not see problem on kernel 2.6.34 RC3 as stated in comment#11.

We had tried the patches mentioned in comment#15 and also #17 on kernel 2.6.32, the display is still not OK.

Patches from comment#15:
drm/i915: give up on 8xx lid status
drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

patches from comment#17:
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. 
drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.

Our question is, what is the right patch to apply for kernel 2.6.32
(SLES/SLED11SP1)?

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

This is badly broken.

(In reply to comment#21)
>Wang Zhenyu 2010-05-19 22:03:34 PDT 
>Don't apply 
>drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.
>
>This is badly broken.

could you let us know the specific patch to apply for kernel 2.6.32
(SLES/SLED11SP1)?. Thanks a lot.

You just need
drm/i915: give up on 8xx lid status
drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

(in reply to comment#23)
>Wang Zhenyu 2010-05-20 00:34:50 PDT 
>You just need
>drm/i915: give up on 8xx lid status
>drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.

with these two is not working.. see comment#16..

(In reply to comment #20)
> (In reply to comment#19)
> >Wang Zhenyu 2010-05-19 20:21:16 PDT 
> >So the problem is still KMS wrongly thinks no panel is connected or lid closed
> >on this 855GM? I think this should be fixed in 2.6.34.
> 
> We tried and confirmed we do not see problem on kernel 2.6.34 RC3 as stated in
> comment#11.
> 
> We had tried the patches mentioned in comment#15 and also #17 on kernel 2.6.32,
> the display is still not OK.
> 
> Patches from comment#15:
> drm/i915: give up on 8xx lid status
> drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.
> 
> patches from comment#17:
> 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. 
> drm/i915: Don't set up the LVDS if it isn't in the BIOS device table.
> 
> Our question is, what is the right patch to apply for kernel 2.6.32
> (SLES/SLED11SP1)?

Will you please try to add the boot option of "drm.debug=0x06" on 2.6.32 and attach the output of dmesg? Of course the patches mentioned in comment #15 and #17 should be applied.

It is very interesting that it can work well on 2.6.34-rcX kernel.

thanks.
    Yakui

>Will you please try to add the boot option of "drm.debug=0x06" on 2.6.32 and
>attach the output of dmesg? Of course the patches mentioned in comment #15 and
>#17 should be applied.

>It is very interesting that it can work well on 2.6.34-rcX kernel.

Yakui, you request is to apply (1) or (2) or (3):

(1) all patches mentioned in comment#15 and #17?

(2) patch mentioned in  comment#15 by itself?

(3) patches mentioned in comment#17 by itself?

Previously, i had tried  (2), (3) independantly which display does not turn out to work.

Created attachment 35843 [details]
dmesg, Xorg.0.log, intel_lvds.c, i915_drv.h

FYI when applying patches in comment#15 in SLED11SP1(2.6.32 kernel). will run into  error while compiling if include this chunk mentioned in patch - "drm/i915: Stop trying to use ACPI lid status to determine LVDS connection":

"
+	if (IS_I8XX(dev) || IS_GEN3(dev))
 		return connector_status_connected;

"

error message:
"drivers/gpu/drm/i915/intel_lvds.c: In function ?intel_lvds_dtect?:
drivers/gpu/drm/i915/intel_lvds.c:616:error:implicit declaration of fuction ?IS_PINEVIEW?"

Thus i had proceed with patches mentioned in comment#15 without this chunk. It is compiled and appiled successfully. However the displayed is not working.
attached is dmesg, xorg.0.log collected with drm.debug=0x06.

Created attachment 35878 [details]
request dmesg and Xorg.0.log with all patches mention in comment#15 and 17 applied

(In reply to comment #28)
> Created an attachment (id=35878) [details]
> request dmesg and Xorg.0.log with all patches mention in comment#15 and 17
> applied

Sorry for the late response.
   From the dmesg log in comment #28 it seems that the i915 driver is not correctly loaded when the KMS is enabled.
    >[    4.080980] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
    >[    4.081098] DRM: Fill_in_dev failed.

    Will you please double check whether you use the same .config file for 2.6.32?
It will be better that you build intel_agpgard into built-in kernel module and see whether the system can be booted correctly.

thanks.

(In reply to comment#29)

>From the dmesg log in comment #28 it seems that the i915 driver is not
>correctly loaded when the KMS is enabled.
>   >[    4.080980] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart
>>module.
>   >[    4.081098] DRM: Fill_in_dev failed.

>   Will you please double check whether you use the same .config file for
>2.6.32?
>It will be better that you build intel_agpgard into built-in kernel module and
>see whether the system can be booted correctly.

Yes i am using the same .config file for 2.6.32.
That is, do a make mrproper then cp /boot/config-`uname -r` ./.config

Then we run make menuconfig

which brings up the kernel configuration menu. Go to Load an Alternate Configuration File and choose .config (which contains the configuration of your current working kernel) as the configuration file and so on...

The issue has temporarily been resolved by switching back to the latest/last UMS capable xf86-video-intel 2.9.1 driver. It might pop up again in 2-3 years from now. :-( Closing as WONTFIX for now.