On Wed, 2015-05-06 at 19:33 +0200, Giulio 'juliuxpigface' wrote: > > > On Mon, 2015-05-04 at 21:56 +0200, Giulio (juliuxpigface) wrote: > > > > Hi folks. > > > > > > > > Does anyone with a laptop equipped with two Amd experience > > > > this? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1218364 > > > > > > > > I'm sorry but this is currently affecting my activity for QA > > > > as > > > > I > > > > can't use > > > > Fedora at all. I promise I'll be back as soon as I figure out > > > > what's > > > > happening with that laptop (*). > > > > > > > > Cheers guys. Feel free to contact me if you have got > > > > suggestions! > > > > > > There's a couple of other radeon parameters you might try > > > twiddling: > > > > > > radeon.aspm=0 > > > radeon.bapm=0 > > > > > > dunno if they'll help, but it can't hurt to try... > > > Hi guys. Even though I found a workaround, yesterday I filled an > upstream bug for the issue. > > The link is this: https://bugs.freedesktop.org/show_bug.cgi?id=90321 > > As shown there, Alex Deucher proposed a patch. I'm wondering what I'm > supposed to do now. In order to test it, I believe that recompiling > the kernel is mandatory, but I'm not sure (this is one of my first > upstream tickets, sorry). > > Should I try to get my hands on it (I don't really know how to, > anyway, but I might learn...), or shall I ping Fedora's maintainer? The way I like to do this (there are others, like poma's) is to rebuild the kernel package. Clone it from git: fedpkg --anonymous clone kernel cd kernel You can stay on master branch, which is the rawhide package, and so right now will give you a 4.1rc2 kernel. Or you can do 'fedpkg - -anonymous switch-branch f22' to switch to the f22 branch. Copy the patch into the directory, then edit the kernel.spec file. Find the two big blocks where patches are defined and applied. There's a comment at the end of the patch definitions - "# END OF FEDORA PATCH DEFINITIONS" - so search for that. Add your patch right above it, with a number higher than the last patch. So right now, for instance, you'd wind up with this, on the master branch: ======================== #rhbz 1218662 Patch26199: libata-Blacklist-queued-TRIM-on-all-Samsung-800-seri.patch Patch26200: 0001-drm-radeon-handle-audio-for-PX.patch # END OF PATCH DEFINITIONS ======================== There are similar comments around the patch application block, so you can find that similarly - look for "# END OF FEDORA PATCH APPLICATIONS". Edit as appropriate again. You'll wind up with: ======================== #rhbz 1218662 ApplyPatch libata-Blacklist-queued-TRIM-on-all-Samsung-800-seri.patch ApplyPatch 0001-drm-radeon-handle-audio-for-PX.patch # END OF PATCH APPLICATIONS ======================== Now you want to bump the package version a bit so it'll be newer than the current kernel package. There's actually a handy macro for this purpose in the kernel spec, near the top: # % define buildid .local You can uncomment that and change it. So for e.g. you could do: %define buildid .1.juliux and then you'd wind up with a kernel based on '4.1.0-0.rc2.git2.1' whose version would be '4.1.0-0.rc2.git2.1.1.juliux' - makes it easy to notice when you're running your own modified kernel. If you like you can put a changelog entry in, following the format of the existing ones - it's not required, but it can be handy so you remember what the hell you did two weeks later. :) Then you can build a .src.rpm: fedpkg --anonymous srpm Then you just have to build it. If you're a packager you can do a Koji scratch build, but if not, you can use mock: mock -r fedora-22-x86_64 --rebuild kernel-4.1.0 -0.rc2.git2.1.1.juliux.src.rpm for e.g. Or of course you can just build it with 'rpm --rebuild', but I like to keep my package builds clean. To use mock you have to set it up if you never have - https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds . You can fiddle about with 'make config-release' and the '%define debugbuildsenabled 0/1' line in kernel.spec - if you want a non-debug kernel and a faster build, you want to run 'make config-release' before creating the .src.rpm, and make sure it's '%define debugbuildsenabled 0' not '%define debugbuildsenabled 1' - but that's not compulsory. Good luck :) If you test and find the patch works it'll likely start working its way upstream, and you could poke the Fedora maintainers and see if they're willing to backport it to Rawhide and F22 kernels. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
