| 1 |
On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@×××××.com> wrote: |
| 2 |
> On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman |
| 3 |
> <paul.hartman+gentoo@×××××.com> wrote: |
| 4 |
>> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@×××××.com> wrote: |
| 5 |
>>> OK, I got it to load by hand: |
| 6 |
>>> |
| 7 |
>>> 1) emerge microcode-ctl |
| 8 |
>>> |
| 9 |
>>> which also emerges microcode-data. Unfortunately microcode-data looks |
| 10 |
>>> to be out of date. |
| 11 |
>> |
| 12 |
>> The ebuild for newer versions (including the latest 20101123) is in |
| 13 |
>> portage as ~amd64 and ~x86. |
| 14 |
>> |
| 15 |
>> |
| 16 |
> |
| 17 |
> Thanks Paul. |
| 18 |
> |
| 19 |
> Also, it does seem to work, for Intel anyway, as a module or built |
| 20 |
> into the kernel. I chose to build it in as I'm tired of how long lsmod |
| 21 |
> is looking these days. |
| 22 |
|
| 23 |
If you use the /etc/init.d/microcode_ctl runscript and have |
| 24 |
MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the |
| 25 |
default), it will unload the module automatically after it runs, so |
| 26 |
you shouldn't see it in lsmod anyway, and saves a few kb of memory. |
| 27 |
But, quite honestly, 8kb of memory is probably inconsequential on a |
| 28 |
system where microcode_ctl is being used in the first place... :) |
Archives