Bug 27524 - linux-2.6.33.2 radeondrm_fb, rv350, garbled console on PowerBook G4
Summary: linux-2.6.33.2 radeondrm_fb, rv350, garbled console on PowerBook G4
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-07 15:17 UTC by Jeremy Huddleston Sequoia
Modified: 2012-02-24 02:56 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg (34.96 KB, text/plain)
2010-04-07 15:17 UTC, Jeremy Huddleston Sequoia
no flags Details
dmesg video=radeon radeon.agpmode=1 (33.14 KB, text/plain)
2010-04-08 13:50 UTC, Jeremy Huddleston Sequoia
no flags Details

Description Jeremy Huddleston Sequoia 2010-04-07 15:17:44 UTC
Created attachment 34776 [details]
dmesg

I have 2.6.33.2 with the KMS radeon driver.  radronfb is disabled, so I'm using radeondrm_fb for console.

The console is completely garbled and unreadable during boot.  Eventually, we startup X, and my machine is usable, but while in console mode, nothing can be read or seen.  It looks like text is just sliced and diced.

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.
Comment 1 Jeremy Huddleston Sequoia 2010-04-07 15:18:43 UTC
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
Comment 2 Michel Dänzer 2010-04-07 15:30:29 UTC
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.
Comment 3 Michel Dänzer 2010-04-07 15:32:21 UTC
(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.
Comment 4 Jeremy Huddleston Sequoia 2010-04-07 16:11:49 UTC
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.
Comment 5 Michel Dänzer 2010-04-08 00:51:33 UTC
(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.
Comment 6 Jeremy Huddleston Sequoia 2010-04-08 13:42:33 UTC
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
Comment 7 Jeremy Huddleston Sequoia 2010-04-08 13:44:22 UTC
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.
Comment 8 Jeremy Huddleston Sequoia 2010-04-08 13:50:23 UTC
Created attachment 34829 [details]
dmesg video=radeon radeon.agpmode=1
Comment 9 Jeremy Huddleston Sequoia 2010-04-08 13:54:07 UTC
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?
Comment 10 Jeremy Huddleston Sequoia 2010-04-08 15:06:34 UTC
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.
Comment 11 Michel Dänzer 2010-04-09 02:21:36 UTC
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.
Comment 12 Jeremy Huddleston Sequoia 2010-04-09 02:48:57 UTC
Ok, tell me what you want me to dump, when you want me to dump it, and how.
Comment 13 Michel Dänzer 2010-04-15 01:27:05 UTC
(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.
Comment 14 Michel Dänzer 2011-02-09 02:09:54 UTC
This is working for me in recent kernels.
Comment 15 Michel Dänzer 2012-02-24 02:56:13 UTC
Assuming this is fixed, reopen if not.


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.