MantisBT - Issues

0000655: Anaconda text-mode installer uses an abnormally large 16x32 console font on AlmaLinux 9.8

Mon, 20 Jul 2026 19:24:30 +0000

During an automated AlmaLinux 9.8 x86_64 installation using iPXE and Kickstart text mode, the Anaconda interface on TTY1 switches to an abnormally large 16x32 console font.

Environment:

- Distribution: AlmaLinux 9.8
- Architecture: x86_64
- Virtualization platform: Proxmox VE 8.4.19
- Installation method: iPXE with Kickstart
- Kickstart mode: text
- Installation locale: en_US.UTF-8
- Anaconda version: anaconda-34.25.7.14-1.el9.alma.1
- Virtual framebuffer driver: bochs-drmdrmfb
- Framebuffer resolution: 1280x800

The framebuffer resolution is correct and the issue is limited to the virtual console used by Anaconda.

Measured console settings:

TTY1, where Anaconda is running:

- Terminal size: 25 rows and 80 columns
- Console font: 16x32x512

TTY2, the installer shell:

- Terminal size: 50 rows and 160 columns
- Console font: 8x16x512

Both virtual consoles use the same 1280x800 framebuffer. Therefore, the problem is not caused by a low framebuffer resolution or browser/noVNC scaling. Anaconda explicitly changes the font only on TTY1.

The Anaconda log confirms the font change:

console fonts found for locale en_US.UTF-8: ['eurlatgr']
setting console font to eurlatgr
console font set successfully to eurlatgr

After Anaconda loads eurlatgr on TTY1, the console changes from the normal 8x16 font to 16x32. This halves the number of available rows and columns and makes the text-mode installer interface abnormally large.

The same Proxmox environment does not show this behavior when installing AlmaLinux 9.7 or AlmaLinux 10.2. The issue is reproducible with AlmaLinux 9.8.

0000654: iptables-nft-1.8.11-15.el10_2 pulls kernel-debug packages during fresh AlmaLinux 10.2 installation

Mon, 20 Jul 2026 18:42:11 +0000

A fresh AlmaLinux 10.2 x86_64 installation performed by Anaconda installs both the normal kernel and the complete kernel-debug package set.

Environment:

- Distribution: AlmaLinux 10.2
- Architecture: x86_64
- Installation method: Anaconda
- Installation media: AlmaLinux 10.2 x86_64 Boot ISO
- Affected package: iptables-nft-1.8.11-15.el10_2.x86_64
- Kernel version: 6.12.0-211.34.1.el10_2.x86_64

Actual result:

The installation contains both the normal kernel:

kernel-core-6.12.0-211.34.1.el10_2.x86_64

and the complete debug kernel package set:

kernel-debug-core-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-core-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-extra-6.12.0-211.34.1.el10_2.x86_64

The first DNF/Anaconda transaction contains:

Install iptables-libs-1.8.11-15.el10_2.x86_64 @anaconda
Install iptables-nft-1.8.11-15.el10_2.x86_64 @AppStream
Install kernel-debug-core-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-core-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-extra-6.12.0-211.34.1.el10_2.x86_64 @anaconda

This proves that the debug kernel packages were selected during the initial installation. They are not leftovers from an earlier iptables version or a previous system update.

Expected result:

A normal AlmaLinux installation should install only the normal kernel variant. The kernel-debug packages should not be installed unless explicitly selected by the user.

