Created attachment 870589 [details] Xorg log Description of problem: After upgrading to kernel-3.13.5-101.fc19.x86_64, my notebook is not booting if my external monitor is connected to HDMI3. If I unplug the monitor, power on the notebook and connect if before or after X start, then it works fine. Version-Release number of selected component (if applicable): kernel-3.13.5-101.fc19.x86_64 How reproducible: Completely Steps to Reproduce: 1. Make sure external monitor is connected to HDMI 3 2. Power on the notebook 3. Actual results: It hangs Expected results: It should work as it is with kernel-3.12.11-201.fc19.x86_64 Additional info: Monitor: Acer PB278Q 27" 16:9 2560 x 1440 This resolution is not officialy supported by the hardware, so I use xrandr to reduce the refresh rate to get full resolution. More at: https://ask.fedoraproject.org/en/question/28865/adding-custom-monitor-resolution-to-supported-list-of-resolutions/ My guess is that the Kernel hangs when trying to start a high resolution text console on the monitor with unsupported resolution. The attachments of version 3.13.5-101 were taken when the notebook was initialized without the external monitor connected to it.
Created attachment 870590 [details] dmesg
Created attachment 870592 [details] dmesg with kernel-3.12.11-201.fc19.x86_64 Dmesg when booting with external monitor connected with previous kernel. There is no text console(eg Alt-F2), but the Kernel boots.
Created attachment 870597 [details] xorg log with kernel-3.12.11-201.fc19.x86_64 Xorg log when booting with external monitor connected with previous kernel.
For taking the conclusion that the kernel was not responding, I have powered the notebook on with external monitor connected, waited it to boot, disconnected external monitors and then tried caps lock key. It was dead.
+Josh Boyer, The kernel is not starting if the monitor is connected, this is why I assigned it to kernel instead of xorg-x11-drv-intel...
http://fedoraproject.org/wiki/KernelBugTriage#Video_Subsystem_bugs
When booting with a display that has native 1920x1080 resolution connected to the same HDMI3 port, it boots normally. So the issue only happens with high resolution monitor connected to HDMI3.
passing nomodeset as Kernel cmd maskes the Kernel to boot, but two screens are still dead.
Problem persists on kernel.x86_64 0:3.13.5-103.fc19.
What is the point of filing Kernel bug reports here if due your silence I need to use stock Kernels from kernel.org and report bugs upstream? Why don't you just stop accepting Kernel bug reports?
The bug is assigned to the people that are in a position to help the most. They're also the people that happen to have numerous bug reports. Not all bugs are equal and due to the high number of them, it's difficult to get to all of them. That being said, your latest comment implies that kernel.org kernels work just fine. So you've tested stock 3.13.5 from upstream and there are no issues with the monitor setup you have described? Also, if you have reported this issue upstream yourself, could you provide a link to the bugzilla entry or mailing list thread?
For me, ignoring a bug report means that no one cares. Why not closing the bug as wontfix? Why not update it saying it has low priority, and that nobody will work on it for the next 12 months? Why not being transparent? The only feedback I get is when I bother you. You are being creative about what my last comment implies. My last comment is the description of the nonsense I'm facing here, it describes my frustration, and what I do not want to do. Should I use the word "regression" again? It worked last time I did. :-)
While I understand your frustration, doing what you suggest in your previous comment isn't nonsense and it might actually lead to progress on the bug. The more people help themselves according to their abilities, the better off the bug will be in terms of getting is resolved. As for commenting low priority, it's not personally my call. Sometimes maintainers wait to see if multiple similar reports come in. Sometimes they're busy working on other bugs. Sometimes they ignore bugs. I have no idea which case this bug is in. Not providing status reports isn't a lack of transparency.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.