snd_hda_codec_cirrus kernel oops
Hey list,
I've noticed the following crash since the last few days, causing audio to no longer to work. It could be related to me updating the firmware (bios) not too long ago (I load Mac OS every few months via an external drive) which caused the firmware to be updated. Or, it was a kernel update, that came along every few weeks.
I'll try to find my archlinux bugzilla stuff, to report it there as well, but I don't think they are actively patching the sound stuff.
The last commit I'm seeing on `patch_cirrus.c` seems to be from aug 2022, so that can't be it, though incidentally, the change is with regards to support for iMac 12,1 model, which is interesting as the number is the same.
I understand you guys probably get tons of bug reports, but best to leave it here, just in case.
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic] [ 90.497019] Code: f9 01 0f 84 20 fe ff ff 48 c7 c2 4d 45 f9 c0 41 83 f9 02 0f 85 fe fd ff ff e9 0a fe ff ff 48 c7 c7 6e 45 f9 c0 e8 13 26 32 e6 <0f> 0b 48 c7 c2 dd 45 f9 c0 e9 f0 fd ff ff 8b 91 10 0b 00 00 48 8b [ 90.497021] RSP: 0018:ffffa50740cebad8 EFLAGS: 00010282 [ 90.497023] RAX: 0000000000000000 RBX: ffff90ea048d1cf0 RCX: 0000000000000027 [ 90.497025] RDX: ffff90ed5eda1688 RSI: 0000000000000001 RDI: ffff90ed5eda1680 [ 90.497027] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffa50740ceb968 [ 90.497028] R10: 0000000000000003 R11: ffffffffa90ca208 R12: ffffffffc0f948c0 [ 90.497030] R13: ffff90ea13961000 R14: ffff90ea13940000 R15: 0000000010000013 [ 90.497032] FS: 00007f1db7091740(0000) GS:ffff90ed5ed80000(0000) knlGS:0000000000000000 [ 90.497034] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 90.497036] CR2: 000056301fb6f000 CR3: 00000001018ec002 CR4: 00000000003706e0 [ 90.497038] Call Trace: [ 90.497040] <TASK> [ 90.497043] snd_hda_gen_parse_auto_config+0xa54/0x2d50 [snd_hda_codec_generic 81639eb673de159e5e532c3e233834b733e4a85d] [ 90.497066] ? snd_hda_parse_pin_defcfg+0xaf7/0xda0 [snd_hda_codec 5b5014cb067d97e046acd84ac2db87d5fa068fb6] [ 90.497086] cs_parse_auto_config+0x3b/0xa0 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497094] patch_cs4208+0x155/0x1a0 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497101] ? snd_hdac_regmap_init+0x24/0x50 [snd_hda_core b180f4281d829fe0e1d0ef6f041e0fc5adf64817] [ 90.497128] hda_codec_driver_probe+0x98/0x150 [snd_hda_codec 5b5014cb067d97e046acd84ac2db87d5fa068fb6] [ 90.497143] really_probe+0x19b/0x3e0 [ 90.497149] ? __pfx___driver_attach+0x10/0x10 [ 90.497152] __driver_probe_device+0x78/0x160 [ 90.497156] driver_probe_device+0x1f/0x90 [ 90.497159] __driver_attach+0xd2/0x1c0 [ 90.497163] bus_for_each_dev+0x85/0xd0 [ 90.497166] bus_add_driver+0x116/0x220 [ 90.497170] driver_register+0x59/0x100 [ 90.497173] ? __pfx_init_module+0x10/0x10 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497179] do_one_initcall+0x5a/0x240 [ 90.497184] do_init_module+0x4a/0x200 [ 90.497190] __do_sys_init_module+0x17f/0x1b0 [ 90.497195] do_syscall_64+0x5d/0x90 [ 90.497213] ? do_user_addr_fault+0x1e0/0x720 [ 90.497217] ? exc_page_fault+0x7c/0x180 [ 90.497222] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 90.497225] RIP: 0033:0x7f1db6b21f9e [ 90.497242] Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48 [ 90.497244] RSP: 002b:00007fff2ac9ec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 90.497246] RAX: ffffffffffffffda RBX: 00005614a9a07e00 RCX: 00007f1db6b21f9e [ 90.497248] RDX: 00005614a8e1dcb2 RSI: 0000000000010660 RDI: 00005614a9a6cdb0 [ 90.497250] RBP: 00005614a8e1dcb2 R08: 0000000000010660 R09: 0000000000000000 [ 90.497251] R10: 000000000005d8a1 R11: 0000000000000246 R12: 0000000000040000 [ 90.497253] R13: 00005614a9a07c50 R14: 0000000000000000 R15: 00005614a9a0bbb0 [ 90.497270] </TASK> [ 90.497271] ---[ end trace 0000000000000000 ]--- [ 90.497273] ------------[ cut here ]------------ [ 90.497274] BUG? [ 90.497284] WARNING: CPU: 3 PID: 343 at sound/pci/hda/hda_generic.c:1238 get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic] [ 90.497293] Modules linked in: snd_hda_codec_cirrus(+) brcmfmac(+) snd_hda_codec_generic ledtrig_audio brcmutil iTCO_wdt snd_hda_intel mei_pxp mei_hdcp snd_intel_dspcfg btusb irqbypass snd_intel_sdw_acpi btrtl intel_pmc_bxt snd_hda_codec btbcm drm_buddy spi_intel_platform btintel snd_hda_core spi_intel iTCO_vendor_support rapl btmtk cfg80211 applesmc i2c_i801 mei_me joydev i2c_algo_bit intel_cstate snd_hwdep ttm i2c_smbus pcspkr mei intel_uncore intel_pch_thermal bluetooth lpc_ich snd_pcm thunderbolt mmc_core drm_display_helper snd_timer snd acpi_als ecdh_generic cec mousedev bcm5974 rfkill intel_gtt industrialio_triggered_buffer soundcore sbs kfifo_buf video apple_mfi_fastcharge sbshc industrialio wmi apple_bl mac_hid dm_multipath sg loop crypto_user fuse bpf_preload ip_tables x_tables usbhid crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic gf128mul ghash_clmulni_intel sha512_ssse3 aesni_intel crypto_simd cryptd applespi crc16 xhci_pci spi_pxa2xx_pci spi_pxa2xx_platform xhci_pci_renesas dw_dmac hid_apple [ 90.497374] tg3 libphy vfat fat btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic crc32c_intel dm_crypt cbc encrypted_keys trusted asn1_encoder tee dm_mod [ 90.497388] CPU: 3 PID: 343 Comm: modprobe Tainted: G W 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497391] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497392] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic] [ 90.497401] Code: f9 01 0f 84 20 fe ff ff 48 c7 c2 4d 45 f9 c0 41 83 f9 02 0f 85 fe fd ff ff e9 0a fe ff ff 48 c7 c7 6e 45 f9 c0 e8 13 26 32 e6 <0f> 0b 48 c7 c2 dd 45 f9 c0 e9 f0 fd ff ff 8b 91 10 0b 00 00 48 8b [ 90.497403] RSP: 0018:ffffa50740cebad8 EFLAGS: 00010282 [ 90.497418] RAX: 0000000000000000 RBX: ffff90ea048d1cf0 RCX: 0000000000000027 [ 90.497420] RDX: ffff90ed5eda1688 RSI: 0000000000000001 RDI: ffff90ed5eda1680 [ 90.497422] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffa50740ceb968 [ 90.497423] R10: 0000000000000003 R11: ffffffffa90ca208 R12: 0000000000000004 [ 90.497425] R13: ffff90ea13961000 R14: ffff90ea13940000 R15: ffffffffc0f945dd [ 90.497427] FS: 00007f1db7091740(0000) GS:ffff90ed5ed80000(0000) knlGS:0000000000000000 [ 90.497429] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 90.497430] CR2: 000056301fb6f000 CR3: 00000001018ec002 CR4: 00000000003706e0 [ 90.497432] Call Trace: [ 90.497433] <TASK> [ 90.497435] snd_hda_gen_parse_auto_config+0x9a5/0x2d50 [snd_hda_codec_generic 81639eb673de159e5e532c3e233834b733e4a85d] [ 90.497444] ? snd_hda_parse_pin_defcfg+0xaf7/0xda0 [snd_hda_codec 5b5014cb067d97e046acd84ac2db87d5fa068fb6] [ 90.497463] cs_parse_auto_config+0x3b/0xa0 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497469] patch_cs4208+0x155/0x1a0 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497476] ? snd_hdac_regmap_init+0x24/0x50 [snd_hda_core b180f4281d829fe0e1d0ef6f041e0fc5adf64817] [ 90.497489] hda_codec_driver_probe+0x98/0x150 [snd_hda_codec 5b5014cb067d97e046acd84ac2db87d5fa068fb6] [ 90.497516] really_probe+0x19b/0x3e0 [ 90.497520] ? __pfx___driver_attach+0x10/0x10 [ 90.497523] __driver_probe_device+0x78/0x160 [ 90.497527] driver_probe_device+0x1f/0x90 [ 90.497530] __driver_attach+0xd2/0x1c0 [ 90.497533] bus_for_each_dev+0x85/0xd0 [ 90.497537] bus_add_driver+0x116/0x220 [ 90.497540] driver_register+0x59/0x100 [ 90.497543] ? __pfx_init_module+0x10/0x10 [snd_hda_codec_cirrus 9ac52229b60afb26837192841054ac3dbe8aecc3] [ 90.497549] do_one_initcall+0x5a/0x240 [ 90.497553] do_init_module+0x4a/0x200 [ 90.497570] __do_sys_init_module+0x17f/0x1b0 [ 90.497576] do_syscall_64+0x5d/0x90 [ 90.497579] ? do_user_addr_fault+0x1e0/0x720 [ 90.497583] ? exc_page_fault+0x7c/0x180 [ 90.497587] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 90.497589] RIP: 0033:0x7f1db6b21f9e [ 90.497595] Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48 [ 90.497596] RSP: 002b:00007fff2ac9ec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 90.497599] RAX: ffffffffffffffda RBX: 00005614a9a07e00 RCX: 00007f1db6b21f9e [ 90.497601] RDX: 00005614a8e1dcb2 RSI: 0000000000010660 RDI: 00005614a9a6cdb0 [ 90.497602] RBP: 00005614a8e1dcb2 R08: 0000000000010660 R09: 0000000000000000 [ 90.497604] R10: 000000000005d8a1 R11: 0000000000000246 R12: 0000000000040000 [ 90.497605] R13: 00005614a9a07c50 R14: 0000000000000000 R15: 00005614a9a0bbb0 [ 90.497609] </TASK> [ 90.497610] ---[ end trace 0000000000000000 ]--- [ 90.512670] bcm5974: bad trackpad package, length: 8 [ 90.569769] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9 [ 90.569831] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10 [ 90.569886] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11 [ 90.569926] input: HDA Intel PCH SPDIF as /devices/pci0000:00/0000:00:1b.0/sound/card1/input12 [ 90.569977] input: HDA Intel PCH SPDIF In as /devices/pci0000:00/0000:00:1b.0/sound/card1/input13
On Thu, 11 May 2023 17:12:23 +0200, Olliver Schinagl wrote:
Hey list,
I've noticed the following crash since the last few days, causing audio to no longer to work. It could be related to me updating the firmware (bios) not too long ago (I load Mac OS every few months via an external drive) which caused the firmware to be updated. Or, it was a kernel update, that came along every few weeks.
I'll try to find my archlinux bugzilla stuff, to report it there as well, but I don't think they are actively patching the sound stuff.
The last commit I'm seeing on `patch_cirrus.c` seems to be from aug 2022, so that can't be it, though incidentally, the change is with regards to support for iMac 12,1 model, which is interesting as the number is the same.
I understand you guys probably get tons of bug reports, but best to leave it here, just in case.
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
Also, as a blind shot, does the patch below work around the bug?
thanks,
Takashi
-- 8< -- --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch,
/* multi-io channels */ if (ch >= cfg->line_outs) - return channel_name[ch]; + goto fixed_names;
switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT: @@ -1234,8 +1234,9 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
+ fixed_names: if (ch >= ARRAY_SIZE(channel_name)) { - snd_BUG(); + codec_err(codec, "Too many channels in %s: %d\n", __func__, ch); return "PCM"; }
Hey Takashi,
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Olliver
thanks,
Takashi
-- 8< -- --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch,
/* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
goto fixed_names;
switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT:
@@ -1234,8 +1234,9 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
- fixed_names: if (ch >= ARRAY_SIZE(channel_name)) {
snd_BUG();
return "PCM"; }codec_err(codec, "Too many channels in %s: %d\n", __func__, ch);
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; }
-static const char * const channel_name[4] = { - "Front", "Surround", "CLFE", "Side" +static const char * const channel_name[] = { + "Front", "Surround", "CLFE", "Side", "Back", };
/* give some appropriate ctl name prefix for the given line out channel */ @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch,
/* multi-io channels */ if (ch >= cfg->line_outs) - return channel_name[ch]; + goto fixed_name;
switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT: @@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
+ fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
Olliver
On 16-05-2023 20:31, Takashi Iwai wrote:
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; }
-static const char * const channel_name[4] = {
- "Front", "Surround", "CLFE", "Side"
+static const char * const channel_name[] = {
"Front", "Surround", "CLFE", "Side", "Back", };
/* give some appropriate ctl name prefix for the given line out channel */
@@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch,
/* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
goto fixed_name;
switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT:
@@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
- fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Takashi
Olliver
On 16-05-2023 20:31, Takashi Iwai wrote:
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; } -static const char * const channel_name[4] = {
- "Front", "Surround", "CLFE", "Side"
+static const char * const channel_name[] = {
- "Front", "Surround", "CLFE", "Side", "Back", }; /* give some appropriate ctl name prefix for the given line out
channel */ @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
case AUTO_PIN_SPEAKER_OUT:goto fixed_name; switch (cfg->line_out_type) {
@@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
- fixed_name:
if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
Hey Takashi,
On 18-05-2023 16:27, Takashi Iwai wrote:
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Ok, so no easy way :) I did try copying things, but didn't get sound either.
I did find the schematics for the 2013 and 2014 models of the macbook; no luck yet on the 2015 (mine). But all 3 have the same model number (A1502), and looking at the schematic (not even sure if it is just a new revision, or actually for the different boards) they seem more or less identical. Especially on the audio part. The nice thing is it tells me what pins things are connected to :) But again, might not be a perfect match to my board (crosses fingers).
What is interesting, the schematics [0] actually list the HDA configuration.
CODEC OUTPUT SIGNAL PATHS
FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL
HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A
DMIC 1 0x09 (9) 0x1c (18) DMIC 2 0x09 (9) 0x1c (18)
HEADSET MIC 0x07 (7) 0x18 (24)
OTHER CODEC GPIO LINES LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN
Granted, that should yield the same infomration I can copy from the other one, but I'm trying to understand what this would mean. Function is obvious, aswell as the pin-complex, it's what hdajackretasks calls pin ID. But the rest is a bit iffy. E.g. what would the volume column indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's of the codec? Maybe my confusion mostly comes as I'm not sure how to relate those fields to hdajackretask.
Olliver
[0]: https://www.alisaler.com/macbook-pro-retina-13-a1502-x304-mlb-820-4924-schem...
Takashi
Olliver
On 16-05-2023 20:31, Takashi Iwai wrote:
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
[ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 [ 90.497008] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; } -static const char * const channel_name[4] = {
- "Front", "Surround", "CLFE", "Side"
+static const char * const channel_name[] = {
- "Front", "Surround", "CLFE", "Side", "Back", }; /* give some appropriate ctl name prefix for the given line out
channel */ @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
case AUTO_PIN_SPEAKER_OUT:goto fixed_name; switch (cfg->line_out_type) {
@@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
- fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
On Thu, 18 May 2023 17:11:53 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 18-05-2023 16:27, Takashi Iwai wrote:
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Ok, so no easy way :) I did try copying things, but didn't get sound either.
I did find the schematics for the 2013 and 2014 models of the macbook; no luck yet on the 2015 (mine). But all 3 have the same model number (A1502), and looking at the schematic (not even sure if it is just a new revision, or actually for the different boards) they seem more or less identical. Especially on the audio part. The nice thing is it tells me what pins things are connected to :) But again, might not be a perfect match to my board (crosses fingers).
What is interesting, the schematics [0] actually list the HDA configuration.
CODEC OUTPUT SIGNAL PATHS
FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL
HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A
DMIC 1 0x09 (9) 0x1c (18) DMIC 2 0x09 (9) 0x1c (18)
HEADSET MIC 0x07 (7) 0x18 (24)
OTHER CODEC GPIO LINES LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN
Granted, that should yield the same infomration I can copy from the other one, but I'm trying to understand what this would mean. Function is obvious, aswell as the pin-complex, it's what hdajackretasks calls pin ID. But the rest is a bit iffy. E.g. what would the volume column indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's of the codec? Maybe my confusion mostly comes as I'm not sure how to relate those fields to hdajackretask.
It's a good information. It corresponds to spec->gpio_eapd_speaker, and GPIO2 would be the bit 0x04, GPIO3 would be 0x08, so it should be set to 0x0c. The headphone has no GPIO assignment, so spec->gpio_eapd_headphone=0.
But subwoofers seem to have the GPIO controls as well, and the gpio bit 0x01 should be set. For that, we'll need to modify cs_automute() function. But let's investigate this later.
FWIW, the GPIO bits can be flipped on the fly, too. Use hda-verb for setting SET_GPIO_MASK, SET_GPIO_DIRECTION and SET_GPIO_DATA.
Takashi
Olliver
Takashi
Olliver
On 16-05-2023 20:31, Takashi Iwai wrote:
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
> [ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted > 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 > [ 90.497008] Hardware name: Apple > Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 > [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 > [snd_hda_codec_generic]
Can you try to decode which line does it hit?
This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
Also, as a blind shot, does the patch below work around the bug?
[ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; } -static const char * const channel_name[4] = {
- "Front", "Surround", "CLFE", "Side"
+static const char * const channel_name[] = {
- "Front", "Surround", "CLFE", "Side", "Back", }; /* give some appropriate ctl name prefix for the given line out
channel */ @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
case AUTO_PIN_SPEAKER_OUT:goto fixed_name; switch (cfg->line_out_type) {
@@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out";
- fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
Hey Takashi,
On 19-05-2023 09:12, Takashi Iwai wrote:
On Thu, 18 May 2023 17:11:53 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 18-05-2023 16:27, Takashi Iwai wrote:
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Ok, so no easy way :) I did try copying things, but didn't get sound either.
I did find the schematics for the 2013 and 2014 models of the macbook; no luck yet on the 2015 (mine). But all 3 have the same model number (A1502), and looking at the schematic (not even sure if it is just a new revision, or actually for the different boards) they seem more or less identical. Especially on the audio part. The nice thing is it tells me what pins things are connected to :) But again, might not be a perfect match to my board (crosses fingers).
What is interesting, the schematics [0] actually list the HDA configuration.
CODEC OUTPUT SIGNAL PATHS
FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL
HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A
DMIC 1 0x09 (9) 0x1c (18) DMIC 2 0x09 (9) 0x1c (18)
HEADSET MIC 0x07 (7) 0x18 (24)
OTHER CODEC GPIO LINES LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN
Granted, that should yield the same infomration I can copy from the other one, but I'm trying to understand what this would mean. Function is obvious, aswell as the pin-complex, it's what hdajackretasks calls pin ID. But the rest is a bit iffy. E.g. what would the volume column indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's of the codec? Maybe my confusion mostly comes as I'm not sure how to relate those fields to hdajackretask.
It's a good information. It corresponds to spec->gpio_eapd_speaker, and GPIO2 would be the bit 0x04, GPIO3 would be 0x08, so it should be set to 0x0c. The headphone has no GPIO assignment, so spec->gpio_eapd_headphone=0.
But subwoofers seem to have the GPIO controls as well, and the gpio bit 0x01 should be set. For that, we'll need to modify cs_automute() function. But let's investigate this later.
FWIW, the GPIO bits can be flipped on the fly, too. Use hda-verb for setting SET_GPIO_MASK, SET_GPIO_DIRECTION and SET_GPIO_DATA.
Thanks for that explanation! Great news. I don't know how; but I managed to 'fix' the bios. Strange yeah. I wanted to create an uefi boot image as that's something arch's mkinitcpio appearantly supports. So I used efiboomgr to add an additional entry.
After a reboot, I regained the apple logo at boot (which was gone for ages), but also the boot chime returned. And for sure, in Linux also sound is working again normally. I have no idea how or why this works, but it does.
For reference, this is what 6.3.x now shows:
[ 15.642288] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=2 (0x12/0x13/0x0/0x0/0x0) type:speaker [ 15.642296] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.642299] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 15.642301] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 15.642303] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x21/0x0 [ 15.642305] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 15.642307] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 15.642309] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 15.735257] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
And hdajackretask (without unconnected pins): Pin ID: 0x10 [Green Headphone] Jack; External; Headphone; Combination; Green; Present; 2; Front;
Pin ID: 0x12 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x13 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x18 [Pink Mic] Jack; External; Microphone; Combination; Pink; Present; 4; Front;
Pin ID: 0x1c [Internal Mic] <blank>; Internal; Microphone; Other Digital; Unknown; Not present; <blank>; Front
Pin ID: 0x21 [White SPDIF Out] Jack; External; SPIDF Out; Combination; White; Present; 3; Front;
The blank connectivity options are a bit off, as is the blank channel group on the internal mic.
So curious on those ...
Anyway, leaving this here for any future in case it is needed again.
Olliver
Takashi
Olliver
Takashi
Olliver
On 16-05-2023 20:31, Takashi Iwai wrote:
On Tue, 16 May 2023 18:49:55 +0200, Olliver Schinagl wrote:
Hey Takashi,
>> [ 90.497004] CPU: 3 PID: 343 Comm: modprobe Not tainted >> 6.3.1-arch2-1 #1 4c16b0b90f71a940c7f1bb2eb00cdd9db2a83452 >> [ 90.497008] Hardware name: Apple >> Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS 481.0.0.0.0 01/12/2023 >> [ 90.497010] RIP: 0010:get_line_out_pfx+0x2dd/0x3e0 >> [snd_hda_codec_generic] > > Can you try to decode which line does it hit? This was the arch 'vendor' kernel, so not easily? I could have tried though I suppose :)
Instead, I just applied your patch and tried that instead.
> > Also, as a blind shot, does the patch below work around the bug? [ 16.593760] 0x000000000000-0x000000800000 : "BIOS" [ 16.603877] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=5 (0x11/0x12/0x13/0x14/0x1d) type:speaker [ 16.603885] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 16.603888] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 16.603890] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 16.603892] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x1e/0x21 [ 16.603894] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 16.603895] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x16 [ 16.603897] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x15 [ 16.603899] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 16.603900] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 16.603902] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1a [ 16.603904] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1b [ 16.603919] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 16.603921] snd_hda_codec_cirrus hdaudioC1D0: Line=0x17 [ 16.603922] snd_hda_codec_cirrus hdaudioC1D0: dig-in=0x22 [ 16.605152] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4 [ 16.605215] snd_hda_codec_cirrus hdaudioC1D0: Too many channels in get_line_out_pfx: 4
the good thing, you fixed the oops; the bad thing, it's no working, but hopefully this helps you gain more insight?
Below is a bit better patch for fixing the Oops.
But, judging from the output above, I guess it won't help completely, because the pin configuration looks broken; e.g. it reports too many "Internal Mic" pins (which must be only one usually).
That said, the actual breakage (except for kernel Oops) is the pin config set by BIOS. Maybe it doesn't set up things properly *at all* You'll need to correct it by providing the full pin config with a quirk table. And for that, you'll need to figure out the pins via trial-and-error, for example, with the help of hdajackretask.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
Reported-by: Olliver Schinagl oliver@schinagl.nl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index fc114e522480..dbf7aa88e0e3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1155,8 +1155,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; } -static const char * const channel_name[4] = {
- "Front", "Surround", "CLFE", "Side"
+static const char * const channel_name[] = {
- "Front", "Surround", "CLFE", "Side", "Back", }; /* give some appropriate ctl name prefix for the given line out
channel */ @@ -1182,7 +1182,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* multi-io channels */ if (ch >= cfg->line_outs)
return channel_name[ch];
goto fixed_name; switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT:
@@ -1234,6 +1234,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out"; + fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM";
On Fri, 19 May 2023 18:53:16 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 19-05-2023 09:12, Takashi Iwai wrote:
On Thu, 18 May 2023 17:11:53 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 18-05-2023 16:27, Takashi Iwai wrote:
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Ok, so no easy way :) I did try copying things, but didn't get sound either.
I did find the schematics for the 2013 and 2014 models of the macbook; no luck yet on the 2015 (mine). But all 3 have the same model number (A1502), and looking at the schematic (not even sure if it is just a new revision, or actually for the different boards) they seem more or less identical. Especially on the audio part. The nice thing is it tells me what pins things are connected to :) But again, might not be a perfect match to my board (crosses fingers).
What is interesting, the schematics [0] actually list the HDA configuration.
CODEC OUTPUT SIGNAL PATHS
FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL
HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A
DMIC 1 0x09 (9) 0x1c (18) DMIC 2 0x09 (9) 0x1c (18)
HEADSET MIC 0x07 (7) 0x18 (24)
OTHER CODEC GPIO LINES LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN
Granted, that should yield the same infomration I can copy from the other one, but I'm trying to understand what this would mean. Function is obvious, aswell as the pin-complex, it's what hdajackretasks calls pin ID. But the rest is a bit iffy. E.g. what would the volume column indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's of the codec? Maybe my confusion mostly comes as I'm not sure how to relate those fields to hdajackretask.
It's a good information. It corresponds to spec->gpio_eapd_speaker, and GPIO2 would be the bit 0x04, GPIO3 would be 0x08, so it should be set to 0x0c. The headphone has no GPIO assignment, so spec->gpio_eapd_headphone=0.
But subwoofers seem to have the GPIO controls as well, and the gpio bit 0x01 should be set. For that, we'll need to modify cs_automute() function. But let's investigate this later.
FWIW, the GPIO bits can be flipped on the fly, too. Use hda-verb for setting SET_GPIO_MASK, SET_GPIO_DIRECTION and SET_GPIO_DATA.
Thanks for that explanation! Great news. I don't know how; but I managed to 'fix' the bios. Strange yeah. I wanted to create an uefi boot image as that's something arch's mkinitcpio appearantly supports. So I used efiboomgr to add an additional entry.
After a reboot, I regained the apple logo at boot (which was gone for ages), but also the boot chime returned. And for sure, in Linux also sound is working again normally. I have no idea how or why this works, but it does.
For reference, this is what 6.3.x now shows:
[ 15.642288] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=2 (0x12/0x13/0x0/0x0/0x0) type:speaker [ 15.642296] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.642299] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 15.642301] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 15.642303] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x21/0x0 [ 15.642305] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 15.642307] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 15.642309] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 15.735257] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
And hdajackretask (without unconnected pins): Pin ID: 0x10 [Green Headphone] Jack; External; Headphone; Combination; Green; Present; 2; Front;
Pin ID: 0x12 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x13 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x18 [Pink Mic] Jack; External; Microphone; Combination; Pink; Present; 4; Front;
Pin ID: 0x1c [Internal Mic] <blank>; Internal; Microphone; Other Digital; Unknown; Not present; <blank>; Front
Pin ID: 0x21 [White SPDIF Out] Jack; External; SPIDF Out; Combination; White; Present; 3; Front;
The blank connectivity options are a bit off, as is the blank channel group on the internal mic.
So curious on those ...
Anyway, leaving this here for any future in case it is needed again.
Good to hear that you managed to recover BIOS.
Could you give alsa-info.sh output from the working state? Run the script with --no-upload option and attach the output. This will help in future if it gets broken again :)
thanks,
Takashi
Hey Takashi,
On 20-05-2023 10:02, Takashi Iwai wrote:
On Fri, 19 May 2023 18:53:16 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 19-05-2023 09:12, Takashi Iwai wrote:
On Thu, 18 May 2023 17:11:53 +0200, Olliver Schinagl wrote:
Hey Takashi,
On 18-05-2023 16:27, Takashi Iwai wrote:
On Thu, 18 May 2023 16:24:02 +0200, Olliver Schinagl wrote:
Hey Takashi,
I've applied the patch you've listed below. Is there some 'fool-proof' way to produce _any_ output however? I've stopped pulse/pipe audio, and only use aplay + alsamixer. Back to basics as they say. For aplay, I use -D sysdefault:CARD=PCH (which was listed as a cirrus card with -L).
Alsamixer was used to ensure all volumes are open.
Without anything running, I was able to use hdajackretask to apply settings. But then, what to put. I get that I have to figure out, what is routed where (i'll try to find the schematic for the macbook pro 12,1), but hence my question, is there some way to produce something? In hdajackretask I've enabled all pins, overriden them all, and set them all to the same configuration. 'Internal, internal, speaker, other-analog, green, not-present, 1, front'. I figured, by setting up verything to the internal speaker, I must get sound out of something, but alas.
I also have a Macbook pro from 1 or 2 generations earlier, 11,2 afaik, where the sound still does work. I've used the same config hdajackretask showed was in use there, but (obviously?) that didn't work.
So I'm a bit grasping at straws. Trying _every_ combination is a bit much?
It's the hard part. I'd try to copy the pin config of the existing models at first, then try shooting one pin by one if it doesn't work.
Ok, so no easy way :) I did try copying things, but didn't get sound either.
I did find the schematics for the 2013 and 2014 models of the macbook; no luck yet on the 2015 (mine). But all 3 have the same model number (A1502), and looking at the schematic (not even sure if it is just a new revision, or actually for the different boards) they seem more or less identical. Especially on the audio part. The nice thing is it tells me what pins things are connected to :) But again, might not be a perfect match to my board (crosses fingers).
What is interesting, the schematics [0] actually list the HDA configuration.
CODEC OUTPUT SIGNAL PATHS
FUNCTION VOLUME CONVERTER PIN COMPLEX MUTE CONTROL
HP/HS OUT 0x02 (2) 0x02 (2) 0x10 (16) N/A TWEETERS 0x03 (3) 0x03 (3) 0x12 (18) CODEC GPIO0 SUB 0x04 (4) 0x04 (4) 0x13 (19) CODEC GPIO0 SPDIF OUT N/A 0x0e (14) 0x21 (33) N/A
DMIC 1 0x09 (9) 0x1c (18) DMIC 2 0x09 (9) 0x1c (18)
HEADSET MIC 0x07 (7) 0x18 (24)
OTHER CODEC GPIO LINES LEFT SPEAKER ID GPIO2 INPUT HIGH = FG, LOW = MERRY RIGHT SPEAKER ID GPIO3 INPUT HIGH = FG, LOW = MERRY DFET CONTROL GPIO4 OUTPUT HIGH = DFETs OPEN
Granted, that should yield the same infomration I can copy from the other one, but I'm trying to understand what this would mean. Function is obvious, aswell as the pin-complex, it's what hdajackretasks calls pin ID. But the rest is a bit iffy. E.g. what would the volume column indicate? What about the 'converter'? And the GPIO's? Are the's GPIO's of the codec? Maybe my confusion mostly comes as I'm not sure how to relate those fields to hdajackretask.
It's a good information. It corresponds to spec->gpio_eapd_speaker, and GPIO2 would be the bit 0x04, GPIO3 would be 0x08, so it should be set to 0x0c. The headphone has no GPIO assignment, so spec->gpio_eapd_headphone=0.
But subwoofers seem to have the GPIO controls as well, and the gpio bit 0x01 should be set. For that, we'll need to modify cs_automute() function. But let's investigate this later.
FWIW, the GPIO bits can be flipped on the fly, too. Use hda-verb for setting SET_GPIO_MASK, SET_GPIO_DIRECTION and SET_GPIO_DATA.
Thanks for that explanation! Great news. I don't know how; but I managed to 'fix' the bios. Strange yeah. I wanted to create an uefi boot image as that's something arch's mkinitcpio appearantly supports. So I used efiboomgr to add an additional entry.
After a reboot, I regained the apple logo at boot (which was gone for ages), but also the boot chime returned. And for sure, in Linux also sound is working again normally. I have no idea how or why this works, but it does.
For reference, this is what 6.3.x now shows:
[ 15.642288] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=2 (0x12/0x13/0x0/0x0/0x0) type:speaker [ 15.642296] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.642299] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 15.642301] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 15.642303] snd_hda_codec_cirrus hdaudioC1D0: dig-out=0x21/0x0 [ 15.642305] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 15.642307] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x1c [ 15.642309] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 [ 15.735257] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
And hdajackretask (without unconnected pins): Pin ID: 0x10 [Green Headphone] Jack; External; Headphone; Combination; Green; Present; 2; Front;
Pin ID: 0x12 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x13 [Internal Speaker] <blank>; Internal; Speaker; Unknown; Unknown; Not present; 1; Back;
Pin ID: 0x18 [Pink Mic] Jack; External; Microphone; Combination; Pink; Present; 4; Front;
Pin ID: 0x1c [Internal Mic] <blank>; Internal; Microphone; Other Digital; Unknown; Not present; <blank>; Front
Pin ID: 0x21 [White SPDIF Out] Jack; External; SPIDF Out; Combination; White; Present; 3; Front;
The blank connectivity options are a bit off, as is the blank channel group on the internal mic.
So curious on those ...
Anyway, leaving this here for any future in case it is needed again.
Good to hear that you managed to recover BIOS.
Could you give alsa-info.sh output from the working state? Run the script with --no-upload option and attach the output. This will help in future if it gets broken again :)
That's even better then what I wrote :p File is attached!
thanks,
Takashi
participants (2)
-
Olliver Schinagl
-
Takashi Iwai