RB8 Specific failure: Audio Record Freeze on RB8

[bhargav0610]

lava job: https://lava.infra.foundries.io/scheduler/job/142454

• cd Runner/suites/Multimedia/Audio/AudioRecord/
• ./run.sh --backend '' --source mic --config-name record_config1 --config-filter '' --record-seconds 5s --loops 1 --timeout 0 --strict 0 --res-suffix ''
  [INFO] 1970-01-01 00:04:05 - Base build detected (no audioreach modules), skipping overlay setup
  [INFO] 1970-01-01 00:04:05 - ---------------- Starting AudioRecord ----------------
  [INFO] 1970-01-01 00:04:06 - Platform Details: machine='Qualcomm Technologies, Inc. Lemans EVK' target='LeMans' kernel='6.19.0-rc8-00570-g227f6a51c3b1' arch='aarch64'
  [INFO] 1970-01-01 00:04:06 - Args: backend=auto source=mic loops=1 durations='' record_seconds=5s timeout=0 strict=0 dmesg=1
  [INFO] 1970-01-01 00:04:06 - Backend fallback chain: pipewire pulseaudio alsa
  [INFO] 1970-01-01 00:04:06 - Using backend: pipewire

Thanks,
Bhargav

[lumag]

Also qualcomm-linux/kernel#233

[smuppand]

This freeze is almost certainly a “no hard timeout” hang inside PipeWire probing or pw-record, not an audio failure per-se.

Using backend: pipewire
and you never see “Using config discovery mode”. That means the script is hanging before it even enters the test loop — most likely inside one of these unbounded calls:
pw_default_mic / pw_default_null_source (usually runs wpctl …)
pw_source_label_safe / wpctl set-default …
or later pw-record if your timeout wrapper isn’t actually enforcing a timeout for tokens like 5s

On RB8, it’s very plausible wpctl (or a PipeWire client call) blocks forever due to a PipeWire/WirePlumber deadlock, and because there’s no guard timeout around those “probe” functions, the entire test blocks until lava-test-shell times out (14400s).

[smuppand]

I tested it with my branch and the changes, and it is passing now. https://lava.infra.foundries.io/scheduler/job/143606

[lumag]

This freeze is almost certainly a “no hard timeout” hang inside PipeWire probing or pw-record, not an audio failure per-se.

Using backend: pipewire and you never see “Using config discovery mode”. That means the script is hanging before it even enters the test loop — most likely inside one of these unbounded calls: pw_default_mic / pw_default_null_source (usually runs wpctl …) pw_source_label_safe / wpctl set-default … or later pw-record if your timeout wrapper isn’t actually enforcing a timeout for tokens like 5s

On RB8, it’s very plausible wpctl (or a PipeWire client call) blocks forever due to a PipeWire/WirePlumber deadlock, and because there’s no guard timeout around those “probe” functions, the entire test blocks until lava-test-shell times out (14400s).

Deadlock where? In the userspace? Which process is blocked? What is the backtrace?

[smuppand]

This freeze is almost certainly a “no hard timeout” hang inside PipeWire probing or pw-record, not an audio failure per-se.
Using backend: pipewire and you never see “Using config discovery mode”. That means the script is hanging before it even enters the test loop — most likely inside one of these unbounded calls: pw_default_mic / pw_default_null_source (usually runs wpctl …) pw_source_label_safe / wpctl set-default … or later pw-record if your timeout wrapper isn’t actually enforcing a timeout for tokens like 5s
On RB8, it’s very plausible wpctl (or a PipeWire client call) blocks forever due to a PipeWire/WirePlumber deadlock, and because there’s no guard timeout around those “probe” functions, the entire test blocks until lava-test-shell times out (14400s).

Deadlock where? In the userspace? Which process is blocked? What is the backtrace?

Yes, the deadlock is with userspace process wpctl status. I haven't been able to reproduce the issue in my local setup. I reviewed the logs from the lava job. We can monitor the process and collect traces when the issue occurs again.