Description

Every rolling nightly from 2026.08.04-0035 onward is unbootable on Intel Denverton
(Atom C3000), Ice Lake Xeon D (Xeon D-1700/2700, ICX-D/CDF) and Snowridge hardware.
vyos-build moved kernel_version to 6.18.41 in 97c2a87c0 (T9067, 2026-08-02), and
6.18.39 through 6.18.41 carry an upstream regression in the built-in 8250_mid PCI
UART driver.

The failure presents as a silent hang immediately after GRUB prints
Booting <version>. Nothing is printed, because the cmdline VyOS generates
(data/templates/grub/grub_vyos_version.j2 in vyos-1x) is console=tty0 with no
earlycon, so the oops happens before the VT console is usable. Adding
earlycon=efifb keep_bootcon ignore_loglevel reveals it.

Affected versions

VyOS rolling: images through 2026.07.30 are fine (6.18.38); 2026.08.04 onward are
broken (6.18.41). As of 2026-08-11 rolling is still on 6.18.41.

Reproduction

Supermicro SYS-510D-10C-FN6P / X12SDV-10C-SP6F, BIOS 2.2a (04/28/2026), UEFI, installed
image 2026.08.05-0033-rolling. Boot normally -> hang after "Booting". From the GRUB
prompt with earlycon=efifb keep_bootcon ignore_loglevel appended:

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.18.41-vyos #1 NONE
Hardware name: Supermicro SYS-510D-10C-FN6P/X12SDV-10C-SP6F, BIOS 2.2a 04/28/2026
Workqueue: events work_for_cpu_fn
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
CR2: ffffffffffffffd6
Call Trace:
 <TASK>
 mid8250_probe.part.0+0x10c/0x230
 ? __pfx_mid8250_set_termios+0x10/0x10
 local_pci_probe+0x41/0x90
 work_for_cpu_fn+0x16/0x20
 process_one_work+0x187/0x340
 worker_thread+0x19d/0x310
 kthread+0xe6/0x200
 ret_from_fork+0x1a9/0x1e0
 ret_from_fork_asm+0x1a/0x30
 </TASK>
Modules linked in:
note: kworker/0:1[11] exited with irqs disabled

RIP: 0010:0x0 is a call through a NULL function pointer; Modules linked in: is empty,
consistent with a built-in driver oopsing before any module loads.

Root cause

b1b4efea05a5 "serial: 8250_mid: Disable DMA for selected platforms" (in stable since
v6.18.39) set dnv_board.setup and dnv_board.exit to PTR_IF(false, ...) — i.e.
NULL — to work around a documented DMA errata (Denverton document #572409 DNV60, Ice
Lake Xeon D #714070 ICXD65, Snowridge #731931 SNR44). It did not add NULL checks at the
three call sites in mid8250_probe() and mid8250_remove(), which had been removed
back in 2022 by 324facd1ccb3 ("Remove unneeded test for ->setup() presence").

We build CONFIG_SERIAL_8250_MID=y, so this is a built-in driver oopsing during early
PCI probe. The probing kworker exits with interrupts disabled and boot never proceeds.

Fixed upstream by 7fb13fd7e9a5 "serial: 8250_mid: Fix NULL function pointer
dereference on DNV/ICX-D/SNR platforms", carrying Fixes: and Cc: stable. Applied to
linux-6.18.y as b2a3eeb57ba2 on 2026-08-03, i.e. first released in v6.18.42.

Proposed fix

Bump data/defaults.toml kernel_version to 6.18.44 (current 6.18.y tip).

Verified that all five patches in scripts/package-build/linux-kernel/patches/kernel/
still apply: of the files they touch, only net/ipv6/route.c changed between v6.18.41
and v6.18.44 — 1db34097998c ("ipv6: Change allocation flags to match rcu_read_lock
section requirements"), editing __ip6_del_rt_siblings() around line 4011. That does
not overlap 0001-linkstate-ip-device-attribute.patch, whose hunks are
rt6_link_filter() / rt6_score_route() around lines 717 and 758. Context offsets only.

Workaround for affected users

The driver is built in, so modprobe blacklisting does not work. Append to the kernel
cmdline instead:

initcall_blacklist=mid8250_pci_driver_init

(module_pci_driver(mid8250_pci_driver) produces the initcall symbol
mid8250_pci_driver_init.) This skips driver registration entirely, so the probe never
runs. Cost is the PCI-enumerated HSUART; IPMI SOL on the standard COM port is
unaffected. Persist it with set system option kernel boot-options once booted, or just
boot the previous image from the GRUB menu.

Possible follow-up (separate task)

Consider adding earlycon to the generated boot options, or documenting it in the
recovery path. A built-in driver oopsing before VT console init is currently
indistinguishable from a dead machine — the visible symptom is GRUB's "Booting ..." line
and nothing else, which cost significant diagnosis time here.