Ryzen 1800X freeze - rcu_sched detected stalls on CPUs/tasks

Bug #1690085 reported by Vincent on 2017-05-11
206
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
High
Unassigned

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

Vincent (hvincent13) wrote :

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1690085

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

apport information

tags: added: apport-collected zesty
description: updated

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Lipido (lipido) wrote :

Hi Vicent,

Did you experience more crashes with kernel 4.11?

Thank you!

Vincent (hvincent13) wrote :

Hi Lipido,

Yes, i'm still experiencing crashes, even when using 4.11

Please find full kern.log in attachment.

Regards,

Lipido (lipido) wrote :

Ok, me too :-(

Crashes appear from 24-48h of operation.

My hardware is:
- SSUS PRIME B350-Plus
- Amd Ryzen 5 1600

OS: Ubuntu 16.04

Tried:
- Update BIOS to the latest (v 609)
- Kernel 4.10
- Disable SMT in bios (from 12 threads to 6 threads)
- Boot clocksource=tsc iommu=soft
- Disable IOMMU in bios

None of these work. I was waiting for 4.11 to be available for Ubuntu as an official package, but it seems that this will not work either.

Another link talking about what seems to be the same issue:

https://forum.level1techs.com/t/ryzen-vs-ubuntu/115715/22

Joseph Salisbury (jsalisbury) wrote :

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.12 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc1/

Changed in linux (Ubuntu):
importance: Undecided → High
status: Confirmed → Incomplete
tags: added: kernel-da-key
Vincent (hvincent13) wrote :

Hi Joseph,

I've just installed 4.12-rc1.
Now waiting for a crash... or not (hope so !)

Regards,

Vincent (hvincent13) wrote :

Just go a kernel panic...

How to add the tag kernel-bug-exists-upstream ?

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: kernel-bug-exists-upstream
Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
status: Confirmed → Triaged
Vincent (hvincent13) wrote :

Hi,

Could you please tell me which address I have to send the mail to?
I don't really understand how to achieve this bug report on the mailing list.

Thanks,

Vincent (hvincent13) wrote :

Hi,

It looks like that the system is stable when removing "nouveau" driver.
Waiting 24/48h and will post again.

Regards,

camparijet (iichikolamp) wrote :

Hi Vincent,

I also met the problem, and your advice removing "nouveau" succeeded for work-around to stabilize system. Before it freeze every 3-5hr after booting up, but now working without problem for 2 days.

My enviroment is:
- cpu: Ryzen 1700
- motherboard: ASUS B350M-A
- graphics card: NVIDIA GK208
- kernel: 4.11.0-041100rc8-generic
- dist: 17.04

Vincent (hvincent13) wrote :

Hi,

5 days update now and no crash.

camparijet => did you installed NVIDIA driver instead ?

Regards,

camparijet (iichikolamp) wrote :

Hi Vincent,

> camparijet => did you installed NVIDIA driver instead ?

No. I don't have to use the card for my purpose, so simply i disable it.

Alex Jones (blenheimears) wrote :

I'm seeing this crash even with the Nvidia official driver.

Alex Jones (blenheimears) wrote :

This is a hardware bug in the CPU. This ticket should be closed as invalid.

Changed in linux (Ubuntu):
status: Triaged → Invalid
Alex Jones (blenheimears) wrote :

Reopening because even though this is a known issue with the CPU we could still implement a workaround. One workaround is to disable address space layout randomization:

echo 0 >/proc/sys/kernel/randomize_va_space

However, that would be disabling a security feature.

Changed in linux (Ubuntu):
status: Invalid → New

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
tags: added: artful
Marc Rene Schädler (suaefar) wrote :

Was this issue officially confirmed to be a hardware bug in Ryzen processors by AMD?
If so, could you provide a link to the statement?

Disabling address space layout randomization (ASLR) seems to alleviate the problem, but does it solve it?

I am investigating unstable behavior under load which could be related.
There, disabling ASLR is not sufficient!
People suggest to increase SOC voltages, use specific versions of the kernel and the like.
See https://community.amd.com/thread/215773?start=135&tstart=0 for more info.

Alex Jones (blenheimears) wrote :

AMD has not publicly commented on this issue that I'm aware of. This issue has been seen on many different operating systems. DragonFlyBSD includes a workaround for this issue. The workaround on Linux is to compile the kernel with CONFIG_RCU_NOCB_CPU, CONFIG_RCU_NOCB_CPU_ALL, and disable ASLR using "echo 0 >/proc/sys/kernel/randomize_va_space". This can be put into rc.local. It's also possible to hardcode ASLR as disabled into the kernel, but this requires modifying the kernel source, not just the config file. There is a new AGESA update released about a week ago, 1.0.0.6a, although I have not tested whether the new AGESA alone (without any kernel changes) solves the issue.

Alex Jones (blenheimears) wrote :

I just tested 1.0.0.6a AGESA, and it does not solve this issue. In some cases just one program will crash, and in other cases the entire system will crash. I will test the workaround above later.

Alex Jones (blenheimears) wrote :

If any of your RAM timings are odd (eg. 17), setting them to the next even number (eg. 18) helps a lot. Recompiling the kernel with CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL, and disabling ASLR is still necessary though. It may also be a good idea to give the SOC slightly more voltage, but not more than 1.2 V.

Kai-Heng Feng (kaihengfeng) wrote :

Alex,

Can you provide link on how DragonflyBSD fixed this issue?

Alex Jones (blenheimears) wrote :

This is the DragonFlyBSD commit. https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20

It appears that there are two different ways that the system can crash, which is why it is necessary to both disable ASLR and to compile the kernel with CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL. The ASLR-related crash usually results in a single or a few programs crashing (although if an important program crashes it can bring down the entire system) and happens under heavy load. The other crash only happens if the kernel was compiled without CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL (Ubuntu's kernel is compiled without these options) and happens when the system is idle or nearly idle, and results in a complete system crash.

Alex Jones (blenheimears) wrote :

If the motherboard allows it, disabling the OpCache will completely prevent (or at least greatly reduce the probability of) the ASLR-related crash, even if ASLR is enabled in the kernel. As far as I'm aware it has no effect on the other type of crash.

Alex Jones (blenheimears) wrote :

I've also determined that changing the CPU, memory, or SOC voltages or timings has little or no effect on either type of crash.

Kai-Heng Feng (kaihengfeng) wrote :

This is beyond my expertise - let's see what upstream can do.

Torge (cyslider) wrote :

I also experience this problem since I updated yesterday.

I am using Kubuntu 16.04 with KDE backports enabled.
I also have a Ryzen 1800X and an Asrock X370 Gaming professional

I experience this either when I boot and don't log in promptly or when I enter the lockscreen.

After reading this page I tried to run
  seq 1 | xargs -P0 -n1 md5sum /dev/zero &

as root to always keep one CPU core busy and indeed this seems to prevent the lockscreen problem...

I would also like to note that the system was not 100% frozen, once every few minutes it seemed to response for a short time, enabling me to switch to the TTY. Then I always saw some processes hanging at 100% that I could not kill, or the kill was delayed for a long time. I always see the errors in the initial posts during that time. The TTY seemes to work fine though, once entered though.

David Wilson (plottt) wrote :

I've ran into this problem several times. After disabling C-states in the motherboard, my system has been running stable for ~5 weeks uptime so far.

Torge (cyslider) wrote :

Ok, this trick did not help and my PC did not make it through the night without freezing again.

However I finally found the real problem. I installed oibaf a while back as my Kubuntu was flickering all over the place. Now it seems the be the source of my problem. I deinstalled oibaf again and now everything seems fine. No lock screen freezing for me anymore.

Stuart Page (sdpagent) wrote :

Just wanting to report that I am also experiencing this issue with a freshly installed Ubuntu Server 16.04.3 with 4.10 kernel on the 22nd August 2017. All the updates applied and running as a KVM host with hardware:

Ryzen 1700 (non-x)
Motherboard: Asus prime B350-Plus
Bios: - Version 0805
 - Disabled SMT
 - Disabled c-states

xb5i7o (xb5i7o) wrote :

Hi guys,

Im getting the same issues, brand new build.

Ryzen 1800x
Asrock X370 Taichi
BIOS: 3.10 (latest)
I tried disabling cool n quiet and c-state

However there is another option under advanced - for GLOBAL C-States that i just disabled today and i am waiting to see what will happen.

On BIOS v3.00 PC would freeze after 6 hours of idling or not touching anything. Come back to see my keyboard and mouse and everything was frozen.
With BIOS v.3.10 now i get random reboots atleast once a day.

Im running Ubuntu 16.04.3 Kernel 4.4.0-93

Anyone know to direct me where the SoC voltage would be in BIOS? is it the VDD SoC?
Anyone know how to update my kernel to 4.10 if it tells me i have the latest?

Stuart Page (sdpagent) wrote :

I finally managed to figure out how to compile a kernel with RCU_NOCB and disabled ASLR as Alex Jones mentioned, and it appears to have worked for me and another guy who helped me put the tutorial together:

http://blog.programster.org/ubuntu-16-04-compile-custom-kernel-for-ryzen

Kai-Heng Feng (kaihengfeng) wrote :

Stuart,

Does this issue also happen on latest mainline kernel?

Franck Charras (franckc) wrote :

Hi,
I'm getting the same issues on several identical builds, with an ASUS prime X370-PRO motherboard.
It's very hard to analyze since it happens randomly every other week, and it leaves no logs. It seems that the freeze happens at idle after very high memory load (observation after logging CPU and RAM loads).
Compiling the kernel as suggested in this thread didn't work (new freeze this morning).

tgui (eric-c-morgan) wrote :

I too still have random computer shutdowns without logs. Uptime varies from a couple days to a week or so. It happens it seems after being relatively idle for a long period. I do have high memory usage because of the VMs I run.

I've disabled C-states, cool and quiet, tested memory, and so forth. I also compiled a new kernel as mentioned by Stuart. I do not have segfaults with compilations.

I am willing to run tests and provide info. Please let me know if anyone wants something.

Ubuntu 16.04
Asrock x370 ITX
32GB Ram
Ryzen 1700

Franck Charras (franckc) wrote :

Ryzen CPUs manufactured before week 24 of this year were known to have issues (especially the segfault issue). It was officially fixed for all ryzen manufactured after week 30. All my ryzen are pre-24 CPUs and they all have this silent crash issue. Does it also happen with the post week 30 ryzen ? (@tgui what is yours ?)

AS (as2008) wrote :

I can confirm the issue with a week 33 Ryzen 1700 on Asus Prime B350 Plus.
I had segfaults with my previous 1700 (week 22 iirc). No more segfaults with the week 33 CPU but still random crashes on (long time) idle.

tags: removed: kernel-da-key
information type: Public → Public Security
information type: Public Security → Public
Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
460 comments hidden view all 540 comments

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 the relevant kernel folk -- certainly nothing which says what the "Typical Current Idle" BIOS option actually does, and whether or how it solves the problem, in part or completely.

Sadly, this long thread has almost nothing to do with identifying any actual Kernel bug or bugs. It's more a sort of support group. [Hello, I'm Chris and I'm an AMD Ryzen user... since I found the "Typical Current Idle" BIOS option, I haven't had a "freeze while idle" for two weeks -- praise be.]

If you are looking for useful information, look away now: angry, bewildered person about to howl at the moon...

--------------

...do I find the situation "Incredible" ? hmmm...

[Final warning: reduced signal/noise ration ahead.]

I bought my Ryzen machine the moment I could order it.

When I came to build it, I found there was some confusion about the "standard" fitting for the CPU cooler -- the plate glued to the motherboard and the cooler fitting were incompatible. I found myself in a three-way stand-off between AMD, the motherboard vendor and the cooler vendor. If there was a specification for the standard AM4 socket fitting for the cooler, it was Top Secret. In the end I voided all warranties, ripped the plate from the motherboard and replaced it by the one supplied with the cooler.

When I set up my new machine, I found the standard configuration for the memory was not as fast as I expected, noting <https://www.amd.com/en/products/cpu/amd-ryzen-7-1800x>. But, I stumbled across this <https://community.amd.com/community/gaming/blog/2017/03/14/tips-for-building-a-better-amd-ryzen-system> where I discovered that the 2667 MT/s I was expecting was for 2 DIMMs; with my 4 DIMMs, 2133 MT/s is what I should have expected. Silly Me ! I have seen BIOSes since then which are supposed to improve memory support... but I think that's more options for overclocking... who knows ? Call me old fashioned, but I am disappointed (but no longer surprised) that I cannot find an AMD data sheet that specifies memory support (or much of anything else, for that matter).

Can I find any documentation for AGESA ? No. It's various versions (and changes in version numbering) ? No.

Does my motherboard vendor provide release notes for each BIOS version ? No. How did I discover which BIOS version had the "Typical Current Idle" option ? By experiment.

If the <email address hidden> fairy has died because I stopped clapping, then I'm sorry.

... so, Incredible ? Nah. Infuriating ? You bet.

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.

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 appreciate the slow trickle of comments along
the lines of confirming that the typical current bios fix is effective,
compared to the absence of comments that the bug persists even with this
option enabled. My current uptime with typical current enabled is 136
days, compared to only a few days without it.

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 on 2xxx series processors.

This huge job log is neatly a year old now, it's crazy. It should be fixed on the processor itself or the BIOS.

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 suddenly stuck during normal office use. Everything stays where is is. No restart, whoops, panic, log entries of any type.

Only reset-button helps.

I did try to diable Global C-State Control in UEFI - didn't help.
After finding this thread today I set Power Supply Idle Control to "Typical Current Idle" and set global C-State back to Auto (since I thought that doesn't help). Sadly, my system froze after 3h.

That is with the first and stock UEFI version F1 (AGESA 1.0.0.4).
I've just seen that there is an updated UEFI version F2. I've just updated and set global c-states to disabled AND Power Supply Idle Control to "Typical Current Idle".

"sudo ./zenstates.py -l" is now:
C6 State - Package - Disabled
C6 State - Core - Disabled

I'll come back with the results.

This makes the whole AMD 1xxx and 2xxx seem unstable.

Questions:
- Why does AMD not care? Is this maybe not NOT a general issue and only affecting a small percentage of users?

- If Windows doesn't suffer from that issue - can we find out why and do a "if amd then powersave like windows"?
Or is it just the lack of information/support by vendor so that we don't know what exactly the issue is, what is causing it and how to work around it?

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.

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 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 disabled by DEFAULT on this OS as i said earlier in this thread.

So it seems possible to fix it via the kernel, without make use of an uefi parameters not enabled by default.
It could increase the user experience under Linux for people who doesn't know this trouble.

So, why don't make simply the same on Linux? IIRC from my reading over hardware.fr article the same apply to Intel cpu. That's a tweak for increasing performance afaik. Ryzen gains ~10%(on games, where latencies are more important) while not having "deep sleep" of cores enabled.

My Wattmeter is not a good one but i see mostly no difference between this core parking partially disabled or not. It must save really few power.

You all can easily test it by core parking control software on this other OS.

(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 disabled by DEFAULT on this OS as i said earlier in this thread.
>
> So it seems possible to fix it via the kernel, without make use of an uefi
> parameters not enabled by default...

I can perhaps confirm that. But I have to say first, I'm not a developer and I do not understand anything about Linux.

I use an AMD Ryzen 5 1600 Six-Core @ 12x 3.2GHz with Gentoo as the operating system. So it's very easy for me to build a kernel just for my machine. (Without the whole Intel, ARM64, Android and Big-Data stuff.)

I try the kernels with standard bios setup, without kernel parameters like "idle = nomwait", without OC. My bios only has Global C-states Auto (which is default) and enable/disable options. There is no "Idle Control to "Typical Current Idle"" in the BIOS. Only CONFIG_RCU_NOCB_CPU=y is set in the .config.

BOOT_IMAGE=/boot/kernel-x86_64-4.19.0-rc3 root=UUID=465f9c93-09d0-441b-9440-8ec7799b557c ro real_root=/dev/sdd4 resume=/dev/sdd3 init=/usr/lib/systemd/systemd
rootfstype=ext4

./zenstates.py -l
...
C6 State - Package - Enabled
C6 State - Core - Enabled
...
On this basis,
It is to be confirmed by me that the kernel 4.17.14 works really well. But the series 4.18.x is cruel. Also the currently as "stable" declarated 4.18.7. Bad. Freeze or reboot every 2 - 3 hours.

To my surprise, the 4.19.0-rcX work well. So far no soft lockups.

I do not know why. But these are the subjective results of my playing with the kernels.

I can also understand that the few kernel developers are working on priority issues. Please think of Specter and Meltdown.

But a few clarifying information would be very welcome..

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.

I am having some success (4 days now) with all of that AND idle=nomwait kernel parameter - although I only read that to be related to resets and not freezes.

Anyways. will keep my system on.

I would like to trade in the LEDs on GPU and mainboard for vendors effort to get some stability in their systems.

Any update from someone who really knows what is going on would be really appreciated. We're playing around with settings which are not explained anywhere.

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 if all changes are needed or if only one or two are necessary.

Will come back with an update when I have the results.

Michael

So what are the implications of using idle=nowait and why isn't it a standard behaviour for all Ryzen CPU going forward?

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 no bug. Then I switched to Leap 15.1 and the bug appeared for the first time (it had a newer kernel). Then I had about 3 weeks before finding this fix.

Now I have openSUSE Tumbleweed with kernel 4.18.8. It was OK since kernel 4.14 and now it keeps on updating the kernel as usual and everything is OK.

Thank you for providing this fix!

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 moment.

(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 there a Bios switch like "Typical Current Idle"? Is there a possibility to switch of C-states completely in the Bios (just for testing to be sure your hangs are the same reason as here)?

(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)?
>
> Do you have the possibility to slightly overclock? Isn't there a Bios switch
> like "Typical Current Idle"? Is there a possibility to switch of C-states
> completely in the Bios (just for testing to be sure your hangs are the same
> reason as here)?

As follows:

[root@amdr jerry]# modprobe msr
[root@amdr jerry]# ./bin/zenstates.py --list
P0 - Enabled - FID = 64 - DID = A - VID = 35 - Ratio = 20.00 - vCore = 1.21875
P1 - Enabled - FID = 66 - DID = C - VID = 60 - Ratio = 17.00 - vCore = 0.95000
P2 - Enabled - FID = 60 - DID = C - VID = 66 - Ratio = 16.00 - vCore = 0.91250
P3 - Disabled
P4 - Disabled
P5 - Disabled
P6 - Disabled
P7 - Disabled
C6 State - Package - Enabled
C6 State - Core - Enabled

[root@amdr jerry]# ./bin/zenstates.py --c6-disable
Traceback (most recent call last):
  File "./bin/zenstates.py", line 112, in <module>
    writemsr(0xC0010292, readmsr(0xC0010292) & ~(1 << 32))
  File "./bin/zenstates.py", line 23, in writemsr
    raise OSError("msr module not loaded (run modprobe msr)")
OSError: msr module not loaded (run modprobe msr)

As you can see msr is loaded and listing the states works fine but the disable option fails.

The bios on this laptop has no power related options that I can see.

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 CPU there is circuitry on the motherboard, which I guess could also be involved ?

Disabling C-States, in particular C6, obviously addresses the apparent root cause.

However, for my machine, setting C6 Package Disabled (using zenstates.py) was not enough. Nor was it enough to set both C6 Package and C6 Core Disabled.

After setting "Typical Current Idle", I have had ~5 months without a "freeze when idle" -- with various kernels up to and including 4.18.9, and (latterly) with no other settings.

So I assume that "Typical Current Idle" does something more than disabling C6... something I have yet to discover.

------------

What the "Typical Current Idle" option does is secret :-(

On my machine (Ryzen 7 1800X, Asus X370-Pro, BIOS 4012), zenstates.py tells me:

   Low Current Idle : C6 Package Enabled : C6 Core Enabled
   Typical Current Idle : C6 Package Disabled : C6 Core Enabled
   Auto : C6 Package Enabled : C6 Core Enabled

and all three have the same three P-States:

   P0: FID=90 DID=8 VID=20 Ratio=36.00 vCore=1.35000
   P1: FID=80 DID=8 VID=2C Ratio=32.00 vCore=1.27500
   P2: FID=84 DID=C VID=68 Ratio=22.00 vCore=0.90000

[I thought that "Typical Current Idle" might be fiddling with P2, but that does not seem to be the case.]

I imagine there are many more parameters I could look at, if only I knew more. For completeness, I leave all other BIOS options in their default state.

While I was checking the effect of the "Current Idle" options, I noticed something peculiar about setting "Typical Current Idle". I started with:

 0) "Typical Current Idle" was: C6 Package Disabled

and then:

 1) reboot into BIOS, set "Low Current Idle", gave: C6 Package Enabled
 2) reboot into BIOS, set "Typical Current Idle", gave: C6 Package Enabled !
 3) shutdown and restart, gave: C6 Package Disabled !

To get the (full) effect of "Typical Current Idle" I have to do a cold boot, apparently !! [I tried this three times, just to be sure.]

------------

I'm curious about "idle=nomwait". I find this will "disable mwait for CPU C-states". AFAIKS, the MWAIT instruction halts the current thread and sets a given C-State to drop into. So not using MWAIT looks like another way of disabling C6 for the core ? Or is there something else going on here ?

Given that I found that disabling C6 is not enough to eliminate "freeze when idle", I would not expect "idle=nomwait" to be enough. Unless "idle=nomwait" does something more... avoiding a Kernel bug, for example ?

(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 comment #419
>
> This seems ok now. Now I need to verify if all changes are needed or if only
> one or two are necessary.
>
> Will come back with an update when I have the results.
>
> Michael

Hi!

First, I've changed my mainboard (see below). AGESA-wise this was a downgrade from 1.0.0.4 to 1.0.0.2.
This does change the chipset from B450 to X470.

Second, I did enable the global c-states in UEFI and am still running without freezes for over 14 days now. I consider that long enough to call it stable.

That means only the following changes are needed:

- typical current idle UEFI setting
- the idle=nomwait kernel parameter

For reference:
Asrock X470 Master SLI with BIOS 1.10
2700x
no overclocking, but ram on XMP profile.

# ./zenstates.py -l
P0 - Enabled - FID = 94 - DID = 8 - VID = 36 - Ratio = 37.00 - vCore = 1.21250
P1 - Enabled - FID = 80 - DID = 8 - VID = 59 - Ratio = 32.00 - vCore = 0.99375
P2 - Enabled - FID = 84 - DID = C - VID = 76 - Ratio = 22.00 - vCore = 0.81250
P3 - Disabled
P4 - Disabled
P5 - Disabled
P6 - Disabled
P7 - Disabled
C6 State - Package - Disabled
C6 State - Core - Enabled

I'll stop playing with parameters since I think I reached the best I can. I'll only update if something changes like freezes keep returning etc.

Regards,
Michael

(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 available on this mavhine.
>
> Feel pretty hopeless at the moment.

I'm on Ryzen 2500U Laptop as well, HP 15-db0229ur with latest BIOS (F.11 Rev.1 in my case) and latest kernel (something that used to be called 4.19-rc7 on kernel.org). Also have no option of entering BIOS settings available on this machine. Tried putting both kernel parameters AND *successfully* disabling ZenStates.py. Already had massive data loss at least twice. I really, really-really hope this issue won't turn into one of those 10-years-old issues.

AMD did publish an errata report, pointing that this may be fixed at software level (page 63).
https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

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.19-rc8, and Mesa to 18.2.2, I was still having stability problems (freezing with error messages in dmesg output). Made the changes in BIOS to typical current IDLE etc. and still was having issues.

But then realised I had not updated the amdgpu firmware, so grabbed the latest version from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git and everything seems to have been stable since then *fingers crossed*.

(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 solved by grabbing latest AMDGPU drivers.

(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're not the only
> one who is saying that the problem can be solved by grabbing latest AMDGPU
> drivers.

No idea, but I would say if you have outdated firmware, it is definitely worth trying updating to latest version.

@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

(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 using a separate GPU - I'm using the GPU built into the Ryzen 2200G APU. This is just firmware loaded by the amdgpu kernel driver.

The firmware is loaded and used by the amdgpu driver as far as I understand. I have just replaced all of the files in /lib/firmware/amdgpu with the latest version.

(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 Advance
>
> No flashing of video card or motherboard here. I'm not using a separate GPU
> - I'm using the GPU built into the Ryzen 2200G APU. This is just firmware
> loaded by the amdgpu kernel driver.
>
> The firmware is loaded and used by the amdgpu driver as far as I understand.
> I have just replaced all of the files in /lib/firmware/amdgpu with the
> latest version.

I'm using the rx580 with mesa stable and kubuntu 18.04.1.... I dont have this issue anymore after motherboard firmware update on another asrock board but just curious would this firmware help with performance or bug fixes on all AMD gpu?

(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 card?
> > > Are you flashing the motherboard?
> > >
> > > Thanks in Advance
> >
> > No flashing of video card or motherboard here. I'm not using a separate
> GPU
> > - I'm using the GPU built into the Ryzen 2200G APU. This is just firmware
> > loaded by the amdgpu kernel driver.
> >
> > The firmware is loaded and used by the amdgpu driver as far as I
> understand.
> > I have just replaced all of the files in /lib/firmware/amdgpu with the
> > latest version.
>
> I'm using the rx580 with mesa stable and kubuntu 18.04.1.... I dont have
> this issue anymore after motherboard firmware update on another asrock board
> but just curious would this firmware help with performance or bug fixes on
> all AMD gpu?

I don't know, but maybe if it's stable now you should stick with your current configuration.

Since the 2200G is the APU chip, which has built in graphics I think I may have experienced amdgpu and cpu-related issues (which this bug seems to be more related to), so I've needed a combination (new UEFI and amdgpu firmware) to get it stable.

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 doesn't expose anything like "typical current idle", etc.)

The only way I've been able to keep this system stable is to keep it busy. I run BOINC and donate some of this shark-style swim-or-die CPU to medical research. There are some nice settings for how the cores get used, and according to htop, tasks get shuffled around to all cores, if that matters. I went with using at most 50% of 25% of the cores (figures I pulled out of ...thin air). That keeps my load average around 2 when I'm doing nothing, but whatever - it's for a good cause.

My CPU is an AMD Ryzen 7 1800X with 8 or 16 cores depending on how one counts, and keeping them from getting bored has, so far, let me get back to rebooting on my terms (upgrades) rather than at random.

This comes up as a Linux problem, but it sure smells like a hardware defect to me. In my mind, all the self-monitoring and user-spying and background-indexing and auto-downloading that Windows does happens to mask this problem for most people. (Plus who would think twice about a randomly-hanging or -rebooting Windows box?) Has anyone run *BSD or FreeDOS or something else which would allow a Ryzen to get bored for hours/days?

> 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

(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 guides in my previous comments. They have no plans on fixing this and suggest using software workarounds. We're left on our own.

(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, not even a question. I've published one of
> their revision guides in my previous comments. They have no plans on fixing
> this and suggest using software workarounds. We're left on our own.

What is the "this" that AMD have no plans to fix ?

I had a look at <https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf> which you referenced earlier. I found 3 MWAIT issues:

  1057 MWAIT or MWAITX Instructions May Fail to Correctly Exit From
       the Monitor Event Pending State

  1059 In Real Mode or Virtual-8086 Mode MWAIT or MWAITX Instructions May
       Fail to Correctly Exit From the Monitor Event Pending State

  1109 MWAIT Instruction May Hang a Thread

but I could not find anything else that might be related to the "freeze when idle" problem.

FWIW, here's the full text for the Erratum 1109:

  1109 MWAIT Instruction May Hang a Thread

       Description: Under a highly specific and detailed set of internal timing
                    conditions, the MWAIT instruction may cause a thread to
                    hang in SMT (Simultaneous Multithreading) Mode.

       Potential Effect on System: The system may hang or reset.

       Suggested Workaround: System software may contain the workaround for
                             this erratum.

       Fix Planned: No fix planned

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" and how that relates to these MWAIT issues ??

...
> 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" and how that relates to these MWAIT issues ??

Good questions, and beyond my ken. "idle=nomwait" did not prevent my system from rebooting while I was away. (I don't know if reboots and freezes are separate problems?) My BIOS doesn't expose anything like "typical current idle", and I have no way to upgrade it since the upgrade tools require Windows.

Is there a guide out there for dummies like me to be able to collect kernel output from these reboots? (Does the kernel even get a chance to do/report anything? Would a report even be helpful to kernel hackers in figuring out more workarounds?) If I can contribute anything plausibly-constructive, I'd love to.

Otherwise, I use and need this machine, so I'll probably just keep treating the symptoms by keeping it busy. (Which I suppose is another software workaround. ;^)

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.

(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. Make space for win10 about 30GB with gparted in your main drive. Boot from the usb memory and install win10, skip registration key dialog etc.

(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 gparted fat32 formatted and
> bootable usb memory stick. Make space for win10 about 30GB with gparted in
> your main drive. Boot from the usb memory and install win10, skip
> registration key dialog etc.

Thanks, I didn't know that. But, since figuring out zenstates.py, I appear to be set. Fingers crossed! (Anyway, I'd rather keep the cpu busy than install windows. ;^)

<soapbox>
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.
</soapbox>

(In reply to Owen Swerkstrom from comment #446)
 <soapbox>
> 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.
> </soapbox>

Asus motherboards are the best, for Linux users especially. You can update the bios via the Ethernet connection or via a small fat32 partition with the Ez flash tool in the bios.

(In reply to fin4478 from comment #447)
> (In reply to Owen Swerkstrom from comment #446)
> <soapbox>
> > 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.
> > </soapbox>
>
> Asus motherboards are the best, for Linux users especially. You can update
> the bios via the Ethernet connection or via a small fat32 partition with the
> Ez flash tool in the bios.

My Asrock has all those features as well I believe.

*** Bug 201719 has been marked as a duplicate of this bug. ***

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 does anyhing (if my mobo even has that...)

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, freeze happens the same way; cursor stops blinking and I don't get any messages.

I am booting with nosmt=force rcu_nocbs=0-5 mem_encrypt=off
 (also CONFIG_RCU_NOCB_CPU=Y ).

Now, I don't feel like doing git-bisect (commits v4.18.19..v4.18.20),...
Does someone have ideas as to what to try next? Anything suspicious in v4.18.20 commits?

Some differences in dmesg 4.18.19..4.18.20:

-smpboot: Allowing 16 CPUs, 10 hotplug CPUs
+smpboot: Allowing 16 CPUs, 4 hotplug CPUs
-.... node #0, CPUs: #1 #2 #3 #4 #5
+.... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11
 smp: Brought up 1 node, 6 CPUs
 smpboot: Max logical packages: 3

-ACPI: (supports S0 S5)
+ACPI: (supports S0 S3 S5)

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! [amdgpu_cs:0:6535]
[12600.931702] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [(journald):18688]
[12600.931736] watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [amdgpu_cs:0:6535]

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 not related to a specific version, it just persists across all kernel versions.

Displaying first 40 and last 40 comments. View all 540 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.