Bug 140435
| Summary: | System Crashes when starting up in Dual-Head configuration | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew D. Stadler <stadler> |
| Component: | system-config-display | Assignee: | Adam Jackson <ajax> |
| Status: | CLOSED CANTFIX | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | mattdm, mhw, sean |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-31 15:53:53 UTC | Type: | --- |
| 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: | 150223 | ||
The related bug "side effects" has been filed as # 140441 rhgb can use a seperate xorg.conf /etc/rhgb/xorg.conf, can you check if there is a config file there at all? If not put a single head xorg.conf file in there (probably /etc/X11/xorg.conf.bak). 1. There were no files at all in /etc/rhgb except for an empty temp directory. 2. I placed a single head xorg.conf in /etc/rhgb 3. Rebooted with 2nd monitor plugged in. 4. 2nd monitor comes up during rhgb showing mirrored image. rhgb completes. dual head is now working! Great suggestion, Paul. I assume there is still a bug or two in the system, but this workaround makes the system functional. This is due to some x limitations, I can probably get system-config-display to put an xorg.conf for rhgb in those setups. In comments for bug # 140441, Paul Nasrat suggested another workaround for the crash during rhgb. In /etc/sysconfig/init, setting GRAPHICAL=no seems to also resolve it. This means there are two useable workarounds for the crash/hang noted in steps 1..3 of the original bug report: - create single-head /etc/rhgb/xorg.conf - disable graphical boot entirely via /etc/sysconfig/init I've been looking into this same problem. The problem is with X and virtual consoles when X is running in dual-head mode. Any attempt to switch vc's (like from rhgb to the first gdm) causes the dual head X process you are switching from to hang. It doesn't release the screen and sits there burning CPU time. You can ssh into the box to confirm. More reproduction steps... Turn off rhgb or set it for standard screen mode (I didn't know about the separate config file - I was switching it using layouts in xorg.conf and gdm.conf). Bring system up to a dual screen display (Xinerama, Clone, or just side-by-side). Now, hit Cntrl-Alt-F1 to switch to the first vc. You're toast. Ssh into the box and do a top. X is on top the process list burning CPU time like a whirling dervish. Kill X with a -QUIT and run gdm-restart and you're back to a gdm login. I'm on a Del D600 laptop with a Radeon Mobility 9000 controller. Worked like a charm under FC2. Comment #6 sounds like bug 138503 My symptoms are exactly the same as comment #6...same laptop too. I agree with comment #7 that this bug appears to be related to bug 138503. More information... Another point on the curve... (Yes, this sounds like bug 138503... I'm going to post this there as well.) From comments in bug 138503... Tried disabling DRI - no help, no joy. Tried disabling hardware acceleration. Problem eliminated. Graphics speeds (especially switching desktops or scrolling Mozilla) sucks, but I can now switch between X server instantiations on different VCs or switch to a terminal mode VC. Looks like the problem may be related to hardware acceleration with the dual head modes. I added this to the "Device" sections (Driver "radeon"): Option "NoAccel" "on" Now it works. Comment it out and restart X and X once again freezes if you try and switch away from an instantiation in a dual head mode. I have additional information on this bug. I feel that it has become more serious. I am running the latest up2date stuff, specifically, xorg-x11-6.8.1-12.FC3.21 With this setup, and referring to the original list of steps, it is no longer possible to proceed beyond step 3. Attempting step 4, unplugging the 2nd monitor, fails as with step 3 - it is hung at "setting the hostname". The only way I was able to recover was to reboot, edit my kernel command line in GRUB, and temporarily remove "rhgb". I would observe that this is now a higher priority problem because now you have a system that can easily be wedged by a user and cannot be recovered by unplugging the monitor, it can only be recovered by knowledge of this specific problem and by understanding how to edit command lines in GRUB. Also, re comment #6, you can only ssh into the "hung" system if it is hung at step #2. If it hangs earlier (as in step #3) it is too early for sshd and you cannot access the system at all. (note, the workarounds still work - I never noticed that this had gotten "worse" because I have been using a single-screen /etc/rhgb/xorg.conf, which masks the problem) Mass update: move dual head bugs from FC5 to FC6, no way they can get fixed before FC5 release at this point. Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. Just a followup, I didn't abandon this bug. I have not been able to follow up because after upgrading to FC5, dual-head became completely unuseable on my system. (Somewhere between FC4 and FC5 the driver for the radeon 7500 became quite flaky in dual-head mode). fedora #185944 fedora #190751 freedesktop #5781 freedesktop #7019 I will be more than happy to regress this bug... if I ever regain dual-head useability.... |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: System hangs when restarting into dual-head configuration. Only a specific sequence of actions seems to be capable of bringing up dual-head. There are two specific issues I'd like to address here. The first is that the system is crashing on startup, and is the subject of this bug report. The 2nd is that a mysterious change (hidden side effects?) causes the system to work again, and I am filing a separate bug (with the same steps & results) to cover that issue. My system is a ThinkPad T30 running FC3, pretty much up-to-date. It has a radeon 7500 and the displays are the internal 1400x1050 and an external VGA dell 2000fp (1600x1200). This system worked properly in single and dual-head configurations when I was running FC2. Version-Release number of selected component (if applicable): system-config-display-1.0.24-1 xorg-x11-6.8.1-12.FC3.1 How reproducible: Always Steps to Reproduce: 1. config system for dual-head, xinerama. 2. reboot. System hangs during RHGB. Note - the on the first reboot, it hangs quite late in the sequence ("starting redhat network"). 3. reboot. System hangs during RHGB, but much earlier ("setting the hostname"). Subsequent reboots always hang earlier, like this. 4. Unplug the external display and reboot. System comes up properly (single page) 5. Plug the external display back in. Restart takes you back to (3). Logout-Login works, but NOTE external display is now mirroring incorrectly (it shows a subset of the total 1400x1050 screen) 6. Run system-config-display and make an inconsequential change (e.g. per bug 136283, s-c-d shows 1400x1050 as the 2nd monitor's resolution. I change it back to 1600x1200). Click OK. 7. Take a look at /etc/X11/ and note - (a) xorg.conf has a new mod time (it's been touched) but "diff xorg.conf xorg.conf.backup" indicates that no actual change was made. 8. Logout - Login. DUAL HEAD NOW WORKS. 9. Restart. We're back to (2) failing on restart. Actual Results: As noted in steps 2 & 3 & 9, the system crashes on dual-head startup. As noted in step 8, it is possible (with a few extra steps) to get it to enter dual-head mode properly. Expected Results: 1. Shouldn't ever crash on startup. 2. Restart vs Logout/Login are supposed to do the same thing, right? But they have different effects. Additional info: