On Wed, 06/05/2015 at 15.06 -0700, Adam Williamson wrote: > 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 Hi guys. Sorry if I bump this again. I've been trying Adam's suggestions, but my problem is that my "/" partition goes easily out of space while mocking (throwing 'OSError: [Errno 28] No space left on device' explicitly. 'df -h' confirms it). How much space is required for this process? My "/" is only 20gb large and I fear it's not sufficient. How can I use an ext4 partition of an external drive? I've tried using the parameter '--rootdir', but the compilation fails. Or... I could work inside a minimal virtual guest - obviously created with a larger "/" - stored on the external drive. The process might be a bit slower, but it should work... What do you think? Thank you in advance! // Giulio (juliuxpigface) -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
