Mailing List Archive

radeon questions
Dear silent alpha list,

I got X to work with my GeForce card and the nv driver. It was
functional, but underwhelming. So, I got a PCI Radeon card via eBay.
Specifically, it's a Visiontek 9250. The lspci output calls it an RV280
9200 PRO. So far, I can't get X to work.
Like nouveau for my nVidia card, the kernel DRM radeon module won't
load. Running modprobe radeon fails and says "Exec format error." The
dmesg output says something about "Relocation (type 4) overflow vs
radeon_resume_kms."
Question 1: Does the kernel module work with any alpha, or is it just mine?

Even worse, the xorg driver doesn't seem to work for me. The Xorg
website says the radeon driver works with the RV280/9250 chip. The
Xorg.0.log shows a long list of radeon models, but none of the 9200/9250
models say PCI. They say AGP or IGP.
I tried to copycat a google result pertaining to a ppc iMac and made a
conf file to explicitly relate the radeon driver to the device by BusID,
but that didn't help.
Question 2: Does anyone have a PCI radeon 9250 working in their alpha?

Should I give up? Any advice is welcome.

Oh, I don't expect my video performance to be very good in a 500MHz
machine with a PCI card. I was hoping there would be an advantage with
drivers for ATI/AMD vs hostile nVidia.

Thanks, DW
Re: radeon questions [ In reply to ]
On Sun, Nov 30, 2014 at 2:20 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
> Dear silent alpha list,
>
> I got X to work with my GeForce card and the nv driver. It was functional,
> but underwhelming. So, I got a PCI Radeon card via eBay.
> Specifically, it's a Visiontek 9250. The lspci output calls it an RV280
> 9200 PRO. So far, I can't get X to work.
> Like nouveau for my nVidia card, the kernel DRM radeon module won't load.
> Running modprobe radeon fails and says "Exec format error." The dmesg
> output says something about "Relocation (type 4) overflow vs
> radeon_resume_kms."
> Question 1: Does the kernel module work with any alpha, or is it just mine?

It should work. My complete guess is that the module is too large.
Maybe try building it into your kernel? I suspect that might make the
problem more obvious.

> Even worse, the xorg driver doesn't seem to work for me. The Xorg website
> says the radeon driver works with the RV280/9250 chip. The Xorg.0.log shows
> a long list of radeon models, but none of the 9200/9250 models say PCI.
> They say AGP or IGP.

I don't expect the 2D driver will work without the kernel module.
Focus on the kernel module first.

> I tried to copycat a google result pertaining to a ppc iMac and made a conf
> file to explicitly relate the radeon driver to the device by BusID, but that
> didn't help.
> Question 2: Does anyone have a PCI radeon 9250 working in their alpha?

I've had a Radeon 9100 working in an alpha, as well as others. A 9250
should work.
Re: radeon questions [ In reply to ]
Matt Turner <mattst88@gentoo.org> writes:

> On Sun, Nov 30, 2014 at 2:20 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
>> Dear silent alpha list,
>>
>> I got X to work with my GeForce card and the nv driver. It was functional,
>> but underwhelming. So, I got a PCI Radeon card via eBay.
>> Specifically, it's a Visiontek 9250. The lspci output calls it an RV280
>> 9200 PRO. So far, I can't get X to work.
>> Like nouveau for my nVidia card, the kernel DRM radeon module won't load.
>> Running modprobe radeon fails and says "Exec format error." The dmesg
>> output says something about "Relocation (type 4) overflow vs
>> radeon_resume_kms."
>> Question 1: Does the kernel module work with any alpha, or is it just mine?
>
> It should work. My complete guess is that the module is too large.
> Maybe try building it into your kernel? I suspect that might make the
> problem more obvious.

Relocation type 4 is R_ALPHA_LITERAL aka "GP relative 16 bit w/optimization"
so it can easily overflow if things get large. Building it into the kernel
should either work or fail to link at all, hopefully with a more elaborate
error message.

Also, which kernel version are you using? Prior to 3.9, the kernel used
the -msmall-data option, which made it especially prone to this kind of
overflow.

--
Måns Rullgård
mans@mansr.com
Re: Re: radeon questions [ In reply to ]
>which kernel version are you using?

It is 3.17.4 from the gentoo-sources. It was 3.14.14, which is still
the newest marked "stable" for alpha.

>I don't expect the 2D driver will work without the kernel module.
Focus on the kernel module first.

I thought the xorg radeon driver would be independent of the kernel
module. I will go back and make a new kernel today. Thanks.
Re: radeon questions [ In reply to ]
>Maybe try building it into your kernel? I suspect that might make the
problem more obvious.

The first attempt failed to build. So, I changed a few other things
from built-in to modules. The second one built successfully.
Indeed, X started and the window manager looked OK. I started xterm and
dragged it around. Just after the kernel, I had emerged mesa-progs.
So, I tried glxgears and CRASH. Blank screen. No response. So, I
logged in on a serial connection and tried my best to shut down
gracefully. I tried X a few more times and tried other programs, but
the results have been the same or worse.
I am encouraged that X might work. There are still problems. I'll keep
trying.
Re: Re: radeon questions [ In reply to ]
On Tue, Dec 9, 2014 at 1:56 PM, Don Wilburn <bodhisattva@gt.rr.com> wrote:
>>which kernel version are you using?
>
> It is 3.17.4 from the gentoo-sources. It was 3.14.14, which is still the
> newest marked "stable" for alpha.
>
>>I don't expect the 2D driver will work without the kernel module.
> Focus on the kernel module first.
>
> I thought the xorg radeon driver would be independent of the kernel module.
> I will go back and make a new kernel today. Thanks.
>

