On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote: > On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markkne...@gmail.com> wrote: > > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman > > > > <paul.hartman+gen...@gmail.com> wrote: > >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markkne...@gmail.com> 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? -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
