On Tuesday 18 January 2011 21:13:49 Paul Hartman wrote:
> On Tue, Jan 18, 2011 at 2:56 PM, Mick <michaelkintz...@gmail.com> wrote:
> > 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?
>
> 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.Yes Paul, you're right. In the days before /lib/firmware was made available I recall that /etc/microcode.dat was the default location of the code. Now that I just ran it by hand once, it complained that /etc/microcode.dat doesn't exist. However, following your prompt I looked at the /etc/init.d/microcode-ctl script and it all makes sense. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
