Kernel 4.7 (Release Candidate) Series

**Doug S** · June 29th, 2016

I am just catching up.

Originally Posted by MikeMecanic

Faster? I would say bigger.

Code:

$ systemd-analyze for 4.4.0.25 alone after a fresh install
Startup finished in 2.704s (kernel) + 10.329s (userspace) = 13.033s
$ systemd-analyze for 4.4.0.27 with .25
Startup finished in 2.814s (kernel) + 10.263s (userspace) = 13.077s
$ systemd-analyze for 4.7-rc4 alone or with .27
Startup finished in 5.114s (kernel) + 12.576s (userspace) = 17.690s
$ df -h | grep ^/dev/sda3
/dev/sda3       236M   65M  159M  29% /boot
$ dpkg --list | grep linux-image
ii  linux-image-4.7.0-040700rc4-generic        4.7.0-040700rc4.201606201235                                amd64        Linux kernel image for version 4.7.0 on 64 bit x86 SMP

Mike: I never did understand your post, as I had not observed any significant increase in the .deb file size or whatever.

All: There is a staggering reduction in the .deb file size for -rc5. The last time I synchronized with the Ubuntu kernel configuration was -rc2, and the differences between the -rc5 kernel configuration are overwhelming.

Aghh... For those that want to try it, like me, I see that the new scheduler based CPU frequency scaling governor for the acpi-cpufreq driver is now included as a module.
Oh, I also see that the default scheduler has changed, from "deadline" to "cfq".
I could go on and on, but the suggestion to users is that they review the differences themselves, looking for any changes that might be relevant to their particular situation.

EDIT 1: Holy crap!!! My own compile took:

Code:

real    45m37.520s
user    290m42.136s
sys     18m55.332s

Whereas it typically took about 22 minutes before. Investigation pending.
EDIT 2: I have not been able to repeat the above mentioned much longer compile time.
The available CPU frequency scaling governors seems messed up to me:

Code:

doug@s15:~/temp$ uname -a
Linux s15 4.7.0-rc5-stock #74 SMP Wed Jun 29 08:11:59 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux
doug@s15:~/temp$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_available_governors
ondemand performance
ondemand performance
ondemand performance
ondemand performance
ondemand performance
ondemand performance
ondemand performance
ondemand performance

Because I sometimes use the other ones that used to be available.

Code:

Linux s15 4.6.0-040600-generic #201605151930 SMP Sun May 15 23:32:59 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
doug@s15:~$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_available_governors
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance
conservative ondemand userspace powersave performance

EDIT 3: Oh, if a CPU frequency governor is a module instead of built in, then it won't appear in the list of available governors until it is either loaded via attempting to use it, or force loaded via "modprobe". My list now is:

Code:

doug@s15:~/test_kernels$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_available_governors
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance
schedutil powersave ondemand performance

because I forgot and switched to "powersave" and because I did "sudo modprobe cpufreq_schedutil".

**Doug S** · July 4th, 2016

Kernel 4.7-rc6 is available. The Ubuntu kernel configuration is the same as -rc5, so the big config changes were between -rc4 and -rc5 (see previous post).
I'm not running it yet, as it is still compiling.

EDIT: Been running for over a day now without issues.

**rowan-potgieter** · July 5th, 2016

I must be honest I have no idea where to log this bug - I tried using "ubuntu-bug linux" but since I've switched to a non-standard kernel I get blocked. I also have an issue with Kernel 4.7 rc6 though...

I use my laptop (details below) with an HP dock connected to 2 x Dell Display Port monitors. I cannot remember the exact dates but at the beginning of June my setup was fine (this is a brand new laptop so it was a fresh install). At some point in June I believe there was a kernel update and after reboot my laptop would hang during boot. I figured out that the issue was related to whenever the dock was connected. Looking at the dmesg output were intel graphics failures when the 2 monitors were initialised.
I switched to the intel nightly kernel from 2016-06-06-yakkety and this has resolved my issues. This is still not perfect because my screens occasionally go "blank" for a second or 2 when moving the mouse between them but it is 100% useable.
I am logging this bug because today I tried the 4.7-rc6-yakkety kernel and the issue has not been resolved - my laptop locks up when starting the 2 x Display Port monitors.

some info from "sudo lshw"
description: Notebook
product: HP EliteBook 820 G3 (T9X46EA#ACQ)
vendor: HP
*-display
description: VGA compatible controller
product: Sky Lake Integrated Graphics
vendor: Intel Corporation

If there is a better place/way to log this issue please let me know

**mikedawson2013** · July 11th, 2016

4.7-rc7 is out! Just installed it. Everything works fine so far.

**Doug S** · July 28th, 2016

Kernel 4.7 has been available for a few days. I have been running it for a few hours now without issues. I compile my own, and did not check if the Ubuntu kernel configuration changed between 4.7-rc7 and 4.7, but at some point I will.

**mave-m** · August 3rd, 2016

Today i updated my 4.7 kernel as there seems to be a new build, but i still get the i915 module errors about missing firmware for skylake based systems.

update-initramfs: Generating /boot/initrd.img-4.7.0-040700-generic
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_ver6.bin for module i915

These are the currently installed packages:

linux-headers-4.7.0-040700_4.7.0-040700.201608021801_all.deb
linux-headers-4.7.0-040700-generic_4.7.0-040700.201608021801_amd64.deb
linux-image-4.7.0-040700-generic_4.7.0-040700.201608021801_amd64.deb

**Doug S** · August 3rd, 2016

Originally Posted by mave-m

Today i updated my 4.7 kernel as there seems to be a new build, but i still get the i915 module errors about missing firmware for skylake based systems.

I still get those messages also. As mentioned somewhere earlier, since I don't have a skylake (and now kbl, whatever the actual name is), I don't care.

**mave-m** · August 4th, 2016

Originally Posted by Doug S

I still get those messages also. As mentioned somewhere earlier, since I don't have a skylake (and now kbl, whatever the actual name is), I don't care.

Good for you, i have a skylake-based system so i do care. "kbl" is Kaby Lake, Skylake's successor.

**Doug S** · August 4th, 2016

Originally Posted by mave-m

Good for you, i have a skylake-based system so i do care. "kbl" is Kaby Lake, Skylake's successor.

You could look at this. And try here, from the link therein. I do not know if you would then need to manually set a link from /lib/firmware/i915/skl_guc_ver6.bin to /lib/firmware/i915/skl_guc_ver6_1.bin, similar to:

Code:

doug@s15:~/c$ ls -l /lib/firmware/i915/skl*
-rw-r--r-- 1 root root   8824 Apr 25 05:56 /lib/firmware/i915/skl_dmc_ver1_23.bin
-rw-r--r-- 1 root root   8928 Apr 25 05:56 /lib/firmware/i915/skl_dmc_ver1_26.bin
lrwxrwxrwx 1 root root     19 Apr 25 05:56 /lib/firmware/i915/skl_dmc_ver1.bin -> skl_dmc_ver1_26.bin
-rw-r--r-- 1 root root 109636 Apr 25 05:56 /lib/firmware/i915/skl_guc_ver1_1059.bin
lrwxrwxrwx 1 root root     21 Apr 25 05:56 /lib/firmware/i915/skl_guc_ver1.bin -> skl_guc_ver1_1059.bin
-rw-r--r-- 1 root root 128320 Apr 25 05:56 /lib/firmware/i915/skl_guc_ver4_3.bin
lrwxrwxrwx 1 root root     18 Apr 25 05:56 /lib/firmware/i915/skl_guc_ver4.bin -> skl_guc_ver4_3.bin

Or if that would happen during install.

**Doug S** · September 2nd, 2016

Originally Posted by Doug S

All: There is a staggering reduction in the .deb file size for -rc5. The last time I synchronized with the Ubuntu kernel configuration was -rc2, and the differences between the -rc5 kernel configuration are overwhelming.

Aghh... For those that want to try it, like me, I see that the new scheduler based CPU frequency scaling governor for the acpi-cpufreq driver is now included as a module.
Oh, I also see that the default scheduler has changed, from "deadline" to "cfq".
I could go on and on, but the suggestion to users is that they review the differences themselves, looking for any changes that might be relevant to their particular situation.

Immediately after boot the reported load average is, for example, 266.59, 63.19, 20.92 (1, 5, 15 minute load averages). I have traced this back to the massive kernel configuration changes between kernel 4.7-rc4 and 4.7-rc5, but haven't figured out which specific change. Such load average numbers could be from a one time load of very approximately 4000, meaning it seems likely that it isn't being initialized properly. It isn't clear to me how such an issue would be kernel config related as opposed to kernel code related.

EDIT: So as to catch the load average as soon as possible after boot I added a script to the end of the boot sequence, and caught 24 uptimes:

Code:

[   25.009523]  08:01:57 up 0 min,  0 users,  load average: 271.03, 58.94, 19.23
[   30.011377]  08:02:02 up 0 min,  0 users,  load average: 296.57, 67.76, 22.29
[   35.012966]  08:02:07 up 0 min,  0 users,  load average: 430.90, 99.40, 32.78
[   40.014476]  08:02:12 up 0 min,  0 users,  load average: 396.39, 97.75, 32.60
[   45.015993]  08:02:17 up 0 min,  0 users,  load average: 364.65, 96.13, 32.42
[   49.958482]  08:02:22 up 0 min,  0 users,  load average: 335.45, 94.53, 32.25
[   54.830996]  08:02:27 up 0 min,  0 users,  load average: 308.59, 92.96, 32.08
[   59.765276]  08:02:32 up 1 min,  0 users,  load average: 283.88, 91.42, 31.90
[   64.731895]  08:02:37 up 1 min,  0 users,  load average: 261.14, 89.90, 31.73
[   69.715492]  08:02:42 up 1 min,  0 users,  load average: 240.23, 88.41, 31.56
[   74.707682]  08:02:47 up 1 min,  0 users,  load average: 220.99, 86.94, 31.39
[   79.704409]  08:02:52 up 1 min,  0 users,  load average: 203.30, 85.50, 31.22
[   84.702339]  08:02:57 up 1 min,  0 users,  load average: 187.02, 84.08, 31.06
[   89.701102]  08:03:02 up 1 min,  0 users,  load average: 172.04, 82.68, 30.89
[   94.701362]  08:03:07 up 1 min,  0 users,  load average: 158.26, 81.31, 30.72
[   99.702528]  08:03:12 up 1 min,  0 users,  load average: 145.59, 79.96, 30.56
[  104.703988]  08:03:17 up 1 min,  0 users,  load average: 133.93, 78.63, 30.39
[  109.705740]  08:03:22 up 1 min,  0 users,  load average: 123.21, 77.33, 30.23
[  114.707627]  08:03:27 up 1 min,  0 users,  load average: 113.34, 76.04, 30.07
[  119.709598]  08:03:32 up 2 min,  0 users,  load average: 104.26, 74.78, 29.91
[  124.711804]  08:03:37 up 2 min,  0 users,  load average: 95.91, 73.54, 29.74
[  129.714023]  08:03:42 up 2 min,  0 users,  load average: 88.23, 72.32, 29.58
[  134.716183]  08:03:47 up 2 min,  0 users,  load average: 81.17, 71.12, 29.43
[  139.718354]  08:03:52 up 2 min,  0 users,  load average: 74.67, 69.93, 29.27

To get those numbers the load samples would have been approximately 590 at 30 seconds and 1985 at 35 seconds and 0 thereafter.

EDIT: see this bug report