| 1 |
On Saturday 30 Apr 2016 17:50:44 Neil Bothwick wrote: |
| 2 |
> On 30 April 2016 16:02:49 BST, Peter Humphrey <peter@××××××××××××.uk> |
| 3 |
> wrote: |
| 4 |
> > On Saturday 30 Apr 2016 10:05:40 Jonathan Callen wrote: |
| 5 |
> > > The proper way to load microcode into the kernel is now to have it |
| 6 |
> > > be part of an initramfs (the initramfs doesn't (I think) have to |
| 7 |
> > > actually do anything, just have the microcode firmware in the |
| 8 |
> > > appropriate location). This is because some things in userspace (like |
| 9 |
> > > glibc itself) only check once for certain CPU features at startup, and |
| 10 |
> > > newer microcode will actually disable some of those features on some |
| 11 |
> > > CPUs (because they are completely broken anyway). This means that |
| 12 |
> > > loading the microcode before any userspace programs run will ensure |
| 13 |
> > > that applications like /sbin/init won't crash just because a feature |
| 14 |
> > > they thought they could use suddenly disappeared. |
| 15 |
> > |
| 16 |
> > Still, it would be better if all kernel versions behaved the same way |
| 17 |
> > in this respect. |
| 18 |
> |
| 19 |
> Not if the newer way is better, which appears to be the case here. |
| 20 |
|
| 21 |
My results show the behaviour alternating between versions, not simply |
| 22 |
progressing from the old to the new. You'd be right of course in the latter |
| 23 |
case. |
| 24 |
|
| 25 |
-- |
| 26 |
Rgds |
| 27 |
Peter |
Archives