From owner-freebsd-current@freebsd.org Tue Sep 11 03:55:29 2018 Return-Path: Delivered-To: freebsd-current@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 8011610A7BBC for ; Tue, 11 Sep 2018 03:55:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "mail.nomadlogic.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA0C8838AF; Tue, 11 Sep 2018 03:55:28 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from creek.local (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 1b51ea0a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 10 Sep 2018 20:55:26 -0700 (PDT) Subject: Re: testing early microcode loading To: Mark Johnston Cc: freebsd-current@freebsd.org References: <20180910182655.GA2849@raichu> <812c75e6-e77b-7559-3d0e-06085df10d0f@nomadlogic.org> <20180911004117.GE2849@raichu> From: Pete Wright Message-ID: <6eee4e31-b6ff-bc32-5974-9bb261eb82df@nomadlogic.org> Date: Mon, 10 Sep 2018 20:55:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180911004117.GE2849@raichu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 03:55:29 -0000 On 9/10/18 5:41 PM, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >> >> On 9/10/18 11:26 AM, Mark Johnston wrote: >>> Hi, >>> >>> Support for boot-time loading of Intel microcode updates has landed in >>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>> I'd like to solicit some testing of the feature ahead of 12.0. >> Hey there Mark, >> So I've just tested this on a kabylake system running a kernel/world >> from Sept 7th which I believe is recent enough. >> >> After updating /boot/loader.conf as per your email I am not sure if any >> microcode updates are being applied.  I'm not seeing any messages >> regarding firmware updates being applied in the dmesg buffer.  > Right, we currently print something only if an update was configured > but failed to apply. We should probably print something either way, > perhaps only if the kernel is booted with -v. i could certainly as being helpful for debugging. >> running x86info results in the following: >> >> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >> Microcode version: 0x000000000000008e >> >> this is after rebooting with the updated loader.conf as well as running >> the rc script by hand.  i didn't think to compare the output of x86info >> before running the rc script, i can do that later today. > Thanks. If the boot-time update succeeded, the rc script should have > been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages > in /var/log/messages? That would indicate that the rc script applied an > update, which would imply that the boot-time update failed somehow. when i ran the rc script after boot i saw the CPU related messages in dmesg on the console (CPU count, type, features, etc).  i did not see anything in /var/log/messages of interest either.  i'll re-test tomorrow when i get back into the office and let you know if i see anything of interest.  my plan is to: - boot with the /boot/loader.conf additions for applying microcode and save the output from x86info - boot with loader.conf settings uncommented, view output of x86conf - then run rc script and get output of x86conf -pete -- Pete Wright pete@nomadlogic.org 310.309.9298