Bug 43379

Created attachment 53973 [details]
Xorg.0.log with external monitor plugged in at grub display time

Can you please add drm.debug=0xe to your kernel boot parameters and attach a dmesg for the failing boot (and for completion one from the successful boot)?

Created attachment 53984 [details]
dmesg output in the failed case

Created attachment 53985 [details]
dmesg output in the successful case

As requested i made the tests with the kernel option 'drm.debug=0xe' added to the grub command line.

Additional info: If you are asking for the number of output ports you see in the log - the notebook is docked into the doching station which makes me powering-on/off the notebook easier.

The notebook itself has a LVDS display, a VGA and a display port connector.
The docking station mirrors the VGA connector and supplies 2 additional display port / DVI combined outputs.

The procedure is as follows. Boot the notebook without starting xdm to the text mode login prompt. Log in and execute 'startx'.

In the failed case i find myself returned to the command prompt where i executed 'dmesg'.

In the successful case the X desktop came up. From an other PC i remotely logged in via ssh and executed the 'dmesg' command.

I think it is related to updated code to handle shared SSC where one output doesn't support SSC (i.e. VGA). Not sure why it is being handled differently though.

I think this hypothesis can be tested by adding i915.lvds_use_ssc=0 to you kernel boot parameters. I suspect this will cause the panel to fail without any VGA monitor connected.

As suggested i made three tests:

1. Monitor attached, lid closed at power-on time
2. Monitor attached, lid open at power-on time until grub menu displays, then closed
3. Monitor detached, lid open at power-on time

Test 1 failed the others were successful.

Your assumption (LVDS screen garbled at test 3) does not apply.

For reference i attached the dmesg-outputs (with kernel option drm.debug=0xe) resulting from the three tests.

Created attachment 54033 [details]
dmesg output from test #1

Created attachment 54034 [details]
dmesg output from test #2

Created attachment 54035 [details]
dmesg output from test #3

Maybe it's the same behaviour as referred in bug https://bugs.freedesktop.org/show_bug.cgi?id=37742

(In reply to comment #11)
> Maybe it's the same behaviour as referred in bug
> https://bugs.freedesktop.org/show_bug.cgi?id=37742

Yes, re-reading your comments, I believe it is. I had this bug marked down as one of the X chooses a bogus configuration.

Can you please test the patches from bug 37742 and reopen if this is actually a distinct bug?

*** This bug has been marked as a duplicate of bug 37742 ***

(In reply to comment #13)
> Can you please test the patches from bug 37742 and reopen if this is actually a
> distinct bug?
> 
> *** This bug has been marked as a duplicate of bug 37742 ***

Despite the negative test result in bug 37742 i van confirm that the patch referred in this bug is working for me.

So i change the state to verfified/worksforme.

Due i am currently at vanilla kernel 3.4-rc5 i did the tests using this kernel version.

First i tried with thew unpatched kernel.
Result: same bug as before.

Then i applied the patch to vanilla kernel 3.4-rc5. Though the referred patch only worked for 2 hunks i had to manually integrate the rest of hunks (about 7).

Result: working

I attach 2 files (used kernel option "drm.debug=0xe") for verification:
- /var/log/messages
- /var/log/Xorg.0.log

Thanks for our assistance.

Created attachment 60942 [details]
/var/log/messages (patched kernel)

/var/log/messages output with integrated patch as referred in bug 37742.

Created attachment 60943 [details]
/var/log/Xorg.0.log (patched kernel)

/var/log/Xorg.0.log output with integrated patch as referred in bug 37742.