0000653: gdm-1:47.0-21.el10_2 regression: Login authentication failure with kernel-6.12.0-211.34.1 (gnome-keyring-daemon socket unavailab

Fri, 17 Jul 2026 13:30:11 +0000

gdm version 1:47.0-21.el10_2 introduces a regression when running on kernel 6.12.0-211.34.1.el10_2. During login, GDM flashes to console and authentication fails initially, with the following errors in systemd journal:

pam_unix(gdm-password:auth): authentication failure
gkr-pam: unable to locate daemon control file
gkr-pam: stashed password to try later in open session

The login eventually succeeds 0000007:0000009 seconds later after GDM restarts. Reverting to the previous gdm version (1:47.0-20.el10_2) resolves the issue on the same kernel.

0000652: kernel-6.12.0-211.34.1 regression: Login authentication failure due to gnome-keyring-daemon socket unavailability

Fri, 17 Jul 2026 13:05:21 +0000

Kernel 6.12.0-211.34.1 introduces a regression in the login flow. When attempting to log in via GDM, the display manager briefly flashes to console and either fails authentication or requires multiple login attempts. Kernel 6.12.0-211.33.1 works without issues.

Lenovo X1 Carbon.

0000651: [AlmaLinux][MANA][Backport][Distros] Patch: net: mana: Add Interrupt Moderation support

Tue, 14 Jul 2026 06:33:38 +0000

Request backport of the following patch.

Problem Summary
This patch implements driver support for the feature: Static and Dynamic Interrupt Moderation (DIM).

Impact on Customer VMs/BMs
Without this patch the Interrupt Moderation won't be available.
Patch Criticality
Medium (High for C200 system) -- Backport as far back as possible for LTS kernel versions if there is no merge conflicts. Mandatory for versions which has C200 systems.
Classification
New feature
Upstream reference
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=433f482add31b8f81c79fcafa739a5e7ab71daf2

0000644: AlmaLinux 10: advisories removed from errata.full.json while their HTML pages remain published — which source is authoritative?

Tue, 14 Jul 2026 03:14:19 +0000

I help maintain the data pipeline of an open-source vulnerability scanner
https://github.com/future-architect/vuls/ , which consumes https://errata.almalinux.org/10/errata.full.json.

Around 2026-05-19..26, the AlmaLinux 10 errata feed went through a large
re-curation:

- Many published ALSA advisories disappeared from errata.full.json.
Our snapshot of 2026-05-21 contained 279 advisories; during that window
the feed shrank to roughly 60, and it has since regrown to 264
(as of 2026-07-02).
- Some advisories were re-issued under new IDs, in some cases more than
once. Example: CVE-2025-13601 was covered by ALSA-2026:0975, which
disappeared and is now covered by ALSA-2026:18344.
- However, the static HTML pages of the removed advisories are still
published: they return HTTP 200 with full content, and they are still
listed in the directory index at https://errata.almalinux.org/10/
(504 ALSA-*.html files vs 264 entries in the current feed).

Impact: comparing our 2026-05-21 snapshot with the current feed, the
removed advisories referenced 434 unique CVEs, of which only 58 are still
referenced by any advisory in the current feed. The remaining 376 CVEs are
no longer covered at all. For downstream consumers of the feed (security
scanners, SBOM/VEX tooling), this is an effective loss of detection
coverage for AlmaLinux 10, while the same advisories still look
"published" on the website.

Questions:
1. Was the removal of these advisories from errata.full.json an
intentional retirement/re-curation, or a side effect of how the feed
is regenerated?
2. Which source should downstream consumers treat as authoritative:
errata.full.json, the HTML pages, or the updateinfo.xml shipped in
the repositories?
3. If the retirement is intentional, could the corresponding HTML pages
be removed or marked as retired, so the two sources stay consistent?
Conversely, if it is not intentional, could the feed be regenerated
to include them again?
4. Is there any announcement or changelog describing this re-curation
that we could reference?

Other examples absent from the feed but live as HTML:
- https://errata.almalinux.org/10/ALSA-2025-21013.html (libssh)
- https://errata.almalinux.org/10/ALSA-2025-23479.html (openssh)
- https://errata.almalinux.org/10/ALSA-2026-13515.html (freeipmi)
- https://errata.almalinux.org/10/ALSA-2026-3517.html (thunderbird)

0000650: [AlmaLinux][MANA][Backport][Distros] 2 Patch set: Fix MANA RX with bounce buffering

Mon, 13 Jul 2026 13:59:57 +0000

Request backport of the following bug fix patch to all kernels versions that has the bottom dependent patch.

Problem Summary
This patch set fixes MANA NIC connection with CVM and bounce buffering.

Regression Issue: Severity P0.

Patch reference:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c72a0f09c57f92113df69f9b902d11c9e4b132f5
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2e2a83b4998af4384e677d3b2ac08565274279bf

So only kernels with this patch 730ff06d3f5c need this fixes

Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")

0000649: kernel BUG in folio_end_writeback via cifs_writepages on close()

Mon, 13 Jul 2026 12:42:49 +0000

--------------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------------

5.14.0-687.15.1.el9_8 (also reproduced on -687.17.1 and -687.20.1) — kernel BUG
at mm/filemap.c:1593 in folio_end_writeback, reached from cifs_writepages during
a synchronous writeback flush issued by the CIFS code itself: in most dumps from
cifs_flush on close(), in two dumps from cifs_open on open(). Seen in the same
event are a refcount_warn_saturate (refcount underflow / use-after-free) in the
CIFS async write path and a socket send failure (Error -32 / EPIPE) to the
server. The crash(8) disassembly confirms the BUG is the
"if (!__folio_end_writeback(folio)) BUG();" case — i.e. writeback is ended on a
folio whose writeback flag was already clear (a double-completion of writeback).

The same underlying corruption also manifests as a second signature: a general
protection fault on a non-canonical address with RIP in unlock_page+0x5, again
directly under cifs_writepages, with the identical refcount-WARN + Error -32
preamble (4 of 17 dumps).

The crash reproduces on fully UNTAINTED kernels: two of the four affected
machines carry no out-of-tree modules at all ("Not tainted" in the dumps).

Severity: crash / kernel panic
Category: kernel

--------------------------------------------------------------------------------
FOUR INDEPENDENT MACHINES, THREE KERNEL BUILDS, IDENTICAL SIGNATURE
--------------------------------------------------------------------------------

The panic has now been captured on four physically different servers (three
different Dell models) across three el9_8 kernel builds. 17 kdumps total. The
call traces match down to the same symbol offsets.

hostA
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernels : 5.14.0-687.15.1.el9_8
Comm : dask worker [tc (e.g. PID 70950, CPU 22)
Hardware: 40 CPUs, 766.6 GB RAM
CIFS : cache=none
Taint : P OE (NVIDIA out-of-tree module loaded)
Dumps : 5 (2026-06-20 .. 2026-06-23)

hostB
Server : Dell PowerEdge R750xa, BIOS 1.20.2
Kernels : 5.14.0-687.15.1.el9_8 and 5.14.0-687.17.1.el9_8
Comm : pt_main_thread / python
Hardware: 24 CPUs, 383.2 GB RAM
CIFS : cache=strict
Taint : P OE (NVIDIA out-of-tree module loaded)
Dumps : 6 (2026-06-20 .. 2026-07-11; the three July dumps are on
-687.17.1)

hostC
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernels : 5.14.0-687.15.1.el9_8 and 5.14.0-687.20.1.el9_8
Comm : dask worker [tc
Taint : NOT TAINTED — no out-of-tree modules
Dumps : 3 (all 2026-07-03; one of them on -687.20.1)

hostD
Server : Dell PowerEdge R640, BIOS 2.26.1
Kernels : 5.14.0-687.20.1.el9_8
Comm : python
Taint : NOT TAINTED — no out-of-tree modules
Dumps : 3 (all 2026-07-03)

Kernel build string (hostA/hostB June dumps):

Linux version 5.14.0-687.15.1.el9_8.x86_64
(mockbuild@x64-builder01.almalinux.org) ...
#1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:51:45 EDT 2026

Four different servers of three models crashing at the identical instruction
with the identical call chain points to a software defect, not a per-machine
hardware fault.

--------------------------------------------------------------------------------
NOT AN OUT-OF-TREE-MODULE ISSUE — UNTAINTED REPRODUCTIONS
--------------------------------------------------------------------------------

Earlier dumps (hostA/hostB) carried the "P ... OE" taint from the NVIDIA driver.
The six hostC/hostD dumps rule that out as a factor: all of them crash with

CPU: 10 PID: 97317 Comm: dask worker [tc Kdump: loaded Not tainted
5.14.0-687.15.1.el9_8.x86_64 #1 (hostC)
CPU: 12 PID: 6801 Comm: python Kdump: loaded Not tainted
5.14.0-687.20.1.el9_8.x86_64 #1 (hostD)

On the subsequent BUG oops line these hosts show "Tainted: G W" — the W is set
by the refcount_warn_saturate WARNING that fires immediately before the BUG in
the very same event; G means no proprietary/out-of-tree modules were ever
loaded. The bug therefore reproduces on a pristine distribution kernel.

--------------------------------------------------------------------------------
WHAT THE DUMPS SHOW
--------------------------------------------------------------------------------

In all 17 dumps the crash is a two-part event on the same CPU/PID. The two
parts are shown below in the order the report discusses them; the order in
which they were actually printed to the kernel log varies (see "A note on
ordering" at the end of this section).

1) refcount underflow in the CIFS async write path

refcount_t: underflow; use-after-free.
WARNING: CPU: PID: at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
... Tainted: P OE 5.14.0-687.15.1.el9_8.x86_64 (hostA/hostB)
... Not tainted 5.14.0-687.20.1.el9_8.x86_64 (hostC/hostD)
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:refcount_warn_saturate+0xba/0x110
Call Trace:
refcount_warn_saturate+0xba/0x110
cifs_call_async+0x1ee/0x330 [cifs]
smb2_async_writev+0x473/0x6f0 [cifs]
? __pfx_cifs_writedata_release+0x10/0x10 [cifs]
cifs_writepages+0x52f/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

The release function on the stack is cifs_writedata_release — i.e. the object
whose refcount saturates/underflows is the CIFS writedata associated with this
writeback.

2) socket send failure, and the BUG

CIFS: VFS: \\ Error -32 sending data on socket to server
------------[ cut here ]------------
kernel BUG at mm/filemap.c:1593!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
... Tainted: P W OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:folio_end_writeback+0x7d/0x80
Call Trace:
folio_end_writeback+0x7d/0x80
cifs_writepages+0x998/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

BUG at mm/filemap.c:1593 inside folio_end_writeback means writeback is being
ended on a folio that is no longer flagged as under writeback — the folio's
writeback state has already been completed/torn down once. Combined with the
refcount underflow on the CIFS writedata and the socket send failure
(Error -32 / EPIPE) seen in the same event, the signature is a use-after-free
/ double-completion of the writeback in the SMB2 async write path, occurring
during a synchronous CIFS flush. We read the failed/aborted send during
writeback as the likely trigger, but state this as a hypothesis rather than a
proven sequence (see "A note on ordering").

Matching offsets on all machines: cifs_call_async+0x1ee, smb2_async_writev+0x473,
cifs_writepages+0x52f (send path) and +0x998 (writeback-end path),
folio_end_writeback+0x7d, BUG at mm/filemap.c:1593.

Socket error code: across all 17 dumps the ONLY error ever logged is
"Error -32 sending data on socket to server" (20 occurrences total). No other
error code appears.

A note on ordering

The three symptoms — the refcount underflow (refcount_warn_saturate), the
socket send failure (CIFS: VFS: ... Error -32 sending data on socket), and the
BUG in folio_end_writeback — appear together in every dump, but their PRINTED
order is not stable (it differs between hosts and even between different dumps
of the same host). We therefore do NOT claim a proven cause-and-effect order
between the send failure and the refcount underflow. printk ordering on a
many-CPU box under load does not necessarily reflect the true event timeline,
and the send-error and refcount messages originate in different contexts. What
is consistent across all dumps is the end state: a CIFS writeback whose state
is ended twice (__folio_end_writeback() returns false -> BUG), in a
synchronous CIFS flush path, in the presence of a failing/aborted SMB2 send.
The "failed send during writeback triggers a bad writeback completion"
reading is our best-supported hypothesis, not a fact the logs establish on
their own.

--------------------------------------------------------------------------------
SECOND MANIFESTATION — GPF ON A NON-CANONICAL ADDRESS IN unlock_page
--------------------------------------------------------------------------------

4 of the 17 dumps (hostB x3, hostA x1) do not reach the BUG in
folio_end_writeback but die a few instructions earlier with a general
protection fault, dereferencing a garbage folio pointer:

general protection fault, probably for non-canonical address
0xd0bbf42d90685ec1: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:unlock_page+0x5/0x40
Call Trace:
? unlock_page+0x5/0x40
cifs_writepages+0x585/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
__filemap_fdatawrite_range+0x54/0x80
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
filp_flush+0x2e/0x80
__x64_sys_close+0x2e/0x80

Preamble (refcount_warn_saturate + Error -32) and entry path are identical to
the BUG variant; only the point of death differs (unlock_page on an
already-freed/poisoned folio vs. folio_end_writeback on a folio whose writeback
bit is already clear). Both are consistent with the same use-after-free /
double-completion of the CIFS writeback state.

--------------------------------------------------------------------------------
NOT ONLY close() — SECOND SYSCALL ENTRY PATH VIA open()
--------------------------------------------------------------------------------

15 of the 17 dumps enter the fatal writeback via the flush on close()
(cifs_flush -> filp_flush -> __x64_sys_close). Two hostC dumps (both
2026-07-03, one of them on an untainted -687.15.1, comm "dask worker") enter it
via open() instead:

do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
__filemap_fdatawrite_range+0x54/0x80
filemap_write_and_wait_range+0x3e/0xb0
cifs_open+0x56e/0xc70 [cifs]
do_dentry_open+0x14f/0x440
do_open+0x219/0x400
path_openat+0x110/0x280
do_filp_open+0xb0/0x160
do_sys_openat2+0x96/0xd0
__x64_sys_openat+0x53/0xa0

The defect is therefore not tied to the close() syscall specifically, but to
the synchronous filemap_write_and_wait_range() flushes that the CIFS code
issues itself (so far observed from cifs_flush and cifs_open). We have NOT
observed the crash from fsync/msync, background writeback (kworker/flush) or
memory reclaim in any dump.

--------------------------------------------------------------------------------
BOTH CACHE MODES AFFECTED
--------------------------------------------------------------------------------

hostA and hostB run different CIFS cache modes, and each crashed with the same
confirmed signature:

- hostA (R740): cache=none
- hostB (R750xa): cache=strict

This is visible in the stacks themselves. On hostB (cache=strict), the writeback
path goes through cifs_strict_writev:

cifs_writepages+0x52f/0xbc0 [cifs]
? generic_perform_write+0x14c/0x210
do_writepages+0xd5/0x1b0
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
...
cifs_writepages+0x998/0xbc0 [cifs]
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]

The cifs_strict_writev frame is present on hostB and absent on hostA, confirming
the two crashes reach the same folio_end_writeback double-completion through two
different CIFS write paths (strict vs. none). The bug therefore does NOT depend
on a single cache mode; it is in the writeback-completion handling common to
both.

--------------------------------------------------------------------------------
crash(8) ANALYSIS — VERIFIED SOURCE LINE AND FULL KERNEL STACK
--------------------------------------------------------------------------------

crash(8) sessions over the full vmcores of hostA and hostB (with vmlinux
debuginfo for 5.14.0-687.15.1.el9_8) confirm the source line and the complete
in-kernel stack that the redacted dmesg only shows by offset.

The disassembly of folio_end_writeback shows the BUG() at line 1593 is reached
directly from the "if (!__folio_end_writeback(folio)) BUG();" path — i.e.
__folio_end_writeback() returned false because the folio's PG_writeback flag was
already clear:

1591 folio_get(folio);
1592 if (!__folio_end_writeback(folio))
... call __folio_end_writeback ; test %al,%al ; je <+125>
1593 BUG();
0xffffffff8137921d <+125>: ud2

Resolved kernel-side backtrace (hostA; hostB is identical bar addresses):

[exception RIP: folio_end_writeback+125]
0000008 cifs_writepages [cifs]
0000009 do_writepages
0000010 filemap_fdatawrite_wbc
0000011 __filemap_fdatawrite_range
0000012 filemap_write_and_wait_range
#13 cifs_flush [cifs]
0000014 filp_flush
0000015 __x64_sys_close
0000016 do_syscall_64
0000017 entry_SYSCALL_64_after_hwframe

This matches the dmesg-derived signature exactly and pins the BUG to the
__folio_end_writeback()-returns-false (writeback already ended) case.

Note for reviewers: in the slab PAGE lines of the attachments, MAPPING values
of the form dead0000000004xx / dead000000000001 are the normal kernel slab
page-poison marker (page->mapping for a slab page), NOT corruption and NOT a
redaction.

--------------------------------------------------------------------------------
CIFS MOUNT OPTIONS (anonymized)
--------------------------------------------------------------------------------

Requested options (autofs map; same on all hosts):

sec=krb5,cruid=${UID},uid=${UID},gid=${GID},forceuid,forcegid,
iocharset=utf8,vers=3.0,nosuid,nodev,dir_mode=0700,file_mode=0700,
noserverino,cache=none

Effective options after expansion (from the hostA/hostB dumps), anonymized:

hostA (R740) — cache=none:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=none,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

hostB (R750xa) — cache=strict:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=strict,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

Anonymized fields: cruid/uid -> , gid -> , username -> ,
addr -> . All other values are verbatim. The two hosts differ
only in the cache mode (none vs. strict).

Why these may matter to maintainers (context, not a diagnosis):

- cache mode. Same signature under cache=none (hostA) and cache=strict (hostB),
so the bug is not specific to one writeback path; see "Both cache modes
affected".
- vers=3.0 (not 3.1.1) and sec=krb5 narrow down which SMB2/3 code path and
auth path are in use.
- soft, actimeo=1, closetimeo=1. A soft mount with very short attribute/close
timeouts means operations abort with errors sooner under network pressure —
consistent with the Error -32 / "send fails mid-writeback" condition seen in
the dumps.
- rsize/wsize=4194304 (4 MiB). Large I/O sizes, relevant to how writeback is
chunked.

We note these as potentially relevant context; we are not claiming any single
option is the proven cause.

--------------------------------------------------------------------------------
UPSTREAM CONTEXT (known class of bug; exact fix status for el9 is an open
question)
--------------------------------------------------------------------------------

This is consistent with a previously reported class of CIFS writeback-completion
bugs rather than a brand-new defect:

- On the linux-cifs list (Feb 2024), Steve French reported the same call path
(cifs_flush -> filemap_write_and_wait_range -> ... -> folio_end_writeback)
hit under xfstests when writes time out due to repeatedly failing server
reconnects. Matthew Wilcox's reading was that the bug is something failing to
call folio_end_writeback() when it should — i.e. a mismatch in writeback-end
accounting, which is exactly the __folio_end_writeback()-returns-false
signature seen here. Our trigger (Error -32 / EPIPE on the socket send during
the close() flush) is the same "send/reconnect fails mid-writeback" condition.
Thread: https://www.spinics.net/lists/linux-cifs/msg31067.html

- The CIFS writeback path saw significant churn upstream: a two-phase
cifs_writepages_begin / cifs_extend_writeback design (around f3dc1bdb6b0b
"cifs: Fix writeback data corruption"), later a cut-over to netfslib
(3ee1a1fc3981), plus follow-up fixes (e.g. a per-cifs_writepages_begin folio
leak fix by Yang Erkun). Several of these touch exactly the folio/writeback
refcounting on the write path.

We have NOT been able to identify a single specific upstream commit and confirm
whether it is present in or missing from the el9_8 kernels. Note that the crash
reproduces unchanged on 5.14.0-687.20.1.el9_8 (the newest build we have in
production), so whatever fix is needed is still missing as of that build.
Determining whether el9's backport of the CIFS writeback path already contains
the relevant fix (or needs one) is the key question for the maintainers, and
requires checking the el9 kernel changelog against the upstream CIFS/netfs
writeback fixes above. We're happy to provide the full vmcore(s) and test
further.

--------------------------------------------------------------------------------
ATTACHMENTS
--------------------------------------------------------------------------------

14 files — for each of seven representative dumps a vmcore-dmesg (.txt) and the
matching kexec/kdump boot log (.log). Naming: --,
where 151/171/201 = 5.14.0-687.15.1/-687.17.1/-687.20.1.el9_8, "bug" = kernel
BUG at mm/filemap.c:1593, "gpf" = GPF variant in unlock_page, "openat" = BUG
variant entered via open() instead of close():

hostA-151-bug.txt/.log R740, tainted P OE, BUG, close(), 2026-06-23
hostB-151-bug.txt/.log R750xa, tainted P OE, BUG, close(), 2026-06-21
hostB-171-bug.txt/.log R750xa, BUG on -687.17.1, close(), 2026-07-11
hostB-171-gpf.txt/.log R750xa, GPF in unlock_page, close(), 2026-07-09
hostC-151-openat.txt/.log R740, NOT TAINTED, BUG, open() entry, 2026-07-03
hostC-201-bug.txt/.log R740, NOT TAINTED, BUG on -687.20.1, 2026-07-03
hostD-201-bug.txt/.log R640, NOT TAINTED, BUG on -687.20.1, 2026-07-03

Full vmcores for all 17 dumps are retained and available on request.

0000636: kernel BUG in folio_end_writeback via cifs_writepages on close()

Mon, 13 Jul 2026 12:42:49 +0000

--------------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------------

5.14.0-687.15.1.el9_8 — kernel BUG at mm/filemap.c:1593 in folio_end_writeback,
reached from cifs_writepages during the writeback flush on close(). Seen in the
same event are a refcount_warn_saturate (refcount underflow / use-after-free) in
the CIFS async write path and a socket send failure (Error -32 / EPIPE) to the
server. The crash(8) disassembly confirms the BUG is the
"if (!__folio_end_writeback(folio)) BUG();" case — i.e. writeback is ended on a
folio whose writeback flag was already clear (a double-completion of writeback).

Severity: crash / kernel panic
Category: kernel

--------------------------------------------------------------------------------
TWO INDEPENDENT MACHINES, IDENTICAL PANIC
--------------------------------------------------------------------------------

The same panic was captured on two physically different servers running the
identical kernel build. The call traces match down to the same symbol offsets.

hostA
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernel : 5.14.0-687.15.1.el9_8
Comm : dask worker [tc (PID 70950, CPU 22)
Hardware: 40 CPUs, 766.6 GB RAM
CIFS : cache=none

hostB
Server : Dell PowerEdge R750xa, BIOS 1.20.2
Kernel : 5.14.0-687.15.1.el9_8
Comm : pt_main_thread (PID 246362, CPU 21)
Hardware: 24 CPUs, 383.2 GB RAM
CIFS : cache=strict

Kernel build string (both dumps):

Linux version 5.14.0-687.15.1.el9_8.x86_64
(mockbuild@x64-builder01.almalinux.org) ...
#1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:51:45 EDT 2026

Two different server models crashing at the identical instruction with the
identical call chain points to a software defect, not a per-machine hardware
fault. The only taint flag present before the crash is from an out-of-tree
module (NVIDIA, visible in "Modules linked in"); there is no machine-check /
hardware-error taint in either dump.

The two hosts also run different CIFS cache modes (hostA cache=none, hostB
cache=strict) yet hit the identical signature — see "Both cache modes affected"
below.

--------------------------------------------------------------------------------
WHAT THE DUMPS SHOW
--------------------------------------------------------------------------------

In both dumps the crash is a two-part event on the same CPU/PID. The two parts
are shown below in the order the report discusses them; the order in which they
were actually printed to the kernel log varies (see "A note on ordering" at the
end of this section).

1) refcount underflow in the CIFS async write path

refcount_t: underflow; use-after-free.
WARNING: CPU: PID: at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
... Tainted: P OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:refcount_warn_saturate+0xba/0x110
Call Trace:
refcount_warn_saturate+0xba/0x110
cifs_call_async+0x1ee/0x330 [cifs]
smb2_async_writev+0x473/0x6f0 [cifs]
? __pfx_cifs_writedata_release+0x10/0x10 [cifs]
cifs_writepages+0x52f/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

The release function on the stack is cifs_writedata_release — i.e. the object
whose refcount saturates/underflows is the CIFS writedata associated with this
writeback.

2) socket send failure, and the BUG

CIFS: VFS: \\ Error -32 sending data on socket to server
------------[ cut here ]------------
kernel BUG at mm/filemap.c:1593!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
... Tainted: P W OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:folio_end_writeback+0x7d/0x80
Call Trace:
folio_end_writeback+0x7d/0x80
cifs_writepages+0x998/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

BUG at mm/filemap.c:1593 inside folio_end_writeback means writeback is being
ended on a folio that is no longer flagged as under writeback — the folio's
writeback state has already been completed/torn down once. Combined with the
refcount underflow on the CIFS writedata and the socket send failure
(Error -32 / EPIPE) seen in the same event, the signature is a use-after-free
/ double-completion of the writeback in the SMB2 async write path, occurring
during the flush on close(). We read the failed/aborted send during writeback
as the likely trigger, but state this as a hypothesis rather than a proven
sequence (see "A note on ordering").

Matching offsets on both machines: cifs_call_async+0x1ee, smb2_async_writev+0x473,
cifs_writepages+0x52f (send path) and +0x998 (writeback-end path),
folio_end_writeback+0x7d, BUG at mm/filemap.c:1593.

A note on ordering

The three symptoms — the refcount underflow (refcount_warn_saturate), the
socket send failure (CIFS: VFS: ... Error -32 sending data on socket), and the
BUG in folio_end_writeback — appear together in every dump, but their PRINTED
order is not stable (it differs between hosts and even between different dumps
of the same host). We therefore do NOT claim a proven cause-and-effect order
between the send failure and the refcount underflow. printk ordering on a
many-CPU box under load does not necessarily reflect the true event timeline,
and the send-error and refcount messages originate in different contexts. What
is consistent across both dumps is the end state: a CIFS writeback whose state
is ended twice (__folio_end_writeback() returns false -> BUG), in the close()
flush path, in the presence of a failing/aborted SMB2 send. The "failed send
during writeback triggers a bad writeback completion" reading is our
best-supported hypothesis, not a fact the logs establish on their own.

--------------------------------------------------------------------------------
BOTH CACHE MODES AFFECTED
--------------------------------------------------------------------------------

The two hosts run different CIFS cache modes, and each crashed with the same
confirmed signature:

- hostA (R740): cache=none
- hostB (R750xa): cache=strict

This is visible in the stacks themselves. On hostB (cache=strict), the writeback
path goes through cifs_strict_writev:

cifs_writepages+0x52f/0xbc0 [cifs]
? generic_perform_write+0x14c/0x210
do_writepages+0xd5/0x1b0
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
...
cifs_writepages+0x998/0xbc0 [cifs]
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]

The cifs_strict_writev frame is present on hostB and absent on hostA, confirming
the two crashes reach the same folio_end_writeback double-completion through two
different CIFS write paths (strict vs. none). The bug therefore does NOT depend
on a single cache mode; it is in the writeback-completion handling common to
both.

--------------------------------------------------------------------------------
crash(8) ANALYSIS — VERIFIED SOURCE LINE AND FULL KERNEL STACK
--------------------------------------------------------------------------------

crash(8) sessions over the full vmcores (with vmlinux debuginfo for
5.14.0-687.15.1.el9_8) confirm the source line and the complete in-kernel stack
that the redacted dmesg only shows by offset.

The disassembly of folio_end_writeback shows the BUG() at line 1593 is reached
directly from the "if (!__folio_end_writeback(folio)) BUG();" path — i.e.
__folio_end_writeback() returned false because the folio's PG_writeback flag was
already clear:

1591 folio_get(folio);
1592 if (!__folio_end_writeback(folio))
... call __folio_end_writeback ; test %al,%al ; je <+125>
1593 BUG();
0xffffffff8137921d <+125>: ud2

Resolved kernel-side backtrace (hostA; hostB is identical bar addresses):

[exception RIP: folio_end_writeback+125]
0000008 cifs_writepages [cifs]
0000009 do_writepages
0000010 filemap_fdatawrite_wbc
0000011 __filemap_fdatawrite_range
0000012 filemap_write_and_wait_range
#13 cifs_flush [cifs]
0000014 filp_flush
0000015 __x64_sys_close
0000016 do_syscall_64
0000017 entry_SYSCALL_64_after_hwframe

