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

[geearf]

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.

This is interesting to me too, the whole compression bothered me so many times.. I'll try that!
Since we're on this, do you know of any way to automagically copy/move the .pkg.tar.* at the end of the -U installation to /cache/pkg?
Often I build something then for whatever reason I need to switch back to the official package, but then to reswitch I need to build again (which is not too slow using ccache but still).

[Hamish Wilson]

Alright, thanks to the excellent help I received on here, I got git bisect to name what it believes to be the troublesome commit:

[hamish@Griffindor mesa]$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[85d7eb730a1cbfbd4c9b2ecd017f6b8dab40b20d] i965: Add a BRW_MOCS_PTE #define.
[hamish@Griffindor mesa]$

I am a bit surprised to see that it says it is one for i965 though.

EDIT: I forgot the final step:

[hamish@Griffindor mesa]$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[64c2bdc334ba472603b1e7cd2c3046cfbce285b6] r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers
[hamish@Griffindor mesa]$

That makes more sense now.

[Hamish Wilson]

[hamish@Griffindor mesa]$ git bisect bad
64c2bdc334ba472603b1e7cd2c3046cfbce285b6 is the first bad commit
commit 64c2bdc334ba472603b1e7cd2c3046cfbce285b6
Author: Michel D?nzer <[email protected]>
Date:   Tue Aug 26 18:21:50 2014 +0900

    r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers
    
    Putting those in VRAM can cause long pauses due to buffers being moved
    into / out of VRAM.
    
    Bugzilla: [url]https://bugs.freedesktop.org/show_bug.cgi?id=84662[/url]
    Cc: [email][email protected][/email]
    Reviewed-by: Alex Deucher <[email protected]>
    (cherry picked from commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786)

:040000 040000 3d09f050c7cf6907d82aebab6bd1d4f719729712 290288e425b6751de0c5f8e02f9d50f566a8d2f3 M	src
[hamish@Griffindor mesa]$]

[geearf]

Awesome!

[dungeon]

That is great 32bit OS radeon bug came to stable , i fighting with it for nearly 3 months to no avail... even earlier if you don't have corruption it is awfull sloooo when compiled with generic tune it is slow, slowww i know, i know

[Hamish Wilson]

Interestingly enough my system was also immune from the HyperZ problems with Br?tal Legend about a year ago because mine was still 32 bit while my brother's was 64 bit, something which allowed me to play normally without crashes while he had to find and work around the bug. What goes around comes around I guess.

Next time I have to re-install for whatever reason I am going to go 64-bit now that I have more confidence in handling legacy applications on the new architecture though.

Still, for the moment I am not quite sure how I am supposed to handle testing the bug with a Mesa 10.3.2 with a 64 bit kernel as recommended by upstream. It is not like I can just boot into a live environment of Arch and test it there.

[dungeon]

Still, for the moment I am not quite sure how I am supposed to handle testing the bug with a Mesa 10.3.2 with a 64 bit kernel as recommended by upstream. It is not like I can just boot into a live environment of Arch and test it there.

I know for Debian, just enable multiarch and install a kernel that is pretty much it . Keep in mind it needs to be pure 64bit 3.17+ kernel and not one builded in multiarch env even it is 64bit!!!

Well someone other may help you how to manage that on Arch

[Hamish Wilson]

At any rate, I decided to spread the knowledge around a little bit by making a page for this on the Arch Wiki:

https://wiki.archlinux.org/index.php/Bisecting_Mesa

[geearf]

Still, for the moment I am not quite sure how I am supposed to handle testing the bug with a Mesa 10.3.2 with a 64 bit kernel as recommended by upstream. It is not like I can just boot into a live environment of Arch and test it there.

You should be able to run a 64b kernel on your 32b Arch, if you CPU is 64b.

[Hamish Wilson]

So I did manage it by using the steps outlined here:

https://wiki.archlinux.org/index.php/Migrating_Between_Architectures_Without_Reinstalling#Install_kernel_.2864-bit.29

If nothing else, I am learning a lot more about what my system is capable of.