Bug 2300988
| Summary: | activating powertop.service results in usb mouse being off after bootup | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | M. Schlegel <moschlegbz> | ||||||
| Component: | powertop | Assignee: | Jaroslav Škarvada <jskarvad> | ||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 41 | CC: | ajax, jskarvad, TicoTimo | ||||||
| Target Milestone: | --- | Keywords: | Desktop | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2025-12-16 17:08:34 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
M. Schlegel
2024-07-29 19:42:09 UTC
Promoted this to Fedora 41 since it's still a problem there. Could you provide output files created by "powertop -C" (or powertop -r) before the service is activated and after the service is activated, i.e. either two html files or two csv files? I suspect the problem is because the service enabled "all" tunables including USB suspend which is quite problematic with some USB implementations. If confirmed I will forward it to upstream, because I think with the auto mode it shouldn't enable potentially problematic tuning. You could also try TuneD, run powertop2tuned (from the tuned-utils package) which will create TuneD profile where you can fine tune tunables you need enabled. TuneD is now by default installed on f41 and up, so it shouldn't be much overhead from the default installation. I'm already running with tuned service set to 'balanced-battery' profile, the reason I was also running powertop service is that I was running tuned but running the powertop command showed many many things were still "Bad" on the Tunables page. I'll look into the powertop2tuned Created attachment 2055804 [details]
powertop -C results before running powertop service
This is the "before" powertop service output
The powertop override was removed by using systemctl edit powertop so powertop was back to the default. Then powertop service as disabled and system was rebooted.
After reboot "powertop -C" was run as root, then "systemctl --now enable powertop" so that powertop service ran in the default way. then "powertop -C" again.
Created attachment 2055805 [details]
powertop -C results after running powertop service
This is the "after" powertop service runs "powertop -C" output
This is the "inxi -JSMa" output on the system
System:
Host: msi Kernel: 6.11.6-300.fc41.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 2.43.1-2.fc41 clocksource: hpet avail: acpi_pm
parameters: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.11.6-300.fc41.x86_64
root=UUID=d1a0e4be-7988-40f6-9011-f563266a6571 ro preempt=full
Desktop: KDE Plasma v: 6.2.2 tk: Qt v: N/A info: frameworks v: 6.7.0
wm: kwin_wayland tools: avail: xfce4-screensaver vt: 2 dm: 1: LightDM
v: 1.32.0 note: stopped 2: SDDM Distro: Fedora Linux 41 (KDE Plasma)
Machine:
Type: Laptop System: Micro-Star product: Bravo 15 A4DDR v: REV:1.0
serial: <superuser required> Chassis: type: 10 serial: <superuser required>
Mobo: Micro-Star model: MS-16WK v: REV:1.0 serial: <superuser required>
part-nu: 16WK.1 uuid: <superuser required> UEFI: American Megatrends
v: E16WKAMS.110 date: 10/29/2020
USB:
Hub-1: 1-0:1 info: hi-speed hub with single TT ports: 4 rev: 2.0
speed: 480 Mb/s (57.2 MiB/s) lanes: 1 mode: 2.0 chip-ID: 1d6b:0002
class-ID: 0900
Hub-2: 2-0:1 info: super-speed hub ports: 2 rev: 3.1
speed: 10 Gb/s (1.16 GiB/s) lanes: 1 mode: 3.2 gen-2x1 chip-ID: 1d6b:0003
class-ID: 0900
Hub-3: 3-0:1 info: hi-speed hub with single TT ports: 4 rev: 2.0
speed: 480 Mb/s (57.2 MiB/s) lanes: 1 mode: 2.0 chip-ID: 1d6b:0002
class-ID: 0900
Device-1: 3-1:5 info: SAVITECH C5D Amp DAC type: HID,audio
driver: hid-generic,snd-usb-audio,usbhid interfaces: 3 rev: 1.1
speed: 12 Mb/s (1.4 MiB/s) lanes: 1 mode: 1.1 power: 4mA
chip-ID: 262a:1120 class-ID: 0102
Device-2: 3-2:4 info: Microsoft Compact Optical Mouse 500 type: mouse
driver: hid-generic,usbhid interfaces: 1 rev: 1.1
speed: 1.5 Mb/s (183 KiB/s) lanes: 1 mode: 1.0 power: 100mA
chip-ID: 045e:0737 class-ID: 0301
Device-3: 3-3:3 info: Intel AX200 Bluetooth type: bluetooth driver: btusb
interfaces: 2 rev: 2.0 speed: 12 Mb/s (1.4 MiB/s) lanes: 1 mode: 1.1
power: 100mA chip-ID: 8087:0029 class-ID: e001
Hub-4: 4-0:1 info: super-speed hub ports: 2 rev: 3.1
speed: 10 Gb/s (1.16 GiB/s) lanes: 1 mode: 3.2 gen-2x1 chip-ID: 1d6b:0003
class-ID: 0900
(In reply to M. Schlegel from comment #3) > I'm already running with tuned service set to 'balanced-battery' profile, > the reason I was also running powertop service is that I was running tuned > but running the powertop command showed many many things were still "Bad" on > the Tunables page. > I'll look into the powertop2tuned powertop2tuned will create custom profile which loads the previous profile (balanced-battery in this case) and adds powertop tuning over it. IMHO you could name the resulting profile also balanced-battery and put it into /etc/tuned/profiles and it should be loaded instead of the system balanced-battery profile. I PR patch upstream. If approved by upstream, I will use it in Fedora downstream: https://github.com/fenrus75/powertop/pull/164 This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. |