From owner-freebsd-stable@freebsd.org Tue Aug 28 15:47:22 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C76F108FEF5; Tue, 28 Aug 2018 15:47:22 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E25A8A7DC; Tue, 28 Aug 2018 15:47:22 +0000 (UTC) (envelope-from meowthink@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id m11-v6so3707949oic.2; Tue, 28 Aug 2018 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qXyAvNjumhujN3WX0qEB6idGe6QmP0AiZO0Bkfb0+Gg=; b=uB8Xfrf0TW3b60TdeXe9W+MR44PCoNT7PvmnVozjh24mxFpZhYHmHnqx5+8fPaU5I0 CzDBYrWuTmOOq7ZarZruSyNT3Qu8vg18DAQvH7q1PchEt8cd8GGOaY3CfzrWf34p/D6p hcuappI2CqlbA9RtwK5fG+z/ihJzW/bWCDRpR2JSDFuPPILTjCbSmparxsBZU29wHGA1 VgYSEsKpeQYm9EFBO8jIX5iOrw+uym3v3wEMMKQLsq0qX9oFKLXJpBkldaOKMqglZkA+ WO7KBA7N5ISut5XdTb9iRaiMhOLjUb9Gi8JwXgb6WQo7ilM4ahA5Xbvh55QbfK7/2UCa kFTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qXyAvNjumhujN3WX0qEB6idGe6QmP0AiZO0Bkfb0+Gg=; b=ez+wStvih7XCPuxdoN9rRwC657l8ClD0W5+fdW4hepgduHvHGqlMASE8sXL9KcAKk+ q4oNrXqIngwT0CZJXmRmxHXiYZdJllncxCNzH/pgptdvCFjh3X7EX7nuIXw1HItkaIXF 19Tf4BIL7dqSenjJttozI8cmao5MmJhaIt+2RrsupeD/fHEq7kDHgMOyWzLQ9uKm9ftO l5i76dqeeDVIoqTLppSWnJ50UER+wrsQYVyKCz+2WfEHG5a6jP4KNHGXJbo1p47ESj6x 3yoa7tlZXUhpeYovPdaZzMREyfafLWc+ppqa8aur2lx7g9QwiZXoCTrx+Cuwhkj+eGo+ qc+g== X-Gm-Message-State: APzg51DHeOkSH5DGUUlKF5rWHbZuNeWiLuLdvxm/T0OxatemTDSi9PBa yn6IrvsdpU/ETyruQ25ML1VLKORm6RnCUZrBtZA= X-Google-Smtp-Source: ANB0VdZEGQXLFqeWgykXke6mXTZ1kQ7wLpdovAqm3jYSzN4p9/w84RW3HRz3Y0HFyconwrGM+7ZcMLcuef4NTYBSWuU= X-Received: by 2002:aca:4802:: with SMTP id v2-v6mr1841203oia.259.1535471241321; Tue, 28 Aug 2018 08:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a54:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 08:47:20 -0700 (PDT) From: Meowthink Date: Tue, 28 Aug 2018 23:47:20 +0800 Message-ID: Subject: Re: Help diagnose my Ryzen build problem (in progress) To: "karu.pruun" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:47:22 -0000 Hi Peeter, On 8/28/18, karu.pruun wrote: > On Mon, Aug 27, 2018 at 6:07 PM Meowthink 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. It works! After hours and hours of different stressing. I got 8 copies of gcc built without any problem. But it costs lots of power and the fan will become very annoying. As so, I don't think I'll test long term stability with this state. machdep.idle: acpi -> spin - will add ~5W, maybe some deeper C states disabled? machdep.idle_mwait: 1 -> 0 - will add another ~50W, CPUs are working insomniac. I tried to set machdep.idle_mwait to 1, or machdep.idle to mwait. Both failed with panics when I start building gcc pass by pass. I'm pretty sure mwait will cause problem, as once I experienced a panic immediately after I issued the sysctl command (the 2nd dump info followed) So my next step will be hlt. Still need some time, though. > > Cheers > > Peeter > > -- > Cheers, meowthink ------------------------------------------------------------------------ machdep.idle=mwait panic: ffs_syncvnode: syncing truncated data. cpuid = 7 KDB: stack backtrace: #0 0xffffffff80b414b7 at kdb_backtrace+0x67 #1 0xffffffff80afa9e7 at vpanic+0x177 #2 0xffffffff80afa863 at panic+0x43 #3 0xffffffff80dcddc4 at ffs_syncvnode+0x5a4 #4 0xffffffff80dcc915 at ffs_fsync+0x25 #5 0xffffffff810ffcb2 at VOP_FSYNC_APV+0x82 #6 0xffffffff80bc3a62 at sched_sync+0x412 #7 0xffffffff80abd813 at fork_exit+0x83 #8 0xffffffff80f5cc7e at fork_trampoline+0xe ------------------------------------------------------------------------ machdep.idle_mwait=1 Fatal trap 9: general protection fault while in kernel mode cpuid = 7; apic id = 07 instruction pointer = 0x20:0xffffffff80e094fe stack pointer = 0x0:0xfffffe081e5df9e0 frame pointer = 0x0:0xfffffe081e5dfa50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (dom0) trap number = 9 panic: general protection fault cpuid = 7 KDB: stack backtrace: #0 0xffffffff80b414b7 at kdb_backtrace+0x67 #1 0xffffffff80afa9e7 at vpanic+0x177 #2 0xffffffff80afa863 at panic+0x43 #3 0xffffffff80f7c14f at trap_fatal+0x35f #4 0xffffffff80f7b70e at trap+0x5e #5 0xffffffff80f5bccc at calltrap+0x8 #6 0xffffffff80e07a17 at vm_pageout+0x87 #7 0xffffffff80abd813 at fork_exit+0x83 #8 0xffffffff80f5cc7e at fork_trampoline+0xe