Bug 544527

Is this perhaps because radeonhd doesn't support KMS? Can you try with radeon.modeset=0?

At kernel commandline?
Or?
I do not use KMS. Kernel was unchanged at 2.6.31.6.

radeonhd is wrong, I run the git radeonhd code.

so no KMS here.

I'm wondering if this is a Fedora bug at all, or it should be closed as upstream (meaning Fedora will pick up a fix when upstream does it); however, upstream bug is reported for radeon driver, not radeonhd.

I experience same thing with radeonhd on 4770, but radeon works more or less OK. Just curious, is there any reason why you don't use radeon?

FWIW:

I use radeonhd from git.
I run a mostly stock (not fedora) kernel.
I changed f11 into f12
I rebuilt radeonhd against the new Xorg dependencies.
So I used same kernel and same radeonhd source as before F12.

Since that time I have the screen corruption.
Just Fedora changed.
So it is a Fedora issue.

Where did I specify radeon? I use radeonhd.
drm says radeon.

Why would I use radeon when there is radeonhd?

That is my point exactly. radeonhd currently has less features and and it doesn't work as good in Fedora as radeon does. Back in the days when radeon didn't support R500 and up, it was reasonable choice; but today, I just use the one that works.

If you could retry your system with radeon, it would be great.

RadeonHD worked fine when we had Fedora 11.
The upgrade to Fedora 12 broke it.
Please fix it and please do not provide workarounds.

The driver source code was unchanged. The kernel was unchanged.

So it is Fedora.

Thanks for the solution.

