(In reply to Charles Lim from comment #673)
> For those who are looking for a solution or already found a solution, there
> is a new update of AGESA rolling out. The new version 1.0.0.4 claims:
>
> * Improved system stability when switching through ACPI power states.
>
> It has arrived on my Asu
Hi folks!
For those who are looking for a solution or already found a solution, there is
a new update of AGESA rolling out. The new version 1.0.0.4 claims:
* Improved system stability when switching through ACPI power states.
It has arrived on my Asus PRIME B350M days ago, I have upgraded and
(In reply to hoper from comment #33)
> Just a small message to say "me too". I spend the last 4 months spending a
> lot of time and money to change the motherboard, the cpu, the power...
> Before doing research and find that these freezes are software related :(
>
> I tried (and manage) to compile
The COVID-19 pandemic is posing an unprecedented threat to EU/EEA
countries and the UK, which have been experiencing widespread
transmission of the virus in the community for several weeks. In
addition, there has been an increasing number of reports of COVID-19
outbreaks in long-term care homes acr
do all that instrumentation on an affected system.
source: https://Getnaijamusic.com
--
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 detect
Dancehall music, also called ragga or dub, style of Jamaican popular
music that had its genesis in the political turbulence of the late 1970s
and became Jamaica’s dominant music in the 1980s and ’90s. Central to
dancehall is the deejay, who raps, or “toasts,” over a prerecorded
rhythm track (bass g
** Changed in: linux
Status: Confirmed => Expired
--
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
Statu
I as the thread starter fully agree with Borislav and set this bug
report to status resolved. Thank you all very much for the interesting
discussion!
Having started with massive stability problems on my new Ryzen build, I
reported this issue to address a potential problem in the Linux kernel.
In t
I really loves this site I give the ceo of this site really deserves an
accolades. Well done for the hard and and smart work got this site. Don forget
to [url=https://naijaflash.com.ng/]I love this ![/url]
[url=https://intrumentalfreebeats.com/]I love this
![/url][url=https://fulloaded.ng/]I lov
I really loves this site I give the ceo of this site really deserves an
accolades. Well done for the hard and and smart work got this site. Don
forget to https://intrumentalfreebeats.com";> latest
Instrumental and freebeats for 2020 https://naijaflash.com.ng";> download latest 2020 songs https://fu
The bug here in question is still up again but I later noticed that I've
mixed up some old files and it popped from no where disturbed me for
about a week untill i finally reached out to a friend who helped me
cleared that, but anyway thanks for the suggestions here.
https://abokiplay.com
--
You
(In reply to Michaël Colignon from comment #660)
> (In reply to eric.c.morgan from comment #659)
> > I applied the latest asrock BIOS with new options "amd cbs global c-state
> > control" to disable voltage lowering when idle.
> >
> > Even with all BIOS settings, custom kernels and params, disabli
Folks,
this bugzilla entry, with the amount of different issues reported and
the amount of FUD all collected in one place, is prohibitively hard for
a debugger to handle. So, I'd suggest if you still would like your issue
looked at, to open a separate bug.
And please refrain from commenting on a
> Likely not bad hardware. My 1700 was RMAd for the segfault issue (another
> pain point), and has passed all testing. Memory has been tested as well,
> many times over, with different profiles and settings.
>
I also had my 1600 RMAd, but still I experience hangs now and then. I
have the impressi
(In reply to Michaël Colignon from comment #660)
> (In reply to eric.c.morgan from comment #659)
> > I applied the latest asrock BIOS with new options "amd cbs global c-state
> > control" to disable voltage lowering when idle.
> >
> > Even with all BIOS settings, custom kernels and params, disabli
(In reply to eric.c.morgan from comment #659)
> I applied the latest asrock BIOS with new options "amd cbs global c-state
> control" to disable voltage lowering when idle.
>
> Even with all BIOS settings, custom kernels and params, disabling C states,
> power supplies and so forth I'm done. 2 year
** Bug watch added: Linux Kernel Bug Tracker #205017
https://bugzilla.kernel.org/show_bug.cgi?id=205017
--
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 freez
I applied the latest asrock BIOS with new options "amd cbs global
c-state control" to disable voltage lowering when idle.
Even with all BIOS settings, custom kernels and params, disabling C
states, power supplies and so forth I'm done. 2 years of this BS.
I picked up a 65 watt Intel i9 9900.
Goo
Ever since upgrading to a Ryzen (1700X), I have experienced frequent
system freezes, which may be related to the problems discussed here.
The freeze mostly happens during a certain heavily threaded task with
disk io.
Symptoms:
* Screen completely freezes, including mouse pointer,
* Existing SSH
Since I set up remote console logging and upgraded my BIOS (again), I have not
seen the hang anymore.
Although I like this, I still have no more clues about the initial
trace/problem.
FYI
I am running on a
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: PRIME B450-PLUS
(In reply to Jaap Crezee from comment #655)
> Could this be related?
>
> [620533.9804061 RBP: R08: 0001 R09:
> 7f901480 [620533.981792] R10: 7f9014de0270 R11: 0206
> R12: 7f90477fdlfe [620533.983039] R13: 7f90477fdlff R14:
> 7f901fff
Could this be related?
[620533.9804061 RBP: R08: 0001 R09:
7f901480 [620533.981792] R10: 7f9014de0270 R11: 0206
R12: 7f90477fdlfe [620533.983039] R13: 7f90477fdlff R14:
7f901700 R15: 7f901fffe540 [620541.767819] watchdog:
https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip -
download, extract, launch ./test-rdrand and check if produces something
different than 0x
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
htt
(In reply to txrx from comment #651)
Typical Current Idle might not be working. Read the sensor output. If
voltage is not higher than without enabling it, try to increase the core
voltage.
My Ryzen 7 1800X seems to not produce hangs since I upgraded to 1003ABB
with an ASUS Crosshair VI Hero and e
(In reply to txrx from comment #651)
> I was able to update my BIOS to version 18, but my system still locks up.
> I tried the following with the new BIOS:
> - use factory defaults
> - disable SMT
> - disable SMT with Typical Current Idle
> - all of the above with SVM disabled/enabled
> Right n
I was able to update my BIOS to version 18, but my system still locks up.
I tried the following with the new BIOS:
- use factory defaults
- disable SMT
- disable SMT with Typical Current Idle
- all of the above with SVM disabled/enabled
Right now I set the power supply idle control to "Low ..."
I have freezes in ryzen 7 2700u in the acer swift sf315-41 model,
kernels tested, 5.2
--
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 detecte
> Sep 10 21:13:56 BelliashPC kernel: Workqueue: 0x0 (events)
> Sep 10 21:13:56 BelliashPC kernel: RIP: 0010:worker_thread+0xfc/0x3b0
> Sep 10 21:13:56 BelliashPC kernel: Code: 0f 84 8e 02 00 00 48 8b 4c 24 18 49
> 39 4f 38 0f 85 a9 02 00 00 83 e0 fb 41 89 47 60 ff 4a 34 49 8b 17 49 8b 47
> 08 48 8
Sep 10 21:13:56 BelliashPC kernel: BUG: kernel NULL pointer dereference,
address: 000d
Sep 10 21:13:56 BelliashPC kernel: #PF: supervisor write access in kernel mode
Sep 10 21:13:56 BelliashPC kernel: #PF: error_code(0x0002) - not-present page
Sep 10 21:13:56 BelliashPC kernel: PGD 0 P
This happened also w/o vbox (I installed it few days ago) and nvidia
proprietary drivers. I used to use nouveau with the same results. I will
open a new ticket.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.
And another example of calltrace:
Sep 5 21:25:32 BelliashPC kernel: NMI backtrace for cpu 1
Sep 5 21:25:32 BelliashPC kernel: CPU: 1 PID: 13564 Comm: DOM File Tainted: P
DOT 5.2.11-gentoo #1
Sep 5 21:25:32 BelliashPC kernel: Hardware name: Gigabyte Technology Co., Ltd.
B450 AORUS
Hi, i bought Acer Aspire 3, A315-41G, Ryzen 5 2500U in January and since
then i had CPU lock up, i manage to install arch but i got CPU lockUP on
every second boot, on every other distribution i got CPU lockUP in
installer...i never use C6 disable script, but i try all possibile
kernel parameters a
After one year, I am finally using my 2700x without any issues, latest
Ubuntu 18.04, Linux 5.0.0-27-generic. No patches, no kernel options. I
put the system to sleep everyday and it always comes back when I press a
key the next day.
I updated the BIOS of the AB350M-DS3Hto F31, the most recent upda
I've been lightly following this thread, but it is still a seemingly
unresolved issue that impedes me from using Linux. Has there been any
real progress on this? Or is the resolution still a vague 'we more or
less know where the issue is but we're still waiting for someone
upstream to take action t
I have a 2700X on MSI X470 Gaming Plus. Update the BIOS to support my
new 3800X also fixed this issue to me. Both CPUs are works well on
Debian Buster without any extra kernel parameter and without disable C6.
--
You received this bug notification because you are a member of Kernel
Packages, whic
** Bug watch added: Red Hat Bugzilla #1738650
https://bugzilla.redhat.com/show_bug.cgi?id=1738650
--
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 - rc
(In reply to raulvior.bcn from comment #635)
ASUSTeK COMPUTER INC. CROSSHAIR VI HERO 7403 08/20/2019
AMD Ryzen 7 1800X Eight-Core Processor
16410MB
2560x1440 pixels
Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 5.0.0-25-generic, LLVM 8.0.0)
Linux 5.0.0-25-generic (x86_64) #26-Ubuntu SMP Thu Aug 1 12
(In reply to raulvior.bcn from comment #634)
Ah, yes. I forgot to add kernel version:
Linux 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64 x86_64
x86_64 GNU/Linux
> My system reboots randomly, mostly at idle. I have tried the 'powersupply
> idle' UEFI option, but it didn't wo
I'm not using any other workarounds in conjunction with `nordrand`.
Perhaps try upgrading to the new BIOS. Note also that my kernel version
differs from yours, but it seems unlikely (though possible) that there's
a regression across those versions.
--
You received this bug notification because yo
(In reply to raulvior.bcn from comment #637)
I got a reboot with the ondemand governor at 1d 14h of uptime.
I have reactivated the Typical Power Supply idle switch. Currently 4 days and 2
hours of uptime. The longest I've ever seen.
The minimum voltage reported by the UEFI is 0.83 V. Using the
p
(In reply to linuxannoyance from comment #618)
After I posted this comment, I have not had any more random crashes. I disabled
Global C-States in my motherboard's firmware, as that was the only option
relating to C-states (C-6 states not being available). Based on my experience
and other comment
Sehr geehrte Damen und Herren,
vielen Dank für Ihre Nachricht, die ich nach dem 26. August 2019 lesen werde.
Freundliche Grüße
Paul Menzel
---
Dear Madam or Sir,
Thank you for your message, I’ll read after my return on August 27th, 2019.
Kind regards,
Paul Menzel
--
You received this
As @C0rn3j mentioned, I'm in a similar boat. With a Ryzen 3700x, I
continue to get the following errors:
```
rcu: INFO: rcu_sched self-detected stall on CPU
...
watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kworker/1:1:94]
```
I've tried just about every workaround that I've read about:
* D
Anyone here seeing this one: Bug 1738650 - Kernel 5.2.5 graphics
unstable
https://bugzilla.redhat.com/show_bug.cgi?id=1738650
Everytning working great as long as I stay on
kernel-5.1.20-300.fc30.x86_64
--
You received this bug notification because you are a member of Kernel
Packages, which is s
Released 3rd generation of ZEN and this strange thing still persist. So
"No fix planned" was not a lie...
Kernel parameter idle=halt fixed my problem for R3 2200u (no lockups for 7
months). You may give it a try.
...just to remind.
--
You received this bug notification because you are a member
(In reply to zheilbron from comment #624)
> As @C0rn3j mentioned, I'm in a similar boat. With a Ryzen 3700x, I continue
> to get the following errors:
>
> ```
> rcu: INFO: rcu_sched self-detected stall on CPU
> ...
> watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kworker/1:1:94]
> ```
>
> I'
(In reply to OptionalRealName from comment #616)
> No 3000 owners yet? Is it safe to buy?
I have one, but I am going to return the laptop I think, it works as
expected but in terms of battery ryzen in linux sucks
PD: windows 5 W in idle
Linux, 12 W in idle in the same laptop with kernels 5.0 5.1
So since October of last year I was having problems with my Arch + KDE
build freezing at idle on my 2700X build. Usually freezes occur while a
YouTube or Twitch video is playing. When it freezes, it would often also
cause whatever audio that is playing to loop over and over. Journalctl
would have n
My experience -
Bought 2400G and 3600. Both CPUs had lockups and no UEFI settings and messing
with C states helped.
What helped was RMA in both cases, the RMA'd CPUs do not have lockups.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to li
Asrock Fatal1ty X370 Gaming-ITX/ac
Ryzen 1700
After the most recent Asrock BIOS update I haven't had any more
crashing. I do not disable C6 anymore. This was a BIOS update to support
the new Ryzen 3xxx chips as I was eyeing the 3900x and wanted the
motherboard to support said chip if I had a weak
Sorry, just to clarify my above comment (since there doesn't appear to
be any way to edit my comment).
1. Freezes usually occur while the system is being left alone, but I
noticed that it would also often occur while a YouTube video, Twitch
stream or even music (via Clementine) was left playing in
My system reboots randomly, mostly at idle. I have tried the
'powersupply idle' UEFI option, but it didn't work. I have changed
motherboard, RAM and PSU, but it still reboots/crashes, doesn't matter
if it's overclocked or not. The system is not reliable.
Currently an ASUS CROSSHAIR VI HERO, BIOS 7
Sehr geehrte Damen und Herren,
vielen Dank für Ihre Nachricht, die ich nach dem 26. August 2019 lesen werde.
Freundliche Grüße
Paul Menzel
---
Dear Madam or Sir,
Thank you for your message, I’ll read after my return on August 27th, 2019.
Kind regards,
Paul Menzel
--
You received this
Reporting back as I said I would: with `nordrand` set as a kernel boot
parameter, the system is stable.
--
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 zheilbron from comment #630)
> Reporting back as I said I would: with `nordrand` set as a kernel boot
> parameter, the system is stable.
Are you using nordrand in combination with other workarounds (BIOS settings,
ZenStates)?
My hardware specs are identical and my system still freeze
--- snip ---
> It seems that leaving the machine idle does not produce the issue. However,
> connecting over Wireguard + SSH (which is how I had been accessing the
> machine) seems to cause the issue to manifest. After following the advice
> here (https://bbs.archlinux.org/viewtopic.php?id=247900),
(In reply to OptionalRealName from comment #616)
> No 3000 owners yet? Is it safe to buy?
Google for linux benchmarks, etc. You will find people are running these
things. There is one bios update push I read about regarding some
windows related thing. I plan to buy a 3000 series setup soon. No fea
Currently running ASRock AB350M Pro4 + Ryzen 1600
Ever since I updated BIOS to 5.50 and set "Typical Current Idle" setting
(couple months ago) I haven't had a single hang.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
h
I have to kind of wonder, doesn't AMD like, want to sell these chips (in
Epyc) to server farms? Ones that will run Linux? Or do Epyc/TR just not
have this problem? My experience with this bug has been a bit bizarre,
especially since AMD's GPUs have really great Linux support these days.
My report:
No 3000 owners yet? Is it safe to buy?
--
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:
Conf
** Tags added: cscc
--
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 lin
FWIW: I have an ASUS Prime 370-Pro, Ryzen 7 1800X, currently running
Kernel v5.0.17.
With "Typical Current Idle", and no kernel tweaks, that has run without
"freezing while idle" for about a year.
Yesterday I upgraded the BIOS, which for some reason reset the "Power
Supply Idle Control" to "Auto"
So when do we get our first post, with the same problems, from X570
users, with Ryzen 3600 / 3600x / 3800 etc?
I'm very curious to know if this issue magically is gone on the next
series.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to li
No workarounds fixed my 2400G lockups.
I RMAd the CPU (got a new one) and motherboard (because the firmware killed
itself) and got it repaired.
Since then I didn't have a single lockup with all the workarounds
disabled, so
I'd say that CPUs before some certain time period were possibly
manufactu
AMD has released a new version of AGESA Combo-AM4 1.0.0.3 for my
motherboard MSI B450 Gaming Plus and others. There were also updates of
the CPU microcode.
The first (#1) on the list for example is Ryzen 2600, old and new bios,
comparison of the microcode version:
OLD bios
╔══
My two (server) machines running 1600's are also not experiencing
problems any more using new BIOSes + 4.19 kernels + "Typical current
bullshit". Hence I tend to agree that for most people the issue is
solved.
However Trevor I'm mostly posting to let you know ECC works fine, at
least with ASRock b
As I mention around Comment 485 and later (starting Jan 22), for us we
have nearly the same computer and after setting BIOS to current idle as
you did, all of our problems disappeared. Haven't messed with it since.
That's 4 months of uptime, zero hangs, zero crashes.
I'd bet everyone who was here
I think I experience the same problem as described here with my recently
built Ryzen computer. After installing a fresh Linux distribution I
started out with Linux kernel 4.19.45. The computer ran for two days
continuously, after a short pause I came back and saw it completely
froze. Screen showed
(In reply to onox from comment #607)
To prevent misunderstandings, let me repeat what I previously wrote,
from a different angle: ASRock X370 Taichi firmware version v5.50 is
worse than previous versions in that it removes the "Power Supply Idle
Control" option off the configuration screen. As a r
(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 S
So Ryzen 3000 is coming, who will be the first guinea pig?
Curious to see if this problem is mysteriously, entirely fixed on the
3000 series.
(I damn well hope so)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://
(In reply to Liu Liu from comment #597)
> Some updates since I last posted. I've updated to gcc-8 and enabled
> idle=halt. Even though idle=halt + gcc-7 with the original reprod steps can
> still cause a lockup. By defaulting to gcc-8 and idle=halt, in day-to-day
> uses, I haven't encountered any s
(In reply to Arup from comment #604)
> AMD issued a new ucode few days back. Anyone using that, it updated
> automatically on my Arch system.
For me this update that came yesterday on Arch did not change the microcode
version at all! Seems like there is no update for my processor.
Before (and sti
AMD issued a new ucode few days back. Anyone using that, it updated
automatically on my Arch system. I havent had the lock up issue on my
ASUS B350 board with latest BIOS and option of system idle current
checked.
--
You received this bug notification because you are a member of Kernel
Packages,
(In reply to OptionalRealName from comment #599)
> This embarrassing problem persists, will it be fixed on the new 3000 series,
> due in the next few months? Does anyone out there have access to this
> hardware?
>
>
> Very close to the 2 year anniversary of this issue and there's still no 100%
>
This bug bugs me so much, that I registered to kernel bugzilla.
I tried many workarounds, nothing solved it.
Machine: ThinkPad A485 with AMD 2500U.
System:
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename: disco
Kernel: Linux kni 5.0.0-13-generic #14-Ubuntu
(In reply to Liu Liu from comment #597)
--- snip --
> Some updates since I last posted. I've updated to gcc-8 and enabled
> idle=halt. Even though idle=halt + gcc-7 with the original reprod steps can
> still cause a lockup. By defaulting to gcc-8 and idle=halt, in day-to-day
> uses, I haven't encou
(In reply to JerryD from comment #598)
> (In reply to Liu Liu from comment #597)
> --- snip --
> > Some updates since I last posted. I've updated to gcc-8 and enabled
> > idle=halt. Even though idle=halt + gcc-7 with the original reprod steps can
> > still cause a lockup. By defaulting to gcc-8 and
It may be originally a hardware issue, but I am sure it does not affect
Windows, so it should be fixable in kernel code. I am not even sure if
the problem was present on Windows at all.
I can reproduce it with 100% success anytime I want.
--
You received this bug notification because you are a m
This bug bugs me so much, that I registered to kernel bugzilla.
I tried many workarounds, nothing solved it.
Machine: ThinkPad A485 with AMD 2500U.
System:
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename: disco
Kernel: Linux kni 5.0.0-13-generic #14-Ubuntu
This embarrassing problem persists, will it be fixed on the new 3000
series, due in the next few months? Does anyone out there have access to
this hardware?
Very close to the 2 year anniversary of this issue and there's still no 100%
clear solution outlining how to fix the problem.
--
You rece
(In reply to Liu Liu from comment #585)
> Created attachment 282319 [details]
> Threadripper 2920x soft lockup
>
> I've went through this thread, and tried to disable c6 state, add idle=halt
> with no effect. Followed this excellent reprod steps in
> https://www.reddit.com/r/Amd/comments/apw8im/
>
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.
(In reply to Philip Rosvall from comment #593)
> Since 5.0.10, and this commit ...:
>
> (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.10)
> "commit 205c53cbe553c9e5a9fe93f63e398da7e59124b6
> Author: Thomas Gleixner
> Date: Sun Apr 14 19:51:06 2019 +0200
>
> x86/speculation: P
(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 S
(In reply to Brendan Long from comment #589)
> I strongly suspect that the graphics driver was the problem since my lockups
> would cause the screen to become completely unresponsive, but sound
> continued working, and in one case I had a lockup during a video call and
> the other person could stil
(In reply to Brendan Long from comment #589)
>
> I eventually did a from-scratch reinstall of Fedora 29 and it suddenly just
> works (for 10+ hours, I don't leave my machine on overnight). Once it
> started working, I set everything back to the defaults except for "Typical
> Current Idle" (since I
I ran into similar problems to this with a Threadripper 1950X and none
of the proposed workarounds did anything. Disabling C6 in the BIOS made
it fail to boot for some reason. Setting "Typical Current Idle" in the
BIOS, processor.max_cstate=1 in the kernel command line, or disabling C6
with ZenStat
I have a couple of Threadrippers (1950X) that also hang under very
specific workloads with a Asus X-399-A motherboard. In my case when the
freeze happens the only way to get the machine back is to unplug it from
the wall and plug it back. Not even reset works.
After many tweaks, I found out that I
Hey, Klaus,
My understanding of that issue is it only affects Ryzen 1700 / 1700x and
doesn't affect Epyc / TR line. I am on ThreadRipper 2920x, which should
be out of marginality problem for over a year now. Also, it doesn't
SegFault at any point, just hangs. I do believe it is the similar
problem
Hello Liu
You're hitting another bug: it happens on high load (which can be easily
triggered by a lot of parallel compilation threads). The only solution for your
kind of problem is to RMA you CPU. See:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response (but
the problem se
Created attachment 282319
Threadripper 2920x soft lockup
I've went through this thread, and tried to disable c6 state, add
idle=halt with no effect. Followed this excellent reprod steps in
https://www.reddit.com/r/Amd/comments/apw8im/ryzen_freezes_in_linux_even_if_linux_is_in_vm/
It is pretty cons
I haven't had the chance to get through the whole thread yet and not
sure if I'll have enough time today. However, I wanted to quickly ask if
anyone has faced this issue with an Intel processor?
We are seeing kernel panics due to the soft lockup issue with the
following configuration:
CPU Archite
I used the rifw=alfie with a 1700x on an MSI X370 Gaming Plus BIOS
7A33v5H with no freezing for 1 week. Computer was rock solid on older
BIOS (7A33v55) for a year+ until BIOS update to latest.
I'm using low power idle option with kernel 4.14.111 opensuse 15.0.
PC had kernel: [Firmware Bug]: AC
I've spent the last few days reading through this thread.
I have Fedora 28, ryzen 1700x, and ASRock Steel Legend B450M. It's a
server mostly used for files at the moment. Bone stock Fedora 28, samba,
ZFS.
With GPU plugged in, hangs within 6-10 hours. Replicating this too often
since March 27th.
> No it hasn't - I'm still waiting for someone to test it and confirm that it
> fixes the issue on their boxes. And by issue I don't mean erratum 1033 -
> that is a red herring anyway - but the lockups people are reporting on some
> broken BIOSes.
Yes, your patch "seems" to work in my case.
"Seem
Created attachment 281999
Add rifw kernel parameter to test a couple of patch to workaround ryzen freezes
Add rifw kernel parameter.
rifw=none - don't do anything
rifw=alfie - ignore BIOS
rifw=boris - use Borislav Petkov patch
I works with kernels 4.19, 4.20 and 5.0.2
--
You received this bug
(In reply to JerryD from comment #578)
> $ sudo rdmsr -a 0xc0011020
> 68000
>
> This is on:
>
> cpu family: 23
> model : 17
> model name: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
> stepping : 0
> microcode : 0x8101007
You're showing me the MSR output for err
(In reply to Borislav Petkov from comment #571)
> (In reply to Lars Viklund from comment #570)
> > rdmsr yields 68010, which has bit 4 set.
>
> Looks like your BIOS applies the fix. Now, does the patch in comment #526
> fix your freezes?
Hi Boris, on my laptop with its latest BIOS I get:
(In reply to Borislav Petkov from comment #571)
> (In reply to Lars Viklund from comment #570)
> > rdmsr yields 68010, which has bit 4 set.
>
> Looks like your BIOS applies the fix. Now, does the patch in comment #526
> fix your freezes?
I'm sorry, I don't currently suffer from any signif
101 - 200 of 514 matches
Mail list logo
