Linux Kernel v6.14 is Released: This is What's New for Compute Express Link (CXL)

Linux Kernel v6.14 is Released: This is What's New for Compute Express Link (CXL)

The Linux Kernel v6.14 release brings several improvements and additions related to Compute Express Link (CXL) technology.

Release Highlights

Linux Kernel v6.14 includes 13 commits to the CXL and DAX subsystems:

CategoryCommits
Bug Fixes1
Refactoring & Cleanup2
Other10

The dominant story in v6.14’s CXL changes is alignment with CXL specification revision 3.1 in the event subsystem. Five event record types — Common, General Media, DRAM, Memory Module, and Component Identifier — were updated to match the latest spec. These records are how CXL devices surface hardware faults, media errors, and performance anomalies to the host, so keeping them in sync with the specification is critical for accurate error classification and interoperability with newer hardware that implements the 3.1 format changes.

On the PCI side, cxl_dvsec_rr_decode() gains support for CXL Type 1 and Type 2 devices. Previously this DVSEC range register decode path only handled Type 3 (memory-expander) devices — the class that has driven most CXL software development to date. Extending it to Type 1 (cache-coherent accelerator, no device memory) and Type 2 (accelerator with device memory) broadens the driver’s device coverage and lays groundwork for a wider range of CXL-attached accelerators and smart NICs.

The cleanup work in v6.14 shows a continued push to use generic driver core primitives rather than CXL-specific wrappers. is_cxl_nvdimm_bridge() is removed from cxl/pmem in favor of the generic device_match_type() API, and device_find_child() in the driver core is constified to improve type safety across subsystems that include CXL. A prototype correction to device_for_each_child_reverse_from() rounds out the driver core fixes.

Key Changes

  • CXL 3.1 Event Record Updates: The Common, General Media, DRAM, and Memory Module event records are all updated to match CXL specification revision 3.1 field layouts. Devices implementing the newer spec will now have their reported events correctly parsed rather than silently misinterpreted.
  • Component Identifier Formatting (CXL 3.1): A new Component Identifier field introduced in CXL spec 3.1 is now formatted and exposed in event output, giving operators a structured way to pinpoint which component inside a device reported an event.
  • Type 1/2 Device Support in DVSEC Decode: cxl_dvsec_rr_decode() now handles CXL Type 1 (cache-coherent, no device memory) and Type 2 (with device memory) devices in addition to Type 3. This is a prerequisite for CXL-attached accelerators to participate in the driver’s range-register enumeration path.
  • NVDIMM Bridge API Modernization: is_cxl_nvdimm_bridge() and the internal match_nvdimm_bridge() helper are removed from cxl/pmem, replaced by the generic device_match_type() driver core API. This reduces CXL-specific boilerplate and keeps device-matching logic in one canonical place.
  • Register Block Counting Refactor: cxl/core/regs gains extracted helper functions for counting register blocks of a given type. The logic existed inline before; factoring it out makes the register enumeration code easier to test and reuse as new register block types appear in future spec revisions.
  • Driver Core Const-Safety: device_find_child() is constified in the driver core and its callers — including CXL paths — are updated. This closes a category of potential const-violation bugs in code that searches the device tree without intending to modify anything.
  • device_for_each_child_reverse_from() Prototype Fix: A mismatch between the function’s declaration and its actual signature is corrected. Left unfixed, this kind of prototype error can silently produce undefined behavior on architectures where the calling convention depends on argument types.

Here is the detailed list of all commits merged into the 6.14 Kernel for CXL and DAX. This list was generated by the Linux Kernel CXL Feature Tracker .

Fastfetch: The Speedy Successor Neofetch Replacement Your Ubuntu Terminal Needs

Fastfetch: The Speedy Successor Neofetch Replacement Your Ubuntu Terminal Needs

If you love customizing your Linux terminal and getting a quick, visually appealing overview of your system specs, you might have used neofetch in the past. However, neofetch is now deprecated and no longer actively maintained. A fantastic, actively maintained alternative is Fastfetch – known for its speed, extensive customization options, and feature set.

While you might be able to install Fastfetch on Ubuntu 22.04 (Jammy Jellyfish) using the standard sudo apt install fastfetch, the version available in the default Ubuntu repositories is often outdated. To get the latest features, bug fixes, and performance improvements, you’ll want to use a different method.

Read More
A Step-by-Step Guide on Using Cloud Images with QEMU 9 on Ubuntu 24.04

A Step-by-Step Guide on Using Cloud Images with QEMU 9 on Ubuntu 24.04

Introduction

Cloud images are pre-configured, optimized templates of operating systems designed specifically for cloud and virtualized environments. Cloud images are essentially vanilla operating system installations, such as Ubuntu, with the addition of the cloud-init package. This package enables run-time configuration of the OS through user data, such as text files on an ISO filesystem or cloud provider metadata. Using cloud images significantly reduces the time and effort required to set up a new virtual machine. Unlike ISO images, which require a full installation process, cloud images boot up immediately with the OS pre-installed

Read More
Is Thinking Mode Affecting Your Agentic Workflows?

Is Thinking Mode Affecting Your Agentic Workflows?

I jumped on the trend of running local LLMs and agents and was having a lot of fun until my agents kept failing, timing out, and just stopping without any obvious reason. I tried PaperClip + ZeroClaw, PaperClip + Hermes-Agent, and Hermes-Agent + Hermes-Workspace with Qwen 3.6 and Gemma 4 models (various sizes and quantization levels). All of them failed in the same way at some point in the workflow with almost nothing reported in the logs to indicate what was happening. Some tasks completed without any problem, but most did not, often leaving me to wonder what was going on. After many hours of debugging and reading many forums, I finally found that this was a model serving configuration trap that catches many people the first time they self-host a reasoning model.

Read More