Bug 15056

Summary: [radeon] machine freezes when X is stopped or second X started
Product: xorg Reporter: Brice Goglin <brice.goglin>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bram, mike.skinner, rleigh
Version: git   
Hardware: Other   
OS: All   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463076
i915 platform: i915 features:
Description Flags
Radeontool output using ofonly framebuffer
Radeontool output using radeonfb framebuffer none

Description Brice Goglin 2008-03-16 05:25:59 UTC
Bram Senders reported this bug a couple weeks ago. He has a PowerPC Mac Mini with a Radeon 9200.

"The machine freezes when the Xserver is stopped...  Just a hard freeze when I try to logout, or shutdown the machine, or restart gdm; anything that kills the X server causes the entire machine to lock up."

There's a log availabel at

Disable DRI, switching to PCI bus type or changing AGPMode didn't help. Only reverting from 6.8.0 to 6.6.193 helped.

Agustin Martin reported a similar problem. And Roger Leigh added:
"It works perfectly if I booted the system with "video=radeonfb:1680x1050-32@60" on the command-line.  I can now switch VTs at will, as well as start and stop X, shut down the system, etc. without problems. However, booting with "video=ofonly" results in all the problems mentioned above.

It might be an issue with the OF framebuffer, or the attempt to restore
the framebuffer when X terminates or VT switches.  IME, ofonly doesn't
come back when you end X, but previously you just got a black screen
rather than a lockup."
Comment 1 Alex Deucher 2008-03-17 10:46:25 UTC
Any chance you can use radeontool (http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary) to dump the radeon registers with OF fb and radeonfb before starting starting X?

(as root) ./radeontool regmatch '*'
Comment 2 Mike Skinner 2008-03-17 23:26:49 UTC
This looks the same as my issue # 14446.

I am happy to mark mine as a duplicate of this one... this one seems to be more concise.

I will try Roger Leigh's suggestion as soon as I can.
Comment 3 Mike Skinner 2008-03-18 15:45:04 UTC
*** Bug 14446 has been marked as a duplicate of this bug. ***
Comment 4 bram 2008-03-19 03:59:58 UTC
Created attachment 15292 [details]
Radeontool output using ofonly framebuffer
Comment 5 bram 2008-03-19 04:01:08 UTC
Created attachment 15293 [details]
Radeontool output using radeonfb framebuffer
Comment 6 bram 2008-03-19 04:04:48 UTC
(In reply to comment #1)
> Any chance you can use radeontool
> (http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary) to
> dump the radeon registers with OF fb and radeonfb before starting starting X?
> (as root) ./radeontool regmatch '*'

I've added two attachments with the radeontool output in them.  There are quite some differences from using ofonly to using radeonfb, unfortunately I don't know what any of this stuff means.  I hope this is of some help anyway :-)
Comment 7 Alex Deucher 2008-03-20 09:50:22 UTC
I'm guessing it has something to do with the memory map:
-MC_FB_LOCATION (0148)  0x07ff0000
+MC_FB_LOCATION (0148)  0x7fff0000

radeonfb sets it up the same way as the x driver while OF does it differently.  When the X driver restores the OF values, that is probably what causes the hang.  Unfortunately, I'm not sure of a good fix.  You might try adjusting the delays when restoring the memmap regs, or maybe the order in which they are restored relative to the rest of the registers.
Comment 8 Adam Jackson 2018-06-12 19:09:19 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.