This matches the dmesg-derived signature exactly and pins the BUG to the
__folio_end_writeback()-returns-false (writeback already ended) case.

Note for reviewers: in the slab PAGE lines of the attachments, MAPPING values
of the form dead0000000004xx / dead000000000001 are the normal kernel slab
page-poison marker (page->mapping for a slab page), NOT corruption and NOT a
redaction.

--------------------------------------------------------------------------------
CIFS MOUNT OPTIONS (anonymized)
--------------------------------------------------------------------------------

Requested options (autofs map; same on both hosts):

sec=krb5,cruid=${UID},uid=${UID},gid=${GID},forceuid,forcegid,
iocharset=utf8,vers=3.0,nosuid,nodev,dir_mode=0700,file_mode=0700,
noserverino,cache=none

Effective options after expansion (from the dumps), anonymized:

hostA (R740) — cache=none:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=none,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

hostB (R750xa) — cache=strict:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=strict,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

Anonymized fields: cruid/uid -> , gid -> , username -> ,
addr -> . All other values are verbatim. The two hosts differ
only in the cache mode (none vs. strict).

Why these may matter to maintainers (context, not a diagnosis):

- cache mode. Same signature under cache=none (hostA) and cache=strict (hostB),
so the bug is not specific to one writeback path; see "Both cache modes
affected".
- vers=3.0 (not 3.1.1) and sec=krb5 narrow down which SMB2/3 code path and
auth path are in use.
- soft, actimeo=1, closetimeo=1. A soft mount with very short attribute/close
timeouts means operations abort with errors sooner under network pressure —
consistent with the Error -32 / "send fails mid-writeback" condition seen in
the dumps.
- rsize/wsize=4194304 (4 MiB). Large I/O sizes, relevant to how writeback is
chunked.