The radeon ddx relies on the KMS kernel driver. The old UMS code in
the ddx was dropped a while ago.

Alex
Re: radeon questions [ In reply to ]
Thanks for your replies. Building the radeon driver into the kernel
seems to work, but trying to make it a module does not (for me anyway).
It makes me wonder if nouveau could work in a similar fashion.

My X crashes were hardware problems. The early DEC Personal Workstation
has a DMA problem with its 64-bit PCI slots. Some well-behaved cards
work fine, apparently. This Visiontek card doesn't make that list.
This is the first time I've had objective proof. Switching to a 32-bit
PCI slot fixed my crashes.
Once I found out those 64-bit slots were ordinary PCI. there was no
reason to put the vido card there anyway. If they were PCI-X (not
express), I could have gotten a 66MHz bus at least, but mine are fixed
at 33. Boo hoo.

My PNY GeForce 5200 did not cause problems in the bad slot. Maybe the
nv driver is too timid to cause a similar problem. Maybe the hardware
is less troublesome. The question is moot.

I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and
24-bit color. My first successful start of glxgears yielded about
60fps. I'm happy just to see those gears turn at all.

Now I need to figure out something better for my fb.modes file. The
framebuffer console text is tiny at 1280x1024.

Adios, DW
Re: radeon questions [ In reply to ]
Don Wilburn <bodhisattva@gt.rr.com> writes:

> Thanks for your replies. Building the radeon driver into the kernel
> seems to work, but trying to make it a module does not (for me
> anyway).
> It makes me wonder if nouveau could work in a similar fashion.

Try and find out. :)

> My X crashes were hardware problems. The early DEC Personal
> Workstation has a DMA problem with its 64-bit PCI slots.

Yes, the older ones have a problem where a bus-master DMA transfer
crosses a page boundary may get corrupted. The more recent SRM versions
include a whitelist of known-good devices, and will refuse to boot if an
unknown card is found in an affected slot (though there is an override).
The slots behind the PCI-PCI bridge have DMA transactions split on page
boundaries anyway, so those are not affected.

> Some well-behaved cards work fine, apparently. This Visiontek card
> doesn't make that list. This is the first time I've had objective
> proof. Switching to a 32-bit PCI slot fixed my crashes. Once I found
> out those 64-bit slots were ordinary PCI. there was no reason to put
> the vido card there anyway. If they were PCI-X (not express), I could
> have gotten a 66MHz bus at least, but mine are fixed at 33. Boo hoo.
>
> My PNY GeForce 5200 did not cause problems in the bad slot. Maybe the
> nv driver is too timid to cause a similar problem. Maybe the hardware
> is less troublesome. The question is moot.
>
> I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and
> 24-bit color. My first successful start of glxgears yielded about
> 60fps. I'm happy just to see those gears turn at all.

60fps could simply be the vertical refresh rate.

--
Måns Rullgård
mans@mansr.com
Re: Re: radeon questions [ In reply to ]
On Sat, Dec 13, 2014 at 2:22 PM, Måns Rullgård <mans@mansr.com> wrote:
> Don Wilburn <bodhisattva@gt.rr.com> writes:
>> I let X default to my 17" non-widescreen LCD monitor's 1280x1024 and
>> 24-bit color. My first successful start of glxgears yielded about
>> 60fps. I'm happy just to see those gears turn at all.
>
> 60fps could simply be the vertical refresh rate.

Yes, it certainly is. vblank_mode=0 will disable it.
Re: Re: radeon questions [ In reply to ]
>Yes, it certainly is. vblank_mode=0 will disable it.
That changed it from 60 to 299, with no other changes.

Since Matt Turner has been reading:
I am probably going to file a bug on mesa-10.3.1. It has stopped me
from building firefox or seamonkey. Changing VIDEO_CARDS didn't help me
this time. Mesa-10.0.4 is the last one marked stable for alpha and it
works here. I tried a newer mesa than 10.3.1, but it failed too.
I will attach the last 10.3.1 emerge info to the bug report.
Is there any other info I can provide that will help?

>the older ones have a problem where a bus-master DMA transfer

I read in the FreeBSD documentation that some MX-5 models had a hardware
workaround from the factory. Since the problem hadn't revealed itself
with my other cards, I was hoping that might apply. Now I know for sure
that mine is a bad one.

>The more recent SRM versions include a whitelist of known-good
devices, and will refuse to boot

The AphaBIOS side tells you about "illegal" cards too. It doesn't even
like the DEC SCSI card. The original Matrox card is the only one I have
that passes.

>Try and find out.
Of the 3 ~identical alphas I saved from the garbage truck, this is the
best one and I'm happy to find a combo that works. If I had another
free monitor, I might try another.
Actually, in the mean time, I came up with a Matrox G550. I was hoping
it might have a driver advantage too, even though the card was weaker
than contemporary ATI/nVidia offerings. The kernel driver doesn't list
G550 as a choice, but Xorg says their driver does go up to G550.
Whatever. I'll think about it some other time.

Adios, DW
Re: radeon questions [ In reply to ]
Don Wilburn <bodhisattva@gt.rr.com> writes:

>>the older ones have a problem where a bus-master DMA transfer
>
> I read in the FreeBSD documentation that some MX-5 models had a
> hardware workaround from the factory. Since the problem hadn't
> revealed itself with my other cards, I was hoping that might apply.
> Now I know for sure that mine is a bad one.

The PWS models with USB ports have the fix.

--
Måns Rullgård
mans@mansr.com