Linux Kernel 5.3rc1 and new Stable branch Kernels released

From LinuxReviews
Jump to navigationJump to search
Tux.png

The Linux Kernel team have released stable branch updates as well as the first release candidate for Linux 5.3. There are some interesting IRQ related fixes for 5.2.2, 5.1.19 and 4.19.60 and not much interesting fixed in 4.14.134 and 4.9.186. Support for AMD Navi GPUs is biggest high-light in 5.3rc1.

Tux-000d-200.png

Commit f29cd95ca0b3, which was added to 5.2.2, 5.1.19 and 4.19.60, stood out as particularly interesting. It relates to the handling of spurious interrupts.

"Quite some time ago the interrupt entry stubs for unused vectors in the system vector range got removed and directly mapped to the spurious interrupt vector entry point.

Sounds reasonable, but it's subtly broken. The spurious interrupt vector entry point pushes vector number 0xFF on the stack which makes the whole logic in __smp_spurious_interrupt() pointless.

As a consequence any spurious interrupt which comes from a vector != 0xFF is treated as a real spurious interrupt (vector 0xFF) and not acknowledged. That subsequently stalls all interrupt vectors of equal and lower priority, which brings the system to a grinding halt.

This can happen because even on 64-bit the system vector space is not guaranteed to be fully populated. A full compile time handling of the unused vectors is not possible because quite some of them are conditonally populated at runtime.

(..)

Fixup the pr_warn so the actual spurious vector (0xff) is clearly distiguished from the other vectors and also note for the vectored case whether it was pending in the ISR or not."

Change-log for Linux Kernel 5.2.2, 5.1.19 and 4.19.60

Nobody wants their system brought to "a grinding halt". The patch is not present in the change-log for new stable branch 4.14.134 and 4.9.186 kernels which indicates that the problem introduced "quite some time ago" was due to changes made sometime between 4.14 and 4.19. We never experienced the grinding halt while using 4.19+ kernels but it is still nice to see that we won't.

A fix for the Intel networking cards using the e1000e driver from the Russians is the only other fix that really stood out in these new kernels. Commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 was added to all the newly released stable kernel branches.

"Driver does not want to keep packets in Tx queue when link is lost. But present code only reset NIC to flush them, but does not prevent queuing new packets. Moreover reset sequence itself could generate new packets via netconsole and NIC falls into endless reset loop.

This patch wakes Tx queue only when NIC is ready to send packets."

kernel commit 0f9e980bf5ee

Nothing else really stands out in the change-logs for the new minor stable branch kernel releases.

Linux 5.3 release candidate 1

There is not yet a new code-name for Linux 5.3, the makefile still says "Bobtail Squid" - which is the code-name used by 5.2 kernels.

Support for AMD's new "Navi" GPUs is among the bigger highlights in the next Linux kernel. These cards are apparently equipped with two graphics rings per graphics pipe, one primary and one for async.

There is also some rather gigantic changes to the Intel i915 graphics driver. A lot of the changes appear to be files that are moved around, display-related files like intel_display.c which used to live in drivers/gpu/drm/i915/ is moved to drivers/gpu/drm/i915/display/. This makes it a bit difficult to tell if there is anything new for the Intel Iris driver or old furniture rearrangement.

The kernel scheduler has gotten a new feature which can track the clamped utilization of each CPU present based on RUNNABLE tasks scheduled on specific CPUs. The new option is called CONFIG_UCLAMP_TASK. This makes it possible to specify a minimum and maximum range for CPU utilization allowed for RUNNABLE tasks.

Support for loading compressed firmware has also been added.

A new network class called CONFIG_NET_VENDOR_GOOGLE is added. Google is apparently planning to make network cards or switches or other networking hardware. Perhaps they already do and they only use it internally.

Sensors on power supplies can now be exposed to the kernel using the HWMON interface (POWER_SUPPLY_HWMON).

Intel is up to something on the CPU side. 5.3rc1 has support for "CometLake-H Platforms" and "CometLake-LP Platforms". There's also a new Intel "Speed Select Technology interface" driver.

The Chinese smartphone and laptop manufacturer Xiaomi has added a WMI key driver for special function keys on their laptops.

On the security side there's now support for enable heap memory zeroing both on allocation and on free's.

The rest of the changes between 5.2 and 5.3 are dull and not at all interesting. There's some new sound chip drivers and a lot of small changes to existing drives. The change-set between 5.1 and 5.2rc1 had a whole lot more in terms of significant changes. The non-graphics related changes are so small it's like reading a change-log between a minor versions like 5.2.1 to 5.2.2, there are oddly few large or important changes in 5.3rc1 outside the GPU tree.

Kernel creator and chief architect Linus Torvalds had this to say about the 5.1rc1 release:

"This is a pretty big release, judging by the commit count. Not the biggest ever (that honor still goes to 4.9-rc1, which was exceptionally big), and we've had a couple of comparable ones (4.12, 4.15 and 4.19 were also big merge windows), but it's definitely up there.

The merge window also started out pretty painfully, with me hitting a couple of bugs in the first couple of days. That's never a good sign, since I don't tend to do anything particularly odd, and if I hit bugs it means code wasn't tested well enough. In one case it was due to me using a simplified configuration that hadn't been tested, and caused an odd issue to show up - it happens. But in the other case, it really was code that was too recent and too rough and hadn't baked enough. The first got fixed, the second just got reverted.

Anyway, despite the rocky start, and the big size, things mostly smoothed out towards the end of the merge window. And there's a lot to like in 5.3. Too much to do the shortlog with individual commits, of course, so appended is the usual "mergelog" of people I merged from and a one-liner very high-level "what got merged". For more detail, you should go check the git tree.

As always: the people credited below are just the people I pull from, there's about 1600 individual developers (for 12500+ non-merge commits) in this merge window."

Linus Torvalds: Linux 5.3-rc1. On the LKML, July 21st 2019.

Kernel researches can study the entire patch-set from 5.2 to 5.3rc1 and leave a comment if we missed anything of importance.

The new kernels can, as always, be acquired from https://www.kernel.org/


published 2019-07-22last edited 2019-07-22


Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.