Bug 1072557 - 3.13.5-101.fc19.x86_64: Hangs on boot if external monitor connected
Summary: 3.13.5-101.fc19.x86_64: Hangs on boot if external monitor connected
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-04 19:05 UTC by peter.senna
Modified: 2015-02-17 19:59 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 19:59:55 UTC
Type: Bug


Attachments (Terms of Use)
Xorg log (99.51 KB, text/plain)
2014-03-04 19:05 UTC, peter.senna
no flags Details
dmesg (69.45 KB, text/plain)
2014-03-04 19:06 UTC, peter.senna
no flags Details
dmesg with kernel-3.12.11-201.fc19.x86_64 (76.12 KB, text/plain)
2014-03-04 19:08 UTC, peter.senna
no flags Details
xorg log with kernel-3.12.11-201.fc19.x86_64 (104.45 KB, text/plain)
2014-03-04 19:09 UTC, peter.senna
no flags Details

Description peter.senna 2014-03-04 19:05:27 UTC
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.

Comment 1 peter.senna 2014-03-04 19:06:19 UTC
Created attachment 870590 [details]
dmesg

Comment 2 peter.senna 2014-03-04 19:08:22 UTC
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.

Comment 3 peter.senna 2014-03-04 19:09:30 UTC
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.

Comment 4 peter.senna 2014-03-04 19:12:07 UTC
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.

Comment 5 peter.senna 2014-03-04 19:27:10 UTC
+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...

Comment 7 peter.senna 2014-03-04 20:40:29 UTC
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.

Comment 8 peter.senna 2014-03-05 15:40:09 UTC
passing nomodeset as Kernel cmd maskes the Kernel to boot, but two screens are still dead.

Comment 9 peter.senna 2014-03-10 15:59:54 UTC
Problem persists on kernel.x86_64 0:3.13.5-103.fc19.

Comment 10 peter.senna 2014-03-19 11:54:42 UTC
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?

Comment 11 Josh Boyer 2014-03-19 13:58:48 UTC
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?

Comment 12 peter.senna 2014-03-19 14:22:48 UTC
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. :-)

Comment 13 Josh Boyer 2014-03-19 14:53:44 UTC
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.

Comment 14 Fedora End Of Life 2015-01-09 21:11:42 UTC
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.

Comment 15 Fedora End Of Life 2015-02-17 19:59:55 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.