Bug 217041
| Summary: | sbs module causes lockup upon suspend/shutdown | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Armin Wolf (W_Armin) |
| Component: | Power-Battery | Assignee: | acpi_power-battery |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | high | ||
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 6.1.12 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg when suspending with sbs being unloaded
dmesg when suspending with pm_test set to "devices" and the sbs module being loaded kernel oops when unloading the sbs module Patch 1 Patch 2 Patch3 |
||
Created attachment 303731 [details]
dmesg when suspending with pm_test set to "devices" and the sbs module being loaded
When testing suspend with pm_test set to "devices" and the sbs module being loaded, the machine still resumes, but the video (ATI Mobility Radeon 9700) does not work anymore.
Created attachment 303732 [details]
kernel oops when unloading the sbs module
Only happens when "modprobe -r sbs" is used, not with "rmmod sbs".
Created attachment 303746 [details]
Patch 1
Created attachment 303747 [details]
Patch 2
Created attachment 303748 [details]
Patch3
I managed to fix the stacktrace upon module unload. The callback function pointer was still used inside a workqueue, which then called the callback function when the module was already unloaded. Regarding the lockup on suspend/shutdown: It seems that the problem does not occur if i clear the SMBus alert flag before executing the callback function, so i suppose the issue lies inside the sbs alert callback. I finally found the culprit, the patch series can be found here: https://lore.kernel.org/linux-acpi/20230225080458.1342359-1-W_Armin@gmx.de/T/#t |
Created attachment 303730 [details] dmesg when suspending with sbs being unloaded On my Acer Travelmate 4002 WLMI, the sbs (Smart Battery Subsystem) module is causing the kernel to lockup when suspending or shutting down. The system then becomes unresponsive and requires a power cycle to reboot. This does not happen when the sbs module is unloaded prior to suspend/shutdown, however using "modprobe -r sbs" causes a kernel oops. So both the sbs and the sbshc modules need to be unloaded manually using "rmmod <module>". If the kernel oops occured, the system also fails to suspend/shutdown. This issue is also present when using a 5.10 series kernel, and likely also when using a 4.19 series kernel.