On 10.05.2015 11:24, 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! > > // Giulio (juliuxpigface) > > Are you're trying to build the whole kernel to test only one module? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
