The Latest Kernel Release.

bamunds · 01-05-2018, 09:15 PM

Quote:

Originally Posted by bassmadrigal

Can't answer all of these...
AFAIK, Intel microcode can only be applied via BIOS/UEFI updates or as part of your initrd. It can't be loaded on the fly like AMD's microcode can (which gets distributed with the kernel-firmware package).

I respect your input and rely on it often, but this time it conflicts with Intel's own statements. The release_notes actually states that there are two ways of updating the microcode, both a traditional microcode.dat (sounds like Slackware) and the more modern for UEFI platforms with /lib/firmware/intel-ucode directory. Maybe the question should be is there any reason Slacware wouldnot accept the traditional way of updating the microcode.dat file? This is way over my novice knowledge and it might call for an experiment from someone who is running a VM. Any volunteers? Maybe our BDFL or one of the development team could chime in here?

Quote:

Originally Posted by bassmadrigal

Pretty sure it doesn't. There's a 15 DEC 2017 version floating around, but as far as I know, it is unofficial (possibly put out by Intel, but not as an official release).

All the sources linked in this thread refer to 20171117, even the debian and gentoo sources are 20171215 repackage of 20171117 files internal.

Quote:

Originally Posted by bassmadrigal

That's correct. You only need one kernel-firmware package. You should always "installpkg" kernel-generic, kernel-huge, kernel-modules, and kernel-source. kernel-firmware can be upgraded because it all resides in the same location. You can safely remove all older kernel-firmware packages. removepkg is smart enough to not remove any files that exist in any other packages, so if the filenames didn't change at all, it would just remove the entry from /var/log/packages/.

Thanks for the confirmation of what I had already suspected. I've removed the excess files.

bamunds · 01-05-2018, 09:32 PM

Quote:

Originally Posted by keefaz

In fact yes there is a method to load microcode in a running system but it's considered as unsafe in README file installed with iucode_tool package.
For intel, firmware microcode files go in /lib/firmware/intel-ucode/

Actually, I've installed the iucode_tool-2.2 from SBo and it doesn't have any warning in the man pages. It does however discuss changes in the Linux version of 4.4 vs earlier which are important. Such as the microcode.dat is now deprecated and how to build the initramfs in to the initrd so that it uploads the later microcode in the early boot. Since my BIOS won't see an update from the vendor, and I do use an initrd I suspect that I'll have to figure this one out. Since my concerns and questions are getting specific, lengthy, and off topic I'll start a separate thread.
Thanks to everyone for the clues and education. Cheers.

Darth Vader · 01-05-2018, 09:38 PM

@bamunds

My solution to load the Intel microcode:

Code:

# Create the base initrd.
mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -w 5 -o /boot/initrd-${KVERSION}.gz

# Concatenate the intel-ucode.cpio and base initrd on the final initrd.
cat /boot/intel-ucode.cpio /boot/initrd-${KVERSION}.gz > /boot/initrd-${KVERSION}_ucode.gz

# Symlink the final initrd.
ln -sf initrd-${KVERSION}_ucode.gz initrd.gz

I use the SBo variant of Intel microcode, for now.

bamunds · 01-05-2018, 09:52 PM

Quote:

Originally Posted by Darth Vader

@bamunds

My solution to load the Intel microcode:

Code:

# Create the base initrd.
mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -w 5 -o /boot/initrd-${KVERSION}.gz

# Concatenate the intel-ucode.cpio and base initrd on the final initrd.
cat /boot/intel-ucode.cpio /boot/initrd-${KVERSION}.gz > /boot/initrd-${KVERSION}_ucode.gz

# Symlink the final initrd.
ln -sf initrd-${KVERSION}_ucode.gz initrd.gz

I use the SBo variant of Intel microcode, for now.

@Darth Vader - I'm going to start a separate thread for this type of help. I really appreciate the help but I'm a little confused with the /boot files you've listed and where they come from. The new thread is "How to load new Intel microcode" and found at this link https://www.linuxquestions.org/quest...13#post5802713 Thanks

bassmadrigal · 01-05-2018, 10:10 PM

Quote:

Originally Posted by bamunds

I respect your input and rely on it often, but this time it conflicts with Intel's own statements. The release_notes actually states that there are two ways of updating the microcode, both a traditional microcode.dat (sounds like Slackware) and the more modern for UEFI platforms with /lib/firmware/intel-ucode directory. Maybe the question should be is there any reason Slacware wouldnot accept the traditional way of updating the microcode.dat file? This is way over my novice knowledge and it might call for an experiment from someone who is running a VM. Any volunteers? Maybe our BDFL or one of the development team could chime in here?

