From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0@n0.is Subject: Re: Linux-libre-4.15 and the NVMe module Date: Mon, 29 Jan 2018 17:09:01 +0000 Message-ID: <87r2q83842.fsf@abyayala.i-did-not-set--mail-host-address--so-tickle-me> References: <87fu6obvfa.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egCvj-0004mi-JR for guix-devel@gnu.org; Mon, 29 Jan 2018 12:09:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egCve-0000Hz-Jr for guix-devel@gnu.org; Mon, 29 Jan 2018 12:09:15 -0500 Received: from aibo.runbox.com ([91.220.196.211]:40288) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1egCve-0000H3-Cd for guix-devel@gnu.org; Mon, 29 Jan 2018 12:09:10 -0500 Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1egCva-0001Za-Rs for guix-devel@gnu.org; Mon, 29 Jan 2018 18:09:06 +0100 Received: from dslb-092-073-177-142.092.073.pools.vodafone-ip.de ([92.73.177.142] helo=localhost) by mailfront11.runbox.com with esmtpsa (uid:892961 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1egCvU-0001Lf-Nu for guix-devel@gnu.org; Mon, 29 Jan 2018 18:09:00 +0100 In-Reply-To: <87fu6obvfa.fsf@netris.org> (Mark H. Weaver's message of "Mon, 29 Jan 2018 09:18:17 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Hi, On Mon, 29 Jan 2018, Mark H Weaver wrote: > Hello Guix, > > I've pushed a new 'kernel-updates' branch that includes the update to > linux-libre-4.15, and asked Hydra to build it. However, I haven't yet > pushed this to 'master' because of a complication. > > At present, all of our kernel configurations have CONFIG_BLK_DEV_NVME=m > which results in an "nvme.ko" module, and this module is included in the > list of modules to be copied to our 'base-initrd' and loaded during > early boot. Oh, good that you've looked deeper into this. I planned to when the rc's started showing this problem but didn't really follow-up to it. > Unfortunately, it seems that in linux-libre-4.15, we must now have > CONFIG_BLK_DEV_NVME=y (built-in) if we wish to keep CONFIG_NVM=y > (Open-Channel SSD target support), which we've had enabled in our kernel > configurations since 4.4. CONFIG_NVM cannot be made modular, and in > 4.15 it now depends on CONFIG_BLK_DEV_NVME=y. > > Since I don't see a nice way in our current 'base-initrd' implementation > to conditionally include "nvme.ko" depending on the kernel > configuration, I simply removed "nvme.ko" from the list of modules, and > changed all of our kernel configurations to have CONFIG_BLK_DEV_NVME=y. > > While I was at it, I updated our older kernel configurations to the > current point releases, using "make oldconfig". My main motivation for > doing this was to explicitly show in our config files that we've enabled > the mitigations for meltdown and spectre. > > Any comments on this approach? Other suggestions? > > Mark > > I think in general it's okay. I'm still rebuilding my server with the patches taken from your branch. I suspect not to run into any problems with it, and skipping the commits they looked good to me. Of course I can only test for x86, not i686 or aarch64 Thanks! -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/