r300 on "PowerBook G4" mac: only swrast after booting and backgrounds render blue instead of black

Yeah, it's definitely loading the swrast dri driver... and I can't figure out a way trick it into using r300...

0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
 Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 255 (2000ns min), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 48
 Region 0: Memory at b8000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at 0400 [size=256]
 Region 2: Memory at b0000000 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at f1000000 [size=128K]
 Capabilities: [58] AGP version 2.0
  Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
  Command: RQ=8 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: radeonfb

I tried updating to mesa and drm trunk to no avail...

I just noticed this in /var/log/Xorg.0.log:

(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0

... ?

Please try to boot the live CD and see if that works so we can see if this is a config issue on your box. I've got a Radeon 9600 with RV350 chipset here and it works with direct rendering using jaunty versions.

Yes, it happens with the livecd.

Also of possible interest, I need to use video=ofonly to get the livecd to work for me. I don't need that with the installed kernel for some reason (I removed it from yaboot.conf and reran ybin).

Let's wait and see if upstream replies to your xorg-devel thread:
http://lists.x.org/archives/xorg-devel/2009-May/000811.html

Meanwhile, for completeness can you run "apport-collect 370200" after booting from the live CD? That way we'll get a complete snapshot of logs etc automatically attached to the bug. Thanks.

I've never used mac so I'm not very familar with yaboot. In case any other triager wonders what ofonly is, read this:
http://<email address hidden>/msg28420.html

Also, Jeremy, can you try to use this boot option instead of "ofonly":
http://<email address hidden>/msg28431.html

Architecture: powerpc
DistroRelease: Ubuntu 9.04
Package: mesa
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.28-6-powerpc (buildd@adare) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #20-Ubuntu Fri Apr 17 08:30:40 UTC 2009
Uname: Linux 2.6.28-6-powerpc ppc
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

imsttfb is the wrong fb for my system.

I can use ofonly and the splash screen (but the splash looks corrupted) or radeonfb (which is default) using live-nosplash.... but splash with radeonfb just leaves my screen white and unusable.

I'm seeing this problem with the exact same builds of libdrm, mesa (libGL and dri), ati x11 drivers, and Xorg server as I had on Fedora. I think this might be kernel related.

When I run apport-collect on the livecd, I get the following:
Please install the pachage "python-launchpadlib"

The apport-collect info is from my installed system. I can revert to ubunto-provided versions of libdrm, mesa, Xorg, and ati x11 driver if you want that data as well, but there is no change.

Also, this is not a G5 mac; this is a PowerBook G4.

Ok, this is certainly a kernel issue. After changing over to Fedora's 2.6.29.1-111 kernel, the issue has gone away.

Here are related kernel log entries when the problem was occurring with the ubuntu kernel:
[ 30.413499] radeonfb 0000:00:10.0: Invalid ROM contents
[ 30.593004] [drm] Initialized radeon 1.29.0 20080528 on minor 0
[ 31.163190] radeonfb 0000:00:10.0: putting AGP V2 device into 4x mode
[ 31.461184] [drm:radeon_do_init_cp] *ERROR* could not find ioremap agp regions!

Architecture: powerpc
DistroRelease: Ubuntu 9.04
Package: mesa
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.29.1-111.fc11.ppc (<email address hidden>) (gcc version 4.4.0 20090423 (Red Hat 4.4.0-1) (GCC) ) #1 Fri Apr 24 10:44:43 EDT 2009
Uname: Linux 2.6.29.1-111.fc11.ppc ppc
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Okay, so if it was fixed in Fedora's 2.6.29.1-111 kernel, then what is the highest Fedora kernel version where you're certain you did have the problem? This might give us a range of changes to search.

This second round of apport-collect is with Ubuntu mesa/libdrm/Xorg/ati x11 drivers and the fc11 kernel. The only non-ubuntu bits are the Fedora kernel.

I'm going to try the karmic kernel, but it looks like it's going to be a pain, since it's not building on ppc right now due to missing debian/rules.d/powerpc.mk ... so I guess I'll have to build it myself the old fashioned way.

https://launchpad.net/ubuntu/+source/linux/2.6.30-2.3/+build/982613

I have not ever had this problem in a fedora kernel, but I don't have many sample points. I have only used:

2.6.27.xx from fc10 (all versions used in fc10 have been good)
2.6.29.1-46 from fc11
2.6.29.1-111 from fc11

Note that versions between 2.6.29.1-46 and -111 had other issues preventing r300 from working, but the versions listed above have all worked.

I think Fedora pulls in Dave Arlie's drm-2.6 tree. I'm doing some test builds using karmic trunk and arlied's rawhide using Fedora's .config and Ubuntu's .config... Hopefully these 4 data points will give me a good place to start a binary search for the issue... right now, I'm just wondering if it's a .config related conflict or something in the driver itself...

I'll let you know when I have more data.

Using current master from the karmic kernel (c14be1e8e5d32db04cdf02a51b2a5e47c292a5c0) and a config based on the jaunty ppc kernel, I am no loner experiencing this issue...

so the issue is either solved in mainline or a patch has been added to ubuntu kernel to address the problem.

I'm guessing this is just fallout due to all the changes to drm for kms. I really don't want to sift through all those changes to get 2.6.28 working. IMO, 2.6.28 was a transition kernel for drm... I'll test 2.6.29 for you if you want, but I'm satisfied just using 2.6.30-rc4 and rolling my own kernel off karmic.

Feel free to close this issue if you feel it appropriate.

Thanks

2.6.29.2 vanilla does not have this issue either.

2.6.28.9 vanilla also has working drm and agp. The last commit in linux-2.6.28.y that should affect this code was on 12/23:

commit 8960223d5973b3eaf8cbc1984969bb6c7661e7b9
Merge: d519c8d... 077ebed...
Author: Linus Torvalds <email address hidden>
Date: Tue Dec 23 17:01:40 2008 -0800

    Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ai

    * 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2
      drm/radeon: fix correctness of irq_enabled check for radeon.

So it looks like this problem is coming from a patch in the jaunty kernel...

It looks like the same conclusion was come to, also back in May, in bug #345542 ... is this a dupe?

Definitely a kernel regression, at least for the PPC port. Rather severe, too, it seems.

Has anyone a patch to submit? We could all, at least, begin testing it. I, for one, would be game.

BTW, shouldn't this be moved from mesa to linux-ports, filed against the PPC kernel? I would do that but I don't know how, in launchpad (never thought I would miss bugzilla...)

Yes, those the two are likely dupes.

Although there is still a mesa bug here in that swrast is rendering blue backgrounds.

Ok, I see. I was mistaken, and thought they had the same single cause.

That one is especially annoying, especially in the GL screensavers. I would bet there are dupes being filed there against the screensaver...

The blue-backgrounds doesn't seem to be ppc dependent (nor ubuntu dependent for that matter). I just saw the exact issue when debugging mesa swrast on an linux/intel client and a darwin/ppc x11 server.

This issue is still occuring with the latest ubuntu kernel:
Linux aerith 2.6.32-19-powerpc #28-Ubuntu Thu Apr 1 14:38:11 UTC 2010 ppc GNU/Linux

root@aerith:~# dmesg | grep radeon
[ 0.084204] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[ 0.471816] radeonfb 0000:00:10.0: Invalid ROM contents
[ 0.471859] radeonfb (0000:00:10.0): Invalid ROM signature 303 should be 0xaa55
[ 0.471869] radeonfb: Retrieved PLL infos from Open Firmware
[ 0.471883] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz
[ 0.471901] radeonfb: PLL min 12000 max 35000
[ 1.228456] radeonfb: Monitor 1 type LCD found
[ 1.228467] radeonfb: EDID probed
[ 1.228476] radeonfb: Monitor 2 type no found
[ 1.228496] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
[ 1.228582] radeonfb: Dynamic Clock Power Management enabled
[ 1.282176] radeonfb: Backlight initialized (radeonbl0)
[ 1.282349] radeonfb (0000:00:10.0): ATI Radeon 4e50 "NP"
[ 39.761396] radeonfb 0000:00:10.0: Invalid ROM contents
[ 39.761521] radeonfb 0000:00:10.0: Invalid ROM contents
[ 40.068426] [drm] radeon kernel modesetting enabled.

root@aerith:~# ls /dev/dri*
ls: cannot access /dev/dri*: No such file or directory
root@aerith:~# grep DRI /var/log/Xorg.0.log
(II) Loading extension XFree86-DRI
(II) Loading extension DRI2
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) GLX: Initialized DRISWRAST GL provider for screen 0

https://bugs.freedesktop.org/show_bug.cgi?id=27502

In 2.6.32, this can be addressed by editing /etc/modprobe.d/radeon-kms.conf and setting modeset=0 instead of modeset=1

Or even better, you can stop building radeonfb into the kernel, so the KMS radeon driver will provide the FB and HW rendering

Jeremy Huddleston, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Please let us know your results. Thank you for your understanding.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

The primary issue relating just to ppc was fixed in kernel 2.6.29.y, so any recent Ubuntu will not be hitting that issue.

The secondary issue of rendering blue backgrounds is not ppc-specific (per my comment #44). This issue is worked around by turning off KMS (setting modeset=0 in /etc/modprobe.d/radeon-kms.conf) or removing radeonfb from the kernel (comments #46 and #47).

Based on https://bugs.freedesktop.org/show_bug.cgi?id=27502, I believe this is no longer an issue with recent kernel and driver versions.