1 |
On Tue, Jan 18, 2011 at 2:56 PM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote: |
3 |
>> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@×××××.com> wrote: |
4 |
>> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman |
5 |
>> > |
6 |
>> > <paul.hartman+gentoo@×××××.com> wrote: |
7 |
>> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@×××××.com> |
8 |
> wrote: |
9 |
>> >>> OK, I got it to load by hand: |
10 |
>> >>> |
11 |
>> >>> 1) emerge microcode-ctl |
12 |
>> >>> |
13 |
>> >>> which also emerges microcode-data. Unfortunately microcode-data looks |
14 |
>> >>> to be out of date. |
15 |
>> >> |
16 |
>> >> The ebuild for newer versions (including the latest 20101123) is in |
17 |
>> >> portage as ~amd64 and ~x86. |
18 |
>> > |
19 |
>> > Thanks Paul. |
20 |
>> > |
21 |
>> > Also, it does seem to work, for Intel anyway, as a module or built |
22 |
>> > into the kernel. I chose to build it in as I'm tired of how long lsmod |
23 |
>> > is looking these days. |
24 |
>> |
25 |
>> If you use the /etc/init.d/microcode_ctl runscript and have |
26 |
>> MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the |
27 |
>> default), it will unload the module automatically after it runs, so |
28 |
>> you shouldn't see it in lsmod anyway, and saves a few kb of memory. |
29 |
>> But, quite honestly, 8kb of memory is probably inconsequential on a |
30 |
>> system where microcode_ctl is being used in the first place... :) |
31 |
> |
32 |
> Is the /etc/microcode.dat path a bug, now that firmware is typically placed in |
33 |
> /lib/firmware? |
34 |
> |
35 |
> Shall I create a symlink or raise a bug report? |
36 |
|
37 |
On my ~amd64 system, using microcode-ctl-1.17-r2 and |
38 |
microcode-data-20101123 the data is installed to /lib/firmware and the |
39 |
runscript does: |
40 |
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV} |
41 |
|
42 |
I think the gentoo packages are designed for you to use the installed |
43 |
runscript which works when you use the microcode-data package from |
44 |
portage since they both use the /lib/firmware location. |
45 |
|
46 |
Based on this I would guess that it is not a bug, but that it is the |
47 |
intended behavior. |