(In reply to Borislav Petkov from comment #574)
> (In reply to Dennis Schridde from comment #573)
> > 2068100
>
> If this is correct:
>
> http://www.cpu-world.com/CPUs/Zen/AMD-Ryzen%205%202400G.html
>
> then you should have in /proc/cpuninfo something like this:
>
> cpu family: 23
> mod
(In reply to Dennis Schridde from comment #573)
> 2068100
If this is correct:
http://www.cpu-world.com/CPUs/Zen/AMD-Ryzen%205%202400G.html
then you should have in /proc/cpuninfo something like this:
cpu family: 23
model: 17
stepping: 0
and if so, not affected.
--
You received
(In reply to Lars Viklund from comment #572)
> (You people should be happy you're not running FreeBSD, there I can
> reasonably reliably hang Ryzens within hours by sending ZFS snapshots :D )
Looks like they've addressed Ryzen errata issues around August 2018:
https://github.com/freebsd/freebsd/b
(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?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to li
(In reply to Borislav Petkov from comment #569)
> (In reply to Tolga Cakir from comment #568)
> > @Borislav has the fix for erratum 1033 "A Lock Operation May Cause the
> > System to Hang" been applied so far? The suggested workaround was "Program
> > MSRC001_1020[4] to 1b", but I couldn't find any
I'm actually desperate about this issue. I'm looking forward to see
results of Boris' patch, though I really doubt it will solve this issue.
Needs explicit check against self-built kernel really.
Not all manufacturers are willing to fix this issue (especially when it
comes to laptops), as Windows
** Bug watch added: freedesktop.org Bugzilla #109206
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--
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 free
@Borislav has the fix for erratum 1033 "A Lock Operation May Cause the
System to Hang" been applied so far? The suggested workaround was
"Program MSRC001_1020[4] to 1b", but I couldn't find anything about it
in master branch. According to the document, 1033 only affects B1.
--
You received this b
There's a patch in comment #526 for people to test before we include it
so that there's at least *some* fix in the kernel, 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/16
I am running Fedora on AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
with Gnome.
I use kernel parameters idle=nomwait iommu=pt processor.max_cstate=1 set
via grubby.
I am not getting any hangs unless I suspend with lid close or suspend on
power button. It would probably be better to not execute a
(In reply to alfie from comment #566)
> But I really want C6/P6 and ignoring the BIOS seems to get me there...
Why do you think the patch I pointed to won't give you C6?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
htt
(In reply to Another User from comment #564)
> Can your system reach turbo frequencies with this patch?
> Maybe I understand something wrongly...
Yes, I have a ryzen 1600 and I can see 1/2 cores running at ~3.6 GHz
under some peculiar stress case.
(In reply to Borislav Petkov from comment #565)
(In reply to Borislav Petkov from comment #569)
> (In reply to Tolga Cakir from comment #568)
> Such a "fix" does not exist. Possibly because it is unlikely this is causing
> it and BIOS might be applying the fix already. People with B1s (model 1,
> stepping 1) could test though by doing as root:
>
(In reply to Tolga Cakir from comment #568)
> @Borislav has the fix for erratum 1033 "A Lock Operation May Cause the
> System to Hang" been applied so far? The suggested workaround was "Program
> MSRC001_1020[4] to 1b", but I couldn't find anything about it in master
> branch. According to the docu
(In reply to alfie from comment #561)
> This is pretty strange, could someone explain it to me? Wasn't mwait bugged
> in ryzen?
Looks like this patch makes kernel to ignore BIOS messages about unsupported
C-state.
this function used in "acpi_processor_ffh_cstate_probe" which further used in
"pro
I have revisited the errata. Errata 1033 "A Lock Operation May Cause the
System to Hang" and 1109 "MWAIT Instruction May Hang a Thread" are the
top contenders. According to page 12 and 13 of that document, Pinnacle
Ridge processors are not affected. However, page 16 and 17 suggest 2nd
Gen Ryzen are
This is pretty strange, could someone explain it to me? Wasn't mwait
bugged in ryzen?
Tired of the random freezes, I tried this:
--- ./arch/x86/kernel/acpi/cstate.c.orig 2018-10-22 08:37:37.0 +0200
+++ ./arch/x86/kernel/acpi/cstate.c2019-03-20 19:26:45.261101857 +0100
@@ -86,6
So if you got message with "typical current idle" option:
[Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
it means probe of this C-state failed and it must be avoided by kernel.
Is there any difference between C-state list in OS with and without this
option? I have only laptop wit
I assume there is several (at least two) similar problems that cause
spontaneous system hangs.
One of them is mwait bug listed in AMD errata. Looks like idle=halt is
partial workaround for this. But, as said in AMD community forum, guest
OS in virtual machine may execute mait instruction and provo
The PSU problem sounds like a weak excuse from AMD or may they are
talking about very very bad 10 dollars units.
The BIOS options "typical/low current" doesn't seems to change the c-states set
up by the kernel routines here. With any selection, I always end up with
c0 POLL
c1 ACPI HLT
c2 ACPI IOP
I am still receiving lockups even with the latest BIOS, all the BIOS
setting recommendations here, and with the idle=halt kernel parameter.
Although I am now fairly certain that I have a faulty motherboard (x470) which
seems to be getting worse, and sometimes doesn't even get to the BIOS at all (
Hi guys. I have an Asus ROG Strix notebook with Ryzen 7 1700. My CPU was
manufactured on week 46 of 2017 (UA 1746PGS), so it does not have the
segfault problem. My notebook completely freeze when it is idle, not
always, but it is more common when newly powered (cool) or after heavy
activities. The
(In reply to Tommy Vercetti from comment #554)
> Same here, I'm using opensuse Leap 15 and Ubuntu 18.10, both 4.12 and 4.18
> kernel suffer the same issue.
> I'm using AMD Ryzen 5 1600 with Asrock Fatal1ty AB350 Gaming-ITX/ac board.
> I'll try updating the latest bios to see if things got fixed.
I
Same here, I'm using opensuse Leap 15 and Ubuntu 18.10, both 4.12 and 4.18
kernel suffer the same issue.
I'm using AMD Ryzen 5 1600 with Asrock Fatal1ty AB350 Gaming-ITX/ac board.
I'll try updating the latest bios to see if things got fixed.
--
You received this bug notification because you are
As I have said previously, I'm not sure that my problem was the same
that others have (I didn't have freezes on idle, but rather freezes when
compiling), but what helped me is updating BIOS to latest version. ASUS
has released a new BIOS with AGESA 0070 for X470 Pro, and I can't
trigger the bug any
(In reply to CodingEagle02 from comment #545)
> Hey out of curiosity, since I can't seem to find a clear answer, what
> exactly does idle=halt do?
idle=halt disables ACPI MWAIT completely, and issues HALT instead of different
C-states for idle.
Without idle=halt, both my machines are issuing erro
(In reply to alfie from comment #542)
>
> Ryzen is not a CPU to run Linux onto.
YMMV but our Ryzen 2600 has been 100% rock solid stable (on 24/7) since
my last comment #493 Jan 23, 2019. All we did was the mwait and
idle:typical bios tweaks. That has worked for many/most people hitting
this bug
(In reply to alfie from comment #542)
> Here (Asus CrossHair VI, 1600, gentoo with any kernel around), no suggested
> workaround works. The system freezes when in very light use and I was never
> able to obtain a single line of debug via serial (I put a small linux mini
> itx box near this computer
(In reply to alfie from comment #551)
> kernel 4.19.27 with rcu_nocbs=0-11 idle=halt nopti, yesterday at around
> 11:30 p.m. I had an "usual" total lookup of the system during light usage (I
> just had an ssh session opened). With idle=halt, I get no "ACPM WAIT C-state
> bug" line in dmesg.
>
> Th
(In reply to ison from comment #544)
> (In reply to Philip Rosvall from comment #541)
> > Try idle=halt! It is the workaround that fixes the random freezes! You
> don't
> > need anything else (at least not with Ryzen 1*** and 2***U processors, as
> it
> > works wonders on my desktop with a 1600 and
kernel 4.19.27 with rcu_nocbs=0-11 idle=halt nopti, yesterday at around
11:30 p.m. I had an "usual" total lookup of the system during light
usage (I just had an ssh session opened). With idle=halt, I get no "ACPM
WAIT C-state bug" line in dmesg.
The problem with this freeze problem is that is diff
(In reply to Philip Rosvall from comment #541)
> Try idle=halt! It is the workaround that fixes the random freezes! You don't
> need anything else (at least not with Ryzen 1*** and 2***U processors, as it
> works wonders on my desktop with a 1600 and my notebook with a 2700U).
>
> IDLE=HALT IS THE
I was severely affected a year ago. My system would not run through one
rebuild of Gentoo, i.e. it would lock up / hard freeze after only a few
hours. I suspect the heavy disk corruption I experienced every time it
happened was a direct result of this, and not caused by unrelated
hardware defects
AGESA 0070 has been released for some mainboards (e.g. ASUS A320M-K,
ASUS X470 Pro and a couple of MSI boards). For anyone experiencing
crashes, I think 0070 is worth a try. Official changelog says something
along "added support for new processors", but more changes under the
hood aren't unlikely.
Hey out of curiosity, since I can't seem to find a clear answer, what
exactly does idle=halt do?
--
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_sc
Try idle=halt! It is the workaround that fixes the random freezes! You
don't need anything else (at least not with Ryzen 1*** and 2***U
processors, as it works wonders on my desktop with a 1600 and my
notebook with a 2700U).
IDLE=HALT IS THE WORKAROUND THAT FIXES THIS BULLSHIT!
I REPEAT:
IDLE=HALT
Here (Asus CrossHair VI, 1600, gentoo with any kernel around), no
suggested workaround works. The system freezes when in very light use
and I was never able to obtain a single line of debug via serial (I put
a small linux mini itx box near this computer just to receive the serial
log).
It seems li
Hi ! I haven’t read all the comments here because there are too many by
now, but I’m puzzled that many consider this to be a Linux-only issue,
because I can tell you that it definitely happens on Windows (10) too,
and I found other people with the same freeze/reboot problem on Windows.
For me the c
Does anyone know whether the kernel version 5.0 solves the issue? From
the changelog, it seems to me like it might.
--
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 18
Well, it's a pity to know 5.0 might not fix it. I was really hoping it
would. On the other hand, it's good to know so many other people have
this issue, which means I'm not alone in hoping it'll be at some point
fixed.
I'll just throw my two cents in though, to hopefully help.
Firstly, technical
fixes*
To be clear, I'm not sure whether CS:GO does freeze my computer after a
given amount of time. I don't think I've tested it thoroughly enough to
be sure. I do know I can play it comfortably without worrying.
--
You received this bug notification because you are a member of Kernel
Packages,
I have tested it on 5.0 and still experienced the soft lockups just as
frequently as with 4.20.
However, I am currently testing kernel 5.0 with PAGE_TABLE_ISOLATION disabled
and it seems that it may be a fix.
Although maybe it's a bit premature to say that, since my experience with this
issue (
Hi,
this comment (536 and 535) for me sounds more or less
the instability is not from idle. because:
"... Applications start segfaulting,..."
"running wine/... (with games)"
for segfaulting you have to change the processor. search the internet
for the "kill ryzon script" run it and look what happe
Hi,
this comment (536 and 535) for me sounds more or less
the instability is not from idle. because:
"... Applications start segfaulting,..."
"running wine/... (with games)"
for segfaulting you have to change the processor. search the internet
for the "kill ryzon script" run it and look what happe
Created attachment 281445
Testcase in docker
I have created a docker file and run script, that allows me to reproduce
the issue. It still takes quite a lot of time usually. This docker
freezes the system in 30 minutes - 5-6 hours. I've been able to
reproduce it with docker in Windows 10, xubuntu 1
Input interpretation:
Wednesday, August 16, 2017
Open code
Enlarge Data Customize A Plaintext Interactive
Date formats:More formats/calendars
16/08/2017 (day/month/year)
Time difference from today (Saturday, March 2, 2019):
1 year 6 months 17 days ago
18 months 17 days ago
80 weeks 3 days ago
563 d
(In reply to Borislav Petkov from comment #526)
> Created attachment 280961 [details]
> Don't do mwait on B1 and earlier
What's the downside of generally disabling mwait? I'm using a Ryzen 7
1700X and don't have any problem ("fixed" it w/ 200 MHz of CPU
Overclocking). The only thing I see, is, tha
(In reply to Klaus Mueller from comment #530)
> Hmm, if rev. 1 doesn't support MWAIT - why can it be a problem anyway
> at the same time which must be fixed by disabling the usage of MWAIT?
> I seem to miss something?
That's a good question but, frankly, I don't have a very exact answer to
it righ
(In reply to Klaus Mueller from comment #528)
> What's the downside of generally disabling mwait?
So in your case, you can't do MWAIT to enter C1 anyway because your
revision doesn't support it. This is why you're seeing those firmware
messages.
> I'm using a Ryzen 7 1700X and don't have any prob
(In reply to Borislav Petkov from comment #529)
> (In reply to Klaus Mueller from comment #528)
> > What's the downside of generally disabling mwait?
>
> So in your case, you can't do MWAIT to enter C1 anyway because your
> revision doesn't support it. This is why you're seeing those firmware
> me
Ok, here's a test patch ontop of 4.20-stable.
It should practically make idle=halt the default on revisions before B2.
You check which revision you have by doing
$ grep stepping /proc/cpuinfo
The number must be < 2.
For the folks with B2 machines we need to keep debugging.
Thx.
--
You receiv
Created attachment 280961
Don't do mwait on B1 and earlier
--
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
(In reply to Borislav Petkov from comment #523)
> (In reply to Philip Rosvall from comment #522)
> > I have only used the workaround since kernel 4.20.4, so I just booted the
> > kernel now without and with the parameter. As can be seen in line 704 in
> the
> > log without "idle=halt", we see the e
(In reply to Borislav Petkov from comment #519)
> (In reply to Philip Rosvall from comment #518)
> > I can confirm that "idle=halt" makes both my Ryzen desktop and Ryzen
> > notebook more stable than anything else I've tried. I have not experienced
> > freezes for some days now.
>
> Can you upload
(In reply to Philip Rosvall from comment #522)
> I have only used the workaround since kernel 4.20.4, so I just booted the
> kernel now without and with the parameter. As can be seen in line 704 in the
> log without "idle=halt", we see the error "[Firmware Bug]: ACPI MWAIT
> C-state 0x0 not support
Created attachment 280915
dmesg w/o boot parameter idle=halt
--
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
S
Created attachment 280917
dmesg with boot parameter idle=halt
--
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
Created attachment 280921
dmesg w/o boot parameter idle=halt, patched acpi-dump-cstates
--
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 detec
I can confirm that "idle=halt" makes both my Ryzen desktop and Ryzen
notebook more stable than anything else I've tried. I have not
experienced freezes for some days now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
htt
(In reply to Philip Rosvall from comment #518)
> I can confirm that "idle=halt" makes both my Ryzen desktop and Ryzen
> notebook more stable than anything else I've tried. I have not experienced
> freezes for some days now.
Can you upload dmesg from the working and non-working kernels pls?
Thx.
(In reply to Borislav Petkov from comment #511)
> 7. install kernel, needs root
> # make modules_install install
$ sudo make modules_install install
...
INSTALL virt/lib/irqbypass.ko
DEPMOD 4.20.5-dirty
sh ./arch/x86/boot/install.sh 4.20.5-dirty arch/x86/boot/bzImage \
Created attachment 280867
dmesg log after rebooting with acpi-dump-cstates patch
--
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 sta
Bugs are sign of success product or any software because it makes
product more effective and perfect to use with the expert’s solutions
and user’s feedback. Thanks for finding bug on random soft lockup on new
Ryzen build.
Lauren,
https://www.cvfolks.co.uk/
--
You received this bug notification b
(In reply to Borislav Petkov from comment #511)
> Ok, here we go:
> 1. Clone stable kernel from here if you haven't done so yet:
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> 2. checkout 4.20 branch
> $ git checkout -b 4.20-stable origin/linux-4.20.y
> 3. apply the
(In reply to T X from comment #513)
> $ sudo updatedb
> $ locate -i config-4
> $ uname -a
> Linux 4.20.4-arch1-1-ARCH #1 SMP PREEMPT Wed Jan 23 00:12:22 UTC 2019
> x86_64 GNU/Linux
>
> Where is the config file?
Arch Linux doesn't package the kernel's config with the kernel. For th
Created attachment 280825
acpi-dump-cstates.diff
--
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 Lin
(In reply to T X from comment #509)
> I haven't built a kernel in about decade, but if you provide step-by-step
> instructions for how to do so, I'll attempt to build the patched kernel and
> then post the dmesg.
Ok, here we go:
1. Clone stable kernel from here if you haven't done so yet:
$ git
(In reply to Maxim Bakulin from comment #492)
> Created attachment 280669 [details]
> dmesg of freeze with 4.20.3 kernel and nomwait, rcu_nocbs, max_cstate applied
>
> some older info here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085/comments/566
>
> I have three machines with
> If I send you a debugging patch, would you be able to apply it, build a
kernel, boot into it and get me dmesg from the box?
I haven't built a kernel in about decade, but if you provide step-by-
step instructions for how to do so, I'll attempt to build the patched
kernel and then post the dmesg.
Can people confirm that idle=halt fixes the issue, like Aaron says in
comment #506?
--
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
Using:
* BIOS Version: P5.30, Release Date: 12/18/2018
* idle=nomwait
* Power Supply Idle Control set to "Typical Current Idle"
The ~20-minute idle lock-up issue appears fixed, despite:
Jan 25 10:21:39 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not
support...
If it locks up overnight, I'll
I'm running with idle=halt, and I have not experienced a freeze for a
couple days now, FWIW.
--
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
(In reply to Maxim Bakulin from comment #503)
> I tried and it didn't help. After freezes started happening at Xubuntu
> 18.04LTS with stock 4.15, I compiled latest 4.20.3 kernel and added
> CONFIG_RCU_NOCB_CPU=y, as it was suggested here, but freezes didn't stop.
> There's my dmesg at comment 492
(In reply to Borislav Petkov from comment #497)
> Folks, just a quick thing: please check whether you have the latest BIOS and
> if not, do upgrade it and check if it makes any difference.
>
> Thx.
Already running latest BIOS (2018/12/19 for ASRock B450 Pro4 and
2018/12/17 for ASUS X470 Pro).
I
Upgraded BIOS as follows:
1. https://www.asrock.com/mb/AMD/Fatal1ty%20AB350%20Gaming-ITXac/index.asp
2. Click Support > BIOS
3. Download Version 5.30 through Global site (ignore "AMD all in 1 VGA driver")
4. Formatted USB as FAT32
5. Copied and unzipped AB350 Gaming-ITXac(5.30)ROM.zip to USB
6. Fl
(In reply to T X from comment #502)
> Jan 25 09:38:33 kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> Jan 25 09:38:33 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported
> by HW (0x0)
Yah, even with the new BIOS that's still there. Doesn't look like it has been
fixed.
If I
(In reply to Borislav Petkov from comment #501)
> What's stopping you from building a kernel on your machine and
> installing it?
I tried and it didn't help. After freezes started happening at Xubuntu
18.04LTS with stock 4.15, I compiled latest 4.20.3 kernel and added
CONFIG_RCU_NOCB_CPU=y, as it
(In reply to Maxim Bakulin from comment #500)
> I found out that openSUSE Tumbleweed with stock 4.20.0 kernel doesn't appear
> to freeze. I tried copying suse's kernel and /lib/modules to Xubuntu
> 18.04LTS, but it didn't seem to help, xubuntu still freezes. Maybe,
> xubuntu's firmware packages are
(In reply to T X from comment #498)
> Jan 24 17:59:39 kernel: [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported
> by HW (0x0)
So this looks like a broken BIOS.
> Jan 24 17:21:00 kernel: Hardware name: To Be Filled By O.E.M. To Be
> Filled By O.E.M./AB350 Gaming-ITX/ac, BIOS P4.60 04/19/2018
L
OS: Antergos Linux 4.20.3-arch1-1-ARCH #1 SMP PREEMPT Wed Jan 16 22:38:58 UTC
2019 x86_64 GNU/Linux.
CPU: AMD Ryzen 7 1700 Eight-Core Processor.
CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtsc
Folks, just a quick thing: please check whether you have the latest BIOS
and if not, do upgrade it and check if it makes any difference.
Thx.
--
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
I did power consumption tests with idle=nomwait option on my Huawei
Matebook D 14 Ryzen 2500u with power meter.
With idle=nomwait idle power consumption is about 4W less!! I did few
reboots to be sure about it.
--
You received this bug notification because you are a member of Kernel
Packages, w
(In reply to Maxim Bakulin from comment #492)
> Created attachment 280669 [details]
> dmesg of freeze with 4.20.3 kernel and nomwait, rcu_nocbs, max_cstate applied
>
> some older info here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085/comments/566
>
> I have three machines with
(In reply to Another User from comment #481)
> (In reply to Aaron Muir Hamilton from comment #480)
> > So my box was mostly idle for the last day or so, and had locked up while
> > the monitor was asleep, so I had to reset it.
>
> Can you test your system with idle=halt parameter instead of idle=n
Sorry the pic is so horrible in attachment 280661, but at least you can
see most of the stack traces. I have a wider pic of it I can use to
transcribe the missing right-hand-side bits if needed.
By "idle: typical" bios tweak I meant the <> tweak everyone else has done.
As for which fix (1 or 2)
>From my experience (a Ryzen 1700X on a MSI B350 motherboard) the freezes
on IDLE, like the ones described from Trevor Cordes, went way once I
changed the "Idle: typical" setting on the BIOS.
I had the bug before the BIOS setting appeared, and tried many things
with more or less success. But the b
(In reply to Borislav Petkov from comment #486)
> (In reply to Trevor Cordes from comment #485)
> > Also, we were able to get a stack trace / panic output that was on
> > the frozen screen in a phone capture jpg. If anyone wants that, I can
> > attach it.
>
> Please do.
>
> > We did the "idle: ty
(In reply to Trevor Cordes from comment #485)
> Also, we were able to get a stack trace / panic output that was on
> the frozen screen in a phone capture jpg. If anyone wants that, I can
> attach it.
Please do.
> We did the "idle: typical" bios tweak
What is that?
> and the idle=nomwait tweak a
(In reply to Borislav Petkov from comment #489)
> Btw, is there any particular reason why you're running a 32-bit kernel?
> If not, I'd consider switching to a 64-bit kernel which is a lot more
> and widely tested.
Yes, we know. This box has been running forever, always upgraded to the
latest Fed
Created attachment 280669
dmesg of freeze with 4.20.3 kernel and nomwait, rcu_nocbs, max_cstate applied
some older info here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085/comments/566
I have three machines with new 2700x CPUs, and all three of them
experience freezes in xubuntu 18
Created attachment 280661
picture of panic on screen before reboot
--
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/ta
(In reply to Trevor Cordes from comment #488)
> Sorry the pic is so horrible in attachment 280661 [details], but at least
> you can see most of the stack traces. I have a wider pic of it I can use to
> transcribe the missing right-hand-side bits if needed.
Thanks, that's good enough.
Btw, is the
(In reply to Borislav Petkov from comment #478)
> (In reply to Aaron Muir Hamilton from comment #476)
> > For the time being, I've now added idle=nomwait to my kernel params, as it
> > seems at least one of these issues is related to MWAIT (according to AMD's
> > errata).
>
> Ok, that's good. Plea
(In reply to Borislav Petkov from comment #482)
> (In reply to Aaron Muir Hamilton from comment #480)
> > So my box was mostly idle for the last day or so, and had locked up while
> > the monitor was asleep, so I had to reset it.
>
> Let me make sure I understand it correctly: you had "idle=nomwai
(In reply to Aaron Muir Hamilton from comment #480)
> So my box was mostly idle for the last day or so, and had locked up while
> the monitor was asleep, so I had to reset it.
Can you test your system with idle=halt parameter instead of
idle=nomwait?
--
You received this bug notification because
(In reply to Aaron Muir Hamilton from comment #483)
> That is maybe an option, for now I disabled C6 from my board firmware (in
> ASRock's case, by selecting "Typical current idle" [sometimes called "Common
> current idle" I think, on some Ryzen boards] in Advanced > AMD CBS > Zen
> Common Options
Hi, just setup brand new Ryzen 5 2600 on Asrock AB350 PRO4 with ECC RAM
with Fedora 29 and the box froze after only 3 hours uptime, right after
we went home for the night, so it was fairly idle (< 0.2% CPU 99% of the
time).
Luckily I had read this thread before buying, so I wasn't too shocked.
I
(In reply to Aaron Muir Hamilton from comment #480)
> So my box was mostly idle for the last day or so, and had locked up while
> the monitor was asleep, so I had to reset it.
Let me make sure I understand it correctly: you had "idle=nomwait" on
the kernel command line and it became unresponsive?
We decided to get 3 Ryzen 2700x machines for testing at work, and we are
bitterly disappointed that they randomly freeze in Linux.
The only message I get in journalctl is "rcu_sched detected stalls
blablabla", and sometimes I don't get even that. I test the system by
compiling QEMU with -j16 in a
(In reply to Aaron Muir Hamilton from comment #476)
> For the time being, I've now added idle=nomwait to my kernel params, as it
> seems at least one of these issues is related to MWAIT (according to AMD's
> errata).
Ok, that's good. Please give your box hell to check whether that really
is fixing
201 - 300 of 514 matches
Mail list logo
