In the second case, I tried downloading the 5700 tar.gz file from the original thread on kernel bugtracker:

bash-4.2# cd
bash-4.2# cd microcode/
bash-4.2# ls -al
total 172
drwxr-xr-x 2 root root 4096 Oct 21 18:53 .
drwx--x--- 23 root root 4096 Oct 21 18:58 ..
-rw-r--r-- 1 1000 1000 21504 Sep 30 01:32 2494656.bin
-rw-r--r-- 1 1000 1000 22528 Sep 30 01:32 2516160.bin
-rw-r--r-- 1 1000 1000 24576 Sep 30 01:32 2538688.bin
-rw-r--r-- 1 1000 1000 10240 Sep 30 01:32 2563264.bin
-rw-r--r-- 1 root root 78384 Oct 21 18:46 5700hq-ucode.tar.gz
bash-4.2# iucode_tool -Sl -K --overwrite --write-earlyfw=/boot/intel-ucode.img *.bin
iucode_tool: system has processor(s) with signature 0x00040671
selected microcodes:
001: sig 0x00040671, pf mask 0x22, 2015-03-27, rev 0x000d, size 10240
iucode_tool: Writing selected microcodes to: /boot/intel-ucode.img
iucode_tool: Writing microcode firmware file(s) into /lib/firmware/intel-ucode
bash-4.2#


Same results... nothing.

@Freaksta
Have you done no.6 from the post by atelszewski, that is something like

Can you paste your full /etc/lilo.conf?

Yes, that's what's so frustrating.

So, I generated the /boot/intel-ucode.img via the tool, and then created a initram via the /usr/share/mkinitrd/mkinitrd_command_generator.sh command output.

I then ran the 'cat /boot/intel-ucode.img initrd.gz > /boot/ucodeinit.gz'

input ucode.init.gz into my lilo and same results... 0x19

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" vt.default_utf8=0"
boot = /dev/sda

#compact # faster, but won't work on all systems.

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
reset
# VESA framebuffer console @ 1024x768x64k
vga = 791
# Normal VGA console
#vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
#vga=791
# VESA framebuffer console @ 1024x768x32k
#vga=790
# VESA framebuffer console @ 1024x768x256
#vga=773
# VESA framebuffer console @ 800x600x64k
#vga=788
# VESA framebuffer console @ 800x600x32k
#vga=787
# VESA framebuffer console @ 800x600x256
#vga=771
# VESA framebuffer console @ 640x480x64k
#vga=785
# VESA framebuffer console @ 640x480x32k
#vga=784
# VESA framebuffer console @ 640x480x256
#vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuznew
root = /dev/sda1
initrd = /boot/ucodeinit.gz
label = Linux
read-only
# Linux bootable partition config ends
# recovery
image = /boot/vmlinuz
root = /dev/sda1
label = Recovery
read-only
# end

using built in ext4 support, not sure if that matters. ext4 is '*' in my kernel.

Hi,

The current kernel as of Sat Nov 14 21:35:57 UTC 2015 update, has the following:
The prayers have been listened

--
Best regards,
Andrzej Telszewski

Great! It seems, asking in the Desired updates thread was a right approach
Meanwhile, new Intel microcode 20151106 is out.
Turning back to the idea that the intel-microcode SlackBuild could create /boot/ucode.cpio. With grub this would work even more smooth that with lilo. One can use something likein /boot/grub/grub.cfg and then the only thing user will have to do after an upgrade of the intel-microcode is to reboot.

Hi,

I'm against. The sole purpose of the SlackBuild is to provide easy and maintainable access to the microcode.
It's up to the user to decide what to do later.

You already mentioned that GRUB can handle the microcode in different manner than LILO.
Also, somebody might want to have different name than /boot/ucode.cpio.

For the time being, intel-microcode.SlackBuild maintainer's (well, me) decision is to leave the SlackBuild as is.
Although, it might change in the future

--
Best regards,
Andrzej Telszewski

OK. After all, it's only one command. And the need of reboot makes the process not completely automatic in any case.

Hi,

Well, not exactly You always apply the microcode to the running system.
The only reason to reboot would be if you knew that the particular microcode update needs to be applied early in the boot.
Anyway, it's probably the safest choice to use early microcode update method and rebooting the system when newer microcode is present on the system.

--
Best regards,
Andrzej Telszewski

Dear Andrzej,

I understand your logic, except for creating /lib/firmware/intel-ucode. If I understand correctly, the Slackbuild as it is now, in case of 14.1 and a Haswell CPU, is not safe. If microcode is not updated early, the microcode module will apply the microcode update when it autoloads and this is not safe for Haswell.

I don't know if the above valid when the microcode module is compiled in the kernel. But in case of a nonstandard kernel with the module that is not compiled in, the existence of /lib/firmware/intel-ucode is not good.

Am I wrong?

Hi,

The logic behind /lib/firmware/intel-ucode is that, newer kernels can load the microcode without the need for externals utilities (e.g. microcode_ctl, which is deprecated anyways).

Correct, but see below.

I'm also not entirely sure, as I'm barely providing the microcode. I don't have enough knowledge to judge what happens exactly.

Please provide me more information (some links) on the Haswell problems that might occur, what is the cause and how we can remedy them.

My point is that, the problems of Haswell won't prevent me from doing what is good for everything else. But if you help, I might try to mitigate them somehow.

--
Best regards,
Andrzej Telszewski

The problem is discussed here. My understanding (completely unprofessional, I'm not a programmer) is the following: update 20140913 first time removed a processor capability (TSX), so that if the update happens after the kernel collects information on the processor capabilities, kernel will think that the capability is present, while in reality it is not. Thus, only an early update is safe.

Hi,

I hate their messaging system, for me it's hardly intuitive.
Anyways, there are many low level details, which I won't bother to follow.
If you find something more condensed, please let me know.

Other that, I have the resolution of this problem on my TODO list, but it'll stay there until either somebody provides me stupid simple instruction or I find the spare time to do some digging.

Sorry for not being of much help this time.

--
Best regards,
Andrzej Telszewski