Hi, I am on 15.0-CURRENT-6014596899c and i noticed a message in dmesg: # dmesg -a | grep -i invalid sysctl: hw.snd.default_unit=1 at line 15: Invalid argument sysctl: hw.snd.default_unit=1 at line 15: Invalid argument Then I checked sound devices using: # cat /dev/sndstat Installed devices: pcm0: <ATI R6xx (HDMI)> (play) default No devices installed from userspace. I noticed that my other sound devices like front/rear panel jack don't show up there. I doubt latest changes affecting sound may have caused this but not sure. Thanks in advance. # dmesg -a | grep -i hda hdac0: <ATI (0x1637) HDA Controller> mem 0xfcb88000-0xfcb8bfff at device 0.1 on pci8 hdac1: <AMD Raven HDA Controller> mem 0xfcb80000-0xfcb87fff at device 0.6 on pci8 hdacc0: <ATI R6xx HDA CODEC> at cad 0 on hdac0 hdaa0: <ATI R6xx Audio Function Group> at nid 1 on hdacc0 pcm0: <ATI R6xx (HDMI)> at nid 3 on hdaa0 hdac1: Command 0x000f0000 timeout on address 0 hdac1: Command 0x000f0002 timeout on address 0 hdac1: CODEC at address 0 not responding!
# pciconf -lv | grep HDA -B4 hdac0@pci0:8:0:1: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1002 device=0x1637 subvendor=0x1043 subdevice=0x87e1 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Renoir Radeon High Definition Audio Controller' class = multimedia subclass = HDA -- hdac1@pci0:8:0:6: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e3 subvendor=0x1043 subdevice=0x86c7 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Family 17h/19h/1ah HD Audio Controller' class = multimedia subclass = HDA
I apologize for the noise, i am on exactly main-n276779-fe4bdd889b5d and sound devices aren't missing and they work. I guess i didn't do an upgrade or something while creating this report.
Reopening because I have the same problem. I get the timeout on address 0 error when my computer has been powered off for a while. Everything's fine after a reboot. Also, it only became a problem after I created a custom kernel config, removing things from GENERIC that aren't needed. hdac0@pci0:5:0:1: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1002 device=0x1637 subvendor=0x1002 subdevice=0x1637 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Renoir Radeon High Definition Audio Controller' class = multimedia subclass = HDA hdac1@pci0:5:0:6: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e3 subvendor=0x1458 subdevice=0xa194 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Family 17h/19h/1ah HD Audio Controller' class = multimedia subclass = HDA
(In reply to Tijl Coosemans from comment #3) Which parts of the GENERIC config did you remove? I am curious because I also hit this error at some point and I have the same device.
(In reply to Christos Margiolis from comment #4) I tried GENERIC again today and saw the same problem so it must have been a coincidence that I first noticed it with a custom kernel.
(In reply to Tijl Coosemans from comment #5) Is this 100% consistent? And if so, how do you reproduce it? Not powering off for a while doesn't make much sense to me at first glance. The only time I hit this error (again, same soundcard) was when I accidentally panicked snd_hda(4).
(In reply to Christos Margiolis from comment #6) Assuming that this issue is the same as the one described in bug #286418, I've observed that my PC has to be powered down for 2 or 3 minutes. If I just power it down, unplug it, hit the ATX power switch, plug it back in, and power it off (within a few seconds) it is likely that the realtek audio device will be found. However if I leave the machine off for several minutes it will not be found on first boot. I know this sounds bizarre, but there you have it. In all cases of failure the dmesg output will reflect what I attached to issue 286418.
(In reply to Christos Margiolis from comment #6) In my case the problem is always there when I switch on the computer in the morning. Then the problem stays no matter how many times I power off and on again. Only a reboot fixes it and then it stays fixed if I power off. Longest I kept it off is an hour over lunch. Next morning the problem is back. I tried to start a git bisect but I can't find an old revision where everything worked. I've gone back as far as Jan 1 and I'm pretty sure everything worked at the end of January. I've done a BIOS downgrade now but this involves a reboot so we'll see tomorrow if actually worked.
(In reply to Tijl Coosemans from comment #8) BIOS downgrade didn't help.
Turns out the problem can be reproduced by simply playing music through the device and then shutting down the computer. A reboot fixes it.
(In reply to Tijl Coosemans from comment #10) I pushed a commit today [1] that fixes a kernel panic that occurred while hot-unloading snd_hda(4), which in turn caused a similar issue to we are talking about, on my machine. What you are describing sounds somewhat similar. Please apply this patch, recompile snd_hda(4), or the whole kernel if you have snd_hda(4) built into it, and let me know. [1] https://cgit.freebsd.org/src/commit/?id=c50c5a47a9d515a7dbf584c10c7f66e56b29b305
(In reply to Christos Margiolis from comment #11) The patch didn't make a difference. Running "kldunload snd_hda" before shutting down seems to work, but this panics frequently: Unread portion of the kernel message buffer: pcm3: detached pcm2: detached pcm1: detached pcm0: detached hdaa0: detached hdacc0: detached pcm5: detached pcm4: detached hdaa1: detached hdacc1: detached Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff816607de stack pointer = 0x28:0xfffffe00d6433d60 frame pointer = 0x28:0xfffffe00d6433d90 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq72: hdac1) rdi: fffff8000180fb00 rsi: 0000000000000001 rdx: 0000000000000001 rcx: 0000000000000640 r8: 0000000000000001 r9: ffffffffffffffff rax: deadc0dedeadc71e rbx: 0000000000000000 rbp: fffffe00d6433d90 r10: ffffffff81193f78 r11: 000000000000295e r12: fffff80001964900 r13: fffff80001915780 r14: 0000000000000000 r15: fffff80001964958 trap number = 9 panic: general protection fault cpuid = 2 time = 1746281150 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d6433ae0 vpanic() at vpanic+0x136/frame 0xfffffe00d6433c10 panic() at panic+0x43/frame 0xfffffe00d6433c70 trap_fatal() at trap_fatal+0x68/frame 0xfffffe00d6433c90 calltrap() at calltrap+0x8/frame 0xfffffe00d6433c90 --- trap 0x9, rip = 0xffffffff816607de, rsp = 0xfffffe00d6433d60, rbp = 0xfffffe00d6433d90 --- HDAC_STREAM_INTR() at HDAC_STREAM_INTR+0x3e/frame 0xfffffe00d6433d90 hdacc_stream_intr() at hdacc_stream_intr+0x53/frame 0xfffffe00d6433dc0 HDAC_STREAM_INTR() at HDAC_STREAM_INTR+0x8d/frame 0xfffffe00d6433e00 hdac_one_intr() at hdac_one_intr+0x18b/frame 0xfffffe00d6433e30 hdac_intr_handler() at hdac_intr_handler+0x83/frame 0xfffffe00d6433e60 ithread_loop() at ithread_loop+0x266/frame 0xfffffe00d6433ef0 fork_exit() at fork_exit+0x82/frame 0xfffffe00d6433f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00d6433f30 --- trap 0x3978e13b, rip = 0xb13fe893bd7fe897, rsp = 0x160873df1a4873db, rbp = 0xaa375ff1a6775ff5 --- Does the interrupt handler need to be destroyed or something?
(In reply to Tijl Coosemans from comment #12) The panic the patch fixes is exactly that. Maybe there is more to be patched, but to make sure first, are you sure you are running the patched snd_hda(4)?
(In reply to Christos Margiolis from comment #13) One possible scenario I can think of is this. The patch drains the callout inside hdac_detach() which is actually called last in the detach hierarchy (hdaa -> hdacc -> hdac), so it could be that because the callout isn't drained until we reach hdac_detach(), it keeps being called _after_ we freed hdaa and hdacc resources, which to me at least makes sense judging by your panic message. I will experiment with draining the callout in hdaa_detach() instead.
I cannot reproduce your panic with the patch applied. What exactly are you doing to reproduce this? Playing sound and shutdown down doesn't panic.
Playing audio and then "kldunload snd_hda" panics sometimes. I think the problem is that the call to bus_generic_detach in hdac_detach destroys the child devices (hdacc, hdaa), and then a callout/taskqueue/interrupt happens during or after that call. This may be a regression from base 11a9117871e6. It removed "sc->codecs[cad].dev = NULL;" from hdac_detach that at least prevented hdac_unsolq_flush from calling child interrupt handlers. Note that this panic is a separate issue from the one reported in this bug.
(In reply to Tijl Coosemans from comment #16) > and then a callout/taskqueue/interrupt happens during or after that call. That's my guess as well, although I am not sure whether that's a problem with the commit you mention, or snd_hda(4) not cleaning up properly in general. Is the problem fixed for you if you move the taskqueue/callout draining block below _before_ the child deletion? hdac_lock(sc); callout_stop(&sc->poll_callout); hdac_reset(sc, false); hdac_unlock(sc); callout_drain(&sc->poll_callout); taskqueue_drain(taskqueue_thread, &sc->unsolq_task); hdac_irq_free(sc); > Note that this panic is a separate issue from the one reported in this bug. IIRC the issue the reported mentions occurred after the panic, so it seems to be somewhat related.
(In reply to Christos Margiolis from comment #17) Yesterday I tried the patch below and "kldunload snd_hda" hasn't panicked yet. But I also added printf("entering hdac_detach\n") to the start of the function and the output looked like this: pcm3: detached pcm2: detached pcm1: detached pcm0: detached hdaa0: detached hdacc0: detached pcm5: detached pcm4: detached hdaa1: detached hdacc1: detached entering hdac_detach hdac0: detached pci5: <multimedia, HDA> at device 0.1 (no driver attached) entering hdac_detach hdac1: detached pci5: <multimedia, HDA> at device 0.6 (no driver attached) So it looks like hdac_detach is called after its children have already been detached, so the patch below only reduces the window I think (or maybe the devices have only been detached and not deleted yet?). The second patch below is probably safer. diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c index 602f5df93648..f83f3dc1e9f8 100644 --- a/sys/dev/sound/pci/hda/hdac.c +++ b/sys/dev/sound/pci/hda/hdac.c @@ -1743,17 +1743,17 @@ hdac_detach(device_t dev) struct hdac_softc *sc = device_get_softc(dev); int i, error; + callout_drain(&sc->poll_callout); + taskqueue_drain(taskqueue_thread, &sc->unsolq_task); + hdac_irq_free(sc); + error = bus_generic_detach(dev); if (error != 0) return (error); hdac_lock(sc); - callout_stop(&sc->poll_callout); hdac_reset(sc, false); hdac_unlock(sc); - callout_drain(&sc->poll_callout); - taskqueue_drain(taskqueue_thread, &sc->unsolq_task); - hdac_irq_free(sc); for (i = 0; i < sc->num_ss; i++) hdac_dma_free(sc, &sc->streams[i].bdl); ----- diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c index 602f5df93648..a87578810ee0 100644 --- a/sys/dev/sound/pci/hda/hdac.c +++ b/sys/dev/sound/pci/hda/hdac.c @@ -1790,6 +1790,16 @@ hdac_print_child(device_t dev, device_t child) return (retval); } +static void +hdac_child_deleted(device_t dev, device_t child) +{ + struct hdac_softc *sc = device_get_softc(dev); + int cad; + + cad = (intptr_t)device_get_ivars(child); + sc->codecs[cad].dev = NULL; +} + static int hdac_child_location(device_t dev, device_t child, struct sbuf *sb) { @@ -2153,6 +2163,7 @@ static device_method_t hdac_methods[] = { /* Bus interface */ DEVMETHOD(bus_get_dma_tag, hdac_get_dma_tag), DEVMETHOD(bus_print_child, hdac_print_child), + DEVMETHOD(bus_child_deleted, hdac_child_deleted), DEVMETHOD(bus_child_location, hdac_child_location), DEVMETHOD(bus_child_pnpinfo, hdac_child_pnpinfo_method), DEVMETHOD(bus_read_ivar, hdac_read_ivar), ----- >> Note that this panic is a separate issue from the one reported in this bug. > IIRC the issue the reported mentions occurred after the panic, so it seems to be somewhat related. No this bug is about hdac failing to attach at boot. There's no panic. hdac1: Command 0x000f0000 timeout on address 0 hdac1: Command 0x000f0002 timeout on address 0 hdac1: CODEC at address 0 not responding! I haven't been able to fix this yet, but I think the device_shutdown method needs to be implemented similar to hdac_suspend.
(In reply to Tijl Coosemans from comment #18) > So it looks like hdac_detach is called after its children have already been detached, so the patch below only reduces the window I think (or maybe the devices have only been detached and not deleted yet?). The second patch below is probably safer. Agreed. However we definitely need to drain the callout as well. Not doing anything isn't correct. I think draining it before the bus_generic_detach() is more reasonable. > No this bug is about hdac failing to attach at boot. There's no panic. The reason I'm saying it might be at least vaguely related to the panic is because there could be an error during detach whereby it leaves the device in a wrong state and so it either needs time to reset or a reboot to be re-initialized properly.
Created attachment 260181 [details] hda.shutdown.patch This patch appears to fix the problem for me. It adds hdac_shutdown, copied from hdac_suspend.
(In reply to Tijl Coosemans from comment #20) Nice! So with those two patches both problems are gone?
(In reply to Christos Margiolis from comment #21) Yes, and a short whoosh sound through the speakers at shutdown is also gone now.
(In reply to Tijl Coosemans from comment #22) Great, feel free to submit a patch for review and we can go through with it. Thank you. :-)
I can take care of the patch if you want, just thought it's better to leave it to you since you can reproduce the panics it fixes.
*** Bug 286418 has been marked as a duplicate of this bug. ***
(In reply to Christos Margiolis from comment #24) The patch that adds hdac_shutdown is ok I think, but I'm not sure about the patch that fixes the panic. I tried without that patch again and got a slightly different panic. In hdaa_stream_intr there's a hdaa_unlock call that allows detaching to continue and then chn_intr crashes. Unread portion of the kernel message buffer: pcm3: detached pcm2: detached pcm1: detached pcm0: detached hdaa0: detached hdacc0: detached pcm5: detached Fatal trap 9: general protection fault while in kernel mode cpuid = 8; apic id = 08 instruction pointer = 0x20:0xffffffff816c1cf7 stack pointer = 0x28:0xfffffe00d6433dc0 frame pointer = 0x28:0xfffffe00d6433dd0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq72: hdac1) rdi: fffff800030bf000 rsi: 0000000000000000 rdx: ffffffff81193ff8 rcx: 0000000000000001 r8: ffffffff80e5da60 r9: 0000000000000000 rax: deadc0dedeadc0de rbx: fffff8002ca1a000 rbp: fffffe00d6433dd0 r10: 0000000000000000 r11: 0000000000000001 r12: 00000000000002a4 r13: 0000000000000001 r14: fffff80003044300 r15: 0000000000000001 trap number = 9 panic: general protection fault cpuid = 8 time = 1746953281 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d6433b40 vpanic() at vpanic+0x136/frame 0xfffffe00d6433c70 panic() at panic+0x43/frame 0xfffffe00d6433cd0 trap_fatal() at trap_fatal+0x68/frame 0xfffffe00d6433cf0 calltrap() at calltrap+0x8/frame 0xfffffe00d6433cf0 --- trap 0x9, rip = 0xffffffff816c1cf7, rsp = 0xfffffe00d6433dc0, rbp = 0xfffffe00d6433dd0 --- chn_intr() at chn_intr+0x17/frame 0xfffffe00d6433dd0 hdaa_stream_intr() at hdaa_stream_intr+0x99/frame 0xfffffe00d6433e10 hdac_intr_handler() at hdac_intr_handler+0x159/frame 0xfffffe00d6433e60 ithread_loop() at ithread_loop+0x266/frame 0xfffffe00d6433ef0 fork_exit() at fork_exit+0x82/frame 0xfffffe00d6433f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00d6433f30 --- trap 0xcedd1844, rip = 0x469a11ec4ada11e8, rsp = 0xe1ad8aa0eded8aa4, rbp = 0x5d92a68e51d2a68a ---
(In reply to Tijl Coosemans from comment #26) IIRC that's the same panic I was also getting. With both my commit and your first patch combined, it seems to work fine, at least so far that I tested (not too much yet).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7 commit d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7 Author: Tijl Coosemans <tijl@FreeBSD.org> AuthorDate: 2025-05-18 13:38:02 +0000 Commit: Tijl Coosemans <tijl@FreeBSD.org> CommitDate: 2025-05-18 13:38:02 +0000 snd_hda: Add shutdown method Power down the device on shutdown similar to what is done in the case of suspend. The device may fail to attach on next boot without this. PR: 286385 Reviewed by: christos, adrian Differential Revision: https://reviews.freebsd.org/D50306 sys/dev/sound/pci/hda/hdac.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=77521692f4c71213c5419268657e696532c28325 commit 77521692f4c71213c5419268657e696532c28325 Author: Tijl Coosemans <tijl@FreeBSD.org> AuthorDate: 2025-05-18 13:38:02 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2025-05-21 19:43:52 +0000 snd_hda: Add shutdown method Power down the device on shutdown similar to what is done in the case of suspend. The device may fail to attach on next boot without this. PR: 286385 Reviewed by: christos, adrian Differential Revision: https://reviews.freebsd.org/D50306 (cherry picked from commit d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7) sys/dev/sound/pci/hda/hdac.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
A commit in branch releng/14.3 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=adf77cb48e4c265f366fb0f290b597fdd0dfdc68 commit adf77cb48e4c265f366fb0f290b597fdd0dfdc68 Author: Tijl Coosemans <tijl@FreeBSD.org> AuthorDate: 2025-05-18 13:38:02 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2025-05-21 23:21:42 +0000 snd_hda: Add shutdown method Power down the device on shutdown similar to what is done in the case of suspend. The device may fail to attach on next boot without this. PR: 286385 Reviewed by: christos, adrian Differential Revision: https://reviews.freebsd.org/D50306 (cherry picked from commit d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7) (cherry picked from commit 77521692f4c71213c5419268657e696532c28325) Approved by: re (cperciva) sys/dev/sound/pci/hda/hdac.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)