Anyone with two AMDs?

Sun May 10 21:42:52 UTC 2015

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.