This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 487919 - Intel graphics w/compositing enabled not correctly resuming from suspend
Intel graphics w/compositing enabled not correctly resuming from suspend
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-01 08:28 EST by Michael Monreal
Modified: 2009-04-17 13:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-17 13:00:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X11 logs (29.06 KB, application/x-gzip)
2009-03-05 06:09 EST, Michael Monreal
no flags Details
Xorg.0.log from the tarball (52.21 KB, text/plain)
2009-03-05 10:50 EST, Matěj Cepl
no flags Details

  None (edit)
Description Michael Monreal 2009-03-01 08:28:03 EST
On a system with Intel i945 graphics (default settings... KMS and UXA active) and Rawhide, resume form suspend does not work properly. Here#s what I found:

- If suspended from GNOME, a resume brings me to a tty1 console. I have no way to switch to X11. I suspect this is a KMS problem. Switching to other ttys works, the system seems to be resuming totally fine but does not seem to restore graphics correctly.

- If suspend is initiated from GDM, resume works perfectly fine (!) including X11 graphics.
Comment 1 Matěj Cepl 2009-03-05 05:28:51 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Also, do you have compiz enabled?

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Michael Monreal 2009-03-05 06:06:48 EST
(In reply to comment #1)
> Also, do you have compiz enabled?

No, but you were close. I'm uing Metacity with composite enabled (run metacity -c once to enable it). If I disable composite in metacity (metacity --no-composite), resume to X11 works flawlessly.
Comment 3 Michael Monreal 2009-03-05 06:09:15 EST
Created attachment 334119 [details]
X11 logs

Here's a full set of X11 logs. I resumed a fre times with composite off, then tried it once with composite on again and rebooted.
Comment 4 Matěj Cepl 2009-03-05 10:45:13 EST
(In reply to comment #2)
> No, but you were close. I'm uing Metacity with composite enabled (run metacity
> -c once to enable it). If I disable composite in metacity (metacity
> --no-composite), resume to X11 works flawlessly.

Please, don't do it --- compositing in metacity is severely broken and unmaintained.
Comment 5 Matěj Cepl 2009-03-05 10:50:04 EST
Created attachment 334141 [details]
Xorg.0.log from the tarball
Comment 6 Michael Monreal 2009-03-05 11:20:35 EST
(In reply to comment #4)
> Please, don't do it --- compositing in metacity is severely broken and
> unmaintained.

Interesting... I asked the maintainer on IRC and he classified it as "meant to be used". If you know any specific bugs, they would be glad to know.
Comment 7 Ray Strode [halfline] 2009-03-10 15:21:13 EDT
I think Matej was remembering the old metacity compositor Soeren did (before a different one got added upstream by Ian).  It's not something we work on downstream, though.

Normally X runs on tty1.  Are you saying you're on tty1 but only see text on the screen? What text do you see?
Comment 8 Jarod Wilson 2009-03-10 15:32:05 EDT
I'm seeing this too on a freshly upgraded ThinkPad T61 w/x3100 graphics using compiz.
Comment 9 Michael Monreal 2009-03-10 15:38:09 EDT
(In reply to comment #7)
> Normally X runs on tty1.
Right

> Are you saying you're on tty1 but only see text on
> the screen? What text do you see?  
Yes... from the top of my head, it has something about Wifi connectivity... about 10 lines. I can test again thursday and provide detailed information.
Comment 10 Michael Monreal 2009-03-13 04:26:28 EDT
Just tried with the latest 2.7 driver from koji, still the same.

Here's what I see after resume (on a black tty):

---
tg3 0000:06:00.0: PME# disabled
tg3 0000:06:00.0: irq 30 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
iwl3945 000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwl3945 000:04:00.0: irq 31 for MSI/MSI-X
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
---

I can switch to tty2 and log in just fine there. If I kill the Xorg process from there, GDM starts just fine. After login, WLAN (and everything else it seems) works.
Comment 11 Michael Monreal 2009-03-13 04:28:09 EDT
In fact, the lines above are the last 10 lines from dmesg.
Comment 12 Jarod Wilson 2009-03-13 08:58:13 EDT
This appears to be a combination of issues... One, pm-utils is forcing a vt switch to vt63 when we're trying to go to sleep. Its done this for a while now, as it used to be necessary to get away from X's vt to properly suspend. For some reason, this is causing X to freak out a bit and restart just before the suspend actually happens. Only it does so on vt63. So on resume, if you login to vt2 and then 'chvt 63', you should see a GDM login screen. Ray has a fix for an issue in GDM that is causing it to respawn over there, should at least bring it back to vt1. As for X... Now that we have functional kernel mode setting again for Intel graphics, that initial vt switch over to 63 when suspending isn't actually needed. So by simply disabling /usr/lib64/pm-utils/sleep.d/90chvt on my T61, I eliminate that vt switch, and now my system happily suspends and resumes with compiz running w/o an error. We're going to get something into pm-utils to make this happen automatically for intel+kms RSN.
Comment 13 Michael Monreal 2009-03-13 09:52:46 EDT
(In reply to comment #12)
> So on resume, if you login
> to vt2 and then 'chvt 63', you should see a GDM login screen. 

I have only tested this far, but I guess you found the issue. Looking forward to the complete fix. Thanks!
Comment 14 Hezekiah M. Carty 2009-04-05 15:40:22 EDT
Removing /usr/lib64/pm-utils/sleep.d/90chvt allows me to suspend and resume without X dying under normal circumstances.  However, if I plug in an external display (this is on a Thinkpad R61, with Intel GM965 video) while the system is suspended and then resume, X restarts and I am put back at the GDM login screen.

If this is not related, I will open a new bug report instead.
Comment 15 Adam Williamson 2009-04-16 18:53:10 EDT
The chvt issue should be fixed as of pm-utils-1.2.5-1.fc11:

- If running on a system that is using KMS, we will refuse to handle any video
  quirks passed to us by HAL, and we will not chvt to an empty console.

so can we close this report now, or are there still issues in the original bug left to address? I think Hezekiah's bug is something different.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 Michael Monreal 2009-04-17 04:52:25 EDT
I just tested on an up-to-date RawHide:

Suspending from GNOME _SOMETIMES_ works fine:

A) if it works, resuming does NOT bring back the desktop session but shows a GDM login. I went to a tty and checked if anything of the old session survived, but this does not seem to be the case :(

B) if it does NOT work, it will just drop back to a GDM login. BUT: pressing shutdown or reboot will trigger a suspend. On resume, the system will reboot or shutdown right away :(

I doubt this is only one bug, but either way, this very basic use case is totally broken atm...
Comment 17 Adam Williamson 2009-04-17 12:58:50 EDT
A) sounds rather like https://bugzilla.redhat.com/show_bug.cgi?id=495562 and https://bugzilla.redhat.com/show_bug.cgi?id=495497 . B) I don't think we have a report for yet, though. Can you isolate any factor which determines whether you hit A or B?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Adam Williamson 2009-04-17 13:00:48 EDT
Still, I think we can close this report for efficiency, as the initial issue has been fixed. Michael, I'm fairly sure your A issue is one of the reports mentioned in #17; please add comments to one of those bugs as appropriate (they're probably dupes of each other but I haven't confirmed that yet). B should probably get filed as a new report. Keeping things clean this way helps address the still-outstanding issues faster, I'm not trying to sweep any problems under the carpet :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 19 Michael Monreal 2009-04-17 13:25:39 EDT
(In reply to comment #17)
> Can you isolate any factor which determines whether you
> hit A or B?

I tried but it seems to be totally random :/
Comment 20 Adam Williamson 2009-04-17 13:34:05 EDT
Ah :\ hopefully then A can get fixed through the other reports, which should help in isolating B...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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