Package Details: linux-amd-staging-drm-next-headers-git 6.12.r1313255.16b8b0512423-1

Git Clone URL: https://aur.archlinux.org/linux-amd-staging-drm-next-git.git (read-only, click to copy)
Package Base: linux-amd-staging-drm-next-git
Description: Headers and scripts for building modules for the Linux kernel with bleeding-edge AMDGPU drivers kernel
Upstream URL: https://gitlab.freedesktop.org/agd5f/linux
Keywords: amd amdgpu dal dc radeon vega
Licenses: GPL-2.0-only
Submitter: yurikoles
Maintainer: yurikoles
Last Packager: yurikoles
Votes: 24
Popularity: 0.000000
First Submitted: 2017-08-24 18:09 (UTC)
Last Updated: 2024-12-19 13:48 (UTC)

Required by (0)

Sources (2)

Pinned Comments

yurikoles commented on 2017-09-25 18:29 (UTC) (edited on 2020-07-07 21:03 (UTC) by yurikoles)

Pull requests are welcome on github.

Please report bugs on upstream GitLab.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

gardotd426 commented on 2020-05-19 19:23 (UTC) (edited on 2020-05-19 19:24 (UTC) by gardotd426)

@chrhasse I've heard that there was an issue with black screens on boot upstream but that it was patched, I guess the issue hasn't been fixed in the agd5f repo. I don't know what patch fixed it, you'll have to wait until they merge the patch I guess. Or contact Alex at AMD and ask him about it. I think it's AlexDeucher@amd.com. He's the main AMD Linux dev, and agd5f is his handle on gitlab and other places. So he would be the person to talk to. But yeah I'm pretty sure this is a bug, not anything wrong with your setup.

chrhasse commented on 2020-05-19 07:21 (UTC)

Is anyone else experiencing build failures with GCC 10.1? I'm getting

arch/x86/kvm/../../../virt/kvm/kvm_main.c: In function ‘__kvm_gfn_to_hva_cache_init’:
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2236:42: error: ‘nr_pages_avail’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
 2236 |  for ( ; start_gfn <= end_gfn; start_gfn += nr_pages_avail) {
      |                                ~~~~~~~~~~^~~~~~~~~~~~~~~~~

and I can solve that error and get it to compile with the patch

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 70f03ce0e5c1..dc8a67ad082d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2219,7 +2219,7 @@ static int __kvm_gfn_to_hva_cache_init(struct kvm_memslots *slots,
    gfn_t start_gfn = gpa >> PAGE_SHIFT;
    gfn_t end_gfn = (gpa + len - 1) >> PAGE_SHIFT;
    gfn_t nr_pages_needed = end_gfn - start_gfn + 1;
-   gfn_t nr_pages_avail;
+   gfn_t nr_pages_avail = 0;

    /* Update ghc->generation before performing any error checks. */
    ghc->generation = slots->generation;

but even though it builds with that patch, I get a black screen on boot.

yurikoles commented on 2020-04-15 09:09 (UTC)

The build is fixed

EnSER commented on 2020-04-15 06:14 (UTC)

This has already been patched in the regular kernel: https://git.archlinux.org/svntogit/packages.git/tree/trunk/sphinx-workaround.patch?h=packages/linux&id=08a7fa88eaa91ef8b0e1f71b496d4097c3702e8d @yurikoles Could you pick that up?

gardotd426 commented on 2020-04-14 23:18 (UTC)

What's going on with the sphinx nonsense? Do we just have to wait for whether they decide to fix it or not before this will work? Because he closed the issue, and it sounded like they're going to allow alternative implementations, but not fix what's broken.

EnSER commented on 2020-04-07 07:08 (UTC)

The build is failing for me at the moment with: Extension error: Could not import extension cdomain (exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (/usr/lib/python3.8/site-packages/sphinx/domains/c.py))

This points to this bug: https://github.com/sphinx-doc/sphinx/issues/7421

Not sure if the mentioned workaround would make sense at the moment or not: https://github.com/sphinx-doc/sphinx/issues/7421#issuecomment-609809210

yurikoles commented on 2020-02-03 19:03 (UTC) (edited on 2020-02-03 19:06 (UTC) by yurikoles)

According to site (https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next) the latest commit was 4 days ago, it seems like they just had forgot to merge/rebase on top of linus repo. I do magic of patch + 1 because of this tags mess, but as for now I think it worth to do a +2.

Regardless of number reported by uname this package has fresh material, e.g. 4 days old. I do infrequent rebases on top of linux-mainline package, but they are often not required, since it just works. Feel free to re-build this package as often as you want to pull new commits.

yurikoles commented on 2020-02-03 18:52 (UTC)

It's next branch, it has material targeting 5.5, but no 5.5 tag obviously. Feel free to examine commit log or repo site.

gardotd426 commented on 2020-02-03 18:45 (UTC)

Why is this a months-old kernel? It's reported here as 5.5.875752.a90553955f0c-1 but it's not. It's 5.4.0-rc7-amd-staging-drm-next-git-01924-ga90553944f0c. Which means the kernel itself from the repo is months old, but that doesn't explain why this page (and the PKGBUILD) is reporting it incorrectly. And yes, I chose to cleanBuild all three involved packages, and they were updated like 2 hours ago. So this is the most up-to-date package available, and it's still only 5.4.0-rc7. Also confirmed by having none of the 5.5 patches, so it's not like uname and every other system utility is just reporting it wrong (which would be ridiculous anyway)

yurikoles commented on 2020-01-11 20:17 (UTC)

I had successfully booted KDE Plasma with my latest build.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »