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.
