(In reply to Moritz Naumann from comment #592) > The latest firmware for X370 Taichi, v5.50 (2019/4/24), removes the "Power > Supply Idle Control" option off the configuration UI; downgrading is not > supported (but effectively possible at least from Windows). It is still > possible to set "Power Supply Idle Control" (C6 package) via MSR using e.g. > /sbin/modprobe msr && /usr/sbin/wrmsr -a 0xC0010292 true > during boot. > > Luckily, this workaround may no longer be needed. While, with default 'BIOS' > (actually UEFI firmware) settings on v5.50, Linux 4.18 still freezes during > idle for me, it no longer does so on 5.1.2 (apparently - needs more testing > - not on 5.0 either).
Hi, have you been able to do more testing? Does it still not freeze anymore for you with v.5.50? You're the second person I find saying that v5.50 removes the freezes with the default settings. I also use the ASRock X370 Taichi and the "Power Supply Idle Control" option, but I'm still on v4.70. However, since my computer also freezes on Windows when idle without changing that option, I now think that this is probably a different problem than the bug in this discussion. I actually found other people on forums who also have experienced those freezes on Windows, so I’m not an isolated case. They don’t all have ASRock boards, but there might also be something specific to ASRock. I have not really tested this yet, but sometime ago, I was told that at least on the ASRock boards, the default SOC voltage of 0.9 V is too low, and that raising it to at least 1.0 V would prevent the freezes (but don't go higher than 1.1 V). I'm probably going to raise that voltage anyway because I would like to increase the frequency of my RAM and lower the timings, if the BIOS would let me do so properly and keep the settings… The v4.x BIOSes for this board are known to have serious bugs in this respect [http://forum.asrock.com/forum_posts.asp?TID=9371&KW=ram+worse&title =psa-stay-away-from-480-bios-x370-taichi], so I will probably take the risk to upgrade to v5.50 soon, too. Meanwhile, AMD replaced my faulty 1700X CPU, and the replacement I received (same CPU model, but produced much later) seems not to have the segfault bug, although I should test it more in order to be completely sure. I must say that AMD was very nice in the RMA process, I really recommend doing the RMA directly with them if you have the segfault bug. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1690085 Title: Ryzen 1800X freeze - rcu_sched detected stalls on CPUs/tasks Status in Linux: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: Hi, We aregetting various kernel crash on a pretty new config. We're using Ryzen 1800X CPU with X370 Gaming Pro Carbon MB (7A32V1) using latest BIOS available (1.52) We are running Ubuntu 17.04 (amd64), we've tried different kernel version, native one and releases from http://kernel.ubuntu.com/~kernel-ppa/mainline/ too. Tested kernel version: native 17.04 kernel 4.10.15 Issues are the same, we're getting random freeze on the machine. Here is kern.log entry when happening : May 10 22:41:56 dev2 kernel: [24366.186246] INFO: rcu_sched detected stalls on CPUs/tasks: May 10 22:41:56 dev2 kernel: [24366.187618] 0-...: (1 GPs behind) idle=49b/1/0 softirq=28561/28563 fqs=913449 May 10 22:41:56 dev2 kernel: [24366.188977] (detected by 12, t=1860207 jiffies, g=10001, c=10000, q=4656) May 10 22:41:56 dev2 kernel: [24366.190344] Task dump for CPU 0: May 10 22:41:56 dev2 kernel: [24366.190345] swapper/0 R running task 0 0 0 0x00000008 May 10 22:41:56 dev2 kernel: [24366.190348] Call Trace: May 10 22:41:56 dev2 kernel: [24366.190354] ? native_safe_halt+0x6/0x10 May 10 22:41:56 dev2 kernel: [24366.190355] ? default_idle+0x20/0xd0 May 10 22:41:56 dev2 kernel: [24366.190358] ? arch_cpu_idle+0xf/0x20 May 10 22:41:56 dev2 kernel: [24366.190360] ? default_idle_call+0x23/0x30 May 10 22:41:56 dev2 kernel: [24366.190362] ? do_idle+0x16f/0x200 May 10 22:41:56 dev2 kernel: [24366.190364] ? cpu_startup_entry+0x71/0x80 May 10 22:41:56 dev2 kernel: [24366.190366] ? rest_init+0x77/0x80 May 10 22:41:56 dev2 kernel: [24366.190368] ? start_kernel+0x464/0x485 May 10 22:41:56 dev2 kernel: [24366.190369] ? early_idt_handler_array+0x120/0x120 May 10 22:41:56 dev2 kernel: [24366.190371] ? x86_64_start_reservations+0x24/0x26 May 10 22:41:56 dev2 kernel: [24366.190372] ? x86_64_start_kernel+0x14d/0x170 May 10 22:41:56 dev2 kernel: [24366.190373] ? start_cpu+0x14/0x14 May 10 22:44:56 dev2 kernel: [24546.188093] INFO: rcu_sched detected stalls on CPUs/tasks: May 10 22:44:56 dev2 kernel: [24546.189461] 0-...: (1 GPs behind) idle=49b/1/0 softirq=28561/28563 fqs=935027 May 10 22:44:56 dev2 kernel: [24546.190823] (detected by 14, t=1905212 jiffies, g=10001, c=10000, q=4740) May 10 22:44:56 dev2 kernel: [24546.192191] Task dump for CPU 0: May 10 22:44:56 dev2 kernel: [24546.192192] swapper/0 R running task 0 0 0 0x00000008 May 10 22:44:56 dev2 kernel: [24546.192195] Call Trace: May 10 22:44:56 dev2 kernel: [24546.192199] ? native_safe_halt+0x6/0x10 May 10 22:44:56 dev2 kernel: [24546.192201] ? default_idle+0x20/0xd0 May 10 22:44:56 dev2 kernel: [24546.192203] ? arch_cpu_idle+0xf/0x20 May 10 22:44:56 dev2 kernel: [24546.192204] ? default_idle_call+0x23/0x30 May 10 22:44:56 dev2 kernel: [24546.192206] ? do_idle+0x16f/0x200 May 10 22:44:56 dev2 kernel: [24546.192208] ? cpu_startup_entry+0x71/0x80 May 10 22:44:56 dev2 kernel: [24546.192210] ? rest_init+0x77/0x80 May 10 22:44:56 dev2 kernel: [24546.192211] ? start_kernel+0x464/0x485 May 10 22:44:56 dev2 kernel: [24546.192213] ? early_idt_handler_array+0x120/0x120 May 10 22:44:56 dev2 kernel: [24546.192214] ? x86_64_start_reservations+0x24/0x26 May 10 22:44:56 dev2 kernel: [24546.192215] ? x86_64_start_kernel+0x14d/0x170 May 10 22:44:56 dev2 kernel: [24546.192217] ? start_cpu+0x14/0x14 Depending on the kernel version, we've got NMI watchdog errors related to CPU stuck (mentioning the CPU core id, which is random). Crash is happening randomly, but in general after some hours (3-4h). Now, we've installed kernel 4.11.0-041100-generic #201705041534 this morning and waiting for crash... For now, the machine is not "used", at least, it's not CPU stressed... Thanks --- ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 DistroRelease: Ubuntu 17.04 InstallationDate: Installed on 2017-05-09 (1 days ago) InstallationMedia: Ubuntu-Server 17.04 "Zesty Zapus" - Release amd64 (20170412) Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=fr_FR.UTF-8 SHELL=/bin/bash Tags: zesty Uname: Linux 4.11.0-041100-generic x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1690085/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