We note these as potentially relevant context; we are not claiming any single
option is the proven cause.

--------------------------------------------------------------------------------
UPSTREAM CONTEXT (known class of bug; exact fix status for el9 is an open
question)
--------------------------------------------------------------------------------

This is consistent with a previously reported class of CIFS writeback-completion
bugs rather than a brand-new defect:

- On the linux-cifs list (Feb 2024), Steve French reported the same call path
(cifs_flush -> filemap_write_and_wait_range -> ... -> folio_end_writeback)
hit under xfstests when writes time out due to repeatedly failing server
reconnects. Matthew Wilcox's reading was that the bug is something failing to
call folio_end_writeback() when it should — i.e. a mismatch in writeback-end
accounting, which is exactly the __folio_end_writeback()-returns-false
signature seen here. Our trigger (Error -32 / EPIPE on the socket send during
the close() flush) is the same "send/reconnect fails mid-writeback" condition.
Thread: https://www.spinics.net/lists/linux-cifs/msg31067.html

- The CIFS writeback path saw significant churn upstream: a two-phase
cifs_writepages_begin / cifs_extend_writeback design (around f3dc1bdb6b0b
"cifs: Fix writeback data corruption"), later a cut-over to netfslib
(3ee1a1fc3981), plus follow-up fixes (e.g. a per-cifs_writepages_begin folio
leak fix by Yang Erkun). Several of these touch exactly the folio/writeback
refcounting on the write path.

