Created attachment 53971 [details] Xorg.0.log with external monitor pluged in at power-on of the notebook If a second monitor is plugged in on VGA port when Notebook (Lenovo T520, HD3000) is switched on xorg does not start. Error message in Xorg.0.log: Intel(0): Failed to set mode: Invalid argument No other (EE) messages are shown there. I tried the stable xf86-video-intel and the latest one. No difference. The only way (workaround) how i get it running is to plug off the external monitor until the grub boot menu displays. Then it is working. See gentoo bug report at: https://bugs.gentoo.org/show_bug.cgi?id=392549 Tests done (external monitor plugged in): 1. lid closed at power on time - X start fails 2. lid open until grub boot menu displayed - success Instead of open/close the lid you can also plug-in the exteral monitor at the grub stage. The behaviour is the same. Tested with Kernel 3.0.6 (gentoo stable) and 3.1.4. I attach two Xorg.0.log files, one for the failed X start, the other with the sucessful X start.
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.
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.