Yeah, I wasn't aware of being able to load it using the /lib/firmware/intel-ucode/ directory until keefaz mentioned it earlier.

And the "traditional" method you mention is what the intel-microcode SlackBuild on SBo does, but I don't know if Pat and team are looking at including this with Slackware itself or just plan to let it stay on SBo.

Quote:

Originally Posted by bamunds

All the sources linked in this thread refer to 20171117, even the debian and gentoo sources are 20171215 repackage of 20171117 files internal.

If you look at Petri Kaukasoina's microcode output, you can see he has a items with newer dates than 20171117, so something newer is floating around.

Code:

2017-12-15 (unofficial bundle with CVE-2017-5715 mitigation):
  * Updated Microcodes:
    sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
    sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
    sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
    sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
    sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
    sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
    sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
    sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
    sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
    sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

kjhambrick · 01-06-2018, 08:55 AM

Quote:

Originally Posted by bamunds

That didn't work. dmesg | less is showing:

[ 0.000000] DMI: emachines T5224/D945GCL, BIOS CF94510J.15A.0028.2006.1213.1629 12/13/2006

which is a very old BIOS.
What should the microcode line look like?

bamunds --

The command below my sig line should work on most Linux Distros / Kernels.

HTH.

-- kjh

Code:

# dmesg -t |grep '^Kernel *command *line:'

Kernel command line: BOOT_IMAGE=Linux44109G.kjh ro root=803 vt.default_utf8=0 elevator=noop ipv6.disable=1

I am a procrastinator ... I've installed but not yet booted 4.4.110 ...

kjhambrick · 01-06-2018, 09:55 AM

Quote:

Originally Posted by bamunds

The Intel location has a really comprehensive list of Intel CPU's and the tar file once exploded has a release_note file which explains two methods of using the 11-17-2017 firmware. My Pentium D 820 is included in that file, per the Intel web site. However, the instruction talk about using microcode.dat or the intel-ucode directory.

<<snip>>
3) Iucode_tools tells me the processor code but not the microcode firmware version date. Is there a way to tell the loaded version date?
<<snip>>

Dang !

I answered the wrong Q ... should have looked at your original post above, bamunds.

This will find the first microcode ref in your /var/log/dmesg file:

Code:

# dmesg -t |grep -m1 'microcode'

microcode: CPU0 microcode updated early to revision 0xba, date = 2017-04-09

I added the -m1 arg to grep, otherwise you'll get a dupe for each Core and then another set of dupes for each thread and finally a copyright notice:

Code:

# dmesg -t |grep 'microcode'

microcode: CPU0 microcode updated early to revision 0xba, date = 2017-04-09
microcode: CPU1 microcode updated early to revision 0xba, date = 2017-04-09
microcode: CPU2 microcode updated early to revision 0xba, date = 2017-04-09
microcode: CPU3 microcode updated early to revision 0xba, date = 2017-04-09
microcode: CPU0 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU1 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU2 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU3 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU4 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU5 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU6 sig=0x506e3, pf=0x2, revision=0xba
microcode: CPU7 sig=0x506e3, pf=0x2, revision=0xba
microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Note that the revision and date on the 'microcode:' lines don't match the Version of the Intel Microcode file ... they match the version of the microcode for your particular CPU in the file that you did install.

I've installed the latest official intel-microcode via the SBo but the latest update for my i7 6700K is from April:

Code:

# ver intel-microcode

-rw-r--r-- 1 root root 4206 Nov 22 03:28 /var/log/packages/intel-microcode-20171117-noarch-1_SBo

The 20171117 Version matches 'the latest' on the Intel Download site:

https://downloadcenter.intel.com/dow...code-Data-File

HTH

-- kjh( on the lookout for an official update from Intel )

bamunds · 01-06-2018, 10:34 PM

Quote:

Originally Posted by kjhambrick

Dang !

(snip)...
I've installed the latest official intel-microcode via the SBo but the latest update for my i7 6700K is from April:

Code:

# ver intel-microcode

-rw-r--r-- 1 root root 4206 Nov 22 03:28 /var/log/packages/intel-microcode-20171117-noarch-1_SBo

The 20171117 Version matches 'the latest' on the Intel Download site:

https://downloadcenter.intel.com/dow...code-Data-File

HTH

-- kjh( on the lookout for an official update from Intel )

