On 10/05/2015 12.44 +0200, poma wrote: > 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? > > Hi poma, thank you for your help. I've tried your suggestion, but something went wrong. The system can't load the radeon driver properly now. I don't know if it is caused by upstream's patch, or I misunderstood some of your steps. Here it's what I did: $ rpm -ivh https://kojipkgs.fedoraproject.org/packages/kernel/4.0.1/300.fc22/src/kernel- 4.0.1-300.fc22.src.rpm $ rpmbuild -bp ~/rpmbuild/SPECS/kernel.spec $ cd ~/rpmbuild/BUILD/kernel-4.0.fc22/linux-4.0.1-300.fc22.x86_64/ $ curl -s https://bugs.freedesktop.org/attachment.cgi?id=115559 | patch -p1 $ make -j drivers/gpu/drm/radeon/radeon.ko $ su # cp drivers/gpu/drm/radeon/radeon.ko /lib/modules/4.0.1 -300.fc22.x86_64/updates/ # depmod # systemctl reboot # mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img -bkp # dracut -v # reboot The problem could be what "# journalctl -b | grep radeon" prints: kernel: radeon: version magic '4.0.1 SMP mod_unload ' should be '4.0.1 -300.fc22.x86_64 SMP mod_unload ' What do you think? // Giulio (juliuxpigface) -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
