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!
// Giulio (juliuxpigface)
(*) or maybe I'll be back on track with a new computer, because the unnecessary overhead caused by double-gpus is tiring me...
On 04.05.2015 21:56, 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!
// Giulio (juliuxpigface)
(*) or maybe I'll be back on track with a new computer, because the unnecessary overhead caused by double-gpus is tiring me...
test@ is neither the first nor the last stop.
http://www.x.org/wiki/radeon Good luck.
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...
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...
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Ok, it seems like I solved this...
I blacklisted the HDMI audio and now Fedora works again.
//Giulio (juliuxpigface)
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?
// Giulio (juliuxpigface)
On Wed, May 6, 2015 at 11:33 AM, Giulio 'juliuxpigface' juliuxpigface@fedoraproject.org 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?
It's a good question I've never asked. If it's essentially certain this fix would go in the mainline kernel, I'd guess there's a good likelihood the kernel team would add the patch in rawhide/f23 kernel, which you can use on Fedora 22. So it's worth asking them if you can't or don't want to build it. That would be a 4.1.0 git kernel however.
If you want to build it against something else like 3.19 or 4.0 then you'd need to build it yourself. I personally find it easier to build kernels from kernel.org source for this purpose, Fedora's custom kernel instructions work for Fedora 21 and it's handy in that it'll build rpms so you can build on one system and install on others (there's a way to tar it up when building from kernel.org source but I've never done that).
On 06.05.2015 19:48, Chris Murphy wrote:
On Wed, May 6, 2015 at 11:33 AM, Giulio 'juliuxpigface' juliuxpigface@fedoraproject.org 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?
It's a good question I've never asked. If it's essentially certain this fix would go in the mainline kernel, I'd guess there's a good likelihood the kernel team would add the patch in rawhide/f23 kernel, which you can use on Fedora 22. So it's worth asking them if you can't or don't want to build it. That would be a 4.1.0 git kernel however.
If you want to build it against something else like 3.19 or 4.0 then you'd need to build it yourself. I personally find it easier to build kernels from kernel.org source for this purpose, Fedora's custom kernel instructions work for Fedora 21 and it's handy in that it'll build rpms so you can build on one system and install on others (there's a way to tar it up when building from kernel.org source but I've never done that).
$ rpm -ivh https://kojipkgs.fedoraproject.org/packages/kernel/4.0.1/300.fc22/src/kernel...
$ rpmbuild -bp ~/rpmbuild/SPECS/kernel.spec
$ cd ~/rpmbuild/BUILD/kernel-4.0.fc21/linux-4.0.1-300.fc21.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
On 06.05.2015 20:56, poma wrote:
On 06.05.2015 19:48, Chris Murphy wrote:
On Wed, May 6, 2015 at 11:33 AM, Giulio 'juliuxpigface' juliuxpigface@fedoraproject.org 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?
It's a good question I've never asked. If it's essentially certain this fix would go in the mainline kernel, I'd guess there's a good likelihood the kernel team would add the patch in rawhide/f23 kernel, which you can use on Fedora 22. So it's worth asking them if you can't or don't want to build it. That would be a 4.1.0 git kernel however.
If you want to build it against something else like 3.19 or 4.0 then you'd need to build it yourself. I personally find it easier to build kernels from kernel.org source for this purpose, Fedora's custom kernel instructions work for Fedora 21 and it's handy in that it'll build rpms so you can build on one system and install on others (there's a way to tar it up when building from kernel.org source but I've never done that).
$ rpm -ivh https://kojipkgs.fedoraproject.org/packages/kernel/4.0.1/300.fc22/src/kernel...
$ rpmbuild -bp ~/rpmbuild/SPECS/kernel.spec
$ cd ~/rpmbuild/BUILD/kernel-4.0.fc21/linux-4.0.1-300.fc21.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
The above mentioned is made on Fedora 21, so translate the actual paths to 22 where necessary.
In the case the radeon.ko is in the initramfs image also, # lsinitrd | grep radeon.ko ask "Dr. Acut" for help, $ man dracut
e.g. # mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img-bkp # dracut -v # reboot
On Wed, May 06, 2015 at 07:33:00PM +0200, Giulio 'juliuxpigface' wrote:
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, ....
Quite possible substantially less. To be completely sure one would need to dig a bit around kernel sources but the https://bugs.freedesktop.org/attachment.cgi?id=115559 patch appears to affect only radeon so recompiling only an affected module (or modules) and replacing originals should be fine. Kernel makefiles are set up to allow such selective recompilations.
This is still a PITA to an extent as you would need to repeat such procedure for an every update of a yet unpatched kernel; but this can be variously "automated". For an example of one way to do such things you can look at 'akmod' packages from rpmfusion.
Technically the same module _may_ work across different kernel versions but usually a recompilation is simpler and faster then checking if an old module will be still good enough.
Michal
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.
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
Well guys... You are awesome!
Thank you for your kind help. I'm applying the patch right now. I'll report here if I face further problems.
Have a nice day/night! (depending on your time zone hehe)
// Giulio (juliuxpigface)
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)
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?
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)
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.
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.
On Sun, 2015-05-10 at 12:44 +0200, poma wrote:
Are you're trying to build the whole kernel to test only one module?
If he's using my approach, yes, he is. There's nothing fundamentally wrong with that. It takes a bit longer, but hey - there's lots of ways to pass time. I've usually found it more trouble than it's worth to isolate individual modules and rebuild them against an existing kernel, but as I said in my original mail, both approaches are perfectly valid.
On 11.05.2015 23:25, Adam Williamson wrote:
On Sun, 2015-05-10 at 12:44 +0200, poma wrote:
Are you're trying to build the whole kernel to test only one module?
If he's using my approach, yes, he is. There's nothing fundamentally wrong with that. It takes a bit longer, but hey - there's lots of ways to pass time. I've usually found it more trouble than it's worth to isolate individual modules and rebuild them against an existing kernel, but as I said in my original mail, both approaches are perfectly valid.
You do not want to build the whole kernel only to find out the patch actually has no effect. Once you prove the patch really does have a positive effect, then you can go with the whole shebang. This is a question of what you actually need, not what you can do. ;)
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 -
Chris Murphy -
Giulio E. -
Giulio E. -
Michal Jaegermann -
poma