Bug 27524

0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
	Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
	Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 48
	Memory at b8000000 (32-bit, prefetchable) [size=128M]
	I/O ports at 0400 [size=256]
	Memory at b0000000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at b0020000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
	Capabilities: [50] Power Management version 2
	Kernel driver in use: radeon

Works for me on the same or at least very similar machine... Try disabling OFfb, I think the handover from that to KMS doesn't quite work yet.

Also, for performance you probably want to pass radeon.agpmode=1 to avoid the fallback to PCI mode - for some reason I haven't figured out yet, AGP 4x or 2x don't work reliably yet with KMS.

(In reply to comment #3)
> Additionally, when X starts, the image displayed is identical to the image that
> was in the framebuffer just before rebooting. (I see my X session with my
> terminal open and 'sudo reboot' as the last command).  After a few seconds, I
> see gdm.

I think it's trying to preserve the console contents but failing because that requires something which is only in Fedora yet. Should probably be fixed to just clear to black in that case, but that would need to be tracked in a separate report.

I set this on my command line:

append="radeon.agpmode=1 video=radeon"

Now the text doesn't garble.  My display just seems "hypercolored" ... I can't really describe it and will need to take a picture if you don't know what I mean.  Once X starts, it becomes usable.

(In reply to comment #4)
> I set this on my command line:
> 
> append="radeon.agpmode=1 video=radeon"
> 
> Now the text doesn't garble.  My display just seems "hypercolored" ... I can't
> really describe it and will need to take a picture if you don't know what I
> mean.

I don't, so please do. :) Also please attach the dmesg with those options.

Here's a link to a video I captured of the boot process using radeon.agpmode=1 video=radeon:

http://cloud.cs.berkeley.edu/~jeremy/PR-27524/STP81647.AVI

Also, once in X, I can change TTY with the ctrl-alt-f# key sequence.  Doing this leaves the display unaltered and hides the mouse pointer.  It looks as though the framebuffer is not being updated.

Created attachment 34829 [details]
dmesg video=radeon radeon.agpmode=1

I'm wondering if video=radeon is enough to punt OFfb.  I see a note at 0.9756 into boot that shows OFfb was still loaded.  It looks like I'd need to do some Kconfig magic to prevent OFfb from being built since it's forced on by PPC.  Is there something else I should try to force radeondrmfb?

ah... video=offb:off is the correct incantation.  Doing so avoids the noted corruption.

So it looks like this is just the offb to radeondrmfb handoff issue.

Right, so let's focus on the OFfb handover issue. One thing that might help track down what's going on would be comparing register dumps from the good and bad cases.

Ok, tell me what you want me to dump, when you want me to dump it, and how.

(In reply to comment #12)
> Ok, tell me what you want me to dump, when you want me to dump it, and how.

Build radeontool from git://anongit.freedesktop.org/~airlied/radeontool and run something like

sudo ./radeontool regmatch '*' >dump.txt

once while the console is garbled and once while it's displaying correctly.

This is working for me in recent kernels.

Assuming this is fixed, reopen if not.