Still Broken: "After lid-close reopening; wifi hangs; fixed by netif restart" in 15-CURRENT

Folks,

Happy New Year! Year 2 of FreeBSD as home machine :)

Last year I reported that after lid close I had to do service netif restart to restore service. T-Daemon identified a bug predicting that behavior and cracauer@ confirmed it was impacting more than me. T-Daemon also suggested that it was fixed in (then) 15.0-CURRENT and my hope was that this would magically go away once I upgraded. Well, I'm upgraded to 15.0-RELEASE, and it's still with me.

Based on the bug tracking references (like the library of Name of the Rose...), I came to this note https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286059 that suggests that the fix is believed to be in main.

So I'm looking for "I"m still broken too" signals OR "You dolt, you've misread the bug tracker; it wasn't fixed" or "You dolt, it was fixed and you forgot to run magic-command hardware-reify - p!" Any takers?
 
If the bug fix was commited to 15-CURRENT then, it's included with 15.0-RELEASE.
 
You can see the commit history:

The PR you referenced is the commit done on 2025-05-28.

Could still be a bunch of bugs in it though, after stable/15 got branched off and main moved to 16-CURRENT there's been quite a lot more work done on that specific driver.


If you still have problems with 15.0-RELEASE you should probably open a PR for it. Maybe some of the fixes from main can be MFC'ed to stable/15 (which will then end up in 15.1-RELEASE).
 
You can see the commit history:

The PR you referenced is the commit done on 2025-05-28.

Could still be a bunch of bugs in it though, after stable/15 got branched off and main moved to 16-CURRENT there's been quite a lot more work done on that specific driver.


If you still have problems with 15.0-RELEASE you should probably open a PR for it. Maybe some of the fixes from main can be MFC'ed to stable/15 (which will then end up in 15.1-RELEASE).
Thanks for the tips. I've opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292249 accordingly.
 
I'm having the exact same issue as described.

The workaround that is linked within those bug reports does solve the issue for me, though I'm guessing it is not the long-term solution.

Specifically:

to /etc/rc.suspend add:
Code:
/usr/sbin/service netif stop wlan0

and to /etc/rc.resume add:
Code:
/usr/sbin/service netif start wlan0
 
The workaround that is linked within those bug reports does solve the issue for me, though I'm guessing it is not the long-term solution.
Yep, same experience.
to /etc/rc.suspend add:
Code:
/usr/sbin/service netif stop wlan0

and to /etc/rc.resume add:
Code:
/usr/sbin/service netif start wlan0

What's odd is that while the scripts run (i can run them manually and they shut down the system)....I still have to run netif restart.

Where are you putting these calls b/c this doesn't work for me:

sh:
 62 for _rc_elem in $files; do
 63   debug "run_rc_script $_rc_elem suspend"
 64   run_rc_script $_rc_elem suspend
 65 done
 66
 67 /usr/bin/logger -t Performing network card stoppage per BUG 263632
 68 /usr/sbin/service netif stop wlan0
 69
 70 /usr/bin/logger -t $subsystem suspend at `/bin/date +'%Y%m%d %H:%M:%S'`
 71 /bin/sync && /bin/sync && /bin/sync
 72 /bin/sleep 3
 73
 74 /bin/rm -f /var/run/rc.suspend.pid
 75 if [ $subsystem = "apm" ]; then

And

sh:
 63 files=`rcorder ${rcorder_opts} /etc/rc.d/* ${local_rc} 2>/dev/null`
 64
 65 for _rc_elem in $files; do
 66   debug "run_rc_script $_rc_elem resume"
 67   run_rc_script $_rc_elem resume
 68 done
 69
 70 # Hack for wifi card
 71 /usr/bin/logger -t Performing network card restart per BUG 263632
 72 /usr/sbin/service netif start wlan0
 
Hi sgharms-

in my rc.suspend, I have one additional line added by desktop-installer above your lines 67/68

Code:
/usr/sbin/automount -fu

and I don't have a line 67 of making a log entry

In my resume script, I have the start in the same exact place, but again, no logger entry.

Hope that helps!
 
My Framework 12 with AX211 work reliably with suspend/resume with the iwlwifi driver only. But WiFi need 30s before working after resuming. My /etc/rc.suspend /etc/rc.resume are unmodified.
 
What does lid close for you? Lock, suspend or hibernate?

With my Thinkpad x390 15.0.2 XFCE4 hibernate does not work, resuming is like rebooting, suspend works, but I have to restart networking.
Yep, it suspends. And yep, i've got `doas service netif restart` as a one-key alias. And it sucks.
 
I use such a crutch.
Code:
cat /usr/local/etc/rc.d/resume_iwx
#!/bin/sh

# PROVIDE: resume_iwx

# KEYWORD: resume

# 

# Add this line to /etc/rc.conf.local or /etc/rc.conf to enable this service:

# 

# resume_iwx_enable (bool):    Set to NO by default.

# Set it to YES to enable foo.

. /etc/rc.subr

name=resume_iwx
rcvar=resume_iwx_enable

load_rc_config $name

: ${resume_iwx_enable:="NO"}

command=":"
extra_commands="resume"
resume_cmd="resume_iwx_resume"

resume_iwx_resume() {
\# Run some commands.
service netif restart wlan0
}

run_rc_command "$1"
 
I have tested on 15 STABLE n 16 CURRENT. On hyprland/wayland, after waking up, the screen goes blank n unresponsive. I will have to press the power button to shut it down. out of curiosity, I installed openbox n xorg-minimal, n logged in using startx. I then close the lid to put it to sleep. I was able to wake it up, but had to do doas service netif restart wlan0, to connect to the net.
I then logged out of openbox, n logged in to hyprland. closing the lid n putting it to sleep. when I reopened the lid, i was able to continue on hyprland, tho I still have to do doas service netif restart wlan0 to connect to the net
 
Back
Top