Power Mac G5 & Radeon X1900 - driver problem
commodorejohn
working with a Radeon X1900 Mac edition video card (PCI-Express) on my
Power Mac G5 Quad. The installer acted a bit weird right from the
start, telling me that the step "Install the system" failed (with
nothing in the way of useful error information,) but I got the base
system installed at least. It booted fine to framebuffer console, so I
set about installing GNOME on it. apt finished with nary a complaint,
but when I rebooted, I found that when it was ready to launch into X,
it choked up and just sat there with a blank screen and a cursor.
(Weirdly, though, the screen itself flickered on and off at a high
rate, faster than the actual cursor blink.)
Framebuffer console still worked, at least, so I was able to boot into
single-user mode and do some investigating in my own limited capacity
for this stuff (by which I mean "Google error messages and see what
specifics are requested.") lspci -k showed the video card properly
with the manufacturer and product name, so it was recognizing it, at
least. When I tried Xorg -configure, though (Xorg 1.7.7, it says,) it
aborted with a "No DRICreatePCIBusID symbol" message. Checking dmesg
gave me a "process Xorg mapped non-existing PCI legacy memory"
message, followed by an "invalid ROM contents" message underneath.
For the time being, I put the GeForce 6600 it came with back in and
got things up and running. However, when I updated to Sid (unstable)
to get Lightspark working, I thought I'd give it another try and see
what happened. The flickering-cursor screen now does not happen, it
recognizes the card fully and attempts to load the radeon driver -
however, it's apparently conflicting with something or other:
conflicting fb usage radeondrmfb vs OFfb ATY,Priona - removing generic
driver
This causes the system to hang completely, such that it can't even
boot into single-user mode...any changes made to fix it will need to
be done with the GeForce in its place.
I'm not sure what all to make of this. I've found a thread about
problems getting the same basic setup (G5 Quad, X1900, Debian) to
work, but it's a couple years old and the symptoms are different.
There's some discussion there about the radeon/radeonhd driver looking
for Atom BIOS information on non-Atom BIOS cards, which would explain
the "invalid ROM contents" message when running Squeeze, but on the
other hand, that seems to be fixed in Sid. Obviously it's playing
nicely enough to run framebuffer console output properly, but beyond
that I'm not so sure. Does that "conflicting fb usage" message
indicate some kind of driver conflict? If so, is there a way I can
disable whatever's conflicting with it and leave only the radeon
driver in place?
Stephen Harker
> I was attempting to get Debian (Squeeze, latest net-install CD)
> working with a Radeon X1900 Mac edition video card (PCI-Express) on my
> Power Mac G5 Quad. The installer acted a bit weird right from the
> start, telling me that the step "Install the system" failed (with
> nothing in the way of useful error information,) but I got the base
> system installed at least. It booted fine to framebuffer console, so I
> set about installing GNOME on it. apt finished with nary a complaint,
> but when I rebooted, I found that when it was ready to launch into X,
> it choked up and just sat there with a blank screen and a cursor.
> (Weirdly, though, the screen itself flickered on and off at a high
> rate, faster than the actual cursor blink.)
>
> Framebuffer console still worked, at least, so I was able to boot into
> single-user mode and do some investigating in my own limited capacity
> for this stuff (by which I mean "Google error messages and see what
> specifics are requested.") lspci -k showed the video card properly
> with the manufacturer and product name, so it was recognizing it, at
> least. When I tried Xorg -configure, though (Xorg 1.7.7, it says,) it
> aborted with a "No DRICreatePCIBusID symbol" message. Checking dmesg
> gave me a "process Xorg mapped non-existing PCI legacy memory"
> message, followed by an "invalid ROM contents" message underneath.
The last thing I saw on getting this to work was the Kernel bug report:
<https://bugzilla.kernel.org/show_bug.cgi?id=13971>
Unfortunately, nothing seems to have happened. I sounds like you got
further than I did. Later kernels and Xorgs must have made some
difference. I gave up on my X1900 and put a 7800GTX 512MB in
instead. It works, but does not have true accelerated 3D Xorg:
squeeze gives software acceleration using nouveau.
> This causes the system to hang completely, such that it can't even
> boot into single-user mode...any changes made to fix it will need to
> be done with the GeForce in its place.
I understand that a similar configuration was used by Ben
Herrenschmidt to test the X1900 while having a 6600 in the 16 lane
slot. It enables some testing.
> I'm not sure what all to make of this. I've found a thread about
> problems getting the same basic setup (G5 Quad, X1900, Debian) to
> work, but it's a couple years old and the symptoms are different.
> There's some discussion there about the radeon/radeonhd driver looking
> for Atom BIOS information on non-Atom BIOS cards, which would explain
> the "invalid ROM contents" message when running Squeeze, but on the
> other hand, that seems to be fixed in Sid. Obviously it's playing
> nicely enough to run framebuffer console output properly, but beyond
> that I'm not so sure. Does that "conflicting fb usage" message
> indicate some kind of driver conflict? If so, is there a way I can
> disable whatever's conflicting with it and leave only the radeon
> driver in place?
You get a similar complaint about "invalid ROM contents" on an iBook
G4 1.33MHz, but X11 and accelerated Xorg works. It seems to be
something to do with the X1900 and X11, but apart from the discussion
I mention earlier I have seen nothing further.
--
Stephen Harker s.ha...@adfa.edu.au
PEMS http://sjharker.customer.netspace.net.au/
UNSW@ADFA
commodorejohn
> The last thing I saw on getting this to work was the Kernel bug report:
> <https://bugzilla.kernel.org/show_bug.cgi?id=13971>
> Unfortunately, nothing seems to have happened. I sounds like you got
> further than I did. Later kernels and Xorgs must have made some
> difference. I gave up on my X1900 and put a 7800GTX 512MB in
> instead. It works, but does not have true accelerated 3D Xorg:
> squeeze gives software acceleration using nouveau.
this working so that I have 3D acceleration (OpenArena is, shall we
say, a bit completely unplayable in software,) rather than having to
wait for nouveau to catch up on older cards. (I'd rant about the
infuriating apathy towards older hardware and architectures that
aren't x86 or ARM in the Linux world, but that's a thread for another
time.)
> You get a similar complaint about "invalid ROM contents" on an iBook
> G4 1.33MHz, but X11 and accelerated Xorg works. It seems to be
> something to do with the X1900 and X11, but apart from the discussion
> I mention earlier I have seen nothing further.
Yeah, only the "invalid ROM contents" message is gone now - I guess
they must have changed things to recognize cards properly on PPC, so
I'm left with some kind of apparent driver conflict between radeon and
"OFfb ATY,Priona" (is "OFfb" OpenFirmware framebuffer, a generic
driver, maybe?) which I'm not sure how to resolve.
Stephen Harker
> On Sep 3, 2:32 am, Stephen Harker <sjhar...@netspace.net.au> wrote:
>> The last thing I saw on getting this to work was the Kernel bug report:
>> <https://bugzilla.kernel.org/show_bug.cgi?id=13971>
> (I'd rant about the
> infuriating apathy towards older hardware and architectures that
> aren't x86 or ARM in the Linux world, but that's a thread for another
> time.)
I would tune in. Yes, there is a significant problem for ppc users
and some of the other architectures. In addition there seems to be a
real problem with pcie cards: few have openfirmware rom options so you
are stuck with old cards. I did see a suggestion that you should be
able to stick a x86 card into a G5 pcie machine and use it in linux,
you would not have a boot display. This was untested and I don't know
if anyone has tried it.
>> You get a similar complaint about "invalid ROM contents" on an iBook
>> G4 1.33MHz, but X11 and accelerated Xorg works. It seems to be
>> something to do with the X1900 and X11, but apart from the discussion
>> I mention earlier I have seen nothing further.
> Yeah, only the "invalid ROM contents" message is gone now - I guess
> they must have changed things to recognize cards properly on PPC, so
> I'm left with some kind of apparent driver conflict between radeon and
> "OFfb ATY,Priona" (is "OFfb" OpenFirmware framebuffer, a generic
> driver, maybe?) which I'm not sure how to resolve.
As I understand it, yes "OFfb" is OpenFirmware framebuffer and was
often used as a (slow) driver for not fully supported firmware. In a
non-ppc world the general advice appears to be that there is a
potential conflict between the framebuffer device and the radeon
device under KMS (Kernel mode setting) kernels and the radeon driver
now uses KMS. A quick search on google shows <http://forums.gentoo.org/
viewtopic-t-871343.html?sid=aa6c5fa19b1f41e66c5eac960d3eafb8> which
says (in part)
==================================================================
As far as I know, PowerPC still requires a framebuffer device,
otherwise there is no boot console. As of the last time I tried KMS,
it was a pretty terrible experience on my PB G4 with an R300. Sleep
and screen brightness do not work and it will lock up unless the AGP
speed is fixed to 1x. To do this, add this to your yaboot
configuration: "append=radeon.agpmode=1"
It is still recommended to stick with UMS for now (See BenH's post
here:
http://www.mail-archive.com/debian-...@lists.debian.org/msg62503.html)
but that won't allow DRM either due to an OpenGL bug in the old driver
(see here: https://bugs.freedesktop.org/show_bug.cgi?id=26496).
Not much choice now, but it is slowly being worked on. Sorry!
==================================================================
That post is dated around April 2011. You could try searching under
"radeon kms ppc" and see if there are any later solutions
commodorejohn
> I would tune in. Yes, there is a significant problem for ppc users
> and some of the other architectures. In addition there seems to be a
> real problem with pcie cards: few have openfirmware rom options so you
> are stuck with old cards.
like "Linux! It makes sweet wizardly love to your old hardware!" Well
no, it bloody well doesn't, not when my older hardware is ever so
slightly out of the mainstream!
> In a
> non-ppc world the general advice appears to be that there is a
> potential conflict between the framebuffer device and the radeon
> device under KMS (Kernel mode setting) kernels and the radeon driver
> now uses KMS.
> otherwise there is no boot console.
setting yaboot to auto-boot Linux anyway as I don't have OSX
installed, but of course I want to be sure I've got it working before
I go doing that, and I might have to do that in order to get it
working...gah, catch-22.
> That post is dated around April 2011. You could try searching under
> "radeon kms ppc" and see if there are any later solutions
which has a xorg.conf file for Radeon 9600, I might be able to tweak
that to work, but will it disable KMS and use the xorg.conf file just
by dropping it in the search path?
commodorejohn
adding the line:
append="radeon.modeset=0"
to the appropriate image in yaboot.conf. This takes care of the total
hang, such that I can now boot into single-user mode without problems,
but leaves me in need of a xorg.conf file in order to start X. Xorg -
configure does create a semi-filled-in template that at least has the
card's PCI bus ID and driver name, but it errors out because "number
of created screens does not match number of detected devices" and
leaves the rest blank. Can someone explain to me how to deal with
this, or point me to a resource on rolling one's own xorg.conf?
rado...@gmail.com
commodorejohn
> 8 years later, I don't think anyone has solved this issue? I currently run a x1900 and 6600 in my G5 and was hoping to get the xorg situation solved. This was the most information I've come across since the bug reports in the linux emails.