Bug 430436 - radeon frame interrupt mistakenly enabled after hibernate
radeon frame interrupt mistakenly enabled after hibernate
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
8
i686 Linux
low Severity low
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-27 21:00 EST by Nick Lamb
Modified: 2008-02-16 17:36 EST (History)
1 user (show)

See Also:
Fixed In Version: xorg-x11-drv-ati-6.7.197-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-16 17:36:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg log file before hibernation (66.46 KB, text/plain)
2008-01-29 17:17 EST, Nick Lamb
no flags Details
Xorg log file after hibernation (88.93 KB, text/plain)
2008-01-29 17:17 EST, Nick Lamb
no flags Details

  None (edit)
Description Nick Lamb 2008-01-27 21:00:27 EST
On an Thinkpad Z60 with a Radeon Mobility X600, ie M24. But presumably affects
other machines too.

This is similar to bug 254216 except that now we're fine until we hibernate, but
when the laptop comes back to life, the interrupt seems to be restored* and
remains active forever. Restarting the X server fixes the problem (until next
time), but obviously isn't very convenient.  Once this bug happens it's by far
the dominating factor in my powertop results, worse even than Beagle, and I can
at least switch Beagle off.

* Powertop shows approx 60 wakeups per second from the interrupt assigned to the
Radeon PCIe device.

If accepted, this bug should probably be added to the long list of blockers in
bug 204948
Comment 1 Matěj Cepl 2008-01-28 13:00:10 EST
I will certainly ASSIGN this to ajax, to find out, but still I believe the
details about your configuration may be relevant.

Please attach your X server config file (/etc/X11/xorg.conf) 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.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

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

Thanks in advance.
Comment 2 Nick Lamb 2008-01-29 17:17:25 EST
Created attachment 293351 [details]
Xorg log file before hibernation
Comment 3 Nick Lamb 2008-01-29 17:17:52 EST
Created attachment 293352 [details]
Xorg log file after hibernation
Comment 4 Nick Lamb 2008-01-29 17:23:34 EST
Two log files attached. I don't use a config file, I haven't ever found it
necessary. So I haven't attached one.

Firstly I started a fresh X server, and logged in. At this point Beagle is the
dominant cause of wakeups, total wakeups are less than 30 per second.

The log at that point is attached as Xorg.0.log.first

Then I hibernated the machine, by choosing Hibernate from the System -> Shutdown
dialog. I moved the machine to another room (since I needed to do this anyway)
and restarted it. I used my password to authenticate and made a second copy of
the log, attached as Xorg.0.log.second

By now wakeups per second has increased to around 90 per second, mostly from an
<interrupt> source associated with the Radeon controller, which shows around 60
wakeups per second when the system is idle.

I have also now discovered that if I switch VTs away from X then the Radeon
interrupts cease until I return to X. So the driver definitely retains the
ability to switch them on and off, and thus this is hopefully a fairly trivial bug.
Comment 5 Nick Lamb 2008-02-16 17:36:27 EST
xorg-x11-drv-ati-6.7.197-1.fc8 recently made available as a Fedora 8 update
seems to fix this problem.

I have been able to suspend to RAM and to disk, in each case verifying with
powertop that the interrupt remains disabled when I restore. Much appreciated,
together with other fixes in this update, and the many improvements of Fedora 8,
 my Z60m is more productive than ever before.

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