On Sun, 2015-05-10 at 11:24 +0200, Giulio 'juliuxpigface' wrote: > 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! Yeah, you do need a decent amount of space in some specific locations that are usually on the root partition to use mock. You can try making /var/lib/mock and /var/cache/mock into mount points on the external drive - I think that should help. -- 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
