Anyone with two AMDs?

[poma]

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?