We have NOT been able to identify a single specific upstream commit and confirm
whether it is present in or missing from 5.14.0-687.15.1.el9_8. Determining
whether el9's backport of the CIFS writeback path already contains the relevant
fix (or needs one) is the key question for the maintainers, and requires checking
the el9 kernel changelog against the upstream CIFS/netfs writeback fixes above.
We're happy to provide the full vmcore(s) and test further.

0000648: gstreamer packages missing qt6 subpackages

Mon, 13 Jul 2026 03:57:55 +0000

Hi!

The package gstreamer1-plugins-good is not build with the qt6 subpackage (gstreamer1-plugins-good-qt6).

This may be enabled by passing --with qt6 to `rpmbuild` or by modifying the spec.

This package is necessary for some qt/kde applications (like kamoso).

Thanks!

0000646: Qemu-img create fails on loop device with sector size 4096

Thu, 09 Jul 2026 13:31:38 +0000

I am getting this issue when trying to convert a qcow2 image to raw on a 4k sector size NVMe disk.
My current qemu-img version is : qemu-img-10.1.0-17.el9_8.3.alma

0000638: samba-4.19.4-16.el8_10.src.rpm fails to build on AlmaLinux 8.10: samba-4.19-redhat.patch cannot be applied

Wed, 08 Jul 2026 08:27:41 +0000

