| Priority | medium |
|---|---|
| Bug ID | 79338 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Something's broken after llvm's svn commit 209067 |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | j.suarez.agapito@gmail.com |
| Hardware | Other |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
Something seems to have been broken in llvm 3.5 after svn revision 209067. What I am experiencing is that the system is stable for desktop usage but after a few minutes from launching a game (I have tried with CKII, Witcher 2, Watelands 2, Cities in motion, Deadfall Adventures and Serious Sam 3) or just after a few seconds after exiting the game the desktop freezes, the screen goes black (can't switch to vt to kill the game/desktop session) and the system becomes unresponsive. I'm afraid I cannot obtain a dmesg log due to that unresponsiveness. If a dmesg log is needed to know the system's specs, the following attachement of another bug report may be of use: https://bugs.freedesktop.org/attachment.cgi?id=97787 I am using a llvm ppa to install llvm 3.5 git. I've tried to compile llvm with no luck, so I cannot bisect. However, I still have in /var/cache/apt/archives the deb packages for svn revisions 209564, 209581 and 209600 and those revisions hang the system in the way described above. So judging by the R600 llvm backend activity (https://github.com/llvm-mirror/llvm/commits/master/lib/Target/R600) and my experience with those svn .deb packages I still have in the apt cache, it seems the culprit must be a commit after 16 May.
Created attachment 99988 [details]<=
/a>
dmesg log
I have uploaded a new dmesg log because I just realised the on= e in the other bug report was not recent.
(In reply to comment #3= ) > [...] after a few minutes from launching a game = (I have tried with CKII, > Witcher 2, Watelands 2, Cities in motion, Deadfall Adventures and Seri= ous Sam > 3) or just after a few seconds after exiting the game [...] If you capture an apitrace of one of those games, does the problem also occ= ur after replaying the apitrace? > I am using a llvm ppa to install llvm 3.5 git. Do the ppa packages use any patches versus upstream? > I've tried to compile llvm with no luck, so I ca= nnot bisect. What's the problem compiling LLVM? It would probably be best if you could bisect yourself.
Thank you for your quick reply, Michel. The ppa I use is llvm.org's ppa (llvm.org/apt/) for Ubuntu 14.04 so I guess= it will just be plain upstream with no additional patches. With regard to compiling, I have two chroot environments, one is i386 and t= he other one is amd64, which I use to recompile mesa (from oibaf's ubuntu ppa) with llvm 3.5 via dpkg-buildpackage (previously editing debian/rules so that the config looks for llvm 3.5 rather than llvm 3.4). I have tried to compile the original tar.gz packages (dpkg-buildpackage) fr= om the llvm.org ppa within those two chroot environments but I just can't get = them to work (config fails complaining about llvm tools, if I remember correctly, even though I downloaded all the tar.gz packages in the ppa and among which there was a package named llvm extra tools or something like that). Using apt-source results in obtaining the llvm 3.4 source tarball from Ubuntu's repositories, not the one from llvm.org, so that does not help either. I th= ink that manually compiling llvm is a bit too much for me (I am not that advanc= ed), so I'll try to get the dpkg-buildpackage working. If that doesn't work I gu= ess I'll give a look at manually compiling. I have never used apitrace either but I will try to find instructions and g= ive it a go. I currently don't have too much free time due to real life (TM) but I'll tr= y to address the llvm compilation (and bisect) and apitrace test. I'll also check newer llvm builds from the ppa in order to check if the problem has been solved.
OK, I finally managed to setup and compile with the dpkg-build= package thing. So I guess I shall be able to reproduce the svn versions to bisect via patches over the ppa llvm source. I'll post my findings.
Created attachment 10012=
3 [details]
dmesg while gpu lock up
Hmmm... the problem actually seems to not be related to llvm.
I managed to obtain a crash dmesg log (see attachment above) while using ll=
vm
3.5 svn 209067 which in theory was a good llvm svn revision. That made me
rethink the cause of the problem and now I think the problem is coming from=
the
kernel.
So I tried linux 3.14 (3.14.0-031400-generic #201403310035), which I had us=
ed
before the 3.15 rc's started to come out. The thing is that with llvm 3.5 s=
vn
209708 and linux 3.14 the gpu does not lock up. This svn 209708 llvm revisi=
on
was making the gpu hang quite fast with linux 3.15-rc6 when launching a gam=
e.
GPU hang with 3.15-rc6 with llvm revs higher than 209067 was quite frequent=
, so
could this be that those higher revs are hitting a bug in linux 3.15-rc6?
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
Finally the problem I was experiencing was indeed related to t=
he linux kernel.
I have installed 3.15-rc7 (I which I had not updated since rc6) and the
problems are gone. Not sure why, but the newer llvm revisions were triggeri=
ng
the bug more frequently.
Guessing by the 3.15-rc7 changelog, I was probably affected by a drm bug:
Alex Deucher (4):
drm/radeon: fix DCE83 check for mullins
drm/radeon: handle non-VGA class pci devices with ATRM
drm/radeon: fix register typo on si
drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off (=
v2)
This report may now be closed.
Thank you, Michel, for your help.