On Sun, Jan 05, 2014 at 12:14:53AM +0100, Aleksandar Kuktin wrote: > >On Sat, 04 Jan 2014 23:33:13 +0100 > >"Armin K." <kre...@email.com> wrote: > > > > On 01/04/2014 11:25 PM, Aleksandar Kuktin wrote: > > > > What exactly is intel-ucode-20130222 for? > > > > CPU microcode update. It updates CPU microcode at runtime using > > "microcode" driver in the kernel. It's firmware actually. > > > > Now that you mention it, it seems that it doesn't work anymore > > somehow, probably since I've built microcode driver into kernel but > > firmware is in /lib/firmware.
Yeah, a similar "progress update" on lkml at the end of this week reporting (in the context of an original report that it was ok in 3.8.2 but broke in 3.8.3) that in fact it doesn't work if built in. Certainly, when I last tried firmware updates (perhaps 6 months ago) I had the impression that none of my boxes had available newer firmware, but I was almost certainly building it in. > > Hmm.. Any improvements in the way system handles itself with the new > firmware? Normally I use AMD, but I'm now on an Intel box so I have to > bother with this a bit. Apart from anything else, you need a CPU version for which updates have been issued (I guess that is usually to install workarounds for errata). In the lkml thread I got involved in, I think that kmail was unusable without the update! Not at all what I had expected. Meanwhile both my own and the other guy's AMD phenoms tend to lose their lunch when using 'make -j4' (fixed by dropping the caches and using -j3) and apparently the firmware update might not alter that. > > BTW, I found that putting firmware into the kernel binary (as opposed > to /lib/firmware) works best for me. No need to deal with helper > programs and other such stuff. > For ordinary drivers (video, particularly radeon, and nic or wifi) that seems to be easier - it does, however, waste kernel memory which is why kernel devs don't recommend it - I guess that is more important on a distro which builds everything, and for 32-bit kernels where at most 4GB (less PCI space, particularly for video) is addressable. The notes look interesting, particularly /lib and /lib32, but I'm supposed to be spending all my time on my (UK) tax return this month, and for the moment I can't afford to study them. Also, I used to think that X32 would be interesting - but modern DDR3 memory sticks are so big that I'm no longer convinced that would be worth the effort. And I don't need any 32-bit binaries in linux. So maybe I won look to deeply at multilib. But it's always interesting to see how other people build things, particularly the order, and to challenge my choices. So, thanks. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
