iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

thenextdon13 · 2025-11-17 05:36:59

Hello-
I very recently (after pacman -Suy in the last few days) started having trouble with my intel 8260 card. My card seems to silently (no messages/significant errors in dmesg, journalctl, 'ip stats') drop traffic whenever iwconfig powersave mode is on. When i disable powersave (via iwconfig $INTERFACE power off) the troubles all go away.

When setting the module parameters to powersave via modprobe iwlwifi power_save=Y power_level={1,5}, the problem does not exist.

when in iwconfig powersave mode, ssh'ing into the wireless router/ap that i am connected to is very bad- latency of typing feedback changes and frequently locks up.

[dylan@thinkarch ~]$ uname -a && lspci | grep -i wireless && iwconfig wlp4s0 | grep Management
Linux thinkarch 6.17.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 14 Nov 2025 06:54:20 +0000 x86_64 GNU/Linux
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
          Power Management:on
[dylan@thinkarch ~]$ ethtool -i wlp4s0 
driver: iwlwifi
version: 6.17.8-arch1-1
firmware-version: 36.c8e8e144.0 8000C-36.ucode
expansion-rom-version: 
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
[dylan@thinkarch ~]$

Ping times occasionally get high, and i get an occational 'DUP!'

64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=22 ttl=64 time=4.27 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=23 ttl=64 time=114 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=24 ttl=64 time=3.64 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=25 ttl=64 time=3.72 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=26 ttl=64 time=4.25 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=27 ttl=64 time=5.69 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=28 ttl=64 time=5.68 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=29 ttl=64 time=4.14 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=30 ttl=64 time=3.74 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=31 ttl=64 time=4.08 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=32 ttl=64 time=3.12 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=33 ttl=64 time=108 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=34 ttl=64 time=5.76 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=35 ttl=64 time=3.23 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=36 ttl=64 time=3.20 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=37 ttl=64 time=5.83 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=38 ttl=64 time=6.15 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=39 ttl=64 time=5.79 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=40 ttl=64 time=3.61 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=41 ttl=64 time=3.64 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=42 ttl=64 time=3.12 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=43 ttl=64 time=108 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=44 ttl=64 time=5.04 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=45 ttl=64 time=4.10 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=46 ttl=64 time=4.15 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=47 ttl=64 time=3.63 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=48 ttl=64 time=3.88 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=49 ttl=64 time=4.95 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=50 ttl=64 time=5.34 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=51 ttl=64 time=112 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=52 ttl=64 time=3.20 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=53 ttl=64 time=107 ms
64 bytes from router01.sandy (fd6e:2bca:e310::1): icmp_seq=54 ttl=64 time=3.50 ms

MTR sees packet loss intermittently here and there, but no small amount (6% in this case)

 1. router01.sandy                                                                                                                                                       6.0%   233    3.0   5.7   1.4 112.4  15.8

The wireless interface does log excessive retries and invalid misc- i'm not sure how normal this is:

wlp4s0    IEEE 802.11  ESSID:"Wifi N"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 20:05:B6:FF:BB:76   
          Bit Rate=130 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=52/70  Signal level=-58 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:5  Invalid misc:221   Missed beacon:0

[dylan@thinkarch ~]$

The network interface doesn't show any errors/dropped/missed/etc

[dylan@thinkarch ~]$ ip stats show dev wlp4s0 
3: wlp4s0: group offload subgroup hw_stats_info
    l3_stats off used off
3: wlp4s0: group xstats_slave subgroup bond suite 802.3ad
3: wlp4s0: group xstats_slave subgroup bridge suite vlan
3: wlp4s0: group xstats_slave subgroup bridge suite mcast
3: wlp4s0: group xstats_slave subgroup bridge suite stp
3: wlp4s0: group xstats subgroup bond suite 802.3ad
3: wlp4s0: group xstats subgroup bridge suite vlan
3: wlp4s0: group xstats subgroup bridge suite mcast
3: wlp4s0: group xstats subgroup bridge suite stp
3: wlp4s0: group afstats subgroup mpls
3: wlp4s0: group offload subgroup l3_stats off used off
3: wlp4s0: group offload subgroup cpu_hit

3: wlp4s0: group link
    RX:  bytes packets errors dropped  missed   mcast           
     558409301  501642      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
      30328152  204899      0       0       0       0 
[dylan@thinkarch ~]$

