- 2015-02-20: kernel 3.17
- 2014-12-12: kernel 3.16
- 2014-09-19: kernel 3.14
- 2014-01-08: kernel 3.12
- 2013-10-31: kernel 3.11
- 2013-07-31: kernel 3.10
- 2013-06-12: kernel 3.9
- 2013-02-28: kernel 3.8
- 2012-12-19: kernel 3.7
- 2012-11-05: kernel 3.5
- 2012-06-13: kernel 3.4
- 2012-03-31: kernel 3.3
- 2012-02-29: kernel 3.2
- 2011-11-30: kernel 3.1
- 2011-08-31: kernel 3.0
- 2011-06-30 kernel 2.6.39
- 2011-05-19 kernel 2.6.38
- 2011-01-27 kernel 2.6.37
- 2010-10-22 kernel 2.6.36
- 2010-09-16 kernel 2.6.35
- 2010-05-28 kernel 2.6.34
- 2010-03-12 kernel 2.6.33
- 2009-12-11 kernel 2.6.32
- 2009-09-23 kernel 2.6.31
- 2009-05-08 kernel 2.6.29
- 2008-11-25 kernel 2.6.27
- 2008-05-07 kernel 2.6.25
If you download any software from this web site please be aware of the Warranty Disclaimer and Limitation of Liabilities.
|upstream kernel 3.7||kernel 3.7 - upstream with feature descriptions.|
|linux-3.7-s390-message-catalog.tar.gz / MD5||"Development Stream" kernel 3.7 - message-catalog (optional)|
To download the linux-3.7.tar.gz visit: http://www.kernel.org/pub/linux/kernel/v3.x
The upstream kernel 3.7 contains the following functionality developed by the Linux on System z development team:
- Kernel: Add JIT compiler for Berkeley Packet Filer programs
The Berkeley Packet Filter or BPF is an interface and a language definition that allows to pass a filter to the kernel to select network packets which are of interest to the user space application. A second way to use the BPF language is system call filtering.
The standard implementation to execute the BPF program is an interpreter, to speed up the filter operation a just-in-time compiler for System z has been added.
- Kernel: Provide an user space interface to retrieve the CPU cache topology
Add an interface for z10 or later machines to expose the CPU cache toplogy to user space.
System z only provides information about CPU caches which are private to a CPU.
Information about shared caches is not exposed.
- Kernel: Add support for the transactional execution facility
Provide the Linux kernel support for the Transaction-Execution facility of System zEC12 or later.
The Transactional-Execution facility is a concurrency mechanism to improve parallelism in an SMP environment.
The user space program needs to utilize new instructions to get the benefits of the fine-grained serialization.
This is useful for lockless data structures and speculative compiler optimizations.
- Kernel: Add interface to query the kernel page table layout
- The sysfs interface now reads the current layout of the kernel address space and provides useful informations for a kernel developer.
- zfcp: No automatic port_rescan on events
The recommended optimal SAN fabric configuration is with single initiator zoning based on (NPIV) WWPNs.
If this is not possible, automatic port_rescan in zfcp can indirectly cause high fabric traffic load due to fabric change events, especially when many Linux images share an FCP channel over multiple subchannels with NPIV enabled. This can in turn lead to lost status notifications, failing name server requests, or in the worst case failing port or adapter recovery and thus failing paths to LUNs.
Allow users to perform automatic port rescans on incoming ELS and on any adapter recovery depending on a module parameter "no_auto_port_rescan" introduced here. Please note that the following unconditional automatic port rescans remain as is: On setting an adapter online and on manual user-triggered writes to the sysfs attribute port_rescan.
If no_auto_port_rescan is enabled, the user can additionally remove unused remote ports by means of the sysfs attribute port_remove sustainably until an unconditional port rescan on adapter online or on writing to the port_rescan sysfs attribute. This saves FCP channel resources and avoids potentially failing recoveries of unused remote ports.
For details see Device Drivers, Features, and Commands, Chapter 'SCSI-over-Fibre Channel device driver', sections 'zfcp device driver kernel parameters', 'zfcp module parameters', 'Scanning for ports', and 'Removing ports'.
- Transparent hugepage support for System z
Makes the Linux transparent hugepage feature available on System z.
With this feature, large pages can be used to back normal anonymous memory mappings.
This works transparently, so that any application for Linux on System z can benefit from using large pages.
This function is made vailable on Sytem z10 or newer and restricted on LPAR only.
For details see Device Drivers, Features, and Commands, Chapter 'Large Page Support'
- s390: Add support for CPU runtime instrumentation
The CPU runtime instrumentation facility enables user-space programs to obtain details of program execution, such as branch prediction
and cache misses and enables instrumentation of the code with sampling instructions.
A new system call, s390_runtime_instr, is added. With this system call a program can enable or disable runtime instrumentation for the calling thread.
After runtime instrumentation is enabled the program can set up all additional parameters like the location of the tracing buffer or which events should be traced by calling the appropriate runtime instrumentation instructions.
This function is made available on Sytem zEC12 or newer and restricted on LPAR only.
- scm: Add support for the Flash Express storage feature
IBM System zEC12 introduced the optional Flash Express feature, an SSD based storage device which can be directly attached to the machine. Linux on System z can now provide block devices to access the storage capacity of this feature.
The block devices and driver are named "Storage-Class Memory" (SCM) after the machine-internal name of the feature. Each chunk of SCM (called increment) assigned to an LPAR is represented by a separate block device named scma, scmb, etc. These block devices are functionally compatible with the usual block device mechanisms known on Linux, such as partitioning, creating filesystems, using with LVM, etc.
For more details see Device Drivers, Features, and Commands, Chapter 'Storage-class memory device driver'.
- zcrypt: Add support for CryptoExpress4S (CEX4A & CEX4C)
This feature extends the zcrypt device driver to support the new CryptoExpress4S Coprocessor (CEX4C) and Accelerator (CEX4A) cards.
From a user perspective on zcrypt the IOCTLs can be used as before. The functions provided from the libica library can also be used as before (see libica Programmer's Reference).
For more details see Device Drivers, Features, and Commands, Chapter 'Generic cryptographic device driver'.
- zcrypt: Improve handling of zcrypt device configuration changes
This feature will improve the RAS capabilities of the AP bus and the zcrypt devices.
External AP bus configuration changes (In case of the loss/add of an adapter) will be detected and handled/recovered by the AP bus respectively the zcrypt device driver.
- s390/partitions: make partition detection independent from DASD ioctls
In some usage scenarios it is desireable to work with disk images or virtualized DASD devices. One problem that prevents such applications is the partition detection in ibm.c. Currently it works only for devices that support the BIODASDINFO2 ioctl, in other words, it only works for devices that belong to the DASD device driver.
This feature makes the ibm.c partition detection as independent as possible from the BIODASDINFO2 ioctl. Only the following two cases are still restricted to real DASDs:
This patch contains:
- Kernel message catalog.
- Add support for automatic message tags to the printk macro families dev_xyz and pr_xyz. The message tag consists of a component name and a 24 bit hash of the message text. For each message that is documented in the included kernel message catalog a man page can be created with a script (which is included in the patch). The generated man pages contain explanatory text that is intended to help understand the messages.
Note that only s390 specific messages are prepared appropriately and included in the generated message catalog.
This patch is optional as it is very unlikely to be accepted in upstream kernel, but is recommended for all distributions which are built based on the 'Development stream'.