I just found out, that it is always the same userspace process causing the fault: rasdaemon.
After disabling it, it seems that the crash and subsequent audio freeze is no longer triggered.

Please try 6.0.3.arch3-1 from the ALA [1].
# pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.0.3.arch3-1-x86_64.pkg.tar.zst

[1] https://wiki.archlinux.org/title/Arch_Linux_Archive#How_to_downgrade_one_package

Investigated a bit more and reported it upstream, seems someone else already reported the problem.

https://linkshortner.net/dyvLZ

Also had this issue on an X570 motherboard with Zen 2 (Ryzen 3xxx desktop) CPU, rasdaemon also implicated.
First noticed Firefox crashing, and even on a new profile still crashes reliably when trying to right-click any tab.
Had issues shutting down -- only SysRq sync was processed and echoed but system never halted and SysRq+B was not respected.

6.0.3.arch3 still had issues, 6.0.2.arch1 is working well.
Even latest 5.15 LTS may have had issues, not certain, but I need to actually use my system now instead of testing again :)

The commits were backported to both 6.0.3 [1] and 5.15.75 [2].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/queue-6.0?id=20d0511e2d90c5d0d554cc00ed6f7225cefe5a2d
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/queue-5.15?id=61b043bba9968212bb27ae28a55fb084bec0dc48

Confirming no issue with linux 6.0.6.arch1 and rasdaemon disabled.
OP opened a bug report upstream[1], thank you!

[1] https://github.com/mchehab/rasdaemon/issues/73

My issues were that the system refused to power off (my primary issue, the same as stated above) and grub-mkconfig hanged during grub-probe, both of which were resolved by disabling rasdaemon.

I've been having the same issues on the 6.0.6-zen1-1-zen and the "vanilla" 6.0.6.arch1-1 kernel (AFAIR).

I am in contact with the responsible linux kernel maintainer, we are currently debugging the root cause.

Possible fix was found and tested successful. Will probably be in upstream kernel soon.

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 199759c73519..4ffcc6e33258 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -937,6 +937,9 @@ void ring_buffer_wake_waiters(struct trace_buffer *buffer, int cpu)
struct ring_buffer_per_cpu *cpu_buffer;
struct rb_irq_work *rbwork;

+ if (!buffer)
+ return;
+
if (cpu == RING_BUFFER_ALL_CPUS) {

/* Wake up individual ones too. One level recursion */
@@ -945,7 +948,14 @@ void ring_buffer_wake_waiters(struct trace_buffer *buffer, int cpu)

rbwork = &buffer->irq_work;
} else {
+ if (WARN_ON_ONCE(!buffer->buffers))
+ return;
+ if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
+ return;
cpu_buffer = buffer->buffers[cpu];
+ /* The CPU buffer may not have been initialized yet */
+ if (!cpu_buffer)
+ return;
rbwork = &cpu_buffer->irq_work;
}

Nice work @ruabmbua. Thanks for reporting it upstream and following through [1]

[1] https://lore.kernel.org/all/20221101191009.1e7378c8%40rorschach.local.home/

6.0.7 lacks the patch unfortunately, to save anyone the time checking,

The fix is queued for 6.0.8 [1].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/queue-6.0/ring-buffer-check-for-null-cpu_buffer-in-ring_buffer_wake_waiters.patch?id=83d0065763ff5ae2be60a854676ded72e614afd1

Confirmed fixed for me with rasdaemon running while on 6.0.8.arch1-1.

Thank you all!