** Changed in: apparmor (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2141298
Title:
AppArmor blocks write(2) to network sockets with Linux 6.19
Status in snapd:
Confirmed
Status in apparmor package in Ubuntu:
Fix Released
Status in chromium-browser package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Bug description:
Ubuntu 26.04 (pre-release) with snapd 2.74 has a regression where
AppArmor blocks network receive operations for Electron-based snaps
with strict confinement, causing all HTTPS connections to fail.
All Electron-based snaps with strict confinement are completely broken
- unable to connect to any HTTPS endpoints.
AFFECTED APPLICATIONS:
- element (tested, confirmed broken)
- prospect-mail (tested, confirmed broken)
- teams-for-linux (tested, confirmed broken)
- Potentially: VS Code, Slack, Discord, and all other Electron snaps
- sbuild+unshare (LP: #2141364)
SYMPTOMS:
1. SSL handshake fails: net_error -10 (ERR_CERT_AUTHORITY_INVALID)
2. App error: "Failed to load URL: https://... with error: ERR_ACCESS_DENIED"
3. Blank page displayed instead of web content
ROOT CAUSE:
AppArmor could be denying network receive operations on IPv6 HTTPS (port 443):
apparmor="DENIED" operation="file_perm" class="net"
profile="snap.teams-for-linux.teams-for-linux"
faddr=2603:1063:27:1::14 fport=443 family="inet6"
sock_type="stream" protocol=6
requested="receive" denied="receive"
SYSTEM INFO:
- Ubuntu: 26.04 (pre-release)
- snapd: 2.74+ubuntu26.04
- Kernel: 6.19.0-3-generic
- snap version output: 2.74
REGRESSION:
- Broken: Ubuntu 26.04 with today update and restart.
STEPS TO REPRODUCE:
1. Install Ubuntu 26.04 (pre-release)
2. Install teams-for-linux snap: snap install teams-for-linux
3. Launch: teams-for-linux
4. Observe SSL errors and AppArmor denials: journalctl -b | grep apparmor | grep DENIED
EXPECTED: Electron snaps can establish HTTPS connections
ACTUAL: AppArmor blocks network receive, all HTTPS connections fail
WORKAROUND:
Use classic confinement (defeats security purpose)
FULL APPARMOR LOG for teams-for-linux:
Feb 09 12:20:52 kernel: audit: type=1400 audit(1770636052.778:4101):
apparmor="DENIED" operation="file_perm" class="net"
profile="snap.teams-for-linux.teams-for-linux" pid=133551
comm="Chrome_ChildIOT" laddr=2a02:8109:a09e:2d00:a71a:d52c:a574:cd43
lport=53180 faddr=2a00:1450:4008:806::200e fport=443 family="inet6"
sock_type="stream" protocol=6 requested="receive" denied="receive"
Log for prospect-mail:
$ prospect-mail
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.087: Theme parsing
error: gtk.css:1413:23: 'font-feature-settings' is not a valid
property name
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.091: Theme parsing
error: gtk.css:3286:25: 'font-feature-settings' is not a valid
property name
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.092: Theme parsing error: gtk.css:3748:23: 'font-feature-settings' is not a valid property name
Loaded settings {
mainMailServiceUrl: 'https://outlook.office.com/mail',
deeplinkUrls: [
'outlook.live.com/mail/deeplink',
'outlook.office365.com/mail/deeplink',
'outlook.office.com/mail/deeplink',
'outlook.office.com/calendar/deeplink',
'to-do.office.com/tasks'
],
mailServicesUrls: [ 'outlook.live.com', 'outlook.office365.com', 'outlook.office.com' ],
safelinksUrls: [
'outlook.office.com/mail/safelink.html',
'safelinks.protection.outlook.com'
]
}
libGL error: MESA-LOADER: failed to open iris (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
libGL error: failed to load driver: swrast
[150913:0209/123744.785246:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150913:0209/123744.785366:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150913:0209/123744.785399:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[150913:0209/123744.786076:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150913:0209/123744.786133:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150913:0209/123744.786156:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[150913:0209/123744.786176:ERROR:ui/gl/gl_display.cc:674] Initialization of all EGL display types failed.
[150913:0209/123744.786200:ERROR:ui/ozone/common/gl_ozone_egl.cc:26] GLDisplayEGL::Initialize failed.
[150913:0209/123744.788284:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150913:0209/123744.788352:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150913:0209/123744.788392:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[150913:0209/123744.789184:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150913:0209/123744.789231:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150913:0209/123744.789258:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[150913:0209/123744.789284:ERROR:ui/gl/gl_display.cc:674] Initialization of all EGL display types failed.
[150913:0209/123744.789309:ERROR:ui/ozone/common/gl_ozone_egl.cc:26] GLDisplayEGL::Initialize failed.
[150913:0209/123744.829927:ERROR:components/viz/service/main/viz_main_impl.cc:189] Exiting GPU process due to errors during initialization
Custom User Agent: Mozilla/5.0 X11; Linux x86_64 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.993: Theme parsing
error: gtk-dark.css:1413:23: 'font-feature-settings' is not a valid
property name
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.995: Theme parsing
error: gtk-dark.css:3286:25: 'font-feature-settings' is not a valid
property name
(prospect-mail:150690): Gtk-WARNING **: 12:37:44.996: Theme parsing error: gtk-dark.css:3748:23: 'font-feature-settings' is not a valid property name
libGL error: MESA-LOADER: failed to open iris (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
libGL error: failed to load driver: swrast
[150950:0209/123745.102046:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150950:0209/123745.102146:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150950:0209/123745.102186:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[150950:0209/123745.102800:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150950:0209/123745.102830:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150950:0209/123745.102854:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[150950:0209/123745.102878:ERROR:ui/gl/gl_display.cc:674] Initialization of all EGL display types failed.
[150950:0209/123745.102904:ERROR:ui/ozone/common/gl_ozone_egl.cc:26] GLDisplayEGL::Initialize failed.
[150950:0209/123745.105119:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150950:0209/123745.105188:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150950:0209/123745.105210:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[150950:0209/123745.105798:ERROR:ui/gl/angle_platform_impl.cc:42] Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1093 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
[150950:0209/123745.105826:ERROR:ui/gl/egl_util.cc:92] EGL Driver message (Critical) eglInitialize: Could not create a backing OpenGL context.
[150950:0209/123745.105847:ERROR:ui/gl/gl_display.cc:639] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[150950:0209/123745.105867:ERROR:ui/gl/gl_display.cc:674] Initialization of all EGL display types failed.
[150950:0209/123745.105886:ERROR:ui/ozone/common/gl_ozone_egl.cc:26] GLDisplayEGL::Initialize failed.
[150950:0209/123745.106596:ERROR:components/viz/service/main/viz_main_impl.cc:189] Exiting GPU process due to errors during initialization
MESA-LOADER: failed to open iris (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: iris
MESA-LOADER: failed to open kms_swrast (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /snap/prospect-mail/75/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load swrast driver
[150920:0209/123745.290838:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[150920:0209/123745.299953:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
(node:150690) electron: Failed to load URL: https://outlook.office.com/mail with error: ERR_ACCESS_DENIED
(Use `prospect-mail --trace-warnings ...` to show where the warning was created)
Prepare 'main.css' to be injected.
Prepare 'unread-number-observer.js' to be injected.
(node:150690) [DEP0180] DeprecationWarning: fs.Stats constructor is deprecated.
Log for teams-for-linux:
$ teams-for-linux
No config file found (user or system-wide), using default values
all good with screenSharingThumbnail you aren't using them
all good with screenLockInhibitionMethod you aren't using them
all good with ssoInTuneEnabled you aren't using them
all good with ssoInTuneAuthUser you aren't using them
Initialising logger with config: {"transports":{"console":{"level":"info"},"file":{"level":false}}}
12:39:48.904 › configPath: /home/alarconj/snap/teams-for-linux/1155/.config/teams-for-linux
12:39:48.906 › Running under Wayland, disabling GPU composition (default behavior)...
12:39:48.906 › Enabling PipeWire for screen sharing...
12:39:48.906 › Disabling GPU support...
dbus-send: /snap/teams-for-linux/1155/lib/x86_64-linux-gnu/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.12.20' not found (required by dbus-send)
12:39:48.932 › [CustomNotificationManager] Initialized and listening on "notification-show-toast" channel
(teams-for-linux:152814): Gtk-WARNING **: 12:39:48.956: Theme parsing
error: gtk.css:1413:23: 'font-feature-settings' is not a valid
property name
(teams-for-linux:152814): Gtk-WARNING **: 12:39:48.959: Theme parsing
error: gtk.css:3286:25: 'font-feature-settings' is not a valid
property name
(teams-for-linux:152814): Gtk-WARNING **: 12:39:48.959: Theme parsing error: gtk.css:3748:23: 'font-feature-settings' is not a valid property name
[152814:0209/123949.008056:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.Secret.Service.ReadAlias: object_path= /org/freedesktop/secrets: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1388" (uid=1000 pid=152814 comm="/snap/teams-for-linux/1155/teams-for-linux --ozone" label="snap.teams-for-linux.teams-for-linux (enforce)") interface="org.freedesktop.Secret.Service" member="ReadAlias" error name="(unset)" requested_reply="0" destination="org.freedesktop.secrets" (uid=1000 pid=3716 comm="/usr/bin/gnome-keyring-daemon --foreground --compo" label="unconfined")
MESA-LOADER: failed to open iris (search paths /snap/teams-for-linux/1155/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: iris
MESA-LOADER: failed to open kms_swrast (search paths /snap/teams-for-linux/1155/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /snap/teams-for-linux/1155/gnome-platform/usr/lib/x86_64-linux-gnu/dri)
failed to load swrast driver
12:39:49.059 › 🔒 IPC Security: Channel allowlisting enabled
12:39:49.059 › 🔒 IPC Security: 50 channels allowlisted
(teams-for-linux:152814): Gtk-WARNING **: 12:39:49.082: Theme parsing
error: gtk-dark.css:1413:23: 'font-feature-settings' is not a valid
property name
(teams-for-linux:152814): Gtk-WARNING **: 12:39:49.084: Theme parsing
error: gtk-dark.css:3286:25: 'font-feature-settings' is not a valid
property name
(teams-for-linux:152814): Gtk-WARNING **: 12:39:49.085: Theme parsing error: gtk-dark.css:3748:23: 'font-feature-settings' is not a valid property name
[152915:0209/123949.124882:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152814:0209/123949.161887:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.login1.Manager.Inhibit: object_path= /org/freedesktop/login1: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.599" (uid=1000 pid=152814 comm="/snap/teams-for-linux/1155/teams-for-linux --ozone" label="snap.teams-for-linux.teams-for-linux (enforce)") interface="org.freedesktop.login1.Manager" member="Inhibit" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=1528 comm="/usr/lib/systemd/systemd-logind" label="unconfined")
[152915:0209/123949.206210:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123949.732665:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123950.248492:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123950.768544:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123951.289729:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123951.833859:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123952.348596:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123952.868749:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123953.397271:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123953.997766:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
[152915:0209/123954.550755:ERROR:net/socket/ssl_client_socket_impl.cc:916] handshake failed; returned -1, SSL error code 1, net_error -10
12:39:54.584 › assignOnDidFailLoadEventHandler : {} - -10 - ERR_ACCESS_DENIED
12:39:54.584 › (node:152814) electron: Failed to load URL: https://teams.cloud.microsoft/ with error: ERR_ACCESS_DENIED
(Use `teams-for-linux --trace-warnings ...` to show where the warning was created)
12:39:54.660 › (node:152814) UnhandledPromiseRejectionWarning: Error: Script failed to execute, this normally means an error was thrown. Check the renderer console for the error.
at node:electron/js2c/renderer_init:2:19969
at IpcRendererInternal.<anonymous> (node:electron/js2c/renderer_init:2:14304)
at IpcRendererInternal.emit (node:events:519:28)
at Object.onMessage (node:electron/js2c/renderer_init:2:13382)
12:39:54.661 › (node:152814) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
RELATED snapd 2.74 CHANGE:
"snap-confine: update AppArmor profile to allow read/write to journal as workaround for snap-confine fd inheritance prevented by newer AppArmor"
This suggests AppArmor policies were updated but network receive was
inadvertently blocked.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/2141298/+subscriptions
понедельник
[Bug 2144336] Re: Support Nova Lake P
** Changed in: linux (Ubuntu Resolute)
Status: Incomplete => Won't Fix
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2144336
Title:
Support Nova Lake P
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Resolute:
Won't Fix
Bug description:
Nova-lake P support is missing in 7.0 but has been merged in linux-next and expected in 7.1
Patches enabling Xe3p_LPG are required, which were submitted in beginning of February and merged upstream [0].
There is two additionnal commits on top of the upstream submission:
- A non upstream patchset to enable the probing of such hardware by default.
- A fixup commit submitted the 3rd March changing the GuC firmware expected [1]
This patchset is submitted in collaboration with intel.
0: https://lore.kernel.org/all/20260206-nvl-p-upstreaming-v3-0-636e1ad32688@intel.com/
1: https://patchwork.freedesktop.org/series/162530/#rev2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2144336/+subscriptions
Status: Incomplete => Won't Fix
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2144336
Title:
Support Nova Lake P
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Resolute:
Won't Fix
Bug description:
Nova-lake P support is missing in 7.0 but has been merged in linux-next and expected in 7.1
Patches enabling Xe3p_LPG are required, which were submitted in beginning of February and merged upstream [0].
There is two additionnal commits on top of the upstream submission:
- A non upstream patchset to enable the probing of such hardware by default.
- A fixup commit submitted the 3rd March changing the GuC firmware expected [1]
This patchset is submitted in collaboration with intel.
0: https://lore.kernel.org/all/20260206-nvl-p-upstreaming-v3-0-636e1ad32688@intel.com/
1: https://patchwork.freedesktop.org/series/162530/#rev2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2144336/+subscriptions
[Bug 2141276] Re: efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE patch
verified with the same above steps on Noble, confirm the proposed kernel
fixed the issue
** Tags removed: verification-needed-noble-linux
** Tags added: verification-done-noble-linux
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2141276
Title:
efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE
patch
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Status in linux source package in Questing:
Fix Committed
Status in linux source package in Resolute:
Fix Released
Bug description:
[Impact]
The swapped bsearch() arguments cause the function to calculate incorrect
element offsets when searching the efi_error_codes array:
- Buggy behavior: bsearch thinks there are 24 elements of 12 bytes each
- Correct behavior: 12 elements of 24 bytes each (on 64-bit systems)
This causes efi_status_to_err() and efi_status_to_str() to read at wrong
memory offsets (every 12 bytes instead of every 24 bytes), potentially:
- Returning incorrect errno values for EFI status codes
- Returning wrong error description strings
- Failing to find valid status codes and returning default error values
These functions are used to translate EFI firmware error codes to Linux
errno values and human-readable strings, affecting error reporting for
EFI-related operations including secure boot and firmware variable access.
[Test Plan]
1. Build kernel with the fix applied
2. Boot system with UEFI firmware
3. Trigger EFI error conditions that exercise efi_status_to_err() and
efi_status_to_str(), such as:
- Secure boot signature verification failures
- EFI variable access errors
- MOK (Machine Owner Key) operations
4. Verify dmesg shows correct EFI error messages
5. Compare error messages before and after the fix to confirm correct
status code translation
Alternatively, a unit test can verify the bsearch returns correct results:
- Call efi_status_to_err() with known EFI status codes (e.g., EFI_SUCCESS,
EFI_INVALID_PARAMETER, EFI_SECURITY_VIOLATION)
- Verify correct errno values are returned (-EINVAL, -EACCES, etc.)
[Where problems could occur]
The fix swaps two adjacent function arguments. Potential issues:
1. The fix changes the search behavior, which could theoretically expose
latent bugs in code that was accidentally working due to the incorrect
search. For example, if code was relying on the -EINVAL fallback when
bsearch failed to find a match, it might now receive a different (correct)
errno value.
2. Since this affects EFI error reporting, any issues would manifest as
incorrect error messages in dmesg or wrong return values from EFI
operations. This could affect debugging but should not cause system
instability.
[Other Info]
- Root cause: The bug was introduced in the SAUCE patch cherry-picked from
kernel-ark commit 2ae9082db0b5:
https://gitlab.com/cki-project/kernel-ark/-/commit/2ae9082db0b5
- Upstream fix: https://gitlab.com/cki-project/kernel-ark/-/commit/49bcc48074ba
- bsearch(3) man page: https://man7.org/linux/man-pages/man3/bsearch.3.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2141276/+subscriptions
fixed the issue
** Tags removed: verification-needed-noble-linux
** Tags added: verification-done-noble-linux
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2141276
Title:
efi: Fix swapped arguments to bsearch() in efi_status_to_*() SAUCE
patch
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Jammy:
Fix Committed
Status in linux source package in Noble:
Fix Committed
Status in linux source package in Questing:
Fix Committed
Status in linux source package in Resolute:
Fix Released
Bug description:
[Impact]
The swapped bsearch() arguments cause the function to calculate incorrect
element offsets when searching the efi_error_codes array:
- Buggy behavior: bsearch thinks there are 24 elements of 12 bytes each
- Correct behavior: 12 elements of 24 bytes each (on 64-bit systems)
This causes efi_status_to_err() and efi_status_to_str() to read at wrong
memory offsets (every 12 bytes instead of every 24 bytes), potentially:
- Returning incorrect errno values for EFI status codes
- Returning wrong error description strings
- Failing to find valid status codes and returning default error values
These functions are used to translate EFI firmware error codes to Linux
errno values and human-readable strings, affecting error reporting for
EFI-related operations including secure boot and firmware variable access.
[Test Plan]
1. Build kernel with the fix applied
2. Boot system with UEFI firmware
3. Trigger EFI error conditions that exercise efi_status_to_err() and
efi_status_to_str(), such as:
- Secure boot signature verification failures
- EFI variable access errors
- MOK (Machine Owner Key) operations
4. Verify dmesg shows correct EFI error messages
5. Compare error messages before and after the fix to confirm correct
status code translation
Alternatively, a unit test can verify the bsearch returns correct results:
- Call efi_status_to_err() with known EFI status codes (e.g., EFI_SUCCESS,
EFI_INVALID_PARAMETER, EFI_SECURITY_VIOLATION)
- Verify correct errno values are returned (-EINVAL, -EACCES, etc.)
[Where problems could occur]
The fix swaps two adjacent function arguments. Potential issues:
1. The fix changes the search behavior, which could theoretically expose
latent bugs in code that was accidentally working due to the incorrect
search. For example, if code was relying on the -EINVAL fallback when
bsearch failed to find a match, it might now receive a different (correct)
errno value.
2. Since this affects EFI error reporting, any issues would manifest as
incorrect error messages in dmesg or wrong return values from EFI
operations. This could affect debugging but should not cause system
instability.
[Other Info]
- Root cause: The bug was introduced in the SAUCE patch cherry-picked from
kernel-ark commit 2ae9082db0b5:
https://gitlab.com/cki-project/kernel-ark/-/commit/2ae9082db0b5
- Upstream fix: https://gitlab.com/cki-project/kernel-ark/-/commit/49bcc48074ba
- bsearch(3) man page: https://man7.org/linux/man-pages/man3/bsearch.3.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2141276/+subscriptions
[Bug 2146310] Re: NFSv4 client hang in OPEN reclaim path waiting for RPC completion
** Attachment added: "flock_test.py"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+attachment/5956857/+files/flock_test.py
** Description changed:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- - Client sends RENEW
- - Server responds with NFS4ERR_EXPIRED
+ - Client sends RENEW
+ - Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- - SETCLIENTID succeeds
- - SETCLIENTID_CONFIRM succeeds
+ - SETCLIENTID succeeds
+ - SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
-
Client gets stuck during reclaim phase.
- Stack trace:
- [<0>] rpc_wait_bit_killable
+ Stack trace:
+ [<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
- [<0>] nfs4_run_open_task
- [<0>] nfs4_open_recover_helper
+ [<0>] nfs4_run_open_task
+ [<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
- [<0>] nfs4_do_open_expired
- [<0>] nfs40_open_expired
+ [<0>] nfs4_do_open_expired
+ [<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
- [<0>] nfs4_reclaim_open_state
- [<0>] nfs4_do_reclaim
+ [<0>] nfs4_reclaim_open_state
+ [<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
-
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
- 2. Run workload scripts:
- - create_and_open.sh
- - flock_test.py
+ 2. Run workload scripts(attachment below):
+ - create_and_open.sh
+ - flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
-
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
-
------------------------------------------------------------------------
-
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
-
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
- NFS4ERR_STALE_CLIENTID?
+ NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146310
Title:
NFSv4 client hang in OPEN reclaim path waiting for RPC completion
Status in linux package in Ubuntu:
New
Bug description:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- Client sends RENEW
- Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- SETCLIENTID succeeds
- SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
Client gets stuck during reclaim phase.
Stack trace:
[<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
[<0>] nfs4_run_open_task
[<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
[<0>] nfs4_do_open_expired
[<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
[<0>] nfs4_reclaim_open_state
[<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
2. Run workload scripts(attachment below):
- create_and_open.sh
- flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+subscriptions
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+attachment/5956857/+files/flock_test.py
** Description changed:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- - Client sends RENEW
- - Server responds with NFS4ERR_EXPIRED
+ - Client sends RENEW
+ - Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- - SETCLIENTID succeeds
- - SETCLIENTID_CONFIRM succeeds
+ - SETCLIENTID succeeds
+ - SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
-
Client gets stuck during reclaim phase.
- Stack trace:
- [<0>] rpc_wait_bit_killable
+ Stack trace:
+ [<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
- [<0>] nfs4_run_open_task
- [<0>] nfs4_open_recover_helper
+ [<0>] nfs4_run_open_task
+ [<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
- [<0>] nfs4_do_open_expired
- [<0>] nfs40_open_expired
+ [<0>] nfs4_do_open_expired
+ [<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
- [<0>] nfs4_reclaim_open_state
- [<0>] nfs4_do_reclaim
+ [<0>] nfs4_reclaim_open_state
+ [<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
-
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
- 2. Run workload scripts:
- - create_and_open.sh
- - flock_test.py
+ 2. Run workload scripts(attachment below):
+ - create_and_open.sh
+ - flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
-
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
-
------------------------------------------------------------------------
-
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
-
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
- NFS4ERR_STALE_CLIENTID?
+ NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146310
Title:
NFSv4 client hang in OPEN reclaim path waiting for RPC completion
Status in linux package in Ubuntu:
New
Bug description:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- Client sends RENEW
- Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- SETCLIENTID succeeds
- SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
Client gets stuck during reclaim phase.
Stack trace:
[<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
[<0>] nfs4_run_open_task
[<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
[<0>] nfs4_do_open_expired
[<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
[<0>] nfs4_reclaim_open_state
[<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
2. Run workload scripts(attachment below):
- create_and_open.sh
- flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+subscriptions
[Bug 2146310] Re: NFSv4 client hang in OPEN reclaim path waiting for RPC completion
** Description changed:
- Hi,
+ NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
- We are seeing an NFSv4.0 client hang on Linux kernel 5.15 (Ubuntu
- 22.04).
+ 1. Environment
- The issue starts when the server returns NFS4ERR_EXPIRED. The client
- then enters recovery, but reclaim never completes.
+ - Client OS: Ubuntu 22.04
+ - Kernel version: 5.15.0-113-generic
+ - NFS protocol: NFSv4.0
- The state manager thread is stuck with the following stack:
+ Mount options: 10.59.62.51:/ on /nfs type nfs4
+ (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
+ ------------------------------------------------------------------------
+
+ 2. Problem Description
+
+ We observed two types of abnormal behaviors related to NFSv4 client
+ state recovery.
+
+ ------------------------------------------------------------------------
+
+ Case 1: No recovery after NFS4ERR_STALE_CLIENTID
+
+ Expected behavior (per RFC7530): - Client should re-establish client
+ identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
+ state (open/lock)
+
+ Actual behavior: - Client keeps retrying normal requests - No recovery
+ process is triggered - No SETCLIENTID observed
+
+ ------------------------------------------------------------------------
+
+ Case 2: Client stuck during reclaim after lease expiration
+
+ Scenario
+
+ 1. Client stops sending RENEW due to network issue
+ 2. Server considers the lease expired
+ 3. After network recovery:
+ - Client sends RENEW
+ - Server responds with NFS4ERR_EXPIRED
+ 4. Client starts recovery:
+ - SETCLIENTID succeeds
+ - SETCLIENTID_CONFIRM succeeds
+ 5. Client enters reclaim phase(with open rpc reclaim=false)
+
+
+ Client gets stuck during reclaim phase.
+
+ Stack trace:
+ [<0>] rpc_wait_bit_killable
+ [<0>] __rpc_wait_for_completion_task
+ [<0>] nfs4_run_open_task
+ [<0>] nfs4_open_recover_helper
+ [<0>] nfs4_open_recover
+ [<0>] nfs4_do_open_expired
+ [<0>] nfs40_open_expired
+ [<0>] __nfs4_reclaim_open_state
+ [<0>] nfs4_reclaim_open_state
+ [<0>] nfs4_do_reclaim
+ [<0>] nfs4_state_manager
+
+
+ ------------------------------------------------------------------------
+
+ 3. Reproduction Steps
+
+ 1. Mount NFS filesystem (see above)
+ 2. Run workload scripts:
+ - create_and_open.sh
+ - flock_test.py
+ 3. Restart NFS server during workload to cause the client lease to expire
+ 4. Issue reproduces reliably
+
+ ------------------------------------------------------------------------
+
+ Additional stack traces
+
+ create_and_open.sh
```
- rpc_wait_bit_killable
- __rpc_wait_for_completion_task
- nfs4_run_open_task
- nfs4_open_recover_helper
- nfs4_open_recover
- nfs4_do_open_expired
- nfs40_open_expired
- __nfs4_reclaim_open_state
- nfs4_reclaim_open_state
- nfs4_do_reclaim
- nfs4_state_manager
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
+ [<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
+ [<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
+ [<0>] nfs4_close_context+0x35/0x60 [nfsv4]
+ [<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
+ [<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
+ [<0>] nfs_file_release+0x3e/0x50 [nfs]
+ [<0>] __fput+0x9c/0x280
+ [<0>] ____fput+0xe/0x20
+ [<0>] task_work_run+0x6a/0xb0
+ [<0>] exit_to_user_mode_loop+0x157/0x160
+ [<0>] exit_to_user_mode_prepare+0xa0/0xb0
+ [<0>] syscall_exit_to_user_mode+0x27/0x50
+ [<0>] do_syscall_64+0x63/0xb0
+ [<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
- Meanwhile:
- - The server repeatedly returns NFS4ERR_EXPIRED
- - The client does not successfully reclaim state
- - IO continues and repeatedly fails
- RPC stats show:
- - ~30M calls
- - very low retransmissions (94)
+ ------------------------------------------------------------------------
- This suggests the issue is unlikely to be caused by network loss or
- server unresponsiveness.
+ flock_test.py
+ ```
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
+ [<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
+ [<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
+ [<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
+ [<0>] do_setlk+0x64/0x100 [nfs]
+ [<0>] nfs_lock+0xb3/0x180 [nfs]
+ [<0>] do_lock_file_wait+0x4f/0x120
+ [<0>] fcntl_setlk+0x127/0x2e0
+ [<0>] do_fcntl+0x4ce/0x5a0
+ [<0>] __x64_sys_fcntl+0xa9/0xd0
+ [<0>] x64_sys_call+0x1f5c/0x1fa0
+ [<0>] do_syscall_64+0x56/0xb0
+ [<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
+ ```
- Additionally, we have verified that:
- - Network connectivity is stable
- - The NFS server is operating normally (no restart or failover observed)
- Importantly:
- - We do observe that RENEW/SEQUENCE-related traffic is being sent from the client
- - However, the client still ends up with an expired lease (NFS4ERR_EXPIRED)
+ ------------------------------------------------------------------------
- This raises the question whether the lease renewal is not being properly
- processed or completed on the client side.
- Given that we are using NFSv4.1 (where lease renewal is implicit via
- SEQUENCE), we would like to understand:
+ [10.59.62.51-man]
+ ```
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
+ [<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
+ [<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
+ [<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
+ [<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
+ [<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
+ [<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
+ [<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
+ [<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
+ [<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
+ [<0>] kthread+0x127/0x150
+ [<0>] ret_from_fork+0x1f/0x30
+ ```
- 1. Under what conditions could the client still hit NFS4ERR_EXPIRED despite ongoing renew/SEQUENCE activity and a healthy server/network?
- 2. Is it possible that RPC completion, session slot handling, or sequence handling issues could prevent the lease from being effectively renewed?
- 3. Could this be a known issue in the NFSv4.1 recovery or session handling path in 5.15?
+ ------------------------------------------------------------------------
- It appears the client is stuck in the OPEN reclaim path waiting for RPC
- completion, and recovery cannot make forward progress.
+ 4. Kernel Version Comparison
- Are there known fixes or patches in newer kernels (e.g., 5.19 or 6.x)
- that address this class of issue?
+ Affected:
+ Ubuntu 22.04 5.15.0-113-generic
- Any pointers or suggestions would be greatly appreciated.
+ Not affected:
+ Ubuntu 20.04 5.4.0-48-generic
+ Ubuntu 22.04 6.8.0-60-generic
+ Ubuntu 24.04 6.8.0-31-generic
+ Centos 7.9 4.19.188-10.el7.ucloud.x86_64
+ Centos 7.9 3.10.0-1062.9.1.el7.x86_64
+ Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
- Thanks
+
+ ------------------------------------------------------------------------
+
+ 5. Questions
+
+ 1. Is it expected that no recovery is triggered after
+ NFS4ERR_STALE_CLIENTID?
+ 2. During reclaim, should OPEN be sent with reclaim=true?
+ 3. Could reclaim=false cause reclaim failure?
+ 4. Why is client stuck in rpc_wait_bit_killable?
+ 5. Is this a known issue in kernel 5.15?
+ 6. Are there any related patches or fixes?
** Attachment added: "create_and_open.sh"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+attachment/5956856/+files/create_and_open.sh
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146310
Title:
NFSv4 client hang in OPEN reclaim path waiting for RPC completion
Status in linux package in Ubuntu:
New
Bug description:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- Client sends RENEW
- Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- SETCLIENTID succeeds
- SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
Client gets stuck during reclaim phase.
Stack trace:
[<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
[<0>] nfs4_run_open_task
[<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
[<0>] nfs4_do_open_expired
[<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
[<0>] nfs4_reclaim_open_state
[<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
2. Run workload scripts(attachment below):
- create_and_open.sh
- flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+subscriptions
- Hi,
+ NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
- We are seeing an NFSv4.0 client hang on Linux kernel 5.15 (Ubuntu
- 22.04).
+ 1. Environment
- The issue starts when the server returns NFS4ERR_EXPIRED. The client
- then enters recovery, but reclaim never completes.
+ - Client OS: Ubuntu 22.04
+ - Kernel version: 5.15.0-113-generic
+ - NFS protocol: NFSv4.0
- The state manager thread is stuck with the following stack:
+ Mount options: 10.59.62.51:/ on /nfs type nfs4
+ (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
+ ------------------------------------------------------------------------
+
+ 2. Problem Description
+
+ We observed two types of abnormal behaviors related to NFSv4 client
+ state recovery.
+
+ ------------------------------------------------------------------------
+
+ Case 1: No recovery after NFS4ERR_STALE_CLIENTID
+
+ Expected behavior (per RFC7530): - Client should re-establish client
+ identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
+ state (open/lock)
+
+ Actual behavior: - Client keeps retrying normal requests - No recovery
+ process is triggered - No SETCLIENTID observed
+
+ ------------------------------------------------------------------------
+
+ Case 2: Client stuck during reclaim after lease expiration
+
+ Scenario
+
+ 1. Client stops sending RENEW due to network issue
+ 2. Server considers the lease expired
+ 3. After network recovery:
+ - Client sends RENEW
+ - Server responds with NFS4ERR_EXPIRED
+ 4. Client starts recovery:
+ - SETCLIENTID succeeds
+ - SETCLIENTID_CONFIRM succeeds
+ 5. Client enters reclaim phase(with open rpc reclaim=false)
+
+
+ Client gets stuck during reclaim phase.
+
+ Stack trace:
+ [<0>] rpc_wait_bit_killable
+ [<0>] __rpc_wait_for_completion_task
+ [<0>] nfs4_run_open_task
+ [<0>] nfs4_open_recover_helper
+ [<0>] nfs4_open_recover
+ [<0>] nfs4_do_open_expired
+ [<0>] nfs40_open_expired
+ [<0>] __nfs4_reclaim_open_state
+ [<0>] nfs4_reclaim_open_state
+ [<0>] nfs4_do_reclaim
+ [<0>] nfs4_state_manager
+
+
+ ------------------------------------------------------------------------
+
+ 3. Reproduction Steps
+
+ 1. Mount NFS filesystem (see above)
+ 2. Run workload scripts:
+ - create_and_open.sh
+ - flock_test.py
+ 3. Restart NFS server during workload to cause the client lease to expire
+ 4. Issue reproduces reliably
+
+ ------------------------------------------------------------------------
+
+ Additional stack traces
+
+ create_and_open.sh
```
- rpc_wait_bit_killable
- __rpc_wait_for_completion_task
- nfs4_run_open_task
- nfs4_open_recover_helper
- nfs4_open_recover
- nfs4_do_open_expired
- nfs40_open_expired
- __nfs4_reclaim_open_state
- nfs4_reclaim_open_state
- nfs4_do_reclaim
- nfs4_state_manager
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
+ [<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
+ [<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
+ [<0>] nfs4_close_context+0x35/0x60 [nfsv4]
+ [<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
+ [<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
+ [<0>] nfs_file_release+0x3e/0x50 [nfs]
+ [<0>] __fput+0x9c/0x280
+ [<0>] ____fput+0xe/0x20
+ [<0>] task_work_run+0x6a/0xb0
+ [<0>] exit_to_user_mode_loop+0x157/0x160
+ [<0>] exit_to_user_mode_prepare+0xa0/0xb0
+ [<0>] syscall_exit_to_user_mode+0x27/0x50
+ [<0>] do_syscall_64+0x63/0xb0
+ [<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
- Meanwhile:
- - The server repeatedly returns NFS4ERR_EXPIRED
- - The client does not successfully reclaim state
- - IO continues and repeatedly fails
- RPC stats show:
- - ~30M calls
- - very low retransmissions (94)
+ ------------------------------------------------------------------------
- This suggests the issue is unlikely to be caused by network loss or
- server unresponsiveness.
+ flock_test.py
+ ```
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
+ [<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
+ [<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
+ [<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
+ [<0>] do_setlk+0x64/0x100 [nfs]
+ [<0>] nfs_lock+0xb3/0x180 [nfs]
+ [<0>] do_lock_file_wait+0x4f/0x120
+ [<0>] fcntl_setlk+0x127/0x2e0
+ [<0>] do_fcntl+0x4ce/0x5a0
+ [<0>] __x64_sys_fcntl+0xa9/0xd0
+ [<0>] x64_sys_call+0x1f5c/0x1fa0
+ [<0>] do_syscall_64+0x56/0xb0
+ [<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
+ ```
- Additionally, we have verified that:
- - Network connectivity is stable
- - The NFS server is operating normally (no restart or failover observed)
- Importantly:
- - We do observe that RENEW/SEQUENCE-related traffic is being sent from the client
- - However, the client still ends up with an expired lease (NFS4ERR_EXPIRED)
+ ------------------------------------------------------------------------
- This raises the question whether the lease renewal is not being properly
- processed or completed on the client side.
- Given that we are using NFSv4.1 (where lease renewal is implicit via
- SEQUENCE), we would like to understand:
+ [10.59.62.51-man]
+ ```
+ [<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
+ [<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
+ [<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
+ [<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
+ [<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
+ [<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
+ [<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
+ [<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
+ [<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
+ [<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
+ [<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
+ [<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
+ [<0>] kthread+0x127/0x150
+ [<0>] ret_from_fork+0x1f/0x30
+ ```
- 1. Under what conditions could the client still hit NFS4ERR_EXPIRED despite ongoing renew/SEQUENCE activity and a healthy server/network?
- 2. Is it possible that RPC completion, session slot handling, or sequence handling issues could prevent the lease from being effectively renewed?
- 3. Could this be a known issue in the NFSv4.1 recovery or session handling path in 5.15?
+ ------------------------------------------------------------------------
- It appears the client is stuck in the OPEN reclaim path waiting for RPC
- completion, and recovery cannot make forward progress.
+ 4. Kernel Version Comparison
- Are there known fixes or patches in newer kernels (e.g., 5.19 or 6.x)
- that address this class of issue?
+ Affected:
+ Ubuntu 22.04 5.15.0-113-generic
- Any pointers or suggestions would be greatly appreciated.
+ Not affected:
+ Ubuntu 20.04 5.4.0-48-generic
+ Ubuntu 22.04 6.8.0-60-generic
+ Ubuntu 24.04 6.8.0-31-generic
+ Centos 7.9 4.19.188-10.el7.ucloud.x86_64
+ Centos 7.9 3.10.0-1062.9.1.el7.x86_64
+ Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
- Thanks
+
+ ------------------------------------------------------------------------
+
+ 5. Questions
+
+ 1. Is it expected that no recovery is triggered after
+ NFS4ERR_STALE_CLIENTID?
+ 2. During reclaim, should OPEN be sent with reclaim=true?
+ 3. Could reclaim=false cause reclaim failure?
+ 4. Why is client stuck in rpc_wait_bit_killable?
+ 5. Is this a known issue in kernel 5.15?
+ 6. Are there any related patches or fixes?
** Attachment added: "create_and_open.sh"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+attachment/5956856/+files/create_and_open.sh
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146310
Title:
NFSv4 client hang in OPEN reclaim path waiting for RPC completion
Status in linux package in Ubuntu:
New
Bug description:
NFSv4 client stuck during state recovery on Ubuntu 22.04 (kernel 5.15)
1. Environment
- Client OS: Ubuntu 22.04
- Kernel version: 5.15.0-113-generic
- NFS protocol: NFSv4.0
Mount options: 10.59.62.51:/ on /nfs type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.59.254.244,local_lock=none,addr=10.59.62.51)
------------------------------------------------------------------------
2. Problem Description
We observed two types of abnormal behaviors related to NFSv4 client
state recovery.
------------------------------------------------------------------------
Case 1: No recovery after NFS4ERR_STALE_CLIENTID
Expected behavior (per RFC7530): - Client should re-establish client
identity via SETCLIENTID / SETCLIENTID_CONFIRM - Client should reclaim
state (open/lock)
Actual behavior: - Client keeps retrying normal requests - No recovery
process is triggered - No SETCLIENTID observed
------------------------------------------------------------------------
Case 2: Client stuck during reclaim after lease expiration
Scenario
1. Client stops sending RENEW due to network issue
2. Server considers the lease expired
3. After network recovery:
- Client sends RENEW
- Server responds with NFS4ERR_EXPIRED
4. Client starts recovery:
- SETCLIENTID succeeds
- SETCLIENTID_CONFIRM succeeds
5. Client enters reclaim phase(with open rpc reclaim=false)
Client gets stuck during reclaim phase.
Stack trace:
[<0>] rpc_wait_bit_killable
[<0>] __rpc_wait_for_completion_task
[<0>] nfs4_run_open_task
[<0>] nfs4_open_recover_helper
[<0>] nfs4_open_recover
[<0>] nfs4_do_open_expired
[<0>] nfs40_open_expired
[<0>] __nfs4_reclaim_open_state
[<0>] nfs4_reclaim_open_state
[<0>] nfs4_do_reclaim
[<0>] nfs4_state_manager
------------------------------------------------------------------------
3. Reproduction Steps
1. Mount NFS filesystem (see above)
2. Run workload scripts(attachment below):
- create_and_open.sh
- flock_test.py
3. Restart NFS server during workload to cause the client lease to expire
4. Issue reproduces reliably
------------------------------------------------------------------------
Additional stack traces
create_and_open.sh
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_do_close+0x2d7/0x380 [nfsv4]
[<0>] __nfs4_close.constprop.0+0x11f/0x1f0 [nfsv4]
[<0>] nfs4_close_sync+0x13/0x20 [nfsv4]
[<0>] nfs4_close_context+0x35/0x60 [nfsv4]
[<0>] __put_nfs_open_context+0xc7/0x150 [nfs]
[<0>] nfs_file_clear_open_context+0x4c/0x60 [nfs]
[<0>] nfs_file_release+0x3e/0x50 [nfs]
[<0>] __fput+0x9c/0x280
[<0>] ____fput+0xe/0x20
[<0>] task_work_run+0x6a/0xb0
[<0>] exit_to_user_mode_loop+0x157/0x160
[<0>] exit_to_user_mode_prepare+0xa0/0xb0
[<0>] syscall_exit_to_user_mode+0x27/0x50
[<0>] do_syscall_64+0x63/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
flock_test.py
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] _nfs4_do_setlk+0x290/0x410 [nfsv4]
[<0>] nfs4_proc_setlk+0x78/0x160 [nfsv4]
[<0>] nfs4_retry_setlk+0x1dd/0x250 [nfsv4]
[<0>] nfs4_proc_lock+0x9d/0x1b0 [nfsv4]
[<0>] do_setlk+0x64/0x100 [nfs]
[<0>] nfs_lock+0xb3/0x180 [nfs]
[<0>] do_lock_file_wait+0x4f/0x120
[<0>] fcntl_setlk+0x127/0x2e0
[<0>] do_fcntl+0x4ce/0x5a0
[<0>] __x64_sys_fcntl+0xa9/0xd0
[<0>] x64_sys_call+0x1f5c/0x1fa0
[<0>] do_syscall_64+0x56/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
```
------------------------------------------------------------------------
[10.59.62.51-man]
```
[<0>] rpc_wait_bit_killable+0x25/0xb0 [sunrpc]
[<0>] __rpc_wait_for_completion_task+0x2d/0x40 [sunrpc]
[<0>] nfs4_run_open_task+0x152/0x1e0 [nfsv4]
[<0>] nfs4_open_recover_helper+0x155/0x210 [nfsv4]
[<0>] nfs4_open_recover+0x22/0xd0 [nfsv4]
[<0>] nfs4_do_open_reclaim+0x128/0x220 [nfsv4]
[<0>] nfs4_open_reclaim+0x42/0xa0 [nfsv4]
[<0>] __nfs4_reclaim_open_state+0x25/0x110 [nfsv4]
[<0>] nfs4_reclaim_open_state+0xd1/0x2c0 [nfsv4]
[<0>] nfs4_do_reclaim+0x12f/0x230 [nfsv4]
[<0>] nfs4_state_manager+0x6d9/0x870 [nfsv4]
[<0>] nfs4_run_state_manager+0xa8/0x1a0 [nfsv4]
[<0>] kthread+0x127/0x150
[<0>] ret_from_fork+0x1f/0x30
```
------------------------------------------------------------------------
4. Kernel Version Comparison
Affected:
Ubuntu 22.04 5.15.0-113-generic
Not affected:
Ubuntu 20.04 5.4.0-48-generic
Ubuntu 22.04 6.8.0-60-generic
Ubuntu 24.04 6.8.0-31-generic
Centos 7.9 4.19.188-10.el7.ucloud.x86_64
Centos 7.9 3.10.0-1062.9.1.el7.x86_64
Centos 8.3 4.18.0-240.1.1.el8_3.x86_64
------------------------------------------------------------------------
5. Questions
1. Is it expected that no recovery is triggered after
NFS4ERR_STALE_CLIENTID?
2. During reclaim, should OPEN be sent with reclaim=true?
3. Could reclaim=false cause reclaim failure?
4. Why is client stuck in rpc_wait_bit_killable?
5. Is this a known issue in kernel 5.15?
6. Are there any related patches or fixes?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146310/+subscriptions
[Bug 2143915] Re: PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump causes severe cursor stuttering
and run $sudo evtest and select the touchpad event to catch the position
coordinates, can you see the "jump by large amounts on the first event
of each new contact"?
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143915
Title:
PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump
causes severe cursor stuttering
Status in linux package in Ubuntu:
Incomplete
Bug description:
Hardware: Acer Swift SFX14-73G
Touchpad: PIXA4812:00 093A:4812 (I2C-HID)
OS: Kubuntu 24.04
Kernel: 6.17.0-14-generic
Session: X11 (KDE Plasma)
Symptoms:
- Touchpad detected by kernel and libinput
- Click works
- Finger contact detected in libinput debug-gui
- Cursor does not move, or moves with severe stuttering
- libinput reports repeated "kernel bug: Touch jump detected and discarded"
- Touch jump occurs on nearly every first contact frame
Steps already attempted:
1. Added /etc/libinput/local-overrides.quirks with AttrPressureRange=2:1
→ Cursor started moving but with heavy stuttering
2. Added /etc/X11/xorg.conf.d/41-ignore-pixa4812-mouse.conf
to ignore duplicate PIXA4812 Mouse and Stylus nodes
→ Reduced conflicts but stuttering persists
3. Tested AttrResolutionHint values (4x4, 8x8, 24x24) → no improvement
4. Tested EVDEV_ABS fuzz override (:::4 on axes 00,01,35,36) → no improvement
5. Tested AttrPressureRange values (5:3, 2:1) → 2:1 gives most movement
but touch jumps still cause regular tracking interruptions
Root cause identified:
The touchpad firmware sends position coordinates that jump by large amounts
on the first event of each new contact. libinput detects these as impossible
physical movements and discards them, causing tracking to reset and the cursor
to stutter or freeze for up to 1 second between movements.
libinput debug-events shows POINTER_MOTION events arriving in bursts
separated by 0.7-1.0 second gaps, each gap coinciding with a
"Touch jump detected and discarded" message.
---
ProblemType: Bug
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
CRDA: N/A
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2026-03-10 (4 days ago)
InstallationMedia: Kubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
MachineType: Acer Swift SFX14-73G
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=625a444b-273c-4e5b-8be6-5e36646d6971 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14~24.04.1-generic 6.17.9
RelatedPackageVersions:
linux-restricted-modules-6.17.0-14-generic N/A
linux-backports-modules-6.17.0-14-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.25
Tags: noble
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/20/2025
dmi.bios.release: 1.6
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.06
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: GLB_ARH
dmi.board.vendor: ARL
dmi.board.version: V1.06
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 1.6
dmi.modalias: dmi:bvnInsydeCorp.:bvrV1.06:bd11/20/2025:br1.6:efr1.6:svnAcer:pnSwiftSFX14-73G:pvrV1.06:rvnARL:rnGLB_ARH:rvrV1.06:cvnAcer:ct10:cvrChassisVersion:sku0000000000000000:
dmi.product.family: Swift X 14
dmi.product.name: Swift SFX14-73G
dmi.product.sku: 0000000000000000
dmi.product.version: V1.06
dmi.sys.vendor: Acer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2143915/+subscriptions
coordinates, can you see the "jump by large amounts on the first event
of each new contact"?
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143915
Title:
PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump
causes severe cursor stuttering
Status in linux package in Ubuntu:
Incomplete
Bug description:
Hardware: Acer Swift SFX14-73G
Touchpad: PIXA4812:00 093A:4812 (I2C-HID)
OS: Kubuntu 24.04
Kernel: 6.17.0-14-generic
Session: X11 (KDE Plasma)
Symptoms:
- Touchpad detected by kernel and libinput
- Click works
- Finger contact detected in libinput debug-gui
- Cursor does not move, or moves with severe stuttering
- libinput reports repeated "kernel bug: Touch jump detected and discarded"
- Touch jump occurs on nearly every first contact frame
Steps already attempted:
1. Added /etc/libinput/local-overrides.quirks with AttrPressureRange=2:1
→ Cursor started moving but with heavy stuttering
2. Added /etc/X11/xorg.conf.d/41-ignore-pixa4812-mouse.conf
to ignore duplicate PIXA4812 Mouse and Stylus nodes
→ Reduced conflicts but stuttering persists
3. Tested AttrResolutionHint values (4x4, 8x8, 24x24) → no improvement
4. Tested EVDEV_ABS fuzz override (:::4 on axes 00,01,35,36) → no improvement
5. Tested AttrPressureRange values (5:3, 2:1) → 2:1 gives most movement
but touch jumps still cause regular tracking interruptions
Root cause identified:
The touchpad firmware sends position coordinates that jump by large amounts
on the first event of each new contact. libinput detects these as impossible
physical movements and discards them, causing tracking to reset and the cursor
to stutter or freeze for up to 1 second between movements.
libinput debug-events shows POINTER_MOTION events arriving in bursts
separated by 0.7-1.0 second gaps, each gap coinciding with a
"Touch jump detected and discarded" message.
---
ProblemType: Bug
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
CRDA: N/A
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2026-03-10 (4 days ago)
InstallationMedia: Kubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
MachineType: Acer Swift SFX14-73G
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=625a444b-273c-4e5b-8be6-5e36646d6971 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14~24.04.1-generic 6.17.9
RelatedPackageVersions:
linux-restricted-modules-6.17.0-14-generic N/A
linux-backports-modules-6.17.0-14-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.25
Tags: noble
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/20/2025
dmi.bios.release: 1.6
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.06
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: GLB_ARH
dmi.board.vendor: ARL
dmi.board.version: V1.06
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 1.6
dmi.modalias: dmi:bvnInsydeCorp.:bvrV1.06:bd11/20/2025:br1.6:efr1.6:svnAcer:pnSwiftSFX14-73G:pvrV1.06:rvnARL:rnGLB_ARH:rvrV1.06:cvnAcer:ct10:cvrChassisVersion:sku0000000000000000:
dmi.product.family: Swift X 14
dmi.product.name: Swift SFX14-73G
dmi.product.sku: 0000000000000000
dmi.product.version: V1.06
dmi.sys.vendor: Acer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2143915/+subscriptions
[Bug 2143915] Re: PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump causes severe cursor stuttering
This is a known issue for a long time, It will be helpful if you can
update that bugzilla bug-report.
https://www.linux.org/threads/touchpad-issues-acer-swift-x.58215/#:~:text=event7%20-%20PIXA4812:00%20093A:4812%20Touchpad:%20kernel%20bug:,from%20the%20pad:%20Bash:%20sudo%20evtest%20/dev
https://bugzilla.kernel.org/show_bug.cgi?id=220627
** Bug watch added: Linux Kernel Bug Tracker #220627
https://bugzilla.kernel.org/show_bug.cgi?id=220627
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143915
Title:
PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump
causes severe cursor stuttering
Status in linux package in Ubuntu:
Incomplete
Bug description:
Hardware: Acer Swift SFX14-73G
Touchpad: PIXA4812:00 093A:4812 (I2C-HID)
OS: Kubuntu 24.04
Kernel: 6.17.0-14-generic
Session: X11 (KDE Plasma)
Symptoms:
- Touchpad detected by kernel and libinput
- Click works
- Finger contact detected in libinput debug-gui
- Cursor does not move, or moves with severe stuttering
- libinput reports repeated "kernel bug: Touch jump detected and discarded"
- Touch jump occurs on nearly every first contact frame
Steps already attempted:
1. Added /etc/libinput/local-overrides.quirks with AttrPressureRange=2:1
→ Cursor started moving but with heavy stuttering
2. Added /etc/X11/xorg.conf.d/41-ignore-pixa4812-mouse.conf
to ignore duplicate PIXA4812 Mouse and Stylus nodes
→ Reduced conflicts but stuttering persists
3. Tested AttrResolutionHint values (4x4, 8x8, 24x24) → no improvement
4. Tested EVDEV_ABS fuzz override (:::4 on axes 00,01,35,36) → no improvement
5. Tested AttrPressureRange values (5:3, 2:1) → 2:1 gives most movement
but touch jumps still cause regular tracking interruptions
Root cause identified:
The touchpad firmware sends position coordinates that jump by large amounts
on the first event of each new contact. libinput detects these as impossible
physical movements and discards them, causing tracking to reset and the cursor
to stutter or freeze for up to 1 second between movements.
libinput debug-events shows POINTER_MOTION events arriving in bursts
separated by 0.7-1.0 second gaps, each gap coinciding with a
"Touch jump detected and discarded" message.
---
ProblemType: Bug
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
CRDA: N/A
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2026-03-10 (4 days ago)
InstallationMedia: Kubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
MachineType: Acer Swift SFX14-73G
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=625a444b-273c-4e5b-8be6-5e36646d6971 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14~24.04.1-generic 6.17.9
RelatedPackageVersions:
linux-restricted-modules-6.17.0-14-generic N/A
linux-backports-modules-6.17.0-14-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.25
Tags: noble
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/20/2025
dmi.bios.release: 1.6
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.06
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: GLB_ARH
dmi.board.vendor: ARL
dmi.board.version: V1.06
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 1.6
dmi.modalias: dmi:bvnInsydeCorp.:bvrV1.06:bd11/20/2025:br1.6:efr1.6:svnAcer:pnSwiftSFX14-73G:pvrV1.06:rvnARL:rnGLB_ARH:rvrV1.06:cvnAcer:ct10:cvrChassisVersion:sku0000000000000000:
dmi.product.family: Swift X 14
dmi.product.name: Swift SFX14-73G
dmi.product.sku: 0000000000000000
dmi.product.version: V1.06
dmi.sys.vendor: Acer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2143915/+subscriptions
update that bugzilla bug-report.
https://www.linux.org/threads/touchpad-issues-acer-swift-x.58215/#:~:text=event7%20-%20PIXA4812:00%20093A:4812%20Touchpad:%20kernel%20bug:,from%20the%20pad:%20Bash:%20sudo%20evtest%20/dev
https://bugzilla.kernel.org/show_bug.cgi?id=220627
** Bug watch added: Linux Kernel Bug Tracker #220627
https://bugzilla.kernel.org/show_bug.cgi?id=220627
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143915
Title:
PIXA4812:00 093A:4812 (Acer Swift SFX14-73G): repeated touch jump
causes severe cursor stuttering
Status in linux package in Ubuntu:
Incomplete
Bug description:
Hardware: Acer Swift SFX14-73G
Touchpad: PIXA4812:00 093A:4812 (I2C-HID)
OS: Kubuntu 24.04
Kernel: 6.17.0-14-generic
Session: X11 (KDE Plasma)
Symptoms:
- Touchpad detected by kernel and libinput
- Click works
- Finger contact detected in libinput debug-gui
- Cursor does not move, or moves with severe stuttering
- libinput reports repeated "kernel bug: Touch jump detected and discarded"
- Touch jump occurs on nearly every first contact frame
Steps already attempted:
1. Added /etc/libinput/local-overrides.quirks with AttrPressureRange=2:1
→ Cursor started moving but with heavy stuttering
2. Added /etc/X11/xorg.conf.d/41-ignore-pixa4812-mouse.conf
to ignore duplicate PIXA4812 Mouse and Stylus nodes
→ Reduced conflicts but stuttering persists
3. Tested AttrResolutionHint values (4x4, 8x8, 24x24) → no improvement
4. Tested EVDEV_ABS fuzz override (:::4 on axes 00,01,35,36) → no improvement
5. Tested AttrPressureRange values (5:3, 2:1) → 2:1 gives most movement
but touch jumps still cause regular tracking interruptions
Root cause identified:
The touchpad firmware sends position coordinates that jump by large amounts
on the first event of each new contact. libinput detects these as impossible
physical movements and discards them, causing tracking to reset and the cursor
to stutter or freeze for up to 1 second between movements.
libinput debug-events shows POINTER_MOTION events arriving in bursts
separated by 0.7-1.0 second gaps, each gap coinciding with a
"Touch jump detected and discarded" message.
---
ProblemType: Bug
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
CRDA: N/A
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2026-03-10 (4 days ago)
InstallationMedia: Kubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210)
MachineType: Acer Swift SFX14-73G
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=625a444b-273c-4e5b-8be6-5e36646d6971 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14~24.04.1-generic 6.17.9
RelatedPackageVersions:
linux-restricted-modules-6.17.0-14-generic N/A
linux-backports-modules-6.17.0-14-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.25
Tags: noble
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/20/2025
dmi.bios.release: 1.6
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: V1.06
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: GLB_ARH
dmi.board.vendor: ARL
dmi.board.version: V1.06
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 1.6
dmi.modalias: dmi:bvnInsydeCorp.:bvrV1.06:bd11/20/2025:br1.6:efr1.6:svnAcer:pnSwiftSFX14-73G:pvrV1.06:rvnARL:rnGLB_ARH:rvrV1.06:cvnAcer:ct10:cvrChassisVersion:sku0000000000000000:
dmi.product.family: Swift X 14
dmi.product.name: Swift SFX14-73G
dmi.product.sku: 0000000000000000
dmi.product.version: V1.06
dmi.sys.vendor: Acer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2143915/+subscriptions
[Bug 2144577] Re: BUG: kernel NULL pointer dereference in amdgpu
Hi Mateusz,
Could you try this test kernel see if it fixes the issue?
https://people.canonical.com/~acelan/bugs/lp2144577
The test kernel includes the 2 commits from v7.0 mainline kernel.
f4db9913e4d3d drm/amdgpu: validate the flush_gpu_tlb_pasid()
e3a6eff92bbd9 drm/amdgpu: Fix validating flush_gpu_tlb_pasid()
To boot up with the test kernel, you need to manually disable the secure
boot from the BIOS menu.
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2144577
Title:
BUG: kernel NULL pointer dereference in amdgpu
Status in linux package in Ubuntu:
Confirmed
Bug description:
Ubuntu 25.10 with kernel 6.17.0-19-generic doesn't boot on my PC. I
freezes on the booting screen, and the kernel logs show a bug:
kernel: Linux version 6.17.0-19-generic (buildd@lcy02-amd64-084) (x86_64-linux-gnu-gcc (Ubuntu 15.2.0-4ubuntu4) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.45) #19-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 6 14:02:58 UTC 2026 (Ubuntu 6.17.0-19.19-generic 6.17.13)
kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.17.0-19-generic root=UUID=354e3c09-bfde-4e47-850f-fe872a882ae5 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
# ...
kernel: [drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
kernel: #PF: supervisor instruction fetch in kernel mode
kernel: #PF: error_code(0x0010) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: Oops: 0010 [#1] SMP PTI
kernel: CPU: 3 UID: 0 PID: 109 Comm: kworker/3:1 Not tainted 6.17.0-19-generic #19-Ubuntu PREEMPT(voluntary)
kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P1.10 04/10/2012
kernel: Workqueue: events amdgpu_tlb_fence_work [amdgpu]
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da87ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 00000003de040002 CR4: 00000000001726f0
kernel: Call Trace:
kernel: <TASK>
kernel: amdgpu_gmc_flush_gpu_tlb_pasid+0xfd/0x480 [amdgpu]
kernel: amdgpu_tlb_fence_work+0x77/0x110 [amdgpu]
kernel: process_one_work+0x18e/0x370
kernel: worker_thread+0x317/0x450
kernel: ? _raw_spin_lock_irqsave+0xe/0x20
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10b/0x220
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x134/0x150
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork_asm+0x1a/0x30
kernel: </TASK>
kernel: Modules linked in: rfcomm cmac algif_hash algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype xt_mac xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat binfmt_misc nf_tables amdgpu(+) usblp intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel amdxcp at24 mei_hdcp mei_pxp kvm snd_hda_codec_atihdmi drm_panel_backlight_quirks gpu_sched irqbypass snd_hda_codec_hdmi drm_buddy snd_hda_codec_alc662 rapl btusb snd_hda_codec_realtek_lib intel_cstate snd_hda_codec_generic radeon btrtl snd_hda_intel btintel i2c_i801 btbcm snd_hda_codec btmtk i2c_smbus drm_ttm_helper i2c_mux ttm bluetooth snd_seq_midi snd_hda_core snd_seq_midi_event drm_exec snd_intel_dspcfg snd_rawmidi drm_suballoc_helper snd_intel_sdw_acpi drm_display_helper lpc_ich snd_hwdep snd_seq snd_pcm snd_seq_device cec snd_timer rc_core snd i2c_algo_bit soundcore mei_me mei intel_smartconnect joydev
kernel: input_leds mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 dm_crypt wacom uas usb_storage hid_generic usbhid hid r8169 polyval_clmulni ghash_clmulni_intel psmouse ahci realtek serio_raw libahci video wmi aesni_intel
kernel: CR2: 0000000000000000
kernel: ---[ end trace 0000000000000000 ]---
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da87ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 00000003de040002 CR4: 00000000001726f0
kernel: note: kworker/3:1[109] exited with irqs disabled
kernel: loop50: detected capacity change from 0 to 8
kernel: fbcon: amdgpudrmfb (fb0) is primary device
kernel: fbcon: Deferring console take-over
kernel: amdgpu 0000:01:00.0: [drm] fb0: amdgpudrmfb frame buffer device
kernel: NET: Registered PF_QIPCRTR protocol family
kernel: sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
kernel: #PF: supervisor instruction fetch in kernel mode
kernel: #PF: error_code(0x0010) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: Oops: 0010 [#2] SMP PTI
kernel: CPU: 1 UID: 0 PID: 91 Comm: kworker/1:1 Tainted: G D 6.17.0-19-generic #19-Ubuntu PREEMPT(voluntary)
kernel: Tainted: [D]=DIE
kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P1.10 04/10/2012
kernel: Workqueue: events amdgpu_tlb_fence_work [amdgpu]
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0000:ffffce5600477db0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008001 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008001 RDI: ffff8a4a6d180000
kernel: RBP: ffffce5600477e08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da86ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 0000000101242006 CR4: 00000000001726f0
kernel: Call Trace:
kernel: <TASK>
kernel: amdgpu_gmc_flush_gpu_tlb_pasid+0xfd/0x480 [amdgpu]
kernel: amdgpu_tlb_fence_work+0x77/0x110 [amdgpu]
kernel: process_one_work+0x18e/0x370
kernel: worker_thread+0x317/0x450
kernel: ? _raw_spin_lock_irqsave+0xe/0x20
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10b/0x220
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x134/0x150
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork_asm+0x1a/0x30
kernel: </TASK>
kernel: Modules linked in: qrtr rfcomm cmac algif_hash algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype xt_mac xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat binfmt_misc nf_tables amdgpu usblp intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel amdxcp at24 mei_hdcp mei_pxp kvm snd_hda_codec_atihdmi drm_panel_backlight_quirks gpu_sched irqbypass snd_hda_codec_hdmi drm_buddy snd_hda_codec_alc662 rapl btusb snd_hda_codec_realtek_lib intel_cstate snd_hda_codec_generic radeon btrtl snd_hda_intel btintel i2c_i801 btbcm snd_hda_codec btmtk i2c_smbus drm_ttm_helper i2c_mux ttm bluetooth snd_seq_midi snd_hda_core snd_seq_midi_event drm_exec snd_intel_dspcfg snd_rawmidi drm_suballoc_helper snd_intel_sdw_acpi drm_display_helper lpc_ich snd_hwdep snd_seq snd_pcm snd_seq_device cec snd_timer rc_core snd i2c_algo_bit soundcore mei_me mei intel_smartconnect joydev
kernel: input_leds mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 dm_crypt wacom uas usb_storage hid_generic usbhid hid r8169 polyval_clmulni ghash_clmulni_intel psmouse ahci realtek serio_raw libahci video wmi aesni_intel
kernel: CR2: 0000000000000000
kernel: ---[ end trace 0000000000000000 ]---
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da86ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 0000000101242006 CR4: 00000000001726f0
kernel: note: kworker/1:1[91] exited with irqs disabled
The previous kernel 6.17.0-14-generic boots without any issues.
I'll try to attach the required information using `apport-collect -p linux BUG#`, but it'll be collected after successfully booting with 6.17.0-14, whereas the bug occurs with 6.17.0-19.
---
ProblemType: Bug
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: mateusz 3017 F.... wireplumber
/dev/snd/controlC1: mateusz 3017 F.... wireplumber
/dev/snd/seq: mateusz 2999 F.... pipewire
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 25.10
InstallationDate: Installed on 2020-10-14 (1979 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
Package: linux (not installed)
ProcEnviron:
LANG=pl_PL.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=354e3c09-bfde-4e47-850f-fe872a882ae5 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14-generic 6.17.9
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.9
RfKill:
0: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
Tags: questing
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: Upgraded to questing on 2026-01-10 (65 days ago)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 04/10/2012
dmi.bios.release: 4.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.10
dmi.board.name: Z77 Pro3
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.10:bd04/10/2012:br4.6:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ77Pro3:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: To Be Filled By O.E.M.
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2144577/+subscriptions
Could you try this test kernel see if it fixes the issue?
https://people.canonical.com/~acelan/bugs/lp2144577
The test kernel includes the 2 commits from v7.0 mainline kernel.
f4db9913e4d3d drm/amdgpu: validate the flush_gpu_tlb_pasid()
e3a6eff92bbd9 drm/amdgpu: Fix validating flush_gpu_tlb_pasid()
To boot up with the test kernel, you need to manually disable the secure
boot from the BIOS menu.
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2144577
Title:
BUG: kernel NULL pointer dereference in amdgpu
Status in linux package in Ubuntu:
Confirmed
Bug description:
Ubuntu 25.10 with kernel 6.17.0-19-generic doesn't boot on my PC. I
freezes on the booting screen, and the kernel logs show a bug:
kernel: Linux version 6.17.0-19-generic (buildd@lcy02-amd64-084) (x86_64-linux-gnu-gcc (Ubuntu 15.2.0-4ubuntu4) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.45) #19-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 6 14:02:58 UTC 2026 (Ubuntu 6.17.0-19.19-generic 6.17.13)
kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.17.0-19-generic root=UUID=354e3c09-bfde-4e47-850f-fe872a882ae5 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
# ...
kernel: [drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
kernel: #PF: supervisor instruction fetch in kernel mode
kernel: #PF: error_code(0x0010) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: Oops: 0010 [#1] SMP PTI
kernel: CPU: 3 UID: 0 PID: 109 Comm: kworker/3:1 Not tainted 6.17.0-19-generic #19-Ubuntu PREEMPT(voluntary)
kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P1.10 04/10/2012
kernel: Workqueue: events amdgpu_tlb_fence_work [amdgpu]
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da87ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 00000003de040002 CR4: 00000000001726f0
kernel: Call Trace:
kernel: <TASK>
kernel: amdgpu_gmc_flush_gpu_tlb_pasid+0xfd/0x480 [amdgpu]
kernel: amdgpu_tlb_fence_work+0x77/0x110 [amdgpu]
kernel: process_one_work+0x18e/0x370
kernel: worker_thread+0x317/0x450
kernel: ? _raw_spin_lock_irqsave+0xe/0x20
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10b/0x220
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x134/0x150
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork_asm+0x1a/0x30
kernel: </TASK>
kernel: Modules linked in: rfcomm cmac algif_hash algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype xt_mac xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat binfmt_misc nf_tables amdgpu(+) usblp intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel amdxcp at24 mei_hdcp mei_pxp kvm snd_hda_codec_atihdmi drm_panel_backlight_quirks gpu_sched irqbypass snd_hda_codec_hdmi drm_buddy snd_hda_codec_alc662 rapl btusb snd_hda_codec_realtek_lib intel_cstate snd_hda_codec_generic radeon btrtl snd_hda_intel btintel i2c_i801 btbcm snd_hda_codec btmtk i2c_smbus drm_ttm_helper i2c_mux ttm bluetooth snd_seq_midi snd_hda_core snd_seq_midi_event drm_exec snd_intel_dspcfg snd_rawmidi drm_suballoc_helper snd_intel_sdw_acpi drm_display_helper lpc_ich snd_hwdep snd_seq snd_pcm snd_seq_device cec snd_timer rc_core snd i2c_algo_bit soundcore mei_me mei intel_smartconnect joydev
kernel: input_leds mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 dm_crypt wacom uas usb_storage hid_generic usbhid hid r8169 polyval_clmulni ghash_clmulni_intel psmouse ahci realtek serio_raw libahci video wmi aesni_intel
kernel: CR2: 0000000000000000
kernel: ---[ end trace 0000000000000000 ]---
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da87ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 00000003de040002 CR4: 00000000001726f0
kernel: note: kworker/3:1[109] exited with irqs disabled
kernel: loop50: detected capacity change from 0 to 8
kernel: fbcon: amdgpudrmfb (fb0) is primary device
kernel: fbcon: Deferring console take-over
kernel: amdgpu 0000:01:00.0: [drm] fb0: amdgpudrmfb frame buffer device
kernel: NET: Registered PF_QIPCRTR protocol family
kernel: sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
kernel: #PF: supervisor instruction fetch in kernel mode
kernel: #PF: error_code(0x0010) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: Oops: 0010 [#2] SMP PTI
kernel: CPU: 1 UID: 0 PID: 91 Comm: kworker/1:1 Tainted: G D 6.17.0-19-generic #19-Ubuntu PREEMPT(voluntary)
kernel: Tainted: [D]=DIE
kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P1.10 04/10/2012
kernel: Workqueue: events amdgpu_tlb_fence_work [amdgpu]
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0000:ffffce5600477db0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008001 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008001 RDI: ffff8a4a6d180000
kernel: RBP: ffffce5600477e08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da86ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 0000000101242006 CR4: 00000000001726f0
kernel: Call Trace:
kernel: <TASK>
kernel: amdgpu_gmc_flush_gpu_tlb_pasid+0xfd/0x480 [amdgpu]
kernel: amdgpu_tlb_fence_work+0x77/0x110 [amdgpu]
kernel: process_one_work+0x18e/0x370
kernel: worker_thread+0x317/0x450
kernel: ? _raw_spin_lock_irqsave+0xe/0x20
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10b/0x220
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x134/0x150
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork_asm+0x1a/0x30
kernel: </TASK>
kernel: Modules linked in: qrtr rfcomm cmac algif_hash algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limit xt_addrtype xt_mac xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat binfmt_misc nf_tables amdgpu usblp intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel amdxcp at24 mei_hdcp mei_pxp kvm snd_hda_codec_atihdmi drm_panel_backlight_quirks gpu_sched irqbypass snd_hda_codec_hdmi drm_buddy snd_hda_codec_alc662 rapl btusb snd_hda_codec_realtek_lib intel_cstate snd_hda_codec_generic radeon btrtl snd_hda_intel btintel i2c_i801 btbcm snd_hda_codec btmtk i2c_smbus drm_ttm_helper i2c_mux ttm bluetooth snd_seq_midi snd_hda_core snd_seq_midi_event drm_exec snd_intel_dspcfg snd_rawmidi drm_suballoc_helper snd_intel_sdw_acpi drm_display_helper lpc_ich snd_hwdep snd_seq snd_pcm snd_seq_device cec snd_timer rc_core snd i2c_algo_bit soundcore mei_me mei intel_smartconnect joydev
kernel: input_leds mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 dm_crypt wacom uas usb_storage hid_generic usbhid hid r8169 polyval_clmulni ghash_clmulni_intel psmouse ahci realtek serio_raw libahci video wmi aesni_intel
kernel: CR2: 0000000000000000
kernel: ---[ end trace 0000000000000000 ]---
kernel: RIP: 0010:0x0
kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
kernel: RSP: 0018:ffffce560061fdb0 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000001
kernel: RDX: 0000000000000002 RSI: 0000000000008000 RDI: ffff8a4a6d180000
kernel: RBP: ffffce560061fe08 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
kernel: R13: 0000000000000000 R14: ffff8a4a6d180000 R15: 0000000000000000
kernel: FS: 0000000000000000(0000) GS:ffff8a4da86ff000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffffffffffffffd6 CR3: 0000000101242006 CR4: 00000000001726f0
kernel: note: kworker/1:1[91] exited with irqs disabled
The previous kernel 6.17.0-14-generic boots without any issues.
I'll try to attach the required information using `apport-collect -p linux BUG#`, but it'll be collected after successfully booting with 6.17.0-14, whereas the bug occurs with 6.17.0-19.
---
ProblemType: Bug
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: mateusz 3017 F.... wireplumber
/dev/snd/controlC1: mateusz 3017 F.... wireplumber
/dev/snd/seq: mateusz 2999 F.... pipewire
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 25.10
InstallationDate: Installed on 2020-10-14 (1979 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
Package: linux (not installed)
ProcEnviron:
LANG=pl_PL.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-14-generic root=UUID=354e3c09-bfde-4e47-850f-fe872a882ae5 ro quiet splash radeon.si_support=0 amdgpu.si_support=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
ProcVersionSignature: Ubuntu 6.17.0-14.14-generic 6.17.9
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.9
RfKill:
0: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
Tags: questing
Uname: Linux 6.17.0-14-generic x86_64
UpgradeStatus: Upgraded to questing on 2026-01-10 (65 days ago)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 04/10/2012
dmi.bios.release: 4.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.10
dmi.board.name: Z77 Pro3
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.10:bd04/10/2012:br4.6:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ77Pro3:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: To Be Filled By O.E.M.
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2144577/+subscriptions
[Bug 2143301] Re: Enable new Intel WCL soundwire support
In order to ensure broader test coverage across a wider range of
hardware, I have added the block-proposed-<series> tags to this bug. We
are holding the promotion until certification testing for the 2026.03.09
kernel SRU is complete.
According to the schedule on kernel.ubuntu.com, testing is slated for
completion by April 10, 2026. These tags will be removed once the
certification results are verified.
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143301
Title:
Enable new Intel WCL soundwire support
Status in HWE Next:
New
Status in firmware-sof package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in firmware-sof source package in Noble:
Fix Committed
Status in linux source package in Noble:
Invalid
Status in linux-oem-6.17 source package in Noble:
Fix Committed
Status in firmware-sof source package in Questing:
Fix Committed
Status in linux source package in Questing:
New
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in firmware-sof source package in Resolute:
Fix Released
Status in linux source package in Resolute:
New
Status in linux-oem-6.17 source package in Resolute:
Invalid
Bug description:
[Impact]
New Dell Slate-1-Piece and Congo platform powered by Intel WildcatLake will have no basic audio functions w/o new firmware-sof which has the new DSP firmware and TPLG files
================ kernel ==============================
Realtek on WCL: (Congo WCL)
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/codecs/rt722-sdca.c?id=a27539810e1e61efcfdeb51777ed875dc61e9d49 [git.kernel.org]
CirrusLogic on WCL: (Slate-1-Piece WCL)
https://lore.kernel.org/linux-sound/aYMpbnzi%2FUTO5Fqs@opensource.cirrus.com/T/#t
<=============== firmware-sof ========================
[Fix]
c78aea2df366275fed6c7b090bae3575951de57f Add 2.14.1 signed firmware binaries for Intel MTL+ targets
f3e02da867b54e6061190d7ff1549e4f00bba17c Add 2.14.1 firmware binaries for Intel MTL and newer targets
cdd3c8f9dd879a51dc8ed3c9aa0b7b0a49c108d8 Add 2.14 tools and topology binaries for Intel MTL and newer targets
11fc822288122b83296e634e8508f483c289d565 v2.14.x: add topologies for v2.14.2
e65a0d4f3ffceaf8a01df7f519707ffaf69746ef v2.14.x: add topologies for v2.14.3
[Test Case]
1. Boot up the machine of new Dell Intel WCL Congo and Slate-1-Piece platform powered by Intel WCL
2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices
3. Click test icon for basic audio output functions
4. Use `arecord` to record and play the recorded audio file with `aplay` for basic speaker/microphone functions.
5. Test on machines of Intel ARL/LNL/MTL/PTL platforms for possible regression
[Where problems could occur]
Per comment from Intel, the primary requirement is that the topology file (sof-ptl-foo.tplg) and DSP firmware (sof-ptl.ri) are a pair and need to be from the same major version.
If we upgrade of FW for only a single generation (e.g. only for WCL)
This will be problematic. The main problem is that you may have two platforms (let's say
PTL and ARL) using same topology files. If you update FW for only PTL, you should also update the topology
files used by PTL (FW+tplg always a pair!), but then if one of the topology files is used by some ARL
products you may have problems (-> scenario 2 problem on ARL then).
So we need to upgrade the DSP FW and the TPLG both for all MTL+
platforms (include ARL/LNL/MTL/PTL/WCL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2143301/+subscriptions
hardware, I have added the block-proposed-<series> tags to this bug. We
are holding the promotion until certification testing for the 2026.03.09
kernel SRU is complete.
According to the schedule on kernel.ubuntu.com, testing is slated for
completion by April 10, 2026. These tags will be removed once the
certification results are verified.
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143301
Title:
Enable new Intel WCL soundwire support
Status in HWE Next:
New
Status in firmware-sof package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in firmware-sof source package in Noble:
Fix Committed
Status in linux source package in Noble:
Invalid
Status in linux-oem-6.17 source package in Noble:
Fix Committed
Status in firmware-sof source package in Questing:
Fix Committed
Status in linux source package in Questing:
New
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in firmware-sof source package in Resolute:
Fix Released
Status in linux source package in Resolute:
New
Status in linux-oem-6.17 source package in Resolute:
Invalid
Bug description:
[Impact]
New Dell Slate-1-Piece and Congo platform powered by Intel WildcatLake will have no basic audio functions w/o new firmware-sof which has the new DSP firmware and TPLG files
================ kernel ==============================
Realtek on WCL: (Congo WCL)
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/codecs/rt722-sdca.c?id=a27539810e1e61efcfdeb51777ed875dc61e9d49 [git.kernel.org]
CirrusLogic on WCL: (Slate-1-Piece WCL)
https://lore.kernel.org/linux-sound/aYMpbnzi%2FUTO5Fqs@opensource.cirrus.com/T/#t
<=============== firmware-sof ========================
[Fix]
c78aea2df366275fed6c7b090bae3575951de57f Add 2.14.1 signed firmware binaries for Intel MTL+ targets
f3e02da867b54e6061190d7ff1549e4f00bba17c Add 2.14.1 firmware binaries for Intel MTL and newer targets
cdd3c8f9dd879a51dc8ed3c9aa0b7b0a49c108d8 Add 2.14 tools and topology binaries for Intel MTL and newer targets
11fc822288122b83296e634e8508f483c289d565 v2.14.x: add topologies for v2.14.2
e65a0d4f3ffceaf8a01df7f519707ffaf69746ef v2.14.x: add topologies for v2.14.3
[Test Case]
1. Boot up the machine of new Dell Intel WCL Congo and Slate-1-Piece platform powered by Intel WCL
2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices
3. Click test icon for basic audio output functions
4. Use `arecord` to record and play the recorded audio file with `aplay` for basic speaker/microphone functions.
5. Test on machines of Intel ARL/LNL/MTL/PTL platforms for possible regression
[Where problems could occur]
Per comment from Intel, the primary requirement is that the topology file (sof-ptl-foo.tplg) and DSP firmware (sof-ptl.ri) are a pair and need to be from the same major version.
If we upgrade of FW for only a single generation (e.g. only for WCL)
This will be problematic. The main problem is that you may have two platforms (let's say
PTL and ARL) using same topology files. If you update FW for only PTL, you should also update the topology
files used by PTL (FW+tplg always a pair!), but then if one of the topology files is used by some ARL
products you may have problems (-> scenario 2 problem on ARL then).
So we need to upgrade the DSP FW and the TPLG both for all MTL+
platforms (include ARL/LNL/MTL/PTL/WCL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2143301/+subscriptions
[Bug 2143301] Re: Enable new Intel WCL soundwire support
** Tags added: block-proposed-noble block-proposed-questing
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143301
Title:
Enable new Intel WCL soundwire support
Status in HWE Next:
New
Status in firmware-sof package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in firmware-sof source package in Noble:
Fix Committed
Status in linux source package in Noble:
Invalid
Status in linux-oem-6.17 source package in Noble:
Fix Committed
Status in firmware-sof source package in Questing:
Fix Committed
Status in linux source package in Questing:
New
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in firmware-sof source package in Resolute:
Fix Released
Status in linux source package in Resolute:
New
Status in linux-oem-6.17 source package in Resolute:
Invalid
Bug description:
[Impact]
New Dell Slate-1-Piece and Congo platform powered by Intel WildcatLake will have no basic audio functions w/o new firmware-sof which has the new DSP firmware and TPLG files
================ kernel ==============================
Realtek on WCL: (Congo WCL)
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/codecs/rt722-sdca.c?id=a27539810e1e61efcfdeb51777ed875dc61e9d49 [git.kernel.org]
CirrusLogic on WCL: (Slate-1-Piece WCL)
https://lore.kernel.org/linux-sound/aYMpbnzi%2FUTO5Fqs@opensource.cirrus.com/T/#t
<=============== firmware-sof ========================
[Fix]
c78aea2df366275fed6c7b090bae3575951de57f Add 2.14.1 signed firmware binaries for Intel MTL+ targets
f3e02da867b54e6061190d7ff1549e4f00bba17c Add 2.14.1 firmware binaries for Intel MTL and newer targets
cdd3c8f9dd879a51dc8ed3c9aa0b7b0a49c108d8 Add 2.14 tools and topology binaries for Intel MTL and newer targets
11fc822288122b83296e634e8508f483c289d565 v2.14.x: add topologies for v2.14.2
e65a0d4f3ffceaf8a01df7f519707ffaf69746ef v2.14.x: add topologies for v2.14.3
[Test Case]
1. Boot up the machine of new Dell Intel WCL Congo and Slate-1-Piece platform powered by Intel WCL
2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices
3. Click test icon for basic audio output functions
4. Use `arecord` to record and play the recorded audio file with `aplay` for basic speaker/microphone functions.
5. Test on machines of Intel ARL/LNL/MTL/PTL platforms for possible regression
[Where problems could occur]
Per comment from Intel, the primary requirement is that the topology file (sof-ptl-foo.tplg) and DSP firmware (sof-ptl.ri) are a pair and need to be from the same major version.
If we upgrade of FW for only a single generation (e.g. only for WCL)
This will be problematic. The main problem is that you may have two platforms (let's say
PTL and ARL) using same topology files. If you update FW for only PTL, you should also update the topology
files used by PTL (FW+tplg always a pair!), but then if one of the topology files is used by some ARL
products you may have problems (-> scenario 2 problem on ARL then).
So we need to upgrade the DSP FW and the TPLG both for all MTL+
platforms (include ARL/LNL/MTL/PTL/WCL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2143301/+subscriptions
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2143301
Title:
Enable new Intel WCL soundwire support
Status in HWE Next:
New
Status in firmware-sof package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in firmware-sof source package in Noble:
Fix Committed
Status in linux source package in Noble:
Invalid
Status in linux-oem-6.17 source package in Noble:
Fix Committed
Status in firmware-sof source package in Questing:
Fix Committed
Status in linux source package in Questing:
New
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in firmware-sof source package in Resolute:
Fix Released
Status in linux source package in Resolute:
New
Status in linux-oem-6.17 source package in Resolute:
Invalid
Bug description:
[Impact]
New Dell Slate-1-Piece and Congo platform powered by Intel WildcatLake will have no basic audio functions w/o new firmware-sof which has the new DSP firmware and TPLG files
================ kernel ==============================
Realtek on WCL: (Congo WCL)
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/codecs/rt722-sdca.c?id=a27539810e1e61efcfdeb51777ed875dc61e9d49 [git.kernel.org]
CirrusLogic on WCL: (Slate-1-Piece WCL)
https://lore.kernel.org/linux-sound/aYMpbnzi%2FUTO5Fqs@opensource.cirrus.com/T/#t
<=============== firmware-sof ========================
[Fix]
c78aea2df366275fed6c7b090bae3575951de57f Add 2.14.1 signed firmware binaries for Intel MTL+ targets
f3e02da867b54e6061190d7ff1549e4f00bba17c Add 2.14.1 firmware binaries for Intel MTL and newer targets
cdd3c8f9dd879a51dc8ed3c9aa0b7b0a49c108d8 Add 2.14 tools and topology binaries for Intel MTL and newer targets
11fc822288122b83296e634e8508f483c289d565 v2.14.x: add topologies for v2.14.2
e65a0d4f3ffceaf8a01df7f519707ffaf69746ef v2.14.x: add topologies for v2.14.3
[Test Case]
1. Boot up the machine of new Dell Intel WCL Congo and Slate-1-Piece platform powered by Intel WCL
2. Open settings->Sound->Output Device and make sure it's not Dummy audio devices
3. Click test icon for basic audio output functions
4. Use `arecord` to record and play the recorded audio file with `aplay` for basic speaker/microphone functions.
5. Test on machines of Intel ARL/LNL/MTL/PTL platforms for possible regression
[Where problems could occur]
Per comment from Intel, the primary requirement is that the topology file (sof-ptl-foo.tplg) and DSP firmware (sof-ptl.ri) are a pair and need to be from the same major version.
If we upgrade of FW for only a single generation (e.g. only for WCL)
This will be problematic. The main problem is that you may have two platforms (let's say
PTL and ARL) using same topology files. If you update FW for only PTL, you should also update the topology
files used by PTL (FW+tplg always a pair!), but then if one of the topology files is used by some ARL
products you may have problems (-> scenario 2 problem on ARL then).
So we need to upgrade the DSP FW and the TPLG both for all MTL+
platforms (include ARL/LNL/MTL/PTL/WCL)
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2143301/+subscriptions
[Bug 2146761] Re: Bluetooth audio headset regression on 7.0.0-10-generic: Shokz OpenComm2 disconnects, works on 6.19.0-6-generic
** Package changed: gnome-shell (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146761
Title:
Bluetooth audio headset regression on 7.0.0-10-generic: Shokz
OpenComm2 disconnects, works on 6.19.0-6-generic
Status in linux package in Ubuntu:
New
Bug description:
After the system update on March 29, 2026, my Bluetooth audio headset
(Shokz OpenComm2 / OpenComm2 by Shokz_II) stopped working on kernel
7.0.0-10-generic.
The headset either disconnects within about 10 seconds after
connect, or the connection is canceled and audio profiles fail to come
up.
If I reboot the same machine into the previous kernel
6.19.0-6-generic, the headset works again without changing userspace
packages or pairing state.
This looks like a kernel regression in 7.0.0-10-generic.
Working kernel:
6.19.0-6-generic
Linux book 6.19.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 18 15:48:21 UTC 2026 x86_64 GNU/Linux
Broken kernel:
7.0.0-10-generic
From previous boot kernel log:
Linux version 7.0.0-10-generic (buildd@lcy02-amd64-051) (x86_64-linux-gnu-gcc (Ubuntu 15.2.0-15ubuntu2) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.46) #10-Ubuntu SMP
PREEMPT_DYNAMIC Thu Mar 19 10:24:42 UTC 2026 (Ubuntu 7.0.0-10.10-generic 7.0.0-rc4)
Userspace versions at the time:
bluez 5.85-4
pipewire 1.6.2-1ubuntu1
wireplumber 0.5.13-1ubuntu1
gnome-shell 50.0-0ubuntu2
same userspace + new kernel fails.
Steps to reproduce:
1. Boot kernel 7.0.0-10-generic.
2. Power on the Shokz OpenComm2 headset.
3. Connect it from GNOME Settings or with bluetoothctl.
4. Wait a few seconds.
Expected result:
The headset should stay connected and its audio profile should become usable.
Actual result:
- Another Bluetooth device (Logitech Pebble mouse) still works, so this is not a total Bluetooth failure.
- I tested re-pairing the headset and rebooting the headset; that did not help on 7.0.0-10-generic.
- I tested disabling Bluetooth headset autoswitch behavior in WirePlumber; that did not fix it on 7.0.0-10-generic.
- There is no GNOME Shell crash here; this does not appear to be the old gnome-shell bug 2138654.
Relevant bluetoothd log lines from the broken boot:
- src/profile.c:ext_connect() Hands-Free Voice gateway failed connect to A0:0C:C3:E1:3F:7C: Connection reset by peer (104)
- src/service.c:btd_service_connect() a2dp-sink profile connect failed for A0:0C:C3:E1:3F:7C: Device or resource busy
- profiles/audio/avdtp.c:avdtp_connect_cb() connect to A0:0C:C3:E1:3F:7C: Connection refused (111)
- profiles/audio/avctp.c:avctp_connect_cb() HUP or ERR on socket: Connection refused (111)
- profiles/audio/avctp.c:avctp_connect_cb() HUP or ERR on socket: Connection timed out (110)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146761/+subscriptions
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146761
Title:
Bluetooth audio headset regression on 7.0.0-10-generic: Shokz
OpenComm2 disconnects, works on 6.19.0-6-generic
Status in linux package in Ubuntu:
New
Bug description:
After the system update on March 29, 2026, my Bluetooth audio headset
(Shokz OpenComm2 / OpenComm2 by Shokz_II) stopped working on kernel
7.0.0-10-generic.
The headset either disconnects within about 10 seconds after
connect, or the connection is canceled and audio profiles fail to come
up.
If I reboot the same machine into the previous kernel
6.19.0-6-generic, the headset works again without changing userspace
packages or pairing state.
This looks like a kernel regression in 7.0.0-10-generic.
Working kernel:
6.19.0-6-generic
Linux book 6.19.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 18 15:48:21 UTC 2026 x86_64 GNU/Linux
Broken kernel:
7.0.0-10-generic
From previous boot kernel log:
Linux version 7.0.0-10-generic (buildd@lcy02-amd64-051) (x86_64-linux-gnu-gcc (Ubuntu 15.2.0-15ubuntu2) 15.2.0, GNU ld (GNU Binutils for Ubuntu) 2.46) #10-Ubuntu SMP
PREEMPT_DYNAMIC Thu Mar 19 10:24:42 UTC 2026 (Ubuntu 7.0.0-10.10-generic 7.0.0-rc4)
Userspace versions at the time:
bluez 5.85-4
pipewire 1.6.2-1ubuntu1
wireplumber 0.5.13-1ubuntu1
gnome-shell 50.0-0ubuntu2
same userspace + new kernel fails.
Steps to reproduce:
1. Boot kernel 7.0.0-10-generic.
2. Power on the Shokz OpenComm2 headset.
3. Connect it from GNOME Settings or with bluetoothctl.
4. Wait a few seconds.
Expected result:
The headset should stay connected and its audio profile should become usable.
Actual result:
- Another Bluetooth device (Logitech Pebble mouse) still works, so this is not a total Bluetooth failure.
- I tested re-pairing the headset and rebooting the headset; that did not help on 7.0.0-10-generic.
- I tested disabling Bluetooth headset autoswitch behavior in WirePlumber; that did not fix it on 7.0.0-10-generic.
- There is no GNOME Shell crash here; this does not appear to be the old gnome-shell bug 2138654.
Relevant bluetoothd log lines from the broken boot:
- src/profile.c:ext_connect() Hands-Free Voice gateway failed connect to A0:0C:C3:E1:3F:7C: Connection reset by peer (104)
- src/service.c:btd_service_connect() a2dp-sink profile connect failed for A0:0C:C3:E1:3F:7C: Device or resource busy
- profiles/audio/avdtp.c:avdtp_connect_cb() connect to A0:0C:C3:E1:3F:7C: Connection refused (111)
- profiles/audio/avctp.c:avctp_connect_cb() HUP or ERR on socket: Connection refused (111)
- profiles/audio/avctp.c:avctp_connect_cb() HUP or ERR on socket: Connection timed out (110)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2146761/+subscriptions
Подписаться на:
Комментарии (Atom)