Yes it did help. Especially helpful are you microcode dmesg outputs showing the microcode dates of your CPU which were loaded. However I am confused about which method you used for updating the microcode. Are you saying you're updating the microcode.dat (now deprecated) or are you using the iucode_tool to build the /boot/intel-ucode.cpio and then cat'ing it into a initrd.gz? Can the updating comments please be taken to the separate thread title "How to update Intel microcode" at https://www.linuxquestions.org/quest...de-4175621053/. Thanks.

Loomx · 01-07-2018, 03:50 AM

Quote:

Originally Posted by bamunds

That didn't work. dmesg | less is showing:

[ 0.000000] DMI: emachines T5224/D945GCL, BIOS CF94510J.15A.0028.2006.1213.1629 12/13/2006

which is a very old BIOS.
What should the microcode line look like?

Mine shows this as the very first line:

Code:

[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09

cwizardone · 01-07-2018, 12:20 PM

Quote:

Originally Posted by cwizardone

The rebuilt huge 4.14.11 kernel and the new Nvidia Long Term driver-384.111 are installed and working well..... so far.

Well, trying to launch WINE locks up the machine tighter than a drum.
Back to 4.14.7.

cwizardone · 01-07-2018, 05:18 PM

Release Candidate 7 of the latest "mainline" development kernel is now available at, https://www.kernel.org/

The tarball, https://git.kernel.org/torvalds/t/linux-4.15-rc7.tar.gz

Mr. Torvalds' announcement, http://lkml.iu.edu/hypermail/linux/k...1.0/04858.html

bassmadrigal · 01-09-2018, 01:19 AM

Quote:

Originally Posted by bassmadrigal

I don't think you can tell. The SlackBuild strips all git information from it, including the latest commit. But the SlackBuild does just grab the latest from "master", so if you go through the commit log, just find where your package date falls in and that's what version you're running.

So, in the latest kernel-firmware update, Pat has started including the commit ID in the version information. No more guessing at what revision you're running

Code:

a/kernel-firmware-20180104_65b1c68-noarch-1.txz:  Upgraded.

kernel-firmware.SlackBuild

(See $HEADISAT in the SlackBuild)

cwizardone · 01-09-2018, 03:49 AM

Quote:

Originally Posted by cwizardone

Well, trying to launch WINE locks up the machine tighter than a drum.
Back to 4.14.7.

Just installed 4.14.12 from -current and all is well, including WINE.

Chuck56 · 01-09-2018, 09:36 AM

Now running 4.14.12 after removal of the 'nopti' kernel parameter for my AMD CPU.

Code:

bash-4.4$ uname -a
Linux slacker.localdomain 4.14.12 #1 SMP Fri Jan 5 17:18:41 CST 2018 x86_64 AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G AuthenticAMD GNU/Linux

Quote:

Originally Posted by Petri Kaukasoina

Or, AMD users can use 'nopti' or 'pti=off' kernel parameter, for example in an append line in lilo.conf. See Documentation/admin-guide/kernel-parameters.txt.

I added the 'nopti' kernel parameter for the 4.14.11 kernel based on Petri's post #440 on page 30 of this thread, I can confirm that the 'nopti' kernel parameter is no longer needed for AMD users. This is called out in the 4.14.12 kernel changelog.

Code:

commit 151d7039757b71ebd9d170af0944562f51149372
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Tue Dec 26 23:43:54 2017 -0600

    x86/cpu, x86/pti: Do not enable PTI on AMD processors
    
    commit 694d99d40972f12e59a3696effee8a376b79d7c8 upstream.
    
    AMD processors are not subject to the types of attacks that the kernel
    page table isolation feature protects against.  The AMD microarchitecture
    does not allow memory references, including speculative references, that
    access higher privileged data when running in a lesser privileged mode
    when that access would result in a page fault.
    
    Disable page table isolation by default on AMD processors by not setting
    the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
    is set.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Link: https://lkml.kernel.org/r/20171227054354.20369.94587.stgit@tlendack-t1.amdoffice.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Here's my reverted/updated elilo.conf

Code:

chooser=simple
delay=1
timeout=1
#
image=vmlinuz-generic-4.14.12
        label=vmlinuz
        initrd=initrd-4.14.12.gz
        append="root=/dev/mapper/slacker-root vga=normal ro"

Hope that helps!

cwizardone · 01-10-2018, 03:23 AM

Kernel updates 4.14.13, 4.9.76, and 4.4.111 are now available at, https://www.kernel.org/.

The change logs,

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.14.13

https://cdn.kernel.org/pub/linux/ker...angeLog-4.9.76

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.111