I am trying to rebuild the official samba-4.19.4-16.el8_10.src.rpm package on AlmaLinux 8.10.

The build process fails during the %prep phase while applying the samba-4.19-redhat.patch patch.

The error obtained is:

/usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch

1 out of 3 hunks FAILED -- saving rejects to file lib/util/substitute.c.rej
1 out of 7 hunks FAILED -- saving rejects to file source3/printing/print_generic.c.rej
1 out of 1 hunk FAILED -- saving rejects to file docs-xml/smbdotconf/printing/printcommand.xml.rej

error: Bad exit status from /var/tmp/rpm-tmp.ulMvkp (%prep)

0000645: KVM AMD-V Random Crashes

Tue, 07 Jul 2026 01:34:38 +0000

Hello. I run many Almalinux systems with various AMD CPUs, a mix of Zen4 and Zen5. Over the years kernel patches for Zen4 bugs (which are many) have been pushed to fix stability particularly regarding virtualization platforms or nested virtualization. Over the past year or two I've still had seemingly completely random crashes for various reasons and I'm stumped. The most recent crash was on an Almalinux 10 system, kernel 6.12 (though similar crashes on mainline), with an Epyc 4464P processor.

The things that stick out in my vmcore dump in /var/crash:

[5516734.848500] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[5516734.848872] CPU: 13 UID: 107 PID: 3126435 Comm: CPU 0/KVM Kdump: loaded Not tainted 6.12.0-124.52.1.el10_1.x86_64 #1 PREEMPT(voluntary)
[5516734.849343] Hardware name: Supermicro AS -3015MR-H8TNR/H13SRD-F, BIOS 1.8 12/23/2025
[5516734.849473] RIP: 0010:srso_alias_return_thunk+0x5/0xfbef5

Attached is a full copy of the vmcore-dmesg crash from my original file (to cut out the standard/useless log)... Anyone have any idea on this? It's seemingly impossible to reproduce, and is random, and seems to be related to a previous flaw mitigation patch for AMD, and related to memory corruption or vulnerability from a guest virtual machine.

I thought about filing a kernel bug report but bugzilla is down, so hopefully someone here might have some insight. I have other AMD Zen4 EPYC systems with rare, random crashes, also related to the CPU/memory seemingly.

0000643: [AlmaLinux][Backport][MANA] net: mana: Fall back to standard MTU when PF reports adapter_mtu of 0

Wed, 01 Jul 2026 17:10:13 +0000

Request backport of the following bug fix patch.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6bd81a5b4e0d

0000642: [AlmaLinux][Mana][Backport] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR

Wed, 01 Jul 2026 14:31:42 +0000

Request backport of the following patch.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=95084f1883a7

0000641: [AlmaLinux][Backport][Mana] patches for Numa, RSS Queues.

Wed, 01 Jul 2026 14:25:23 +0000

Request backport of the following patches

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=45b2b84ac6fde39c427018d6cdf7d44258938faa
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/commit/?h=hyperv-fixes&id=7b3b1e5a87b2f5e35c52b5386d7c327be869454f

0000640: [AlmaLinux][Backport][MANA] net: mana: Optimize irq affinity for low vcpu configs

Wed, 01 Jul 2026 13:59:06 +0000

Upstream References

https://lore.kernel.org/all/20260624072138.1632849-1-shradhagupta@linux.microsoft.com/

Dependence Patch
upstream previous kernel version for patch: bug fix for: Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")

0000639: [AlmaLinux][Backport][MANA] net: mana: fix error-path issues in queue setup

Tue, 30 Jun 2026 12:55:57 +0000

Request backport of the following patch.

Problem Summary
Two error-path fixes in MANA queue setup, both surfaced during review of a recently upstreamed patch series.

Patch 1 initializes queue->id to INVALID_QUEUE_ID in mana_gd_create_mana_wq_cq() so that a CQ creation failure before the firmware id is assigned does not NULL gc->cq_table[0] and silently break whichever real CQ owns that slot. This mirrors the existing pattern in mana_gd_create_eq().

Patch 2 guards mana_destroy_txq()'s call to mana_destroy_wq_obj() with an INVALID_MANA_HANDLE check, mirroring mana_destroy_rxq(). Without it, TX setup failures lead to a firmware-rejected destroy of (u64)-1 and a spurious error in dmesg.