It appears this is userspace / iwconfig related, and not driver related, as with iwconfig power off, and the driver parameters as follows, I no longer have the problems. I did try power_level=5 as well as power_level=1 and the shown power_level=0. All seemed to work just fine.

[dylan@thinkarch module]$ head iwlwifi/parameters/power_save iwlwifi/parameters/power_level iwlmvm/parameters/power_scheme && sudo iwconfig wlp4s0 | grep Management
==> iwlwifi/parameters/power_save <==
Y

==> iwlwifi/parameters/power_level <==
0

==> iwlmvm/parameters/power_scheme <==
2
          Power Management:off
[dylan@thinkarch module]$

seth · 2025-11-18 08:22:02

Ftr, you're not enabling powersaving yourself?
https://bbs.archlinux.org/viewtopic.php … 2#p2273282

We need to figure who and what does that (and how)

thenextdon13 · 2025-11-19 06:24:13

Correct, although maybe I set up some powersaving program when I set this box up. I don't remember.

I browsed through https://wiki.archlinux.org/title/Power_management and see i have tlp installed but it apparently shuts itself down after boot? As well as have upower installed and running
however
I see nothing in the upower config file that is related to wireless network cards, and a look through upower -d had nothing related to wireless or network cards- and tlp man page makes mention of wifi but only looks to be associated with disabling or enabling wifi, not setting power save mode.

[dylan@thinkarch ~]$ sudo systemctl status upower.service 
● upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: disabled)
     Active: active (running) since Sun 2025-11-16 10:11:25 PST; 2 days ago
 Invocation: eff7c0ea7b5b47cab507dcb614f69791
       Docs: man:upowerd(8)
   Main PID: 1159 (upowerd)
      Tasks: 4 (limit: 9204)
     Memory: 4.6M (peak: 5.6M)
        CPU: 21.948s
     CGroup: /system.slice/upower.service
             └─1159 /usr/lib/upowerd

Nov 16 10:11:25 thinkarch systemd[1]: Starting Daemon for power management...
Nov 16 10:11:25 thinkarch systemd[1]: Started Daemon for power management.
Nov 18 21:49:31 thinkarch upowerd[1159]: Conflicting charge/discharge state between batteries!
[dylan@thinkarch ~]$ sudo systemctl status tlp.service 
● tlp.service - TLP system startup/shutdown
     Loaded: loaded (/usr/lib/systemd/system/tlp.service; enabled; preset: disabled)
     Active: active (exited) since Sun 2025-11-16 10:11:15 PST; 2 days ago
 Invocation: ee7d1e18e53043ed914f38d0da65943d
       Docs: https://linrunner.de/tlp
    Process: 609 ExecStart=/usr/bin/tlp init start (code=exited, status=0/SUCCESS)
   Main PID: 609 (code=exited, status=0/SUCCESS)
   Mem peak: 6.3M
        CPU: 377ms