OK, leaving this to the maintainer (I'm only a bugzapper), thank you for reporting.

(In reply to comment #7)
> Why would I use radeon when there is radeonhd?  

Because radeon is best integrated in Fedora.

Udo, the driver with the best support in Fedora is radeon, not radeonhd.

I am providing radeonhd packages solely for those hopefully increasingly rare corner cases where Fedora+radeon do not work for someone, not as a replacement or the going forward thing or anything like that.

(In reply to comment #9)
> RadeonHD worked fine when we had Fedora 11.
> The upgrade to Fedora 12 broke it.
> Please fix it and please do not provide workarounds.
> The driver source code was unchanged. The kernel was unchanged.

It is well possible that radeonhd is broken because it does not work with an essential Fedora feature. KMS is an example for such a feature. Possibly there are other changes which cannot be simply switched off like KMS can.

So you say you are running an F12 system with a F11 kernel?

I run a kernel.org kernel.
I run git radeonhd.

So there is no KMS being used as far as I know.

Why is KMS essential?
Why/when/how is it used and why is it an issue here?
Why, if it is, was this issue not raised during the upgrade and was a solution provided? Or at least a choice?

Now again: when I run the xorg that is in F12, is KMS mandatory?
If not: why can't I run radeonhd?
If not: why is this bug here? Why do I see the corruption?
Why am I seeing a picture at all?
KMS does not have to do any thing here as the mode is set only once.
Yet I see corruption all over the desktops all the time.

Now what is the exact cause?
Or what can I do to help you find it?
Please let me know.

Created attachment 376345 [details]
config

Where is the KMS here?

Please provide a technical explanation about where the issue is.
I might take the bug elsewhere if needed.

<MostAwesomeDude> udovdh: Sure they do.
<udovdh> please explain?
<MostAwesomeDude> The problem is that you've changed too much of your system.
<MostAwesomeDude> You're asking them to support an older kernel.
<udovdh> so far I only got workarounds or attempts in that direction
<udovdh> 2.6.31.6 old?
<MostAwesomeDude> You're also asking them to support a known broken driver.
<udovdh> the driver was OK
<udovdh> fedora changed it
<udovdh> xorg changed and now it corrupts the screen
<udovdh> so it is radeonhd that is buggy
<MostAwesomeDude> Right, the known broken driver is radeonhd.
<udovdh> of course there is no technical explanation why the messages point in that direction
<udovdh> I do not want to exclude this option
<udovdh> but since 1.0.0 radeonhd was perfect for me
<MostAwesomeDude> Well, look at it this way. He asked you to upgrade, right?
<udovdh> so please explain what goes wrong so that we get the messages I see
<udovdh> upgrade?
<MostAwesomeDude> And he let you know that radeonhd is known broken with FC12.
<udovdh> I went through the Fedora 12 thing
<udovdh> they think so
<udovdh> no explanation
<MostAwesomeDude> rhd doesn't support KMS.
<udovdh> not a mention about the info at the url I pasted
<MostAwesomeDude> F12's kernel does KMS for your chipset.
<udovdh> where does kms play a role here?
<udovdh> please help me understand
<udovdh> as I argued in the bugreport?
<udovdh> I do not run f12 kernel
<udovdh> so no kms
<MostAwesomeDude> Then don't file bugs against F12!
<udovdh> ?
<udovdh> you don;'t get it yet
<udovdh> I changed the distro
<udovdh> except the kernel
<udovdh> except radeonhd
<udovdh> so it must be the distro if I get issues
<udovdh> right?
<MostAwesomeDude> Wrong!
<udovdh> please explain where that thought problem is
<MostAwesomeDude> It's the kernel! And rhd!
<udovdh> kernel was unchanged
<udovdh> and did not do kms
<udovdh> so please do not mention kms without technical explanation
<MostAwesomeDude> You're not really in F12 if your kernel is from F11.
<udovdh> my kernel is not form f11
<udovdh> it is from kernel.org
<udovdh> as I wrote.
<MostAwesomeDude> Okay, so why can't you just use an F12 kernel and F12's radeon?
<udovdh> that issue was already dealt with in the bug.
<udovdh> the problem is with the radeonhd/fedora 12 combination
<MostAwesomeDude> Well, basically neither glisse, airlied, or I have replied on the bug, but the solution *is* to stop using radeonhd.
* MNZ (n=mnzaki.186.111) has joined #radeonhd
<udovdh> that will help the driver. yes.
<udovdh> still no technical explanation
<MostAwesomeDude> Technical explanation: Nobody cares about radeonhd in F12 and is completely happy to not do anything about bugs assigned to it.
<yangman> look, we don't always have or need technical explanations for things you shouldn't do
<MostAwesomeDude> On a completely unrelated note, can I see your dmesg?
<yangman> "not supported" is a completely valid reason
<MostAwesomeDude> I can probably find a technical explanation in there. :3
<udovdh> not supported would mean if they can pinpoint that the problem is not in their software
<udovdh> which nobody did, so far
<udovdh> I would be happy to take the bug elsewhere
<udovdh> still no technical explanation
<MostAwesomeDude> udovdh: Pastebin your dmesg.
<udovdh> http://pastebin.com/d468072da
<udovdh> (part, not all)
<MostAwesomeDude> That's useless to me.
<MostAwesomeDude> I need the whole thing.
* ech0s7 has quit ("Sto andando via")
<udovdh> there's only 128K max...
<MostAwesomeDude> I need to see what the drm modules say when they load.
<udovdh> http://pastebin.com/d2cb24a5e
<MostAwesomeDude> You're not using a Fedora kernel. I'm going to close the bug as NOTOURBUG unless you can come up with a really really good reason why this is Fedora's problem. :C
<udovdh> I said it was a kernel.org kernel.
<udovdh> I said the kernel was the same
* yangman facepalms
<udovdh> I said the distro went from1 1 to 12
<udovdh> you don't read
<udovdh> you do not get it yet
<udovdh> the kernel does no KMS as I explained
<udovdh> so the kernel is no issue here
<udovdh> the kernel worked wine with f11
<udovdh> the kernel worked fine with f11
<udovdh> the kernel does same with f12
<udovdh> just all the xorg stuff changed
<udovdh> because of f12
<udovdh> so it is NOT a fedora bug of course
<MostAwesomeDude> Then stop using Fedora's bugzilla.
<udovdh> you do not get the irony?

Let's make things clear: radeonhd is buggy AND more or less unsupported in Fedora. Point-blank buggy. That's why you see coruption.

This stuff broke in Fedora 12 because of upstream changes. If you really want this to get fixed, if that's your goal, please forward this upstream.

Thanks in advance.

Technical explanation: radeonhd doesn't properly talk to modern DRM all the time for r600+ chipsets thanks to the API not being quite solidified at certain release times. This occurs even when KMS is disabled at boot.

Upstream (radeonhd) solution: Dunno, ask Fedora.

Upstream (X.org) solution: Use radeon; radeonhd isn't officially shipped in X.org and we don't really handle bugs against it.

Upstream (kernel) solution: Use radeon; radeonhd is known to be broken with modern kernels. Additionally, why not use KMS? It's more stable and provides advanced features like TTM/GEM and DRI2.

~ C.

P.S. Can we get this closed as NOTOURBUG as per the convo the reporter and I had on IRC?

Thanks, Corbin, that was also my idea the whole time. NOTABUG per comment #17.

drm is in the kernel right?
was unchanged.


and broken? you may think so, please provide explanation, but for me it was solid since 1.0.0 as I explained.

s/broken/outdated. In other words, radeonhd is not ready to be used in modern drm/kernel environment. Use radeon.

drm was unchanged. kernel and driver were unchanged.
also the freedesktop link in the bug mentions radeon corruption as well as radeonhd corruption.
so it must be buggy radeonhd.

<udovdh> have a nice evening.
* Fuddl has quit (Read error: 60 (Operation timed out))
* BigBrain has quit (Remote closed the connection)
* pmjordan (n=phillip.132.159) has joined #radeonhd
* dmb has quit ("Leaving")
* bushwakko has quit ()
<FxChiP> udovdh, no
<FxChiP> Kernel.org kernels and Fedora kernels ARE NOT THE SAME
<airlied> Fedora supports the sw Fedora ship, we don't support our sw + shit we don't ship, we don't have time
<airlied> yes its probably a bug in our server but we arent going to look for it, you should run an upstream X server as well
<airlied> and if it happens there report it upstream
<FxChiP> wait
<FxChiP> what do distros patch in X?
<airlied> Fedora patches fixes for the X server that hadn't gone upstream yet, sometimes they aren't also proper fixes
<airlied> like I think the one that might be causing this issue
<airlied> upstream is still talking about the correct answer
<FxChiP> Fedora just sorta plowed through and chose one
<FxChiP> Fair enough then
<FxChiP> ... so wait
<FxChiP> He's using a custom generic kernel with the distro-specific X components
<FxChiP> And is kvetching when they don't line up?

http://bugs.freedesktop.org/show_bug.cgi?id=24771

and

http://bugs.freedesktop.org/show_bug.cgi?id=24948

yes, it is radeonhd: https://bugzilla.redhat.com/show_bug.cgi?id=539571

For others like me who need to use radeonhd due to lack of radeon support on particular hardware, it's possible to bypass DRI with radeonhd.  I changed, in my xorg.conf:

< Load "dri"
< Load "dri2"
> Disable "dri"
> Disable "dri2"

2D performance is surprisingly good.

The radeonhd site says 1.3 is the first version to use DRI by default.  As a Fedora matter, we're shipping it with DRI turned on when we know it is broken.  That's not helpful.

Can we recompile radeonhd without DRI support for an update?  Or sed the xorg to turn off DRI?  If somebody is going to use radeonhd the way we ship it isn't acceptable.

(In reply to comment #25)
> For others like me who need to use radeonhd due to lack of radeon support on
> particular hardware, it's possible to bypass DRI with radeonhd.

Bill, I hope that "lack of radeon support on particular hardware" is being tracked in some bug on the xorg-x11-drv-ati package?

> The radeonhd site says 1.3 is the first version to use DRI by default.  As a
> Fedora matter, we're shipping it with DRI turned on when we know it is broken. 

DRI is not broken for me.

> Can we recompile radeonhd without DRI support for an update?  Or sed the xorg
> to turn off DRI?  If somebody is going to use radeonhd the way we ship it isn't
> acceptable.  

Compiling radeonhd without DRI does not make sense, as radeonhd with DRI works for me, AFAICT.

DRI on RV635 is not broken, and works for me for quite a while except for this xorg server bug.
RV630 is also OK for DRI.
And why mention 1.3?
Try git http://wiki.x.org/wiki/radeonhd#head-f79351b4e2b19fad40529ce297ac2d2a1e90354c and if that doesn't work see #radeonhd at freenode to get intouch with a dev. (xorg --logverbose 7 might help, etc)
See the wiki, see the wiki.

>Bill, I hope that "lack of radeon support on particular hardware" is being
tracked in some bug on the xorg-x11-drv-ati package?

yes, bug 509937.

>Compiling radeonhd without DRI does not make sense, as radeonhd with DRI works
for me, AFAICT.

Ah, interesting.  I gathered from discussion here and on the radeonhd site that there was an ABI mismatch causing the problems in this bug's summary.  A possible fix may have been checked in to git earlier this month, though it was described along the lines of 'it should work'. 

I tried compiling without DRI and the code doesn't compile that way on the version we have in -updates.  There is November patch which looks like it fixes the type define order to make that work, but that may be obsolete now.

> And why mention 1.3?

because that's what we're shipping in f12-updates?

> See the wiki, see the wiki.  

What I was trying to get at was shipping something that works in Fedora, not solving it in my particular case.  If there are fixes the wiki reflects we should be packaging those, right?

Are the folks with working DRI running 1.2 from f12 or 1.3 from f12-updates?

radeonhd git
mesa git (7.8-devel)
libdrm-*-2.4.17-1.fc13.x86_64
and kernel.org 2.6.32.2
and 1d, 2d, 3d works well as far as I can see.

So we use DRI and DRM here. (!?)

The ABI issue mentioned w.r.t. this bug was greatlu invalid was the bug was FIXED with an xorg server update and not with a change to radeonhd or related package.
airlied didn't accept this bug but it was widespread amon other cards as well so it was not (necessarily) a radeonhd or kernel.org issue.
Never was it documented why my `original` source was not enough to meet Fedora standards to qualify to make a but. Enough related bug wre mentioned which indicated the source of the issue.

As radeonhd is still in development, see the wiki) a regular git update would be fiting. Especially for the people that do not experience support for certain hardware as radeonhd is almost regularly updated for newer chips.

So git I do advise here.

So, with a fully-updated f12:

  xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64
  xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc12.x86_64
  2.6.31.9-174.fc12.x86_64 

I still see those DRI errors on an RV620 machine:  

Dec 30 20:20:14 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 10
Dec 30 20:20:15 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 13
Dec 30 20:20:17 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 9
Dec 30 20:20:20 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 7
Dec 30 20:21:24 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 5
Dec 30 20:22:19 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 16
Dec 30 20:23:11 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 3
Dec 30 20:24:02 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 13
Dec 30 20:24:18 zpm kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 21

The visible symptom is very regular blanking of the screen, and eventually a GPU reset, which actually kills X.  Turning off dri/dri2 in xorg.conf returns the system to proper functioning.

Here's the indication I saw that DRI was broken and recently fixed in git:
  http://lists.opensuse.org/radeonhd/2009-12/msg00057.html

This is from the wiki about acceleration being on by default in 1.3:
  # 2D acceleration (EXA) is enabled by default now, except on RV740. 

So, yes, a recent git would probably be helpful.

Did't they push stuff yet?
I run e.g.
xorg-x11-server-common-1.7.3-3.fc12.x86_64.rpm
xorg-x11-server-devel-1.7.3-3.fc12.x86_64.rpm
xorg-x11-server-Xorg-1.7.3-3.fc12.x86_64.rpm

And none of that bug.

http://koji.fedoraproject.org/koji/buildinfo?buildID=147423 or newer perhaps

Looks like they only started to push yesterday:

https://admin.fedoraproject.org/updates/search/xorg-x11-server?_csrf_token=af5f956cf3d12fbfe8726ec43cf50069e5e860af

At least stuff is happening, great!
Thanks for the tip.

Hmm. New bug here? https://admin.fedoraproject.org/updates/xorg-x11-server-1.7.3-8.fc12?_csrf_token=4f1404a45348a362cd0d44ff995ea2dd562a18cd

I do not see that issue with the 1.7.3-3 here. (!?)

I installed 1.7.3-7 here and the drm:radeon_cp_indirect messages are gone.  Assuming they haven't simply been masked, that appears to be fixed.

The screen blanking still occurs with DRI on, so perhaps that's a separate bug.  I'll try the recent git build next time I restart my X server.