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."
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 '*'
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.
*** Bug 14446 has been marked as a duplicate of this bug. ***
Created attachment 15292 [details]
Radeontool output using ofonly framebuffer
Created attachment 15293 [details]
Radeontool output using radeonfb framebuffer
(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 :-)
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.
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.