Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
igt@device_reset@unbind-reset-rebind - incomplete - *ERROR* audio power refcount 1 after unbind
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: HSW BDW: igt@device_reset@unbind-reset-rebind - incomplete - *ERROR* audio power refcount 1 after unbind
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-hsw-4770r", "fi-bdw-5557u", "shard-hsw2", "fi-hsw-4200u", "fi-hsw-peppy", "fi-bdw-gvtdvm", "shard-hsw8", "shard-hsw4", "shard-hsw6", "shard-hsw3", "fi-hsw-4770", "shard-hsw7", "shard-hsw", "shard-hsw5", "shard-hsw1", "fi-bdw-samus"] OR machine_tag IS IN ["HSW", "BDW"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@device_reset@unbind-reset-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["incomplete"])) AND dmesg ~= '\*ERROR\* audio power refcount 1 after unbind'
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: HSW BDW: igt@device_reset@unbind-reset-rebind - incomplete - *ERROR* audio power refcount 1 after unbind
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-hsw-4770r", "fi-bdw-5557u", "shard-hsw2", "fi-hsw-4200u", "fi-hsw-peppy", "fi-bdw-gvtdvm", "shard-hsw8", "shard-hsw4", "shard-hsw6", "shard-hsw3", "fi-hsw-4770", "shard-hsw7", "shard-hsw", "shard-hsw5", "shard-hsw1", "fi-bdw-samus"] OR machine_tag IS IN ["HSW", "BDW"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@device_reset@unbind-reset-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["incomplete"])) AND dmesg ~= '\*ERROR\* audio power refcount 1 after unbind'
Also, the same issue is now triggered by igt@core_hotunplug@bind - #2464 (closed) will become a duplicate of this one as soon as the filter is updated.
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: All machines: igt@core_hotunplug@unbind-rebind - warn - Warning on condition IS_HASWELL(devid) || IS_BROADWELL(devid), WARNING: Manually enabling audio PM to work around a kernel WARN
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@core_hotunplug@unbind-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["warn"])) AND stderr ~= 'Warning on condition IS_HASWELL\(devid\) \|\| IS_BROADWELL\(devid\).*\n.*WARNING: Manually enabling audio PM to work around a kernel WARN'
The CI Bug Log issue associated to this bug has been updated by Lakshmi Vudum.
New filters associated
HSW: igt@device_reset@unbind-reset-rebind - warn - Warning on condition (bool) IS_HASWELL(devid) || IS_BROADWELL(devid) in function unbind_reset_rebind.*, Manually enabling audio PM to work around a kernel WARN
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: All machines: igt@core_hotunplug@unbind-rebind|igt@core_hotunplug@hotunbind-rebind - warn - Warning on condition IS_HASWELL(devid) || IS_BROADWELL(devid), WARNING: Manually enabling audio PM to work around a kernel WARN
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@core_hotunplug@hotunbind-rebind", "igt@core_hotunplug@unbind-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["warn"])) AND stderr ~= 'Warning on condition IS_HASWELL\(devid\) \|\| IS_BROADWELL\(devid\).*\n.*WARNING: Manually enabling audio PM to work around a kernel WARN'
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: HSW BDW: igt@device_reset@unbind-reset-rebind - warn - Warning on condition (bool) IS_HASWELL(devid) || IS_BROADWELL(devid) in function unbind_reset_rebind.*, Manually enabling audio PM to work around a kernel WARN
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-hsw-4770r", "fi-bdw-5557u", "shard-hsw2", "fi-hsw-4200u", "fi-hsw-peppy", "fi-bdw-gvtdvm", "shard-hsw8", "shard-hsw4", "shard-hsw6", "shard-hsw3", "fi-hsw-4770", "shard-hsw7", "shard-hsw", "shard-hsw5", "shard-hsw1", "fi-bdw-samus"] OR machine_tag IS IN ["HSW", "BDW"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@device_reset@unbind-reset-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["warn"])) AND stderr ~= 'Warning on condition \(bool\) IS_HASWELL\(devid\) \|\| IS_BROADWELL\(devid\) in function unbind_reset_rebind.*\n.*Manually enabling audio PM to work around a kernel WARN'
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND (machine_name IS IN ["fi-icl-u2", "shard-hsw6", "shard-iclb", "shard-hsw3", "shard-iclb1", "shard-iclb2", "shard-hsw7", "shard-iclb3", "shard-iclb4", "fi-icl-u3", "shard-iclb5", "fi-icl-y", "shard-hsw5", "shard-iclb6", "fi-icl-guc", "fi-icl-dsi", "re-icl-u", "shard-iclb7", "shard-iclb8", "fi-hsw-4770r", "fi-icl-u4", "shard-hsw8", "shard-hsw4", "fi-hsw-4770", "shard-hsw1", "fi-icl-1065g7", "shard-hsw2", "pig-icl-1065g7", "shard-hsw", "fi-hsw-4200u", "fi-hsw-peppy", "fi-icl-u"] OR machine_tag IS IN ["ICL", "HSW"]) AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@runner@aborted"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["fail"])) AND stdout ~= 'Previous test: (device_reset \(unbind-reset-rebind\)|core_hotunplug \(unbind-rebind\))'
A CI Bug Log filter associated to this bug has been updated by Lakshmi Vudum:
Description: All machines: igt@core_hotunplug@unbind-rebind|igt@core_hotunplug@hotunbind-rebind|igt@core_hotunplug@.*lateclose - warn - Warning on condition IS_HASWELL(devid) || IS_BROADWELL(devid), WARNING: Manually enabling audio PM to work around a kernel WARN
Equivalent query: runconfig_tag IS IN ["DRM-TIP"] AND ((testsuite_name = "IGT" AND test_name IS IN ["igt@core_hotunplug@hotunbind-rebind", "igt@core_hotunplug@hotrebind-lateclose", "igt@core_hotunplug@unbind-rebind"])) AND ((testsuite_name = "IGT" AND status_name IS IN ["warn"])) AND stderr ~= 'Warning on condition IS_HASWELL\(devid\) \|\| IS_BROADWELL\(devid\).*\n.*WARNING: Manually enabling audio PM to work around a kernel WARN'
@tejasree why closed? Why no single word of justification? How has the issue been fixed? Can we remove the workaround from IGT? Or is that kernel warning an expected behaviour on HSW/BDW? Is the issue going to be addressed by Level 0 itself? Or, is Level 0, with its requirement for a functional driver unbind-rebind, never going to be used on affected platforms?
Those new reports look like a new, completely different issue for me. Why has the new filter been associated with this bug? How is it related to the original issue reported here, i.e., the "ERROR audio power refcount 1 after unbind" dmesg signature, or the "Manually enabling audio PM to work around a kernel WARN" stderr signature of the workaround temporarily applied?
This problem is due to a feature of the current drm-audio-component interface. At unbind, i915 display driver goes ahead and unregisters the audio component. There is no check for the power reference and there is no interface for audio driver to let i915 know that it's in the middle of a use-case and cannot be unbind. Example traces:
The unbind() call is a void call with no way for audio driver to return -EBUSY. The intel_audio_deinit() call in i915 is also a void call, with no way to abort the deinit from display driver code.
So if audio happens to be active, you'll get the "ERROR audio power refcount 1 after unbind" from this test case. It then depends on system state (whether audio is used), whether runtime pm is enabled in the audio driver and how it's configured (the patch that @ickle noted earlier in this bug change this aspect and trigger the warning in new cases), or hardware (platforms like hsw require audio driver to keep a power-ref all the time so you'll hit this warning more often on these platforms).
This unbind i915 test case has some workarounds (for e.g. hsw and a couple of other platforms), but fundamentally this is a design gap and I'm not really sure how to tackle this. It would seem, the unbind should be blocked if audio is using i915, but a very good question how to exactly make this happen.
@kaivehmanenintel what happens if you unbind an audio driver from an audio device which is in use? Or if you unplug a USB audio adapter which is in use? Similar things should happen if an audio component is unregistered, I believe.
@jkrzyszt Both these cases work in audio, so this is really specific to the HDA-i915 implementation of drm-audio-component. With USB audio, the bus is by its nature hot-pluggable and this is a common use-case. Unbinding the HDA driver is also covered as there is infra to stop an ALSA card (and recover by probing the card). In both cases, the whole ALSA card is removed.
With i915, i915 is one of the HDA codecs in the system and the same ALSA card (e.g. snd-hda-intel is one driver that can be used) is handling multiple codecs. We have no support for "hotplug" of individual codecs in the system. On a typical product, the codecs are soldered on the motherboard (or within SoC).
We can gracefully handle the case that drm-audio-component is removed and stop the playback, but we have no infra to reestablish communication once i915 is rebound. Currently the supported sequence really is to unbind HDA driver first and then unbind i915.
In context of SOF (the DSP enabled HDA driver implementation), we have talked about making the HDMI/DP a separate ALSA card. This would allow to implement this case more easily, but this a rather major change to the DSP architecture as we'd have to split the DSP topologies for different use-cases (now they are in single DSP topology description). And this won't help the large set of hardware using the non-DSP HDA driver.
So we kind of have two approaches:
have ability for audio side to "veto" the unbind(), or
implement true per-codec hotplug/removal to all HDA drivers (snd-hda-intel, SOF, SST, ..)