I'm reporting a new WARN_ON in sound/hda/hdac_bus.c that was not present
in 5.15. Sorry, I don't have time to bisect this right now but report
is below.
dmesg in 5.14 kernel was:
snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffaa2ac520)
GACT probability on
Mirror/redirect action on
Simple TC action Loaded
u32 classifier
Performance counters on
input device check on
Actions configured
hdaudio hdaudioC0D0: Unable to bind the codec
hdaudio hdaudioC0D2: Unable to bind the codec
dmesg in 5.15 kernel produces WARN_ON in sound/hda/hdac_bus.c
snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffad8b02a0)
GACT probability on
Mirror/redirect action on
Simple TC action Loaded
u32 classifier
Performance counters on
input device check on
Actions configured
snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
Initializing XFRM netlink socket
------------[ cut here ]------------
NET: Registered PF_INET6 protocol family
WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
snd_hdac_bus_exit+0x40/0x50
Segment Routing with IPv6
Modules linked in:
CPU: 14 PID: 186 Comm: kworker/14:2 Tainted: G I 5.15.0 #1
Hardware name: ASUSTeK COMPUTER INC. System Product Name/WS C246 PRO,
BIOS 1401 08/13/2020
In-situ OAM (IOAM) with IPv6
Workqueue: events azx_probe_work
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
RIP: 0010:snd_hdac_bus_exit+0x40/0x50
NET: Registered PF_PACKET protocol family
Code: 75 19 48 8b 57 58 48 8d 47 58 48 39 c2 75 1b 48 81 c7 f8 02 00 00
e9 ff 97 57 ff 0f 0b 48 8b 57 58 48 8d 47 58 48 39 c2 74 e5 <0f> 0b 48
81 c7 f8 02 00 00 e9 e2 97 57 ff 66 90 0f 1f 44 00 00 41
RPC: Registered rdma transport module.
RSP: 0000:ffffa545007b7e88 EFLAGS: 00010202
RPC: Registered rdma backchannel transport module.
Key type dns_resolver registered
RAX: ffff89f483078880 RBX: ffff89f483078828 RCX: 0000000080200010
RDX: ffff89f4830792f0 RSI: 0000000000000001 RDI: ffff89f483078828
RBP: ffff89f483078e70 R08: 0000000000000000 R09: ffffffffacf094a4
R10: 0000000000000004 R11: 0000000000000032 R12: ffff89f7dbda50c0
R13: ffff89f7dbda9100 R14: 0000000000000000 R15: ffff89f7dbda9105
FS: 0000000000000000(0000) GS:ffff89f7dbd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000194a0c001 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
azx_free+0xba/0x170
process_one_work+0x1db/0x380
worker_thread+0x4d/0x3e0
? rescuer_thread+0x370/0x370
kthread+0x124/0x150
? set_kthread_struct+0x40/0x40
ret_from_fork+0x1f/0x30
---[ end trace 9779b9e2ef53104c ]---
On Tue, 09 Nov 2021 22:12:30 +0100,
Scott Branden wrote:
>
> I'm reporting a new WARN_ON in sound/hda/hdac_bus.c that was not
> present in 5.15. Sorry, I don't have time to bisect this right now
> but report is below.
>
> dmesg in 5.14 kernel was:
> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffaa2ac520)
> GACT probability on
> Mirror/redirect action on
> Simple TC action Loaded
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> hdaudio hdaudioC0D0: Unable to bind the codec
> hdaudio hdaudioC0D2: Unable to bind the codec
>
> dmesg in 5.15 kernel produces WARN_ON in sound/hda/hdac_bus.c
> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffad8b02a0)
> GACT probability on
> Mirror/redirect action on
> Simple TC action Loaded
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
> Initializing XFRM netlink socket
> ------------[ cut here ]------------
> NET: Registered PF_INET6 protocol family
> WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
This indicates the leftover codecs on the bus, and it's likely
triggered by the recent change to allow retrying the codec probes.
Did this HD-audio stuff work at all before 5.15? The codec bind error
itself shouldn't be brought by that change.
The warning itself can be solved by the patch below, I suppose
(note: totally untested!)
thanks,
Takashi
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2327,7 +2327,8 @@ static int azx_probe_continue(struct azx *chip)
out_free:
if (err < 0) {
- azx_free(chip);
+ pci_set_drvdata(pci, NULL);
+ snd_card_free(chip->card);
return err;
}
Hi Takashi,
On 2021-11-10 6:33 a.m., Takashi Iwai wrote:
> On Tue, 09 Nov 2021 22:12:30 +0100,
> Scott Branden wrote:
>>
>> I'm reporting a new WARN_ON in sound/hda/hdac_bus.c that was not
>> present in 5.15. Sorry, I don't have time to bisect this right now
>> but report is below.
>>
>> dmesg in 5.14 kernel was:
>> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffaa2ac520)
>> GACT probability on
>> Mirror/redirect action on
>> Simple TC action Loaded
>> u32 classifier
>> Performance counters on
>> input device check on
>> Actions configured
>> hdaudio hdaudioC0D0: Unable to bind the codec
>> hdaudio hdaudioC0D2: Unable to bind the codec
>>
>> dmesg in 5.15 kernel produces WARN_ON in sound/hda/hdac_bus.c
>> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffad8b02a0)
>> GACT probability on
>> Mirror/redirect action on
>> Simple TC action Loaded
>> u32 classifier
>> Performance counters on
>> input device check on
>> Actions configured
>> snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
>> Initializing XFRM netlink socket
>> ------------[ cut here ]------------
>> NET: Registered PF_INET6 protocol family
>> WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
>
> This indicates the leftover codecs on the bus, and it's likely
> triggered by the recent change to allow retrying the codec probes.
>
> Did this HD-audio stuff work at all before 5.15? The codec bind error
> itself shouldn't be brought by that change.
I don't know if HD-audio works at all on this system - we don't test
HD-audio but parse the dmesg for issues so detected this new one.
>
> The warning itself can be solved by the patch below, I suppose
> (note: totally untested!)
I tested your patch below and can confirm the WARN_ON is not produced on
boot.
>
>
> thanks,
>
> Takashi
>
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -2327,7 +2327,8 @@ static int azx_probe_continue(struct azx *chip)
>
> out_free:
> if (err < 0) {
> - azx_free(chip);
> + pci_set_drvdata(pci, NULL);
> + snd_card_free(chip->card);
> return err;
> }
>
>
Regards,
Scott
On Wed, 10 Nov 2021 19:53:53 +0100,
Scott Branden wrote:
>
> Hi Takashi,
>
> On 2021-11-10 6:33 a.m., Takashi Iwai wrote:
> > On Tue, 09 Nov 2021 22:12:30 +0100,
> > Scott Branden wrote:
> >>
> >> I'm reporting a new WARN_ON in sound/hda/hdac_bus.c that was not
> >> present in 5.15. Sorry, I don't have time to bisect this right now
> >> but report is below.
> >>
> >> dmesg in 5.14 kernel was:
> >> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffaa2ac520)
> >> GACT probability on
> >> Mirror/redirect action on
> >> Simple TC action Loaded
> >> u32 classifier
> >> Performance counters on
> >> input device check on
> >> Actions configured
> >> hdaudio hdaudioC0D0: Unable to bind the codec
> >> hdaudio hdaudioC0D2: Unable to bind the codec
> >>
> >> dmesg in 5.15 kernel produces WARN_ON in sound/hda/hdac_bus.c
> >> snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffad8b02a0)
> >> GACT probability on
> >> Mirror/redirect action on
> >> Simple TC action Loaded
> >> u32 classifier
> >> Performance counters on
> >> input device check on
> >> Actions configured
> >> snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
> >> Initializing XFRM netlink socket
> >> ------------[ cut here ]------------
> >> NET: Registered PF_INET6 protocol family
> >> WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
> >
> > This indicates the leftover codecs on the bus, and it's likely
> > triggered by the recent change to allow retrying the codec probes.
> >
> > Did this HD-audio stuff work at all before 5.15? The codec bind error
> > itself shouldn't be brought by that change.
> I don't know if HD-audio works at all on this system - we don't test
> HD-audio but parse the dmesg for issues so detected this new one.
OK.
> > The warning itself can be solved by the patch below, I suppose
> > (note: totally untested!)
>
> I tested your patch below and can confirm the WARN_ON is not produced
> on boot.
Good, then I'll submit and merge the proper patch.
Thanks!
Takashi