Anyone with two AMDs?

Sun May 10 09:24:35 UTC 2015

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)