Nov 16 10:11:15 thinkarch systemd[1]: Starting TLP system startup/shutdown...
Nov 16 10:11:15 thinkarch tlp[609]: Applying power save settings...done.
Nov 16 10:11:15 thinkarch tlp[609]: Setting battery charge thresholds...done.
Nov 16 10:11:15 thinkarch systemd[1]: Finished TLP system startup/shutdown.
[dylan@thinkarch ~]$ sudo upower -d
Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               SANYO
  model:                00HW022
  serial:               731
  power supply:         yes
  updated:              Tue 18 Nov 2025 10:01:38 PM PST (10 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               pending-charge
    warning-level:       none
    energy:              0.82 Wh
    energy-empty:        0 Wh
    energy-full:         15.7 Wh
    energy-full-design:  23.51 Wh
    voltage-min-design:  11.25 V
    capacity-level:      Normal
    energy-rate:         0 W
    voltage:             11.165 V
    charge-cycles:       N/A
    percentage:          5%
    capacity:            66.7801%
    technology:          lithium-polymer
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-supported:    yes
    icon-name:          'battery-caution-charging-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          BAT1
  vendor:               SANYO
  model:                01AV405
  serial:               1632
  power supply:         yes
  updated:              Tue 18 Nov 2025 10:01:38 PM PST (10 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              7.79 Wh
    energy-empty:        0 Wh
    energy-full:         9.53 Wh
    energy-full-design:  26.33 Wh
    voltage-min-design:  11.4 V
    capacity-level:      Normal
    energy-rate:         5.196 W
    voltage:             11.272 V
    charge-cycles:       N/A
    time to empty:       1.5 hours
    percentage:          82%
    capacity:            36.1945%
    technology:          lithium-ion
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-supported:    yes
    icon-name:          'battery-full-symbolic'
  History (charge):
    1763532068	82.000	discharging
    1763532008	83.000	discharging
  History (rate):
    1763532098	5.196	discharging
    1763532068	5.235	discharging
    1763532038	5.185	discharging
    1763532008	4.565	discharging

Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          AC
  power supply:         yes
  updated:              Tue 18 Nov 2025 09:58:49 PM PST (179 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    warning-level:       none
    online:              no
    icon-name:          'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         yes
  updated:              Tue 18 Nov 2025 10:01:38 PM PST (10 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             yes
    state:               discharging
    warning-level:       none
    energy:              8.61 Wh
    energy-full:         25.23 Wh
    energy-rate:         5.196 W
    charge-cycles:       N/A
    time to empty:       1.7 hours
    percentage:          34.126%
    icon-name:          'battery-good-symbolic'

Daemon:
  daemon-version:  1.90.10
  on-battery:      yes
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: PowerOff
[dylan@thinkarch ~]$

TLP Man page
https://man.archlinux.org/man/tlp.8.en
and associated wifi command
https://man.archlinux.org/man/wifi.1.en

The iwconfig power save DOES change state whenever i plug/unplug the laptop- so there has to be something changing it!

It is not set in modprobe.d, udev rules, or NetworkManager config

[dylan@thinkarch ~]$ ls -l /etc/modprobe.d/
total 0
[dylan@thinkarch ~]$ ls -l /etc/udev/rules.d/
total 0
[dylan@thinkarch ~]$ ls -l /etc/NetworkManager/conf.d/
total 0
[dylan@thinkarch ~]$

And dmesg -w / journalctl -f don't provide any reliably repeated while plugging/unplugging, however I occasionally am getting messages about txrate changes from wpa_supplicant and battery charge state conflicts:

Nov 18 22:11:28 thinkarch wpa_supplicant[595]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-56 noise=9999 txrate=144400
Nov 18 22:12:14 thinkarch upowerd[1159]: Conflicting charge/discharge state between batteries!
Nov 18 22:12:16 thinkarch wpa_supplicant[595]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-61 noise=9999 txrate=130000
Nov 18 22:13:04 thinkarch wpa_supplicant[595]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-69 noise=9999 txrate=86700
Nov 18 22:14:01 thinkarch upowerd[1159]: Conflicting charge/discharge state between batteries!
Nov 18 22:14:04 thinkarch wpa_supplicant[595]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-62 noise=9999 txrate=115600

I'd love any suggestion on how to figure out dafq is changing the powersave mode on and off when plugging/unplugging!
thank you!

seth · 2025-11-19 15:41:03

I'd love any suggestion on how to figure out dafq is changing the powersave mode on and off when plugging/unplugging!

Disable tlp and upowerd and see whether this still happens
Udev rules also come in /usr/lib/udev (actually most will, /etc is for local rules)

thenextdon13 · 2025-11-20 04:45:02

There are a lot of rules in /usr/lib/udev as you point out, looking back at the thread you referenced with iwlwifi crashing, i tried looking for power_save and found nothing

[dylan@thinkarch udev]$ pwd
/usr/lib/udev
[dylan@thinkarch udev]$ ls -l rules.d/ |wc -l
90
[dylan@thinkarch udev]$ grep -i "power_save" * -r
[dylan@thinkarch udev]$

Looks like it isn't upower or tlp (this was after manually stopping the services, plugging in laptop and unplugging it again from power source)

[dylan@thinkarch udev]$ sudo systemctl status upower tlp | grep -e Loaded -e Active
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: disabled)
     Active: inactive (dead)
     Loaded: loaded (/usr/lib/systemd/system/tlp.service; disabled; preset: disabled)
     Active: inactive (dead)
[dylan@thinkarch udev]$ while $BLAH; do iwconfig wlp4s0 | grep -i Management; sleep 1; done
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:on
          Power Management:on
^C
[dylan@thinkarch udev]$

Nothing in /etc seems to reference iwconfig or power_save

[dylan@thinkarch etc]$ pwd && sudo grep -i -e power_save -e iwconfig * -r
/etc
tlp.conf:#SOUND_POWER_SAVE_ON_AC=1
tlp.conf:#SOUND_POWER_SAVE_ON_BAT=1
tlp.conf:# Note: effective only when SOUND_POWER_SAVE_ON_AC/BAT is activated.
tlp.conf:#SOUND_POWER_SAVE_CONTROLLER=Y
[dylan@thinkarch etc]$

Disabled the upower.service and tlp.service, going to do a reboot and i'll note if anything has changed. I don't have a good way to save this text until then....

Whoa, i have something really weird going on. upowerd is somehow started even when its not enabled?
Let me double check this.

[dylan@thinkarch /]$ sudo systemctl status upower
● upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: disabled)
     Active: active (running) since Wed 2025-11-19 20:54:00 PST; 10min ago
 Invocation: a5e3e0d2d3bf4cc78a2e49c56a18fe7a
       Docs: man:upowerd(8)
   Main PID: 1019 (upowerd)
      Tasks: 4 (limit: 9204)
     Memory: 4.3M (peak: 5.2M)
        CPU: 596ms
     CGroup: /system.slice/upower.service
             └─1019 /usr/lib/upowerd

Nov 19 20:54:00 thinkarch systemd[1]: Starting Daemon for power management...
Nov 19 20:54:00 thinkarch systemd[1]: Started Daemon for power management.
[dylan@thinkarch /]$ sudo find /etc/systemd -iname "*upower*"
[dylan@thinkarch /]$ sudo systemctl enable upower.service
Created symlink '/etc/systemd/system/graphical.target.wants/upower.service' → '/usr/lib/systemd/system/upower.service'.
[dylan@thinkarch /]$ sudo find /etc/systemd -iname "*upower*"
/etc/systemd/system/graphical.target.wants/upower.service
[dylan@thinkarch /]$ sudo systemctl disable upower.service
Removed '/etc/systemd/system/graphical.target.wants/upower.service'.
[dylan@thinkarch /]$ sudo find /etc/systemd -iname "*upower*"
[dylan@thinkarch /]$

I'll do another reboot now that i'm 100% sure upower isn't in enabled in /etc/systemd via simlink

Very strange.

[dylan@thinkarch ~]$ sudo systemctl status upower
[sudo] password for dylan: 
● upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: disabled)
     Active: active (running) since Wed 2025-11-19 21:10:34 PST; 21s ago
 Invocation: e2118a9cf9f045b4804aee68c68eb1a5
       Docs: man:upowerd(8)
   Main PID: 1023 (upowerd)
      Tasks: 4 (limit: 9204)
     Memory: 4.5M (peak: 5.3M)
        CPU: 198ms
     CGroup: /system.slice/upower.service
             └─1023 /usr/lib/upowerd

Nov 19 21:10:33 thinkarch systemd[1]: Starting Daemon for power management...
Nov 19 21:10:34 thinkarch systemd[1]: Started Daemon for power management.
[dylan@thinkarch ~]$ uptime
 21:11:32 up 2 min,  1 user,  load average: 0.76, 0.46, 0.18
[dylan@thinkarch ~]$ sudo find /etc/systemd -iname "*upower*"
[dylan@thinkarch ~]$

I don't think this is what is causing iwconfig power change of state, as with the process stopped it still has the same change of state with plugging/unplugging...

[dylan@thinkarch ~]$ sudo kill 1023
[dylan@thinkarch ~]$ while $BLAH; do iwconfig wlp4s0 | grep -i Management; sleep 1; done
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:on
          Power Management:on
^C
[dylan@thinkarch ~]$ sudo systemctl status upower | grep -A 1 CGroup
[dylan@thinkarch ~]$

Did another reboot to check parent process to upowerd and it appears to be init/systemd

[dylan@thinkarch ~]$ sudo systemctl status upower | grep -A 1 CGroup
     CGroup: /system.slice/upower.service
             └─999 /usr/lib/upowerd
[dylan@thinkarch ~]$ ps -o ppid= -p 999
      1
[dylan@thinkarch ~]$ 
[dylan@thinkarch ~]$ ps aux | head -3
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.6  0.1  23156 13492 ?        Ss   21:17   0:01 /usr/lib/systemd/systemd --switched-root --system --deserialize=52
root           2  0.0  0.0      0     0 ?        S    21:17   0:00 [kthreadd]
[dylan@thinkarch ~]$

I don't think upowerd is what is causing my iwconfig power to change state, as it still changes with the PID killed for upowerd killed- but it seems like figuring out why/how upowerd is getting started would be a first step

Thank you again for your help/insight.

Last edited by thenextdon13 (2025-11-20 05:29:38)

seth · 2025-11-20 15:10:03

Anything could start the service "manuall" - try to "systemctl mask upower.service" it.
If it still starts it might be in the initramfs, you'd have to regenerate that?

If nuking upowerd doesn't prevent the state change, test the situation on the rescue.target and multi-user.target (2nd link below) so we'll at least know on what layer this happens.

thenextdon13 · 2025-11-21 06:07:18

Well, masking upower did it with respect to upower running..
but something is still handling power management events for the card, changing its iwconfig power state with plugging unplugging.

[dylan@thinkarch ~]$ sudo systemctl status upower
[sudo] password for dylan: 
○ upower.service
     Loaded: masked (Reason: Unit upower.service is masked.)
     Active: inactive (dead)
[dylan@thinkarch ~]$ while $BLAH; do iwconfig wlp4s0 | grep -i Management; sleep 1; done
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:on
          Power Management:off
          Power Management:off
          Power Management:off
          Power Management:on
^C
[dylan@thinkarch ~]$ ps aux | grep -i upower
dylan       2624  0.0  0.0   6620  4148 pts/0    S+   22:03   0:00 grep -i upower
[dylan@thinkarch ~]$

I think i need to look into the iwconfig code to understand what/how it enables power managment, since it doesn't change the driver parameters, i believe.

I think i need to look intot

seth · 2025-11-21 08:01:43

nb. that iwconfig is probably considered to be deprecated anyway, https://archlinux.org/packages/core/x86_64/iw/ (that's however not the cause of your problem)
=> https://git.kernel.org/pub/scm/linux/ke … /tree/ps.c
https://elixir.bootlin.com/linux/v6.17. … R_PS_STATE

Natirolan · 2025-11-21 11:12:40

I’ve seen 8260 cards where userspace like iwd or NetworkManager re-enables power saving regardless of module settings. Testing in multi-user.target is the quickest way to isolate it.

thenextdon13 · 2025-11-22 03:23:39

seth wrote:

Anything could start the service "manuall" - try to "systemctl mask upower.service" it.
If it still starts it might be in the initramfs, you'd have to regenerate that?
If nuking upowerd doesn't prevent the state change, test the situation on the rescue.target and multi-user.target (2nd link below) so we'll at least know on what layer this happens.

Okay, i'm not sure if ya'll will believe me.. but.. as per @seth and @Natirolan's suggestions i dropped to multi-user (with no gui), and to rescue targets, and still have change of powersave state reported by iwconfig with the plugging/unplugging of the laptop.

Good to learn about getting into the rescue target (vs olden days of just a '1' for runlevel one at the end of the kernel command line)
Also, found out I didn't have a root passwd set / account was locked and learned about passwd -l to lock- or setting a passwd to unlock -

So;
what on earth would still change state in rescue.target?

Note; i did not check state of upower or tlp while there... maybe i'll go do that now..

Update: tlp is not running (no big surprise) nor is upower- and upower still shows up as masked.

Interesting note- even though AC is plugged in, during boot powersave is enabled until i unplug, then plug back in again.
Copy on iwconfig being deprecated and iw the new path. Thank you for that (and the help of course)

Last edited by thenextdon13 (2025-11-22 03:35:34)

seth · 2025-11-22 09:11:19

Firmware? Kernel module? (some wmi / platform specific module? Check "lsmod")
You could use https://wiki.archlinux.org/title/Acpid to reset this

Arch Linux

#1 2025-11-17 05:36:59

iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#2 2025-11-18 08:22:02

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#3 2025-11-19 06:24:13

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#4 2025-11-19 15:41:03

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#5 2025-11-20 04:45:02

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#6 2025-11-20 15:10:03

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#7 2025-11-21 06:07:18

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#8 2025-11-21 08:01:43

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#9 2025-11-21 11:12:40

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#10 2025-11-22 03:23:39

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

#11 2025-11-22 09:11:19

Re: iwlwifi - silent packet loss iwlwifi 8260 w/ iwconfig powersave on

Board footer