Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 839272

Summary: Xorg freezes when screen cable disconnected and reconnected again
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: mdomonko, pfrields
Target Milestone: rc   
Target Release: 7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 09:37:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 782468, 982785    
Attachments:
Description Flags
dmesg
none
messages none

Description Vladimir Benes 2012-07-11 12:34:26 UTC
Description of problem:
I have [Quadro NVS 290] [10de:042f] with signal splitter into two screens. When I disconnects the primary one and reconnect it back X gets frozen in a while.

Keyboard is frozen as well as numlock is not reacting as well. I can get some response from the system over ssh. I can kill X and free keyboard but I cannot get X server back to show something .. need to reboot to get screen back. 

will paste more logs and possibly gdb traceback

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.12.0-5.el7.x86_64
xorg-x11-drv-nouveau-0.0.16-36.20120306gitf5d1cd2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.disconnect primary screen from signal splitter cable
2.reconnect it back 

  
Actual results:
whole computer frozen (keyboard, no screen)

Expected results:
no freeze.. computer back to normal

Additional info:
it needs to be primary screen, secondary is working as expected

Comment 1 Vladimir Benes 2012-07-11 13:41:06 UTC
Created attachment 597575 [details]
dmesg

Comment 2 Vladimir Benes 2012-07-11 13:41:43 UTC
Created attachment 597576 [details]
messages

Comment 3 Martin 2012-07-17 14:00:51 UTC
I can reproduce this bug on Quadro 600 with first monitor connected to single-link DVI and second to DisplayPort with DVI adapter.

I have another two scenarios:

1) When I disable primary monitor in Control Center and then enable, Xorg freezes. It doesn't depend only on HW disconnect.

2) When I boot with only one monitor and then I connect second monitor, Xorg freezes too.

Comment 4 Martin 2012-07-17 14:35:53 UTC
HW (dis)connect scenario is not reproducible with 2 VGA outputs*, only with scenarion 1 above.

*It does nothing automatically, must be enabled by Control Center, like in scenario 1.

GPU: NVS 300 with dual-link DVI to 2x VGA adapter

Comment 5 Martin 2012-07-18 10:23:34 UTC
I can reproduce this bug only in Gnome Shell or GDM login screen. KDE and VT does not triger this bug,

I've found a workaround when second monitor is connected, but disabled. Switch to VT, wait for second monitor to show console, then switch back to Gnome Shell and enable second monitor.

Comment 6 Martin 2012-07-18 10:37:12 UTC
Bug is reproducible with these nVidia cards and setups (always 2 monitors):

DVI interface:
Quadro 600 with DVI and DP to DVI adapter
NVS 300 with dual-link DVI to 2x DVI adapter
Quadro 400 with DVI and DP to DVI adapter
Quadro NVS 295 with 2x DP to DVI adapter

VGA interface:
NVS 300 with dual-link DVI to 2x VGA adapter

Comment 9 Paul W. Frields 2013-03-11 18:13:48 UTC
Can you retest with Alpha 3 and report back?

xorg-x11-server-Xorg-1.13.1-3.el7.x86_64
xorg-x11-drv-nouveau-1.0.6-2.el7.x86_64

Comment 10 Vladimir Benes 2013-03-12 07:40:56 UTC
this is definitely still there and affecting all cards not just this one.

Comment 13 Ben Skeggs 2013-10-23 00:22:55 UTC
This needs retesting once an el7 kernel with updated DRM is available.  The relevant paths changed significantly, and issues similar to these were fixed in the process.  Hopefully that means this one is already too :)

Comment 14 Michal Domonkos 2013-11-21 12:51:43 UTC
Retested on the latest RHEL7 nightly by several disconnect/connect cycles (using a VGA splitter) and it seems like this issue is already resolved.

To be precise, the only exception is when I disconnect the monitor and then connect it back but to the other of the two VGA outputs on the splitter.  In such case the monitor won't power on automatically but switching to a VT and back using CTRL-ALT-Fx combo does the trick.  This is not a big issue I think and probably not related to this BZ, so I suggest to close as VERIFIED.

Comment 15 Michal Domonkos 2013-11-22 16:04:40 UTC
Also re-tested Comment 3 and everything went smooth.

Comment 17 Ludek Smid 2014-06-13 09:37:47 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.