From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 56E343E3163 for ; Sun, 26 Jul 2026 18:21:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785090092; cv=none; b=iL+Sgk7agcg/bLmE4BEE0yXnZKaPAbpsZYWJDWwRTBGez3dKH74VNBGYJn6+LsqYtD/m0khIX6NtIjZmS5/uMvOQXXKDY6Hr3sJ5LBo1SF2iBPLr6qAoK+6TCGBCws9l/uEMa1oAixheONbR4/ztmofi9Yuz4rm4hcRE1LHO7Bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785090092; c=relaxed/simple; bh=Jpe9nMj8D/r5dEewuZKM12VFxKoRQ5AdR/UYBCopHj0=; h=MIME-Version:From:To:Cc:Subject:Message-ID:Date:Content-Type; b=GHiuqtHR8QbzFIxW0jIMXz3VHajFWtm+1KW3McGsXquw2dUr6eWtmepwg7pifeo7gomDLknwZEw6gP5rlQ8ObyFNuuZFTzKcrH3Q6Jcn5ewki0BdV6hr5wYPU6Q3qGyLhm2Omz0La7u3ZgJO3egOF44OzARf5a70imlubFihMAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=recursiveintell.com; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.222.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=recursiveintell.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-9690c99c917so693406241.2 for ; Sun, 26 Jul 2026 11:21:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785090089; x=1785694889; h=content-transfer-encoding:content-type:date:message-id:subject:cc :to:from:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ONmVHlBZvOI0iD4ajPdXD82wwgbRBXTGldDTbVh27Yk=; b=q4rRpGfRwo1kYCx/cIXCHJAGV+MD63R6dWj79T1kINn7Amt9tGmfPX+aNHBYi+rDsQ hE7wabWd2Q5qEvn4AcYTfLqpVmToOJscsAwLZNU6CwFdA6KIgK2IgRPufmta2L0XrCj4 75TQ7+BjraZ100q9F9OxBOdISvYe2uKtFAyQydefKSnYhkzPfYqMKtDr8dwFlE9dc2Qi 6RiKy4nEt+mE4aDP1P3K312oX1gOtY4Tl9nFNkBnxs2mzplr6icBdSwNS7k4+0lTlizu BwwtapkHpDPYiYcnRW6WthprgYDy2CXbpu6sAzdcn7WWReGlJjev2bZhdYZLAPhQI0X2 rVyw== X-Forwarded-Encrypted: i=1; AHgh+RoUl/Tvkl+uOYxEZni966/s1hjbqtp/Cx1LbFhJQaJF9WIs5LYSshUMQw0YWxvsVKW90fwQbLUXmPmviDY=@vger.kernel.org X-Gm-Message-State: AOJu0YwdiupJVUFtoJIukBjw/ajrNBRqZY0qhxzoXK8QoFw6LhKKkk/c j+2trjeCMIWpX5VfiUCbaXuxxPEVbEQRsf7xPhz6Pn5pcekZBGhCSi/n X-Gm-Gg: AR+sD10JgTGSt2m1hrLhN4+s958Cf4Hhu4/u1Wr66vFTG+6GU9PhpFaNKapLORgvWNM igi6orUxgHAoTuOGgmQc6QeOcSU0dqqzqvoD1cpy2Ql5iWbIFhNKeNwruh+9+HU3T7ywZavoRDT x/1PFp+NqWN2Tz+yfbmu0u5uaGrXqMMlDYboyhZdDVYAHwB6nQ2ifkDcUpf65ck/tWRiGUbOUJS ENuclarIBJT47YMpzMV6OUcpOHbGT5qmyXhtursuc+490ki/tcZte4YNBbsVuPt3//o5BOiZJpH GJxR/fJtgLOUhdqqReq7hC+I9spzBy8CyJ3hLAnLXiz8XNbrJK7Tb8JESLpv1f7q+HINuhaIGCx T/WoWJRmWipPTGFIyPJtnezG1a1Q3ChzwoFvccXBDOAhDSHlN2xJZbZ87K/EFgHUFYYRBFbtHUZ 289t1O X-Received: by 2002:a05:6102:3711:b0:739:8c52:f2b with SMTP id ada2fe7eead31-7503fb97f37mr2910608137.18.1785090088901; Sun, 26 Jul 2026 11:21:28 -0700 (PDT) Received: from nobara-pc ([75.138.15.254]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-75033d6a692sm3933201137.1.2026.07.26.11.21.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jul 2026 11:21:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "Josh Stevenson" To: Cc: , , Subject: [BUG] rtw89_8852bte: Recurring firmware crashes (LBC watchdog / SER) on RTL8852BE-VT despite ASPM and PS disabled Message-ID: <18c5e9fa2f7b7f5e.f55361b117e95aa2.460cfd9fd11f5e9a@nobara-pc> Date: Sun, 26 Jul 2026 18:21:28 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I'm experiencing recurring firmware crashes on a Realtek RTL8852BE-VT Wi-Fi adapter. The crashes happen every 30 minutes to several hours during normal use, with 990 crash events logged in the current boot (2 days 11 hours uptime). The firmware auto-recovers via SER (System Error Recovery) each time, but connectivity drops briefly. This is a known issue reported by multiple users (e.g., Arch Linux forum post [1]), but I have not found an existing upstream bug report with full diagnostic data. [1] https://bbs.archlinux.org/viewtopic.php?id=3D290480 ## Hardware - Laptop: HP Laptop 15-fc0xxx (baseboard 8DC7) - Wi-Fi: Realtek RTL8852BE-VT PCIe 802.11ax PCI ID: 10ec:b520 (subsystem 10ec:b520) Module: rtw89_8852bte (depends on rtw89_pci, rtw89_8852b) - CPU: AMD Ryzen 7 7730U - OS: Nobara 43 (based on Fedora 44) - Kernel: 7.1.3-200.nobara.fc44.x86_64 - Firmware package: linux-firmware-20260622-1.fc44 - Firmware files: rtw8852b_fw.bin, rtw8852b_fw-1.bin, rtw8852b_fw-2.bin (dated 2026-06-22) ## Already-tried mitigations (no effect) The following module parameters are set in /etc/modprobe.d/ and confirmed active, but crashes persist: options rtw89_pci disable_clkreq=3Dy disable_aspm_l1=3Dy disable_aspm_l1ss= =3Dy options rtw89_core disable_ps_mode=3Dy NetworkManager Wi-Fi powersave is set to disable (value 2). iw dev shows "Power save: off". ## Crash pattern Crashes occur in bursts of 3 SER events: 1. R_AX_LBC_WATCHDOG=3D0x00000081 2. SER catches error: 0x1000 (L2 reset) 3. SER catches error: 0x1001 (L1 reset) 4. SER catches error: 0x1002 (firmware reset) Each burst takes ~30ms. The firmware then auto-recovers and NetworkManager reconnects within a few seconds. Total crash events across 15 boots: 13,395+ Peak boot: 3,060 crashes in one session. ## Complete crash log (one representative event) Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_LBC_WATCH= DOG=3D0x00000081 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: <--- Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches er= ror: 0x1000 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status =3D = 0xa1001100 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR =3D= 0x0 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA =3D = 0x0 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC =3D 0x= b8900635 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = =3D 0x1001 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_I= NFO =3D 0x1000000 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC =3D= 0xb898815b Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC =3D= 0xb89880f3 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC =3D= 0xb898815d [... more fw PC entries ...] Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches er= ror: 0x1001 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status =3D = 0xa1008100 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR =3D= 0x0 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA =3D = 0x0 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC =3D 0x= b8986657 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = =3D 0x1002 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_I= NFO =3D 0xf1000000 Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC =3D= 0xb89a1ea3 [... more fw PC entries ...] Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches er= ror: 0x1002 ## Observations 1. The crash trigger is R_AX_LBC_WATCHDOG=3D0x00000081 =E2=80=94 the LBC (LPS Boundary Check) watchdog fires, indicating the firmware stopped responding. 2. FW BADADDR varies: 0x0, 0x4444, 0xaaaa =E2=80=94 suggesting different crash sites in the firmware. 3. FW EPC/RA is always 0x0. 4. The fw PC values cluster around 0xb898_xxxx and 0xb89a_xxxx, suggesting the firmware is crashing in the same code regions. 5. Disabling ASPM, clkreq, and power save mode does NOT prevent the crashes. This suggests the root cause is in the firmware itself, not in the driver's power management integration. 6. Auto-recovery via SER works reliably =E2=80=94 the Wi-Fi reconnects every time. But the brief connectivity drops are disruptive. ## Questions 1. Is this a known firmware bug? Is there a newer firmware version available or in development? 2. Are there any driver-side workarounds to reduce LBC watchdog triggers (e.g., adjusting watchdog timeout, disabling LBC)? 3. Would a newer kernel version (e.g., mainline) have rtw89 patches that address this? 4. Is there additional diagnostic data I can collect to help narrow down the root cause? Thank you for your work on this driver. Best regards, Josh Stevenson