Upstream reference

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5985474e1cb4
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f8fd56977eee

0000637: [AlmaLinux][Mana][Backport] Cobalt 200 mana networking performance patch to use full 4k page rx buffers (disable page fragmentat

Tue, 30 Jun 2026 12:18:05 +0000

Request backport of the following patch.

Primary Patch

https://lore.kernel.org/all/20260602202801.1873742-1-dipayanroy@linux.microsoft.com/

Prerequisite Patches
https://lore.kernel.org/all/acLUhLpLum6qrD%2fN@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=17bfe0a8c014
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5b05aa36ee24

Dependencies
All prerequisite patches must be applied before enabling the ethtool flag patch
Requires existing MANA RX path implementation with page_pool support

0000635: AMDI0015 (DesignWare I3C master) driver initialization failure (Timeout -110 / UBSAN shift-out-of-bounds) on AMD EPYC 5th Gen

Thu, 25 Jun 2026 12:58:53 +0000

IMPORTANT NOTE FOR TRIAGE:
We are opening this ticket here under the explicit direction of Benny (AlmaLinux). Although the attached logs were captured from a Proxmox VE kernel environment, this is a critical upstream Linux kernel driver/hardware compatibility issue on the new AMD EPYC 5th Gen platform. It directly impacts any modern enterprise Linux ecosystem trying to leverage native I3C telemetry on this Gigabyte hardware.

---

A critical issue has been identified during the initialization of the native MIPI I3C bus on an AMD EPYC 5th Generation platform hosted on a Gigabyte server (Model: XV23-ZU0-AAJ1-000).

During the boot sequence, the Synopsys/DesignWare I3C master control driver (dw-i3c-master.c) fails entirely. This driver failure triggers two explicit kernel errors:
1. UBSAN Math Error (Underflow): A shift-out-of-bounds error occurs when the driver tries to parse an invalid or corrupt hardware initialization response as an unsigned 64-bit integer.
2. Driver Timeout (Error -110): The integrated AMD ACPI I3C devices (AMDI0015) do not respond to the OS probing requests within the time limit (ETIMEDOUT), causing the controller to fail and disable itself.

Secondary Impact (Power Capping):
Concurrently, the CPU performance is degraded; the processor persistently caps its power consumption at ~245W despite its nominal 300W TDP specification. This is highly suspected to be a security Power Capping mechanism triggered by the AMD System Management Unit (SMU) or BMC due to the lack of high-speed telemetry from the VRMs/PMICs over the failed I3C bus.

Hardware & Firmware Context:
* Server Model: Gigabyte XV23-ZU0-AAJ1-000 (Motherboard MZU3-MG0-000)
* CPU: AMD EPYC 5th Generation
* Firmware: BIOS version R22_F17

0000634: Disk I/O issue in Proxmox VM (Aborted Command) + XFS shut down

Thu, 18 Jun 2026 10:13:05 +0000

Following this thread : https://forum.proxmox.com/threads/io_uring-on-kernel-7-0-6-2-pve-pve-9-2-3-guest-disk-i-o-errors-eio-filesystem-xfs-shutdown.184360/

I discovered a strange behavior on AlmaLinux 10 inside a Proxmox VM. It appears that kernel 6.12.0-211.22.1.el10_2.x86_64 has issue that triggers a disk failure (see screenshots).

Randomly, the filesystem (XFS) becomes unavailable and I can't do anything more except stop and start the VM again.

I don't know if it's related to the storage architecture on Proxmox but I'm using LUKS + LVM-thin on 2 different hosts that are impacted.

Here is the way I was able to reproduce :

root@zabbix :~$ fio --name=stress-write --ioengine=libaio --iodepth=64 --rw=randwrite \
--bs=4k --direct=1 --size=20G --numjobs=8 --runtime=600 \
--time_based --ramp_time=30 --group_reporting \
--filename=/tmp/fio-test --output-format=normal,json \
--output=fio-result.json
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:15s]
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:15s]
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:14s]
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=20592291840, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=9765498880, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=11389923328, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10865082368, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=4592693248, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=17240551424, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10608463872, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18193764352, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10405310464, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18420568064, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=20068622336, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=14732562432, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=19714949120, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=11894398976, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=13342396416, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18269777920, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=21153767424, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=8210624512, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=5009162240, buflen=4096

0000633: [AlmaLinux][Backport][MANA] net: mana: Cache MANA_QUERY_LINK_CONFIG result to avoid repeated HWC queries

Mon, 15 Jun 2026 05:50:08 +0000

Request backport of the following patch to all active kernels.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=8e0ffcc926f4

0000632: [AlmaLinux][MANA][Backport][Distros] Patch: net: mana: Add support for PF device 0x00C1

Mon, 15 Jun 2026 05:06:37 +0000

Request backport of the following patch.

Problem Summary : Dual link feature added 2nd PF, that require this patch to support it.

Impact on Customer VMs/BMs : All BM (Bare metal) instances with Dual Link feature. (VR system)
Repro details : without this patch the 2nd PF (device 0x00C1) won't be available.
Relationship to large feature : None
Patch Criticality: Medium (High for Distros on VR system)
Classification : New feature
Upstream reference

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=53a65db20a4f3fe6c01b1f789f9eae6b1244910f

0000623: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 8

Wed, 10 Jun 2026 21:49:37 +0000

Currently, the maximum queue depth supported for gVNIC on overcommited Gen3+ VMs such as N4 is 1K, whereas the maximum queue depth supported on Gen1/Gen2 VMs is 2K. Customers who are migrating their workloads from N2 to N4 have requested higher queue depth support on N4 VMs.

GVE driver changes to support greater than 1K queue depth for overcommitted Gen3+ have been upstreamed to Linux kernel recently:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a2f19184014f
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=07993df56091

0000621: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 10

Fri, 05 Jun 2026 13:20:21 +0000