Anyone with two AMDs?

Sun May 10 19:59:45 UTC 2015

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)