Bug 430436

Summary: radeon frame interrupt mistakenly enabled after hibernate
Product: [Fedora] Fedora Reporter: Nick Lamb <redhat>
Component: xorg-x11-drv-atiAssignee: Dave Airlie <airlied>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: mcepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
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 22:36:27 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:
Attachments:
Description Flags
Xorg log file before hibernation
none
Xorg log file after hibernation none

Description Nick Lamb 2008-01-28 02:00:27 UTC
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 18:00:10 UTC
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 22:17:25 UTC
Created attachment 293351 [details]
Xorg log file before hibernation

Comment 3 Nick Lamb 2008-01-29 22:17:52 UTC
Created attachment 293352 [details]
Xorg log file after hibernation

Comment 4 Nick Lamb 2008-01-29 22:23:34 UTC
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 22:36:27 UTC
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.