ever thought that hardware is „NOT“ faulty? it is.

ever thought that software can fix hardware?

it can.

root@dwaves:/usr/share/doc/intel-microcode# vim NEWS.Debian

intel-microcode (1.20140913.1) stable; urgency=low

    This release drops support for automatically applying microcode
intel-microcode (1.20140913.1) stable; urgency=low

    This release drops support for automatically applying microcode
    updates without a reboot.  The microcode updates can still be applied
    without a reboot through manual action of the system administrator,
    but this operation is not considered safe anymore.

    Microcodes known to be dangerous have been renamed so that they will
    not be found by the microcode module, except inside the initramfs.
    This is a reactive blacklisting: it is unlikely to be complete at any
    point in time.

    Refer to /usr/share/doc/intel-microcode/README.Debian for details.

 -- Henrique de Moraes Holschuh <hmh@debian.org>  Fri, 10 Oct 2014 12:27:57 -0300

intel-microcode (1.20120606.4) unstable; urgency=low

    The initramfs logic to automatically restrict the microcodes that have
    to be installed using iucode-tool can fail in a very specific situation
    when the intel-microcode package is installed for the first time at the
    same time the _currently running_ kernel is being upgraded.

    intel-microcode will warn you should that happen, and will install all
    microcodes, resulting in a much larger initramfs image than expected.

    If you did hit this failure mode and you believe the large initramfs
    will cause problems for your system to reboot, please remove the
    intel-microcode package to reduce the initramfs size, reboot to load
    the upgraded kernel, and then reinstall the intel-microcode package.

    Once the intel-microcode package is installed, it will cooperate with
    the kernel packages and automatically avoid the issue on future
    upgrades.

 -- Henrique de Moraes Holschuh   Sat, 11 Aug 2012 19:02:20 -0300

intel-microcode (1.20120606.1) unstable; urgency=low

    This major release update changes how Debian handles Intel system
    processor microcode updates.  Initscripts and the old microcode.ctl
    utility are not used to load microcode anymore.

    Previously, microcode.ctl would be used to read the text file
    distributed by Intel (microcode.dat), convert it to binary, and upload
    to /dev/cpu/microcode.  This functionality has been deprecated in the
    kernel upstream for a long time, the firmware loader and a sysfs
    interface should be used instead.

    The Intel microcode.dat file is now preprocessed using iucode-tool when
    the intel-microcode package is built, and the resulting binary data
    files for /lib/firmware/intel-ucode are shipped, ready for use by the
    kernel.

    The intel-microcode package now provides automation for autoloading
    microcode from the initramfs, instead of relying on any initscripts.
    Refer to the README files in /usr/share/ doc/intel-microcode for more
    details; there is some limited support for /usr/share/misc/
    intel-microcode.dat files.

    If you don't use an initramfs for a custom-built kernel, please make
    sure the microcode driver is a module, and to load it at a time
    /lib/firmware is already available.  Adding it to /etc/modules is
    usually enough.  In this specific case, /usr/share/misc/
    intel-microcode.dat is not supported, refer to the README files for
    more detail.

    WARNING: if you have an old /usr/share/misc/intel-microcode.dat file,
    it may cause problems because of the way Intel does microcode release
    management.  As a rule, it is best to remove outdated microcode.dat
    files from the system.

 -- Henrique de Moraes Holschuh <hmh@debian.org>  Tue, 10 Jul 2012 16:06:06 -0300
                                                                                                                                                                                                                          73,2          Bot
admin