Thanks a lot for providing here attachment for Random Soft Lockup on new
Ryzen build. Is really very helpful for IT learners who also visit
Personal Statement Folks.
Caroline,
Design UCAS nursing personal statement
-http://www.personalstatementfolks.co.uk/nursing-personal-statement/ at
Personal
Created attachment 280601
My /proc/cpuinfo
This is my ThreadRipper 2950X /proc/cpuinfo, as requested.
--
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 -
(In reply to Borislav Petkov from comment #475)
> (In reply to Aaron Muir Hamilton from comment #474)
> > I just experienced this issue with a Threadripper 2950X on kernel 4.20.3
>
> Anything in dmesg?
>
> Please upload full dmesg, /proc/cpuinfo and kernel .config.
There is no header soldered on
(In reply to Aaron Muir Hamilton from comment #474)
> I just experienced this issue with a Threadripper 2950X on kernel 4.20.3
Anything in dmesg?
Please upload full dmesg, /proc/cpuinfo and kernel .config.
Anything particular you did to reproduce it? Any correlation between
what the box does and
I just experienced this issue with a Threadripper 2950X on kernel 4.20.3
--
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 C
Sorry but this bugzilla entry is humongous with 110 people on CC and all
reporting some different aspects of what they're seeing and what they're
trying and and...
In order to debug this properly, I'd like for someone to test the latest
upstream kernel 4.20 and try to reproduce the issue there. Th
Hey guys so finally I found this bugreport which I guess explains those
soft lockups on my Ryzen 7 1700 based system. I had temporarily switched
to Win10 since I hoped this bug would be resolved after some time, but
now 1,5 years later it is still there on the latest kernel.. At least I
can finally
Maybe we need to contact AMD support and ask them to implement
workaround they suggested (document in Comment 459) in Linux?
--
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:
(In reply to dl9px from comment #468)
> Just asked the helpdesk what we can do to get help and more attention.
> Disabling c6 still is a workaround for me, but that's not how I intended to
> run my system.
Thanks.
I'm in the same boat with C6. I know I'm a small fish but my company
won't be using
Just asked the helpdesk what we can do to get help and more attention.
Disabling c6 still is a workaround for me, but that's not how I intended
to run my system.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs
So it would appear that also for me the issue is not completely resolved
by setting "Typical Power idle". One of my two (identical) servers
reported this morning that a bunch of processes had blocked for more
than 120s:
(I cut out a lot of other info like call traces, also these are just 4 example
I have random freezes with Ryzen 2200u laptop. Display image just
freezes and system stops responding. Only way to get out from this state
is to holding power button (even magic SysRq key does not work). No any
clues in logs.
With Ubuntu 18.04 it was happen nearly once per week (not intense use).
(In reply to Bráulio Bhavamitra from comment #464)
> You freeze seems GPU related, try a new kernel/firmware
I also have got amdgpu crash with same screen freeze, but magic key had
worked that time and error left in kernel log. And I was able reproduce
that with certain game in dolphin emulator.
Have these lockups with Fedora 29 default kernel and AMD Ryzen 7 1700X
Eight-Core Processor.
Kernel parameter "idle=nomwait" does not help, but the disable C6 script
does...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
(In reply to Another User from comment #463)
> I have random freezes with Ryzen 2200u laptop. Display image just freezes
> and system stops responding. Only way to get out from this state is to
> holding power button (even magic SysRq key does not work). No any clues in
> logs.
>
> With Ubuntu 18.
My understanding is that idle=nomwait disables the use of the MWAIT
instruction in the kernel implementation of the CPU idle state.
I also *think* that, under the hood, disabling C6 and the "Typical Power
idle" option also have a similar (or perhaps the same?) effect of
reducing the use of MWAIT.
(In reply to Michael from comment #459)
> I think this bug is mostly about the official AMD Errata 1109 "MWAIT
> Instruction May Hang a Thread".
>
> This is described here (
> https://developer.amd.com/wp-content/resources/55449_1.12.pdf ) as:
>
> "Under a highly specific and detailed set of inte
(In reply to Bráulio Bhavamitra from comment #460)
> (In reply to Michael from comment #459)
> > I think this bug is mostly about the official AMD Errata 1109 "MWAIT
> > (...)
> >
> > Question: Will the Linux kernel ever implement a workaround (as suggested
> by
> > AMD??
>
> idle=nomwait kernel
I think this bug is mostly about the official AMD Errata 1109 "MWAIT
Instruction May Hang a Thread".
This is described here ( https://developer.amd.com/wp-
content/resources/55449_1.12.pdf ) as:
"Under a highly specific and detailed set of internal timing conditions, the
MWAIT instruction may ca
Hi,
I have an ASUS A320M-K with latest BIOS 4027 (AGESA 1.0.0.6), Ryzen 7
2700, Patriot Viper RGB 16GB RAM 3200CL16, Samsung 830 SSD 128GB,
Corsair AX860 860W PSU (80+ Platinum) and ASUS ROG Strix RX480 8GB.
Running Arch Linux w/ Kernel 4.19.12 and GNOME 3.30 on Wayland. BIOS
configured to Default
@Weasel that's a different problem, that doesn't necessarily occur with
the same CPUs. This specific bug entry is about lockups that (to quote
the original message) "typically occur when the load is low".
For example, I've had several low-load lockups on my Ryzen 1700, I
haven't had a single high
You can test your ryzen with the program(It is currently no longer being
further developed by the developer): https://github.com/suaefar/ryzen-test
My 2200G shows no segfault, but "TIME TO FAIL: 885 s".
Under Windows 10 one Ryzen 2200G is freezing often under load for 20-30 seconds.
Another Ryze
That's not an AMD specific problem, I'm getting the same issue on a
Intel I7 8700
--
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 st
(In reply to Vladyslav Yamkovyi from comment #453)
> Let's face it: I really, really don't think measuring time before a freeze
> makes any sense. It just occurs under certain circumstances or even randomly
> due to some hardware bug - 4.19 will work 4 days for the first time, 3 hours
> for the sec
Let's face it: I really, really don't think measuring time before a
freeze makes any sense. It just occurs under certain circumstances or
even randomly due to some hardware bug - 4.19 will work 4 days for the
first time, 3 hours for the second time and 23 hours for the third.
That's for sure - it's
Well, 4.18.19 froze after four days.
4.19.7 froze in 3½ hours.
rcu_nocb_poll mem_encrypt=off nosmt=force
CONFIG_RCU_NOCB_CPU=y
CONFIG_PREEMPT_RCU=y
[12572.931476] watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
[(journald):18688]
[12572.931509] watchdog: BUG: soft lockup - CPU#4 stuck for 22s
With Ryzen 1600X + Radeon RX 550 + ASRock Taichi X370 I didn't have this bug
until 4.18.20. 4.18.18 had 12 days uptime and 4.18.20
(and 4.19.6) maybe 6 hours. 4.18.19 now has 56 hours uptime.
X just freezes (keyboard+mouse dead) and I have to press reset button.
Likewise, if I am in console, fr
>From the dupe bug report -
Gigabyte GA-AX370-Gaming K5 (latest UEFI - 2018/08/08)
AMD Ryzen 5 2400G
Running Arch Linux with 2018-10-26 linux-firmware and I still get soft
lockups and one other issue capable of freezing the system.
I'll try the 'Power Supply Idle Control' setting and see if that
*** Bug 201719 has been marked as a duplicate of this 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
(In reply to fin4478 from comment #447)
> (In reply to Owen Swerkstrom from comment #446)
>
> > BIOS updates should have their own boot images; how on Earth they can get
> > away with requiring a specific OS is all kinds of backwards.
> >
>
> Asus motherboards are the best, for Linux users espe
(In reply to Owen Swerkstrom from comment #446)
> BIOS updates should have their own boot images; how on Earth they can get
> away with requiring a specific OS is all kinds of backwards.
>
Asus motherboards are the best, for Linux users especially. You can
update the bios via the Ethernet conne
(In reply to fin4478 from comment #445)
> (In reply to Owen Swerkstrom from comment #443)
> I have no way to upgrade it since the upgrade tools require Windows.
>
> Win10 is free and runs freely forever. Download the iso file from ms site.
> Mount the iso file virtually and copy files to a gparte
(In reply to Owen Swerkstrom from comment #443)
I have no way to upgrade it since the upgrade tools require Windows.
Win10 is free and runs freely forever. Download the iso file from ms
site. Mount the iso file virtually and copy files to a gparted fat32
formatted and bootable usb memory stick.
(In reply to Vladyslav Yamkovyi from comment #433)
> (In reply to simonmcquire from comment #432)
> > But then realised I had not updated the amdgpu firmware...
>
> Does that means that the issue was already resolved and it's just distros
> being outdated? I haven't tried this solution yet but you
(In reply to simonmcquire from comment #436)
> (In reply to Eduardo Reyes from comment #435)
> > @simonmcquire
> >
> > Can you please clarify what this amdgpu firmware you are using is and what
> > for?
> > Are you flashing the video card?
> > Are you flashing the motherboard?
> >
> > Thanks in A
(In reply to Eduardo Reyes from comment #437)
> (In reply to simonmcquire from comment #436)
> > (In reply to Eduardo Reyes from comment #435)
> > > @simonmcquire
> > >
> > > Can you please clarify what this amdgpu firmware you are using is and
> what
> > > for?
> > > Are you flashing the video ca
...
> so there ! I guess "idle=nomwait" is "the workaround" ?
>
> "Typical Current Idle" appears to work for some (including me) but not for
> everyone. If one or more of these MWAIT errata is the root cause of the
> "freeze when idle" problem, I wonder why AMD introduced "Typical Current
> Idle
(In reply to Vladyslav Yamkovyi from comment #441)
> (In reply to Owen Swerkstrom from comment #439)
> > This comes up as a Linux problem, but it sure smells like a hardware defect
> > to me.
> Any system that does not provides a software workaround must be affected
> according to published errata,
I have an Asus ROG Strix GL702ZC notebook with Ryzen 7 1700 + Radeon
RX580 on Ubuntu 18.04. Kernel parameter "idle=nomwait" made no diference
to me. Idle freezes persists. The only thing that solved my problem was
to disable CPU C6 state through zenstates.py.
--
You received this bug notification
(In reply to Eduardo Reyes from comment #435)
> @simonmcquire
>
> Can you please clarify what this amdgpu firmware you are using is and what
> for?
> Are you flashing the video card?
> Are you flashing the motherboard?
>
> Thanks in Advance
No flashing of video card or motherboard here. I'm not
(In reply to Owen Swerkstrom from comment #439)
> This comes up as a Linux problem, but it sure smells like a hardware defect
> to me.
Any system that does not provides a software workaround must be affected
according to published errata, not even a question. I've published one of their
revision
I'm one of the users James mentioned early on; I don't know how to
capture kernel output when I'm greeted with a completely-locked-up or
already-rebooted machine. If it's hardware, I don't see what the kernel
could do anyway.
I've tried all the tricks mentioned here, when applicable. (My BIOS
do
> Has anyone run *BSD or FreeDOS or something else which would allow a Ryzen to
> get bored for hours/days?
Yes, FreeBSD is affected too
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-BSD-Lock-
Ups-2018
--
You received this bug notification because you are a member of Kernel
Packages,
(In reply to simonmcquire from comment #432)
> But then realised I had not updated the amdgpu firmware...
Does that means that the issue was already resolved and it's just
distros being outdated? I haven't tried this solution yet but you're not
the only one who is saying that the problem can be so
(In reply to Klaus Mueller from comment #427)
> (In reply to JerryD from comment #426)
> > I am on Ryzen 2500U Laptop, HP. I am using kernel 4.18.9-200.fc28.x86_64.
> >
> > The zenstates.py script fails when I try to disable C6. Oh well.
>
> Did you load msr kernel module before (modprobe msr)?
>
I had this same bug in June 2018 and in the beginning of July 2018. It
seems to be solved for me by " Look in BIOS settings for "PSU Idle
Control" and set it to "Typical Current Idle" "
The bug was appearing about a few days (2-7) in low usage mode.
I was using openSUSE Leap 15.0 before this and
Want to share this in case it helps anyone else. I stumbled across this
issue after putting together a new Ryzen 2200G HTPC with AsRock AB350
M-ITX mainboard a few weeks ago. Would encounter random freezes every
couple of hours.
After updating UEFI to latest version, updating kernel to latest
4.
The root cause of the "freeze when idle" appears to be a fault in the
mechanism which wakes the CPU up once it has gone into the deepest of
deep sleeps.
Mr AMD has pointed the finger at PSUs which fail to maintain the correct
voltage when the current draw approaches 0A. Between the PSU and the
CP
(In reply to Michael from comment #423)
> So, I'm running Ubuntu 18.04 stock kernel with
> - Typical Current Idle
> - disabling global c-states
> - idle=nomwait kernel parameter
>
> and have no freezes for 8 Days now - new record. So it looks like I can
> confirm what Nelson Castillo mentioned in
@simonmcquire
Can you please clarify what this amdgpu firmware you are using is and what for?
Are you flashing the video card?
Are you flashing the motherboard?
Thanks in Advance
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in U
(In reply to JerryD from comment #426)
> I am on Ryzen 2500U Laptop, HP. I am using kernel 4.18.9-200.fc28.x86_64.
>
> The zenstates.py script fails when I try to disable C6. Oh well.
>
> I have kernel parameters: idle=nomwait processor.max_cstate=5
>
> I still get lockup. No BIOS settings avail
I am on Ryzen 2500U Laptop, HP. I am using kernel
4.18.9-200.fc28.x86_64.
The zenstates.py script fails when I try to disable C6. Oh well.
I have kernel parameters: idle=nomwait processor.max_cstate=5
I still get lockup. No BIOS settings available on this mavhine.
Feel pretty hopeless at the mo
So, I'm running Ubuntu 18.04 stock kernel with
- Typical Current Idle
- disabling global c-states
- idle=nomwait kernel parameter
and have no freezes for 8 Days now - new record. So it looks like I can
confirm what Nelson Castillo mentioned in comment #419
This seems ok now. Now I need to verify
So what are the implications of using idle=nowait and why isn't it a
standard behaviour for all Ryzen CPU going forward?
--
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:
Ryz
(In reply to JerryD from comment #426)
> I am on Ryzen 2500U Laptop, HP. I am using kernel 4.18.9-200.fc28.x86_64.
>
> The zenstates.py script fails when I try to disable C6. Oh well.
Did you load msr kernel module before (modprobe msr)?
Do you have the possibility to slightly overclock? Isn't t
Hi,
update from me, as promised. First my system for reference:
2700X
B450 Chipset - Gigabyte B450 AORUS PRO with F2 BIOS
PSU from 2018 which is "Haswell compatible".
Typical Current Idle AND disabling global c-states didn't help.
Running Ubuntu 18.04 LTS with its stock kernel 4.15.0-34 right now
(In reply to Michaël Colignon from comment #420)
> ...
> I want to add another thing, about fixing it directly from the kernel.
> As typical idle current seems (i am testing it again for see) not needed
> under the other OS, that's because the core parking under this other OS is
> partially disable
Michael, with all that enabled also try the " idle=nomwait " kernel
option If the upgrade to F2 doesn't work.
I have a similar BIOS and the same CPU. I had to enable all what you did
but this wouldn't work without idle=nomwait. See my post above.
--
You received this bug notification because you
Hi, another Michael here.
The typical idle current fixed the trouble, if you have still freeze under low
load after it's:
a bug in the uefi that doesn't really apply the "typical idle
current"(disabling partially core parking).
another problem than the one on this thread.
I want to add another
Sorry guys, typical Current Idle doesn't fix it for me.
I can't believe this is not yet nailed down. I kinda lost believe in the
AMD comeback.
I do have this issue.
My setup is a 2700X on a Gigabyte B450 AORUS PRO.
I did hunt this freeze issue down to the behaviour decribed here: System
is sudd
The situation is incredible, in that there doesn't (seem) to be a
concrete sure fire solution to this.
If there's a BIOS option, which can fix it, it should damn well be put
MANDATORY in all BIOS - not an option, locked in. System stability
should not be this unreliable.Especially now they're
Haven't had a single lockup after update to Kernel 4.15 and setting the
BIOS to typical idle current setting. Have run the PC for few days and
no issues nor any lock up under heavy CPU use.This is a ASUS B350M board
with latest BIOS on Ryzen 1700.
--
You received this bug notification because you
I erred earlier in suggesting that this bug should be closed with
"fixed". Rather, this bug should should be closed with "notabug" because
there appears to be no evidence to suggest that it is actually a kernel
bug, compared to considerable evidence suggesting it is not.
Meanwhile, I personally
So still no concrete 100% sure fire solution?
Incredible.
--
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
Sta
Who knows ?
When I say that "Typical Current Idle" appears to eliminate the "freeze
when idle" problem, I mean that (a) that is my experience (to date), and
(b) I have seen others reporting similar experience.
I'm not aware of any public, definitive information from AMD, any
motherboard vendor or
It appears that selecting the "Typical Current Idle" BIOS option (where
available) eliminates the "freeze when idle" problem (somehow).
That said, it also appears that this is *not* the default.
The need for the option appears to be Linux specific, or at least it is
not needed for W*nd*rs.
That
Unfortunately, setting the governor to performance doesn't fix the issue
here (Ryzen 7 1700, ASRock Fatal1ty X370 Gaming X).
--
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:
I have an Asus ROG Strix GL702ZC notebook with Ryzen 7 1700 + Radeon
RX580, and I have soft lockups too. The computer completly freeze when
idle. My system is an Ubuntu 18.04.1. Kernel parameters like
"idle=nomwait" and "rcu_nocbs=0-15" don't fix my problem. Now, I'm using
my computer "without lock
(In reply to Antoine Pitrou from comment #398)
> @Daniel what makes you think this bug is fixed? It certainly isn't for me.
> I have a ASRock Fatal1ty X370 Gaming X motherboard, a Ryzen 7 1700 CPU, have
> updated the motherboard BIOS to its latest version (4.80 with
> PinnaclePI-AM4_1.0.0.2 Patch
(In reply to Antoine Pitrou from comment #407)
> (In reply to Michaël Colignon from comment #400)
> >
> > Hi Antoine, i checked the manual of your Asrock motherboard quickly.
> > For your machine the "typical idle current" is named "c6 mode"
> > Disable it and you get the "typical idle current", i
@Paul I understand this. I'm also monitoring the corresponding Ubuntu
issue. Still, I was asking whether there was a specific reason to
believe this bug was fixed upstream (as opposed to the fact that a
single person doesn't experience the issue anymore).
--
You received this bug notification be
The title of the bug should be changed to include Ryzen 7 1700X, and the
reporter should follow up, if the problem still occurs with Linux 4.18.
For the other issues, separate bug reports should be submitted. Though
the mailing lists might be the better forum for this, as the Linux
kernel develope
(In reply to Michaël Colignon from comment #400)
>
> Hi Antoine, i checked the manual of your Asrock motherboard quickly.
> For your machine the "typical idle current" is named "c6 mode"
> Disable it and you get the "typical idle current", i think.
> While keeping the boost monothread.
Hi Michaël
I don't think there is any reason to think that the "c6 mode" option had
anything to do with "typical idle current". Its name implied that it
disabled C6 states, which it actually didn't (according to the Zenstates
script).
--
You received this bug notification because you are a member of Kernel
(In reply to Antoine Pitrou from comment #398)
> @Daniel what makes you think this bug is fixed? It certainly isn't for me.
> I have a ASRock Fatal1ty X370 Gaming X motherboard, a Ryzen 7 1700 CPU, have
> updated the motherboard BIOS to its latest version (4.80 with
> PinnaclePI-AM4_1.0.0.2 Patch
To anyone applying the BIOS/CONFIG_RCU_NOCB_CPU/ZenStates solution
together with the idle=nomwait solution, I believe this is unnecessary
as these are different problems relating to different CPUs. The former
worked for my Ryzen 5 1600X, while only the latter worked for my much
newer Ryzen 7 2700U
(In reply to Daniel Phillips from comment #397)
> This bug should be closed as "FIXED" in my humble opinion. "NEW" is grossly
> inaccurate.
>
> My workstation uptime is now 109 days, continuous operation without suspend,
> mainly idle, mixed with episodes of heavy load on all cores and everything
@Daniel what makes you think this bug is fixed? It certainly isn't for
me. I have a ASRock Fatal1ty X370 Gaming X motherboard, a Ryzen 7 1700
CPU, have updated the motherboard BIOS to its latest version (4.80 with
PinnaclePI-AM4_1.0.0.2 Patch A) and am still getting idle lockups with
kernel 4.15.
Hello there. I read most of the thread a week ago.
My machine was freezing when idle and when not idle. I read most of this
thread and thanks to it got a stable setup.
@Daniel: When you say that you think the problem is fixed, do you know
what change/Linux version fixes the issue for most people?
The "freezing while idle" problem does appear to be (at least) worked
around by the "Typical Current Idle" option. If that counts as a fix,
then the bug is fixed -- or rather, was never a Kernel Bug.
The "Random Soft Lockup" -- the nominal subject of the bug -- on the
other hand... who can tell ?
This bug still occurs for me with 4.15.0-32-generic (Ubuntu 18.04.1) if
I don't disable C6 states.
--
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_
This bug should be closed as "FIXED" in my humble opinion. "NEW" is
grossly inaccurate.
My workstation uptime is now 109 days, continuous operation without
suspend, mainly idle, mixed with episodes of heavy load on all cores and
everything in between. The technical term for this is "spectacularly
I have Ryzen 7 1800X on Asus Prime X370-Pro. I upgraded the BIOS to
v4011(Update AGESA 1.0.0.2a + SMU 43.18) and:
1) turned on the "Typical Current Idle" option.
2) stopped using zenstates.py -- which I had been using to enable "C6 Core"
but disable "C6 Package" (to no avail).
3) di
(In reply to OptionalRealName from comment #393)
> There still does not appear to be a single consistent solution to this
> problem and it exists in Ryzen 1xxx and 2xxx series.
Actually, there are several workarounds known to work listed in this
thread.
I've been running a stable x1800 using the
> It's a nuanced hard to troubleshoot bug in a processor + support chipsets
> with a known workaround which only seems to happen on Linux... not really
> sure how that is "embarrassing". It sucks, it's new silicon. Welcome to
> being an early adopter.
Thread Reported:2017-08-16 19:05 UTC
(In reply to ValdikSS from comment #391)
> These lockups are probably not related to this bug. I've updated by Intel
> Sandy Bridge laptop to 4.17.5 from Fedora 28 repository and now I have
> random CPU lockups, too.
> 4.17.3 worked fine.
Please take a look at this report, it matches your descript
** Bug watch added: Red Hat Bugzilla #1598989
https://bugzilla.redhat.com/show_bug.cgi?id=1598989
** Bug watch added: Red Hat Bugzilla #1598462
https://bugzilla.redhat.com/show_bug.cgi?id=1598462
--
You received this bug notification because you are a member of Kernel
Packages, which is su
There still does not appear to be a single consistent solution to this
problem and it exists in Ryzen 1xxx and 2xxx series.
Apparently not in the Epyc series, is that correct?
This thread is utterly embarrassing for AMD, truly embarrassing.
--
You received this bug notification because you are
These lockups are probably not related to this bug. I've updated by Intel Sandy
Bridge laptop to 4.17.5 from Fedora 28 repository and now I have random CPU
lockups, too.
4.17.3 worked fine.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
I'm watching this thread since February. My first stable workaround with
legacy BIOS-Mode was the kernel parameter rcu_nocbs=0-15 because the
BIOS didn't have the "Typical Current Idle" Option.
Systeminfo
R7 1700, GA AX370-Gaming K7 with BIOS F23f in legacy mode, PSU Corsair HX750,
OS Gentoo Linu
I have the ASUS B350M board and I updated to latest BIOS 4014 but my
lock ups started with the latest kernel 4.17 in Arch where the lock up
bug reappeared. I have set the idle current setting to typical and so
far no lock up in two days, lets see what happens in few days. Keeping
my fingers crossed
idle=nomwait fixed all hangs (from
https://community.amd.com/thread/224000
--
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
Interestingly,
I had a nicely running system, uptime about 30 days, and I just decided
to upgrade the Kernel to the latest (Fedora 28), and "what the heck" I
will just upgrade the motherboard BIOS too.
Mobo: ASUSTeK model: PRIME B350M-A
6 core AMD Ryzen 5 1600X Six-Core (-MT-MCP-) arch: Zen rev.1
(In reply to Robert Hoffmann from comment #386)
> Interestingly,
>
> I had a nicely running system, uptime about 30 days, and I just decided to
> upgrade the Kernel to the latest (Fedora 28), and "what the heck" I will
> just upgrade the motherboard BIOS too.
>
> Mobo: ASUSTeK model: PRIME B350M-
Did the ppl with the new BIOSes double test the 'Power Supply Idle
Control' option by disabling it temporary? Because, it could also be
fixed by that Agesa update some of you mentioned (also mentioned in [1])
tl;dr:
Had soft lockup at full load, BIOS-update seems to help, but it doesn't have
the
Adding to the confusion here:
I'm running a Ryzen 1700 on Asus PRIME B350-PLUS motherboard and on BIOS
version 4011 I have the "Power Supply Idle Control" option and I have
changed it from "Auto" to "Low Current Idle" a week or so ago and after
that I have had zero lockups.
According to this bug
Created attachment 277137
attachment-17307-0.html
Yep, typical current parameter in your UEFI
If not there, update it
De : bugzilla-dae...@bugzilla.kernel.org
Envoyé : Monday, July 2, 2018 11:12:26 AM
À : ledesillusionni...@hotmail.com
Objet : [Bug 196683] Rando
I have finally gotten to stable (no soft lockup). Asus released the 0702
bios which includes Agesa update 1.0.0.2c. Typical Current is set to
enabled within the bios. No other special kernel command-line options
are enabled.
Machine:
* Kernel 4.7.13
* AMD Ryzen 2700X
* SuperNOVA 650 G3 650W (
(In reply to Alexandre Badalo from comment #379)
> Is there any workaround/solution for this bug? With this problem i can't
> reliably have the PC running as a server :(
>
> The bug is almost 1 year old
People need to contact AMD, it's ridiculous this is still ongoing.
--
You received this bug
There are two solutions or workarounds that have been reliable for me,
one of which I now trust more than the other.
First, if your BIOS has the option for 'Power Supply Idle Control'
hiding somewhere in its settings (generally in a sub-menu off an
'advanced' menu), setting it to 'Typical current
301 - 400 of 514 matches
Mail list logo
