Package Details: linux-ryzen-git 4.17.r11346.g8efcf34a2639-1

Git Clone URL: (read-only, click to copy)
Package Base: linux-ryzen-git
Description: The Linux kernel and modules (git version), with GCC optimization patch and Ryzen-friendly config flags (CONFIG_RCU_NOCB_CPU=y) to enable the rcu_nocbs=0-x boot argument
Upstream URL:
Licenses: GPL2
Provides: linux
Submitter: ssorgatem
Maintainer: navigaid
Last Packager: ssorgatem
Votes: 8
Popularity: 0.000000
First Submitted: 2017-12-01 11:30
Last Updated: 2018-06-12 13:27

Required by (188)

Sources (4)

Latest Comments

1 2 3 Next › Last »

trougnouf commented on 2020-02-29 15:23

==> Starting prepare()...
patching file arch/x86/include/asm/module.h
Hunk #1 succeeded at 27 (offset 2 lines).
Hunk #2 succeeded at 65 (offset 2 lines).
patching file arch/x86/Kconfig.cpu
Hunk #1 succeeded at 123 (offset 7 lines).
Hunk #2 succeeded at 156 (offset 7 lines).
Hunk #3 succeeded at 165 (offset 7 lines).
Hunk #4 succeeded at 173 (offset 7 lines).
Hunk #5 succeeded at 331 (offset 7 lines).
Hunk #6 succeeded at 341 (offset 7 lines).
Hunk #7 succeeded at 361 (offset 7 lines).
Hunk #8 succeeded at 451 (offset 7 lines).
Hunk #9 FAILED at 481.
Hunk #10 succeeded at 506 (offset -6 lines).
Hunk #11 succeeded at 545 (offset -6 lines).
1 out of 11 hunks FAILED -- saving rejects to file arch/x86/Kconfig.cpu.rej
patching file arch/x86/Makefile
Hunk #1 succeeded at 119 (offset -5 lines).
patching file arch/x86/Makefile_32.cpu
Hunk #1 succeeded at 24 (offset 1 line).
Hunk #2 succeeded at 44 (offset 1 line).
==> ERROR: A failure occurred in prepare().

p-we commented on 2018-04-22 22:54

Does anyone know if running this kernel (or other recent kernel with the same patches and flags applied) is likely to help issue with v4l firmware not being loaded for new system with Ryzen 1600X + B350 chipset? System is Arch with LTS 4.14 which works fine otherwise. No build issues. The TBS driver package only go to 4.14 at this time.

Context: I use out of kernel TBS linux drivers which also require separate firmware. Dmesg showing no firmware being loaded and it stops there. Works perfect for older AMD (K8) and Intel (Sandy Bridge) hardware.

Thanks for help with slightly off topic question. Somewhat desperate. Getting nowhere in TBS and V4l forums.

Vagr9K commented on 2018-03-16 13:34

@mrpg I agree with you, but to be fair to AMD, idle kernel lockup bug has been fixed with a BIOS update recently (you can now disable the Package C state from AMD CBS if you experience crashes). On the other hand, C-States were and still are a mess for some people even in case of Intel.

The last soft lockup that I was dealing with was an Arch specific issue that had nothing to do with the CPU itself. Ubuntu 17.10 had no issues whatsoever for the record. I also posted a fix.

As of right now the only issue I have with AMD hardware is AMDGPU DC creating screen flicker/corruption when using auto power profile, but AMD is aware of the bug (, and as long as I still have amdgpu.dc=0parameter available to me, I don't see it as a serious issue. After all they are adding Freesync/HDMI audio support to their OSS drivers, and it's not a simple task.

With all those issues considered, overall I'd say that Ryzen/RX580 redeemed themselves for me.

I just wish they were a little bit more polished.

mrpg commented on 2018-03-16 10:57

@Vagr9K I appreciate the followup, thank you. Sadly, I can't really help. Anyways, I agree wholeheartedly with your annoyance at these issues. AMD (and in my case, also MSI) should be ashamed for selling such (at best) alpha-level hardware.

Is it really too much to ask these vendors to test their hardware on ONE LINUX BOX? It is just stunning that after one year (!) there is still tremendous uncertainty in everyday operation of these systems. If AMD really wants to challenge Intel, they will have to do MUCH better. Not in ten years have I ever had any CPU bugs with Intel; once started, these machines run forever. Not so with Ryzen. Just today, I experienced another soft lockup, and this under no load whatsoever. And since installing a new MSI BIOS, the whole situation has become even worse.

This is just completely execrable. While I very much appreciate all your hard work (and of all the others here who also deal with these issues), I would much rather not have to deal with these issues at all. It is unacceptable, and these vendors should be truly ashamed of themselves for selling this stuff.

Vagr9K commented on 2018-03-16 05:23

Sorry for an off-topic comment again but I don't want to leave people having the issue in the dark.

Apparently OPCache has nothing to do with it. It just degrades performance enough to make reproduction much harder.

Update to the latest GCC from testing that fixes This will also fix unexplainable issues like fork() resource starvation and strange lockups.

At least it did it for me.

No more issues when compiling with '-j16'.

Vagr9K commented on 2018-03-13 22:52

Seems like I've found a workaround.

Disable OPCache from BIOS (AMD CBS->Zen Common Options-> OPcache control).

Keep mind that it comes with a ~5% performance penalty (at least in Cinebench).

On a side note, I am getting really tired of all this CPU bugs.

Vagr9K commented on 2018-03-13 15:52

Okay. I tried disabling power-saving features, locking my CPU at 3.7GHz, disabling boosts/etc, completely resetting the BIOS and still got random lockups while compiling.

Kernel regression is also out of question, since I was running versions starting from 4.13 to 4.16 when crashes happened.

I suspect this might be related to:


2) High poll rate Keyboards/Mouses, ckb-next driver

3) ccache

4) Latest AGESA update

5) Pulseaudio (during one of the crashes audio was still working perfectly, I'll try rolling back pulseaudio updates)

6) RAM. Even though I have CL14 Samsung B-Die RAM, still don't want to exclude the possibility.

@mrpg and @quasd. Sorry for bothering again, but any tips/suggestion besides the -j12 trick? I'll collect some dmesg samples from lockups and try reporting upstream too.

mrpg commented on 2018-03-12 16:38

@Vagr9K Nope, I have a MSI X370 Gaming Pro Carbon.

I also had my CPU RMA'd, but there are still weird issues that occur rarely. When I used this package, I sometimes had this effect that the computer became unresponsive and the CPU LED on the mainboard started lighting up. Due to this, I am currently not using this kernel, but the standard kernel in the "linux" package.

However, when doing heavy compression (for example), sometimes these (hard) lockups still occur.

As to your description of what sometimes happens when compiling the kernel, I can second that -- I had exactly the same issues. Literally the same. Very, very weird.

Vagr9K commented on 2018-03-12 16:33

@mrpg Do you have Crosshair 6 Hero with the latest BIOS by any chance?

I've been trying to bisect an amdgpu-dc flickering bug recently, and every 5th kernel compilation ended up soft-locking the threads one by one until the system became completely unresponsive. There are also a bunch of cgroup warnings about rejecting fork() due to lack of resources and then a CPU trace in dmesg.

The CPU is segfault bug free (AMD RMA). Interestingly enough this issue wasn't happening in December when I originally received the CPU and compiled a bunch of stuff (including kernels and GCC). I am also using '-j16' for compilation speed.

ssorgatem commented on 2018-02-26 10:52

Well, I used an updated patch from that issue, I hope it works well (seems to work in my system; can't fully test due to an unrelated bug in linux 4.16 with Vega GPUs)