Help diagnosing problems with a Readon HD 4670 on Mesa 10.3.2-1

[Hamish Wilson]

Yesterday on Arch I upgraded from Mesa 10.3.1-1 to 10.3.2-1 and since then I have been having corruptions in OpenGL reliant games as well as Chromium. I am using a Radeon HD 4670 with R600g as supplied by Arch.





My question now then is how is the best way to go about making a bug report?

[Hamish Wilson]

I downgraded to the previous Mesa version and the problems went away, so I have at least confirmed that Mesa is indeed the problem:

cd /var/cache/pacman/pkg/
sudo pacman -U mesa-10.3.1-1-i686.pkg.tar.xz mesa-dri-10.3.1-1-i686.pkg.tar.xz mesa-libgl-10.3.1-1-i686.pkg.tar.xz mesa-vdpau-10.3.1-1-i686.pkg.tar.xz

[Hamish Wilson]

Strangely enough I can not find any reference to 10.3.2 on the Mesa website:

http://mesa3d.sourceforge.net/index.html

[Hamish Wilson]

Lacking any further information, I endeavoured to create a bug report anyway:

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

[OneTimeShot]

Did you try the usual dpm on/off, HyperZ on/off tests?

[geearf]

bitsec could be a good option to find where it broke.
It'll be quite time consuming as mesa takes a while to build.

And the '-1' of the build version is only of interest to Arch devs, not to Mesa devs.
It refers to the version of the PKGBUILD not of the upstream code.

[geearf]

Also:

I downgraded to the previous Mesa version and the problems went away, so I have at least confirmed that Mesa is indeed the problem:

cd /var/cache/pacman/pkg/
sudo pacman -U mesa-10.3.1-1-i686.pkg.tar.xz mesa-dri-10.3.1-1-i686.pkg.tar.xz mesa-libgl-10.3.1-1-i686.pkg.tar.xz mesa-vdpau-10.3.1-1-i686.pkg.tar.xz

Not saying you are wrong in your assumption, but something could have changed on the build machine, that produced a bad new mesa package. So it wouldn't have to be an upstream issue. For instance, if any package mesa depends on to build had been updated to a newer, buggy, version it could lead to something like that.
I forgot the full story, but on another forum I follow, one guy using Arch had a bug in a KDE package, but once he rebuilt the package on his machine it worked... I don't remember what the issue was though.
(I doubt this is the case, but I thought I would explain it to you anyway).

[Hamish Wilson]

Did you try the usual dpm on/off, HyperZ on/off tests?

I have tested both DPM and HyperZ with no obvious effect - given that I am on Mesa 10.3 HyperZ would also be disabled by default anyway.

Not saying you are wrong in your assumption, but something could have changed on the build machine, that produced a bad new mesa package. So it wouldn't have to be an upstream issue. For instance, if any package mesa depends on to build had been updated to a newer, buggy, version it could lead to something like that. I forgot the full story, but on another forum I follow, one guy using Arch had a bug in a KDE package, but once he rebuilt the package on his machine it worked... I don't remember what the issue was though. (I doubt this is the case, but I thought I would explain it to you anyway).

I am aware that it could be a problem with the Arch package, which is why I made a point of pointing them out. Thanks for the elaboration anyway.

bitsec could be a good option to find where it broke. It'll be quite time consuming as mesa takes a while to build.

This is what upstream suggested but I must admit to not even knowing where to begin when it comes to this. Any pointers or explanations as to how to go about this would be appreciated.

[geearf]

Sure!

bisect means that you are going to do a binary search for the faulting git commit.

Here's an example, we have commits from 0 to 9, 0 being the last one you know was good (in this case the last commit to 10.3.1) and 9 the first one you know is bad (here the last commit to 10.3.2).

So the first thing you'll try is synchronizing your local git repository to commit (0 + 9) / 2 => commit 5
Now you try building at commit 5, then test again to see if you have the issue.
If you don't have it, you know the problem came after commit 5, so your range is between 6 and 9.
If you do have it, you know the problem came at commit 5 or before, so your range is now between 0 and 5.

Now you synchronize again to the new middle of your range, try again and so on till you find the commit at fault.
As you can see doing a binary search is a lot faster than trying every commit one by one.

This is a good article to help you do it:

http://git-scm.com/docs/git-bisect

Feel free to ask if you need help.

[haagch]

This is what upstream suggested but I must admit to not even knowing where to begin when it comes to this. Any pointers or explanations as to how to go about this would be appreciated.

Since you are on archlinux I can tell you my "workflow":

Get an AUR package with mesa git like mesa-git: https://aur.archlinux.org/packages/mesa-git/
If you're using yaourt, it's just "yaourt -G mesa-git; cd mesa-git", else you'll have to download the tarball from the website and extract it etc. and cd to the directory.

First, make it clone the mesa git repository and create the build directories and stuff with "makepkg -o"

Then you can "cd src/mesa" where the source will be. You once need to do "git bisect start".
Then "git tag" shows all the tags you can use to specify where to bisect.
In your case you want to do tell git that the revision tagged with mesa-10.3.1 was still good: "git bisect good mesa-10.3.1"
And you want to tell it that mesa-10.3.2 is bad: "git bisect bad mesa-10.3.2"

Now go back to your initial mesa-git directory (that contains the PKGBUILD file) with cd ../.. or so. Doing only "makepkg" would remove all the changes you just made. You need to use the -e switch to makepkg: "makepkg -efsi" will compile and install what currently is in src/.

After it is installed, you can test whether your stuff works or not. If it works, you go again into mesa-git/src/mesa and tell git that it was either good or bad: "git bisect good" or "git bisect bad".
Then you go back to mesa-git/ and do "makepkg -efsi" again. Do not forget -e.

and repeat until git tells you which one is the bad commit.

You may also want to switch to PKGEXT='.pkg.tar.gz' in /etc/makepkg.conf, because the default is PKGEXT='.pkg.tar.xz' which is fine if you want to optimize your packages for size, but takes annoyingly much time to compress your package, only to immediately install it once and never again.