Assigning Simon since he wrote the test, and it should not need to warn about permission issues UNLESS it needed to dump results and couldn't.

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* CHAMELIUM: igt@kms_chamelium@hdmi-audio - warn - Home directory not accessible: Permission denied
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6222/re-icl-u/igt@kms_chamelium@hdmi-audio.html

This is a libasound (ALSA) issue: it also happens when executing `aplay` on the DUT:

    $ sudo aplay -L
    Home directory not accessible: Permission denied
    Home directory not accessible: Permission denied
    […]

Assigning Tomi as Martin suggested.

Does this make any difference?

# sudo -i aplay -L

The error message comes from alsa library. The fist function aplay calls is snd_device_name_hint(). It may produce the error message. I suspect
1. aplay is invoked by user, XXX
2. there is no /home/XXX
3. snd_device_name_hint() complains there is no /home/XXX.

I still skeptical why it accesses home directory for listing PCM devices.

Simon, what are next steps here?

Tomi, do you want me to find which function in alsa library complains and why?

(In reply to Tomi Sarvela from comment #4)
> Does this make any difference?
> 
> # sudo -i aplay -L

Yes, this works. HOME is set to /root in this case I guess.

This is an unimportant ALSA warning. This is an infra issue, not a Chamelium/driver issue.

A CI Bug Log filter associated to this bug has been updated:

{- CHAMELIUM: igt@kms_chamelium@hdmi-audio - warn - Home directory not accessible: Permission denied -}
{+ CHAMELIUM: igt@kms_chamelium@(hdmi|dp)-audio - warn - Home directory not accessible: Permission denied +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_314/fi-icl-u2/igt@kms_chamelium@dp-audio.html

All CI testhosts have user 'testrunner' with valid $HOME /home/testrunner with permissions rwxr-xr-x. Shell is /bin/bash, as default Ubuntu user shell.

Plain sudo (root) can access the testrunner home directory. Does aplay -L do special tricks, like changing UID again?

I can't really see where this error comes from:

Home directory not accessible: Permission denied

(In reply to Tomi Sarvela from comment #11)
> All CI testhosts have user 'testrunner' with valid $HOME /home/testrunner
> with permissions rwxr-xr-x. Shell is /bin/bash, as default Ubuntu user shell.
> 
> Plain sudo (root) can access the testrunner home directory.

See below.

> Does aplay -L do special tricks, like changing UID again?

No.

> I can't really see where this error comes from:
> 
> Home directory not accessible: Permission denied

Hmm. It turns out this comes from pulseaudio. It has calls a check_ours function in src/pulsecore/core-util.c:1450.

Tomi, could you make sure pulseaudio isn't auto-started on the DUTs? This can be done by editing /etc/pulse/client.conf and adding:

    autospawn = no

We have a check that skips the test if pulseaudio is loaded anyway. Maybe this can turn some skips into fail/pass.

testrunner@icl-u2:~$ ps -aux | grep pulse
testrun+  4748  0.0  0.0 278880  6932 ?        Sl   18:06   0:00 /usr/bin/pulseaudio --start --log-target=syslog

Added autospawn = no on fi-icl-u2.

If this fixes any issues, I'll make it farmwide configuration.

A CI Bug Log filter associated to this bug has been updated:

{- CHAMELIUM: igt@kms_chamelium@(hdmi|dp)-audio - warn - Home directory not accessible: Permission denied -}
{+ CHAMELIUM: igt@kms_chamelium@(hdmi|dp)-audio - warn/fail - Home directory not accessible: Permission denied +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_321/fi-skl-6700k2/igt@kms_chamelium@hdmi-audio.html

Seems like autospawn=no doesn't completely disable PulseAudio: Pulse devices still show up in ALSA. This happens because the Pulse ALSA plugin is sitll enabled. It can be disabled like so:
https://wiki.debian.org/PulseAudio#Dynamically_enable.2Fdisable

I've ran these commands on fi-icl-u2:

mkdir /usr/share/alsa/alsa.conf.pulse/
dpkg-divert --divert /usr/share/alsa/alsa.conf.pulse/pulse.conf --rename  /usr/share/alsa/alsa.conf.d/pulse.conf
dpkg-divert --divert /usr/share/alsa/alsa.conf.pulse/99-pulseaudio-default.conf.example  --rename  /usr/share/alsa/alsa.conf.d/99-pulseaudio-default.conf.example
dpkg-divert --divert /usr/share/alsa/alsa.conf.pulse/50-pulseaudio.conf --rename  /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf

The error message doesn't show up anymore when running `sudo aplay -L`.

This method looks unnecessarily complicated.

Is there an simpler method of disabling PulseAudio? Dynamic choice is not really needed, preferred way is to fix settings for good in all DUTs.

It seems like the commands above fixed the warning issues on fi-icl-u2.

(In reply to Tomi Sarvela from comment #16)
> This method looks unnecessarily complicated.
> 
> Is there an simpler method of disabling PulseAudio? Dynamic choice is not
> really needed, preferred way is to fix settings for good in all DUTs.

It doesn't seem like it. PulseAudio is enabled by default by Debian via these configuration files. Simply removing them would not prevent updates from re-installing the files.

`autospawn = no` prevents PulseAudio form starting, but the PulseAudio ALSA modules are still loaded and still print the error message.

I guess you could still `apt-get remove --purge pulseaudio`, if no package depends on it. Need to make sure it doesn't come back with an upgrade or by installing a new dependency. So this solution looks a little fragile to me.

Tomi, any updates on this?

An alternative would be not to bother with this and mark this bug as NOTABUG.

Removed the dpkg-divert from icl-u2 and removed pulseaudio from there. Let's see if it fixes the warning.

`sudo aplay -L` now works without the warning on fi-icl-u2. Can we remove pulseaudio from all machines, Tomi?

PulseAudio has been uninstalled from DUTs connected to CHamelium boards. This fixes the issue. Closing.