Date: Tue, 28 Aug 2018 10:54:17 +0300 From: "karu.pruun" <karu.pruun@gmail.com> To: Si Miao <meowthink@gmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Help diagnose my Ryzen build problem Message-ID: <CADdF=ML8S47k6Lq9bUJE=kKCXTzytsMh%2BuytCC1nQqm407jVcQ@mail.gmail.com> In-Reply-To: <CABnABobTqsQOVHEtP8ybUo3t6ZUonxAKR8F5kAN%2B8GpxNFrX0g@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> <CABnABobTqsQOVHEtP8ybUo3t6ZUonxAKR8F5kAN%2B8GpxNFrX0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 27, 2018 at 6:07 PM Meowthink <meowthink@gmail.com> wrote: > >> 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? If I was you, I'd play around with the sysctls mentioned above and see if it helps. Start with disabling both mwait and hlt, perhaps machdep.idle=spin machdep.idle_mwait=0 (assuming that 'spin' means hlt will not used) and then if that does not lead to a panic, try enabling mwait. I can't test 2400G since I don't have it any more. I booted FreeBSD a couple of times but did not run it over long periods of time. Cheers Peeter --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADdF=ML8S47k6Lq9bUJE=kKCXTzytsMh%2BuytCC1nQqm407jVcQ>