This recent bug might be related: "21419953: Whirlwind: determine source for CRDA regulation" (I don't have access to the bug, use search to find some context).

@1: That doesn't seem to be a recent bug. (I'm also not sure about that bug number; I found a different number with the same title on b/.)

# export COUNTRY=us
# crda 
Failed to set regulatory domain: -22

I wonder if something broke in the kernel?

It's probably related to how the udev rule is setup:

/lib/udev/rules.d/85-regulatory.rules

  KERNEL=="regulatory*", ACTION=="add|change", SUBSYSTEM=="platform", RUN+="/sbin/crda"

The COUNTRY environment is only set on a change event (see net/wireless/reg.c:call_crda), but not on an add event. If you wraps /sbin/crda to dump out the environment, you will see crda complains about missing COUNTRY env only on add events.

The regulatory.rules has't been updated for a long time. The issue is probably there for a long time.

And the example shown in https://wireless.wiki.kernel.org/en/developers/regulatory/crda doesn't trigger crda on an add event either:

# Example file, should be put in /etc/udev/rules.d/regulatory.rules
KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"

@3: On groups.google the date is 15 Feb 2017, it seems the ID corresponds to a different Buganizer instance. From the info on the default Buganizer I agree that this bug is old. Sorry for the noise.

There was a related bug where someone pointed out that our wireless-regdb needs updating, theres a workaround or two in the Intel driver for now. I'll hunt and update details here. 

Thanks for the info. My bet: I noticed this on recent images because udev logs things differently. (Total guess; but I don't see this in syslog on R56 feedback reports.)

Also:

commit f398bd88927a25ae599ce9c8c2a5a6cdad6322ba
Author: Sam Leffler <sleffler@chromium.org>
Date:   Mon Feb 28 14:26:42 2011 -0800

    chromiumos-overlay: add initial WiFi regulatory support
    
    This adds the basic mechanisms for regulatory support.  With
    these changes the crda program is launched by the kernel (via
    udev) to install regulatory rules.  One can manually change
    the regulatory domain using iw reg set.
    
    CRDA changes:
    - trim ebuild and unmask on supported platforms
    - use noverify target to workaround build problem (trying to
      use target binary on build host)
    - install private udev rule to process both add+change events
      (won't be needed once udev is updated)
...

So...we can remove the 'add' I expect :)

There are also a few other cases that crda exits with 234 (-EINVAL), so it's hard to tell which cases it hits. My local test on kevin only hit the add event case:


@@
ACTION=add
USEC_INITIALIZED=2710618
SEQNUM=1069
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
MODALIAS=platform:regulatory
PWD=/
--
COUNTRY environment variable not set.
234
--

@@
ACTION=change
USEC_INITIALIZED=2729516
SEQNUM=1070
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
MODALIAS=platform:regulatory
PWD=/
COUNTRY=00
--
0
--

@@
ACTION=add
USEC_INITIALIZED=6220393
SEQNUM=1511
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
MODALIAS=platform:regulatory
PWD=/
--
COUNTRY environment variable not set.
234
--

@@
ACTION=change
USEC_INITIALIZED=8018080
SEQNUM=1630
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
MODALIAS=platform:regulatory
PWD=/
COUNTRY=US
--
0
--

If you can reproduce the issue on your device, you could try removing "add" from /lib/udev/rules.d/85-regulatory.rules.

A corrupted regulatory db will also cause crda to exit with 234 as well, but your manual run of crda failed like "Failed to set regulatory domain: -22",  which implied that the db was probably ok.

Not sure if you're hitting a different issue, but I guess we can update udev rule: https://chromium-review.googlesource.com/c/456847/

One other note: it seems crda is really only meant to run from a udev rule, so it failed when I ran it manually (e.g., in the OP and in #4) for other reasons.

I think Ben's change is all that's needed here, and the only "regression" is the change in the way udev logged failures. There are other related issues. e.g., this:

https://b.corp.google.com/issues/36226673

It wasn't 100% a new problem, but it was more noticeable because it showed up in syslog.

Similarly, I expect the ALSA errors also captured in the OP are not new errors:

[   12.783510] udevd[2131]: Process '/usr/sbin/alsactl restore 0' failed with exit code 99.



localhost ~ # /usr/sbin/alsactl restore 0
/usr/sbin/alsactl: load_state:1683: Cannot open /var/lib/alsa/asound.state for reading: No such file or directory
Found hardware: "rk3399-gru-soun" "" "" "" ""
Hardware is initialized using a generic method
localhost ~ # echo $?
99

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/07da126eb75850810601eb108bb83a064f2eb858

commit 07da126eb75850810601eb108bb83a064f2eb858
Author: Ben Chan <benchan@chromium.org>
Date: Tue Mar 21 02:30:22 2017

net-wireless/crda: only invoke crda on change events

The regulatory platform device in the Linux kernel emits udev change
events, with a 'COUNTRY' variable set in the environment, to notify CRDA
(/sbin/crda) to update the regulatory domain. CRDA requires 'COUNTRY' to
be set in the environment, or otherwise exits with an error code. As the
'COUNTRY' variable isn't set upon a udev add event of the regulatory
device, we don't need to invoke crda upon an add event.

BUG= chromium:702802 
TEST=Manually verify that there is no more crda error from `dmesg`.

Change-Id: I3e796f5c4927bf354d44cada1aed275176db011d
Reviewed-on: https://chromium-review.googlesource.com/456847
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/07da126eb75850810601eb108bb83a064f2eb858/net-wireless/crda/files/regulatory.rules
[rename] https://crrev.com/07da126eb75850810601eb108bb83a064f2eb858/net-wireless/crda/crda-1.1.1-r6.ebuild

Seeing more errors e.g. https://listnr.corp.google.com/product/208/report/68344548198

which is R60-9592.42.0

@Kirtika: I'd suggest filing a new bug. There are driver/kernel/device-specific reasons that crda might fail. For instance, I've seen early Kevin devices with bad region info programmed to their OTP, and so setting regions can fail there. (Those failures show up like you've seen.)