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 then repeat the procedure starting from 'make ...' Pay attention: "curl -s https://bugs.freedesktop.org/attachment.cgi?id=115559 | patch -p1" is one-liner. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
