WiFi_OnOff: improve wait handling for delayed interface creation#482
Conversation
|
Failed job from the pre-merge workflow: https://lava.infra.foundries.io/scheduler/job/243672 Job Without PR: https://lava.infra.foundries.io/scheduler/job/244641 |
smuppand
force-pushed
the
wifi-connectivity
branch
from
4685908 to
7499f9a
Compare
|
@qcom-anilyada and @bhargav0610 I'm noticing a pattern with the device connected to rb4-hyd-01. Please check—every time, the wifi test fails because the interface isn't coming up at all. The same test passes on other RB4 machines. |
|
|
||
| case "$max_wait" in | ||
| ''|*[!0-9]*) | ||
| max_wait=30 |
There was a problem hiding this comment.
Should this be updated to 60 too?
Addressed. I updated the helper default and fallback wait values to 60s so direct callers of wait_for_wifi_interface() behave consistently with WiFi_OnOff/run.sh.
| ;; | ||
| esac | ||
|
|
||
| ;; | ||
| esac | ||
|
|
||
|
|
||
| if command -v udevadm >/dev/null 2>&1; then | ||
| log_info "No WiFi interface yet; triggering net uevents and waiting for udev settle" | ||
| udevadm trigger --subsystem-match=net >/dev/null 2>&1 || true |
There was a problem hiding this comment.
This will re-trigger on all network interfaces, which are already settled.
Perhaps this can be done
udevadm trigger --action=add --subsystem-match=net >/dev/null 2>&1 || true
There was a problem hiding this comment.
This will re-trigger on all network interfaces, which are already settled. Perhaps this can be done
udevadm trigger --action=add --subsystem-match=net >/dev/null 2>&1 || true
Addressed. Updated the trigger to use --action=add with --subsystem-match=net so it is more targeted.
|
|
||
| # Keep stdout reserved for the detected interface name. This helper is | ||
| # commonly used through command substitution, so all diagnostics from the | ||
| # wait loop must go to stderr. The final interface is printed through fd 3, |
There was a problem hiding this comment.
Should the README be also updated to let the user know that fd 3 is in use and they cannot use it.
There was a problem hiding this comment.
Should the README be also updated to let the user know that fd 3 is in use and they cannot use it.
Good point. I removed the fd 3 usage completely, so no README update is needed. The helper now sends diagnostics explicitly to stderr and keeps stdout reserved only for the detected interface name.
In LAVA, WiFi driver modules can be visible before the cfg80211 PHY or wlan netdev has been created. The current wait_for_wifi_interface() helper only polls get_wifi_interface() for 30 seconds, which can fail early on systems where firmware, udev, or netdev creation completes later. Update wait_for_wifi_interface() to trigger net uevents, wait for udev settle when available, keep polling for the configured timeout, and emit periodic wait progress logs. Also increase the WiFi_OnOff default wait window to 60 seconds while preserving the existing WIFI_WAIT_SECS environment override. This keeps the CI policy strict: if the WiFi stack is present but no usable interface appears after retries, the test still fails. The change only reduces false failures caused by asynchronous driver/firmware/netdev initialization timing. Signed-off-by: Srikanth Muppandam <smuppand@qti.qualcomm.com>
smuppand
force-pushed
the
wifi-connectivity
branch
from
7499f9a to
8c0b837
Compare
4 participants
Improve WiFi interface discovery robustness for
WiFi_OnOffby allowing more time for delayed WiFi netdev creation in LAVA/CI environments.Why
WiFi_OnOffcan fail in LAVA even when the WiFi stack is present:wlan*/WiFi interface appears within the current wait windowThis can happen because driver/module visibility, firmware initialization, cfg80211 PHY registration, and netdev creation are asynchronous. In automated CI, the interface may appear later than the current 30-second wait.