On 10.05.2015 23:42, poma wrote: > On 10.05.2015 21:59, Giulio 'juliuxpigface' wrote: >> 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) >> > > > You need to specify Fedora part of the kernel name in kernel's config file: > ~/rpmbuild/BUILD/kernel-4.0.fc22/linux-4.0.1-300.fc22.x86_64/.config > > change the empty string: > CONFIG_LOCALVERSION="" > with: > CONFIG_LOCALVERSION="-300.fc22.x86_64" > > so you get: > $ modinfo radeon | grep vermagic > vermagic: 4.0.1-300.fc22.x86_64 SMP mod_unload > > rather than it is now: > vermagic: 4.0.1 SMP mod_unload > > you can do it like this: > $ cd ~/rpmbuild/BUILD/kernel-4.0.fc22/linux-4.0.1-300.fc22.x86_64/ > $ sed -i 's/CONFIG_LOCALVERSION=""/CONFIG_LOCALVERSION="-300.fc22.x86_64"/' .config > Even better in Makefile: e.g. EXTRAVERSION = to EXTRAVERSION = -300.fc21.x86_64 This will also cover debug kernels. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
