On Mon, Aug 27, 2018 at 3:21 PM Meowthink <meowthink at gmail.com> wrote:> That's kib, who has committed things in that script to both 12 [1] and > stable/11 [2]. > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > Ryzen 5 2400G's model is 11h. > > On the microcode. It shall be updated through UEFI/BIOS updates. I > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > 0x810100b. > > Seems like ... the only thing I can do is sit down and wait?The revision https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 works around the mwait issue, i.e. it sets sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt Now it may or may not relate to your problem, but it appears that Ryzen 2400G also has another issue with HLT, see the DragonFly bug report https://bugs.dragonflybsd.org/issues/3131 which AMD is aware of and is possibly working on, but it may not have appeared in the errata yet. The bug report says that until this is fixed, the workaround is to also disable HLT in cpu_idle. I am not sure what is the correct value for the sysctl on FreeBSD, perhaps sysctl machdep.idle=0 or some other value? Cheers Peeter --
On Mon, 27 Aug 2018 16:16:47 +0300 "karu.pruun" <karu.pruun at gmail.com> wrote:> On Mon, Aug 27, 2018 at 3:21 PM Meowthink <meowthink at gmail.com> wrote: > > That's kib, who has committed things in that script to both 12 [1] and > > stable/11 [2]. > > > > Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my > > Ryzen 5 2400G's model is 11h. > > > > On the microcode. It shall be updated through UEFI/BIOS updates. I > > think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel > > 0x810100b. > > > > Seems like ... the only thing I can do is sit down and wait? > > The revision > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > works around the mwait issue, i.e. it sets > > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > Now it may or may not relate to your problem, but it appears that > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > report > > https://bugs.dragonflybsd.org/issues/3131 > > which AMD is aware of and is possibly working on, but it may not have > appeared in the errata yet. The bug report says that until this is > fixed, the workaround is to also disable HLT in cpu_idle. I am not > sure what is the correct value for the sysctl on FreeBSD, perhaps > > sysctl machdep.idle=0 > > or some other value? >It is in the latest errata and there are no plans to fix it. Based on the detailed description, this is a problem only in a hypervisor. AMD has a suggested workaround for it. -- Gary Jennejohn
Hi peeter, On 8/27/18, karu.pruun <karu.pruun at gmail.com> wrote:> On Mon, Aug 27, 2018 at 3:21 PM Meowthink <meowthink at gmail.com> wrote: >> That's kib, who has committed things in that script to both 12 [1] and >> stable/11 [2]. >> >> Unfortunately, that's for Ryzens family 17h model 00h-0fh, whereas my >> Ryzen 5 2400G's model is 11h. >> >> On the microcode. It shall be updated through UEFI/BIOS updates. I >> think mine is now PinnaclePI-AM4_1.0.0.4 with microcode patchlevel >> 0x810100b. >> >> Seems like ... the only thing I can do is sit down and wait? > > The revision > > https://svnweb.freebsd.org/base/head/sys/x86/x86/cpu_machdep.c?r1=336763&r2=336762&pathrev=336763 > > works around the mwait issue, i.e. it sets > > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt >I think that shall not apply to 2400G, which is model 11h not 1h. Here're what I have now: machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi machdep.idle_apl31: 0 machdep.idle_mwait: 1> Now it may or may not relate to your problem, but it appears that > Ryzen 2400G also has another issue with HLT, see the DragonFly bug > report > > https://bugs.dragonflybsd.org/issues/3131 >Thanks a lot for that info. It's much easier to prove your problem, since it's reproducible. But mine was so random to catch... Anyway, it seems like the IRET issue [1] is still not fixed? I'm highly doubt that my issue is this related because my system became significantly more stable since I stop that irq storm from bluetooth module - Though it still panics occasionally. So could anybody tell, what's the difference between FreeBSD workaround [2] and the DragonflyBSD one?> which AMD is aware of and is possibly working on, but it may not have > appeared in the errata yet. The bug report says that until this is > fixed, the workaround is to also disable HLT in cpu_idle. I am not > sure what is the correct value for the sysctl on FreeBSD, perhaps > > sysctl machdep.idle=0 > > or some other value?In the meantime, I have this microcode # cpucontrol -m 0x8b /dev/cpuctl0 MSR 0x8b: 0x00000000 0x0810100b Hence I should use mwait? Still don't know what should I set. Any idea?> > Cheers > > Peeter > > -- >Thank you for your direction. Cheers, meowthink [1] http://lists.dragonflybsd.org/pipermail/commits/2017-August/626190.html [2] https://reviews.freebsd.org/D11780