Date: Mon, 27 Aug 2018 23:07:28 +0800 From: Meowthink <meowthink@gmail.com> To: "karu.pruun" <karu.pruun@gmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Help diagnose my Ryzen build problem Message-ID: <CABnABobTqsQOVHEtP8ybUo3t6ZUonxAKR8F5kAN%2B8GpxNFrX0g@mail.gmail.com> In-Reply-To: <CADdF=MKUOwkZwOb8qAdOHv0uWAPZVjJW8i_CvWoTMSa=p4B8Qw@mail.gmail.com> References: <CABnABoZA4DUOFfr7JdbbBAWxak3=ge6zX0HXtu1RffQH7tSb2Q@mail.gmail.com> <CAOa8eG4UGCo3Evz7sp7w72irtP2yb=-9-KURrvCQGu6Z-1HwVA@mail.gmail.com> <20180827132905.191dbd8c@ernst.home> <CABnABobmAv_-wCCkRiq6iYQ67mmKbC-g8J5_1K55qCktvVhF%2BA@mail.gmail.com> <CADdF=MKUOwkZwOb8qAdOHv0uWAPZVjJW8i_CvWoTMSa=p4B8Qw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi peeter, On 8/27/18, karu.pruun <karu.pruun@gmail.com> wrote: > On Mon, Aug 27, 2018 at 3:21 PM Meowthink <meowthink@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABnABobTqsQOVHEtP8ybUo3t6ZUonxAKR8F5kAN%2B8GpxNFrX0g>