From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PfJfl-0006fN-S6 for garchives@archives.gentoo.org; Tue, 18 Jan 2011 22:05:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8BDBE0943 for ; Tue, 18 Jan 2011 22:05:04 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 02910E0819 for ; Tue, 18 Jan 2011 21:13:49 +0000 (UTC) Received: by bwg12 with SMTP id 12so154394bwg.40 for ; Tue, 18 Jan 2011 13:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=NJFciLUW1VyOwkQw7kim9WMMC2bQVYzfX43Yi7MyXV8=; b=BjEjTnOzwFhSHImCyWBTrXzCKLFr5JMlc1+62C42qA+bXDBwghgTFrcU08iZkYJC9y dAq9cyjdGsg/UEIptnzCgxabBVHYpByldmPoBr/5mjS8je9TsOzfxYKD434NurPOBz3m lJpcffnAmi42QrnoDGqgdCMIizbldkAojl3xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=xvWnNduqwxuMDVhNpqpcNdUX7CUwn8lv0perNt1sjZjsbGJht4k2TWleK19ZL+vwPK Up/I1P4UhRoAm757ZDNT8GPRa3+5GZHUdQaB3kFZ/1Pqi7TpIMMjz059kKj/eJJ5OdgS oHgHRAGuQJFg1SbUMgybFL9ORmOzP5hxUK/GM= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.57.197 with SMTP id d5mr4000608bkh.63.1295385229079; Tue, 18 Jan 2011 13:13:49 -0800 (PST) Sender: paul.hartman@gmail.com Received: by 10.204.18.197 with HTTP; Tue, 18 Jan 2011 13:13:49 -0800 (PST) In-Reply-To: <201101182056.22212.michaelkintzios@gmail.com> References: <20110117172148.GD5748@solfire> <201101182056.22212.michaelkintzios@gmail.com> Date: Tue, 18 Jan 2011 15:13:49 -0600 X-Google-Sender-Auth: s2JZtjAAYIrU5Z3uKnmL6TVHaDM Message-ID: Subject: Re: [gentoo-user] Microcode update AMD From: Paul Hartman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: X-Archives-Hash: 5f737fbed5d1e4fd19bdf939a26ee8c1 On Tue, Jan 18, 2011 at 2:56 PM, Mick wrote: > On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote: >> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht wrote: >> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman >> > >> > wrote: >> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht > wrote: >> >>> OK, I got it to load by hand: >> >>> >> >>> 1) emerge microcode-ctl >> >>> >> >>> which also emerges microcode-data. Unfortunately microcode-data looks >> >>> to be out of date. >> >> >> >> The ebuild for newer versions (including the latest 20101123) is in >> >> portage as ~amd64 and ~x86. >> > >> > Thanks Paul. >> > >> > Also, it does seem to work, for Intel anyway, as a module or built >> > into the kernel. I chose to build it in as I'm tired of how long lsmod >> > is looking these days. >> >> If you use the /etc/init.d/microcode_ctl runscript and have >> MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the >> default), it will unload the module automatically after it runs, so >> you shouldn't see it in lsmod anyway, and saves a few kb of memory. >> But, quite honestly, 8kb of memory is probably inconsequential on a >> system where microcode_ctl is being used in the first place... :) > > Is the /etc/microcode.dat path a bug, now that firmware is typically placed in > /lib/firmware? > > Shall I create a symlink or raise a bug report? On my ~amd64 system, using microcode-ctl-1.17-r2 and microcode-data-20101123 the data is installed to /lib/firmware and the runscript does: microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV} I think the gentoo packages are designed for you to use the installed runscript which works when you use the microcode-data package from portage since they both use the /lib/firmware location. Based on this I would guess that it is not a bug, but that it is the intended behavior.