Bug 99013 - [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable
Summary: [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for ...
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
: 99026 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-07 04:59 UTC by Alexandre Demers
Modified: 2016-12-09 02:19 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Alexandre Demers 2016-12-07 04:59:06 UTC
Using an R9 280X
kernel 4.8.12 (radeonsi driver)

LLVM 4.0.0svn r288795
Latest drm from git
latest ddx ati from git

When compiling mesa commit 4c8c13b3, the system is unusable. Reverting to the previous commit fix the behavior.

My screen displays a fixed background followed by a black flash and a refresh every few seconds once logged in Gnome 3.

Switching to a terminal shows rings hanging and diving into systemd's journal, I see a lot of the following:

déc 06 23:23:47 Xander kernel: ------------[ cut here ]------------
déc 06 23:23:47 Xander kernel: WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/radeon/radeon_objec
déc 06 23:23:47 Xander kernel: Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat kvm_am
déc 06 23:23:47 Xander kernel:  ehci_hcd libata usbcore scsi_mod usb_common i8042 serio i915 i
déc 06 23:23:47 Xander kernel: CPU: 1 PID: 650 Comm: Xorg Tainted: G      D W       4.8.12-2-A
déc 06 23:23:47 Xander kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5
déc 06 23:23:47 Xander kernel:  0000000000000286 00000000e7a1a4fc ffff880406243b40 ffffffff812
déc 06 23:23:47 Xander kernel:  0000000000000000 0000000000000000 ffff880406243b80 ffffffff810
déc 06 23:23:47 Xander kernel:  0000005400000001 ffff8803e57f5468 ffffffffffffffff ffff8803e57
déc 06 23:23:47 Xander kernel: Call Trace:
déc 06 23:23:47 Xander kernel:  [<ffffffff812fde90>] dump_stack+0x63/0x83
déc 06 23:23:47 Xander kernel:  [<ffffffff8107c85b>] __warn+0xcb/0xf0
déc 06 23:23:47 Xander kernel:  [<ffffffff8107c98d>] warn_slowpath_null+0x1d/0x20
déc 06 23:23:47 Xander kernel:  [<ffffffffa00ff09a>] radeon_ttm_bo_destroy+0xea/0xf0 [radeon]
déc 06 23:23:47 Xander kernel:  [<ffffffffa006b7fb>] ttm_bo_release_list+0xcb/0x220 [ttm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa0073780>] ? ttm_bo_man_put_node+0x40/0x50 [ttm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa006c5bf>] ttm_bo_unref+0x1af/0x220 [ttm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa00ff5d9>] radeon_bo_unref+0x39/0x70 [radeon]
déc 06 23:23:47 Xander kernel:  [<ffffffffa01124f7>] radeon_gem_object_free+0x57/0x70 [radeon]
déc 06 23:23:47 Xander kernel:  [<ffffffffa00048a9>] drm_gem_object_free+0x29/0x70 [drm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa000492a>] drm_gem_object_unreference_unlocked+0x3a/
déc 06 23:23:47 Xander kernel:  [<ffffffffa0004a55>] drm_gem_object_handle_unreference_unlocke
déc 06 23:23:47 Xander kernel:  [<ffffffffa0005025>] drm_gem_object_release_handle+0x55/0xa0 [
déc 06 23:23:47 Xander kernel:  [<ffffffff812fe912>] idr_for_each+0xb2/0x110
déc 06 23:23:47 Xander kernel:  [<ffffffffa0004fd0>] ? drm_gem_object_init+0x40/0x40 [drm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa0005820>] drm_gem_release+0x20/0x30 [drm]
déc 06 23:23:47 Xander kernel:  [<ffffffffa00047c2>] drm_release+0x2c2/0x380 [drm]
déc 06 23:23:47 Xander kernel:  [<ffffffff8120b4ff>] __fput+0x9f/0x1e0
déc 06 23:23:47 Xander kernel:  [<ffffffff8120b67e>] ____fput+0xe/0x10
déc 06 23:23:47 Xander kernel:  [<ffffffff8109a0d0>] task_work_run+0x80/0xa0
déc 06 23:23:47 Xander kernel:  [<ffffffff810806e2>] do_exit+0x2c2/0xb50
déc 06 23:23:47 Xander kernel:  [<ffffffff81003016>] ? ___preempt_schedule+0x16/0x18
déc 06 23:23:47 Xander kernel:  [<ffffffff81080feb>] do_group_exit+0x3b/0xb0
déc 06 23:23:47 Xander kernel:  [<ffffffff81081074>] SyS_exit_group+0x14/0x20
déc 06 23:23:47 Xander kernel:  [<ffffffff815f8032>] entry_SYSCALL_64_fastpath+0x1a/0xa4
déc 06 23:23:47 Xander kernel: ---[ end trace 44dfe616ce5e8b1c ]---
Comment 1 Michel Dänzer 2016-12-07 06:32:54 UTC
(In reply to Alexandre Demers from comment #0)
> LLVM 4.0.0svn r288795

The Mesa commit you bisected requires LLVM SVN r288865 ("AMDGPU: Add llvm.amdgcn.interp.mov intrinsic") or newer.
Comment 2 Alexandre Demers 2016-12-07 18:09:05 UTC
(In reply to Michel Dänzer from comment #1)
> (In reply to Alexandre Demers from comment #0)
> > LLVM 4.0.0svn r288795
> 
> The Mesa commit you bisected requires LLVM SVN r288865 ("AMDGPU: Add
> llvm.amdgcn.interp.mov intrinsic") or newer.

Isn't there a check done against LLVM's version? Does it have the needed granularity to point to a given a commit/revision?
Comment 3 Marek Olšák 2016-12-07 20:21:15 UTC
Older LLVM from svn is officially unsupported. Latest LLVM from svn usually works with Mesa git, but not always.
Comment 4 Christoph Haag 2016-12-07 20:53:16 UTC
Which makes bisecting a lot harder, but understandable that the devs don't want to have the burden of having many intermediate workarounds in the code that's not used for any of the actual llvm releases.

But what I came here to say is that I have llvm 3.9.0 from the Archlinux Repos and this commit breaks everything for me too.
Comment 5 Michel Dänzer 2016-12-08 01:55:57 UTC
(In reply to Christoph Haag from comment #4)
> Which makes bisecting a lot harder, but understandable that the devs don't
> want to have the burden of having many intermediate workarounds in the code
> that's not used for any of the actual llvm releases.

It's not about what we want — there's simply no way to know which SVN revision of LLVM we're building against. So it's not possible for Mesa to work with LLVM SVN snapshots both before and after incompatible API changes. All we can try to ensure is that current Mesa Git master works with current LLVM SVN trunk.


> But what I came here to say is that I have llvm 3.9.0 from the Archlinux
> Repos and this commit breaks everything for me too.

Fixed in https://cgit.freedesktop.org/mesa/mesa/commit/?id=26ba8c920d2727cae8ab45096db70e4691b00245 .
Comment 6 Christoph Haag 2016-12-08 07:37:34 UTC
The build system already uses llvm-config --version which contains the revision for svn versions. Of course it breaks when you update llvm without rebuilding mesa, and you probably don't want to run llvm-config --version every time the mesa libraries are loaded, so yea...

Anyway

> Fixed in
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=26ba8c920d2727cae8ab45096db70e4691b00245 .

Thanks, that fixed it on my llvm 3.9.
Comment 7 Michel Dänzer 2016-12-08 07:41:56 UTC
(In reply to Christoph Haag from comment #6)
> The build system already uses llvm-config --version which contains the
> revision for svn versions.

That just prints "4.0.0svn" for me, using the LLVM Git mirror.
Comment 8 Alexandr Zelinsky 2016-12-08 11:17:14 UTC
*** Bug 99026 has been marked as a duplicate of this bug. ***
Comment 9 Alexandre Demers 2016-12-08 17:36:37 UTC
(In reply to Michel Dänzer from comment #7)
> (In reply to Christoph Haag from comment #6)
> > The build system already uses llvm-config --version which contains the
> > revision for svn versions.
> 
> That just prints "4.0.0svn" for me, using the LLVM Git mirror.

Same here, so sadly no revision info.


However, just to be clear (since I'm unable to test it right now): am I understanding from Christoph's comment that we are allowing the driver to be built against LLVM 3.9? If we rely on features included after the 3.9 release, shouldn't mesa check for 4.0.0svn (at least, beginning from 4c8c13b3)?
Comment 10 Marek Olšák 2016-12-08 21:30:06 UTC
Mesa only checks for LLVM 4.0. There is no distinction between LLVM 4.0 and 4.0svn.

If you want LLVM git, you always have to update Mesa from git along with LLVM and hope for the best. Or you can stick with LLVM 3.9 and only use Mesa git.
Comment 11 Michel Dänzer 2016-12-09 02:19:42 UTC
(In reply to Alexandre Demers from comment #9)
> If we rely on features included after the 3.9 release, shouldn't mesa check for
> 4.0.0svn (at least, beginning from 4c8c13b3)?

The commit you bisected to does that, grep for HAVE_LLVM. However, there was a typo in the intrinsic name used with LLVM 3.9 and older.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.