Created attachment 288415 [details] alsa-info.sh output When upgrading from 5.5.13 to 5.6, NVidia HDMI audio stops working. The card is still there with all controls in alsamixer, but there is no sound output. Downgrading to 5.5.13 solves the issue. The problem was initially observed on linux-5.6.2-arch1-1 from the Arch Linux repositories. I compiled 5.7.0-rc1 for testing purposes, which shows the same behavior as 5.6. Speaker-test reports the following: $ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1 speaker-test 1.2.2 Playback device is hdmi:CARD=NVidia,DEV=1 Stream parameters are 48000Hz, S16_LE, 6 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 8544000 Period size range from 32 to 4272000 Using max buffer size 8544000 Periods = 4 Unable to set hw params for playback: Cannot allocate memory Setting of hwparams failed: Cannot allocate memory
It's the first report, and currently I have no clue what went south. Could you try bisecting?
BTW, the max buffer size shown in speaker-test looks very large. Is it same for both working and non-working cases?
I will have a go at bisecting tonight. There seems to be at least one other user affected at https://bbs.archlinux.org/viewtopic.php?id=254507 Speaker-test on the working kernel (5.5.13-arch2-1) shows smaller buffer sizes indeed: $ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1 speaker-test 1.2.2 Playback device is hdmi:CARD=NVidia,DEV=1 Stream parameters are 48000Hz, S16_LE, 6 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 349504 Period size range from 32 to 174752 Using max buffer size 349504 Periods = 4 was set period_size = 174752 was set buffer_size = 349504 0 - Front Left 4 - Front Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 23.013076
OK, if the memory size differs: do you happen to set 0 to CONFIG_SND_HDA_PREALLOC_SIZE? That would explain. It'll allow the memory allocation up to 32MB, and the application tries to allocate the max size and fails. Please try to set 1024 or 2048 (corresponds to 1MB / 2MB) and see whether it makes working.
Ah, wait... This can't be set explicitly any longer, and that's the cause of the regression. Please try reverting c31427d0d21e198c74d5d92082c4b8194b257f82, and set the old CONFIG_SND_HDA_PREALLOC_SIZE used for 5.5 kernel. I guess we need to revert the commit, but increase the default size instead.
Created attachment 288427 [details] alsa-info.sh v5.7-rc1 with c31427d reverted
Ok, reverting that commit on v5.7-rc1 and setting CONFIG_SND_HDA_PREALLOC_SIZE=4096 (value from working 5.5.13 config) fixed the memory allocation issue, but unfortunately still no sound... Speaker-test now reports the following: $ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1 speaker-test 1.2.2 Playback device is hdmi:CARD=NVidia,DEV=1 Stream parameters are 48000Hz, S16_LE, 6 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 349504 Period size range from 32 to 174752 Using max buffer size 349504 Periods = 4 was set period_size = 174752 was set buffer_size = 349504 0 - Unknown 1 - Unknown 2 - Unknown 3 - Unknown 4 - Unknown 5 - Unknown Time per period = 21.996715 I will do some more testing/reverting on earlier versions soon.
Hm, then there must be another reason. But at least we should revert and change the default again. The patch I'm going to submit is below.
Created attachment 288429 [details] Patch for fixing kconfig CONFIG_SND_HDA_PREALLOC_SIZE
Created attachment 288455 [details] git bisect log Git bisect points to 742db30c4ee6cd28142e83e154b5271f95a2c67a as the culprit. The log is slightly longer than strictly necessary, I mixed up one good/bad somewhere in the process and had to replay. All bisect builds were tested with c31427d0d21e198c74d5d92082c4b8194b257f82 reverted where necessary and CONFIG_SND_HDA_PREALLOC_SIZE=4096. On "good" builds, speaker-test reported no errors and gave correct channel names. On "bad" builds, the channel names were all "Unknown" and did not produce any sound, though no error was reported in this case either.
One more test result: building v5.7-rc1 with c31427d0d21e198c74d5d92082c4b8194b257f82 and 742db30c4ee6cd28142e83e154b5271f95a2c67a reverted works without any of the mentioned issues. It gives me sound again and the channel names in speaker-test are correct.
Thanks for bisection. Just to be sure, which driver are you testing, nouveau or Nvidia binary-only? Please give alsa-info.sh outputs on both working and non-working cases.
Created attachment 288467 [details] alsa-info.sh output in working state Attached here is the output from alsa-info.sh on v5.7-rc1 with both c31427d0d21e198c74d5d92082c4b8194b257f82 and 742db30c4ee6cd28142e83e154b5271f95a2c67a reverted. This produces a kernel with working sound as expected. I am using nouveau (never installed the nvidia driver) and according to https://bbs.archlinux.org/viewtopic.php?id=254507 the nvidia driver is not affected. Below is the output from alsa-info.sh on v5.7-rc1 with only c31427d0d21e198c74d5d92082c4b8194b257f82 reverted to address the memory allocation issue. In this scenario, there is no sound output and all channel names in speaker-test are "Unknown" as seen earlier in this thread.
Created attachment 288469 [details] alsa-info.sh output in broken state
Comparing those two outputs shows that "HDMI/DP,pcm=X Jack" on Nvidia exactly inverted value: pcm=7 showed true and and others false in the working case, while pcm=7 showed false and others true in the broken case. If my understanding is correct, this value is directly delivered from nv50_audio_component_get_eld(), and it invokes drm_detect_monitor_audio() for each inquired port and stores the returned value. That is, the possible culprit is: either - Something wrong in nv_connector->edid values, - drm_detect_monitor_audio() is broken for your device, or - we're looking at a wrong information It's still puzzling why all values are inverted. Hmm. Could you check the EDID values from sysfs?
Created attachment 288477 [details] edid on affected HDMI port See attachment, dump was taken in broken state (v5.7-rc1 with only the memory allocation fix).
Let's check whether the code executed in nouveau returning the expected value. Please try the debug patch below and see what values are shown.
Created attachment 288479 [details] test debug patch
Takashi, I can see this too with a test equipment for a nouveau driver: - MST is activated in the audio driver, but it seems that it does not match the video driver state (4 MST audio devices have "joined" state because audio component does not send the proper MST device id - value -1 is used!) - dynamic PCM assignments are enabled with the nvidia patch code (not a real problem, makes debugging a bit harder) - physical video port mapping to HDA NID mapping fails for my test platform (it seems that wrong value is used on the video driver side (shift by 6 not 4 port2pin mapping)
Good that you have equipment for testing / debugging! I'm locked without those (my Nvidia machine is in the office), so couldn't test anything for now. MST might be indeed a problem that was added recently. My original patch has been tested without MST in the past, admittedly.
Created attachment 288481 [details] dmesg output with debug patch Dmesg output from the debug patch is attached. I had to edit the third hunk slightly, as nv_connector is not declared in nv50_audio_disable. I used the line below instead, but it looks like it's not being called anyway: + pr_info("XXX audio disable: index=%d, encoder=%p, crtc=%p\n", + nv_crtc->index, encoder, nv_crtc);
Thanks. Could you give alsa-info.sh output again after this plugged state? I'm afraid that the mapping between the crtc index and the HDA pin on yours isn't straightforward like my tested device. That can be tough.
Same problem here for both sound devices, on-board analog and HDMI (AMDGPU driver) on kernel 5.6.3 artix/arch. `$ speaker-test -D <device> -c 2` with `<device>` being: - `hw:0,3` (HDMI) - `hw:1,0` (on-board sound-card) - `default` (mapped to `hw:0,3` by config) all fail saying: ``` Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 8544000 Period size range from 32 to 4272000 Using max buffer size 8544000 Periods = 4 Unable to set hw params for playback: Cannot allocate memory Setting of hwparams failed: Cannot allocate memory ``` All do work though when buffer size is limited with "--buffer 2000"
Takashi, what do you mean exactly by "plugged state"?
Created attachment 288487 [details] Output of asla-info.sh
(In reply to schopdiedwaas from comment #24) > Takashi, what do you mean exactly by "plugged state"? I meant the moment you got alsa-info.sh output, i.e. the status with the monitor connection. But never mind, I think I see now the culprit. Could you try the patch below?
Created attachment 288489 [details] Test fix for nouveau audio
... and if the patch doesn't work, please check what values nv_encoder->or and nv_crtc->index have.
(In reply to contact from comment #23) > Same problem here for both sound devices, on-board analog and HDMI (AMDGPU > driver) on kernel 5.6.3 artix/arch. > > `$ speaker-test -D <device> -c 2` (snip) > Setting of hwparams failed: Cannot allocate memory This should be fixed by the patch in comment 9 and setting CONFIG_SND_HDA_PREALLOC_SIZE to 2048 or whatever reasonable value.
Created attachment 288495 [details] alsa-info.sh output after patch The patch from comment 27 seems to fix the issue. Sound is working and speaker-test reports normal channel names. Output from alsa-info.sh after the fix is attached. $ speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1 speaker-test 1.2.2 Playback device is hdmi:CARD=NVidia,DEV=1 Stream parameters are 48000Hz, S16_LE, 6 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 349504 Period size range from 32 to 174752 Using max buffer size 349504 Periods = 4 was set period_size = 174752 was set buffer_size = 349504 0 - Front Left 4 - Front Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 22.008309
Thank you for the MST port / device id fix. But the patch does not resolve issue for my platform. Notifications with debug prints: [ 24.426589] XXX: Notify port = 0 dev_id = 0 [ 24.426599] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 4 not registered [ 25.884095] XXX: Notify port = 0 dev_id = 0 [ 25.884099] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 4 not registered [ 27.500536] rfkill: input handler disabled The correct NIDs are 6 and 7 (confirmed with the proprietary driver). We need to find a way to dermine this physical output connection in the nouveau driver.
Is NID 0x04 a valid pin widget? Or does your HDMI codec have different widget layout? Please give alsa-info.sh output.
Created attachment 288497 [details] Proper fix patch for nouveau audio The same patch as the previous one but with a proper changelog.
Hmm, this laptop has HDMI and miniDP ports, both are reported as port 0 / dev_id 0 to the audio driver (see above; added encoder->link print): XXX: get or/port = 0 index/dev_id = 0 (link = 1) Something is missing in the video driver... The output are identified as [CONNECTOR:127:DP-3] - HDMI connector and [CONNECTOR:91:DP-4] - miniDP connector. If you have a hint, where to read the correct values, I can give a try. Codec NIDs: Node 0x04 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Devices: 4 *Dev 00: PD = 1, ELDV = 1, IA = 0 Dev 01: PD = 0, ELDV = 0, IA = 0 Dev 02: PD = 0, ELDV = 0, IA = 0 Dev 03: PD = 0, ELDV = 0, IA = 0 Connection: 4 0x08* 0x09 0x0a 0x0b Node 0x05 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Devices: 4 *Dev 00: PD = 0, ELDV = 0, IA = 0 Dev 01: PD = 0, ELDV = 0, IA = 0 Dev 02: PD = 0, ELDV = 0, IA = 0 Dev 03: PD = 0, ELDV = 0, IA = 0 Connection: 4 0x08* 0x09 0x0a 0x0b Node 0x06 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Devices: 4 Dev 00: PD = 0, ELDV = 0, IA = 0 Dev 01: PD = 0, ELDV = 0, IA = 0 Dev 02: PD = 0, ELDV = 0, IA = 0 *Dev 03: PD = 0, ELDV = 0, IA = 0 Connection: 4 0x08* 0x09 0x0a 0x0b Node 0x07 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Devices: 4 Dev 00: PD = 0, ELDV = 0, IA = 0 Dev 01: PD = 0, ELDV = 0, IA = 0 Dev 02: PD = 0, ELDV = 0, IA = 0 *Dev 03: PD = 0, ELDV = 0, IA = 0 Connection: 4 0x08* 0x09 0x0a 0x0b
Judging from the output, I guess the audio has never worked on yours with nouveau. The PD=1 indicates that nouveau enabled already the wrong one. Disabling the audio component in HD-audio side is easy, just comment out the call of generic_acomp_init() in patch_nvhdmi(). Could you confirm that it's broken no matter whether the audio component is used or not?
Also, it might be interesting not to skip the port NONE. --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1695,9 +1695,11 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid) * For DP MST audio, Configuration Default is the same for * all device entries on the same pin */ +#if 0 config = snd_hda_codec_get_pincfg(codec, pin_nid); if (get_defcfg_connect(config) == AC_JACK_PORT_NONE) return 0; +#endif /* * To simplify the implementation, malloc all
(In reply to Takashi Iwai from comment #35) > Disabling the audio component in HD-audio side is easy, just comment out the > call of generic_acomp_init() in patch_nvhdmi(). The patch below adds the module option to control it, too, for convenience.
Created attachment 288501 [details] Patch to add a module option to disable audio component binding
Ok, after some more debugging, I feel that the audio component part is incomplete. My hw has those connectors: [ 5.383622] XXX: crtcs = 0xf [ 5.383819] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf82, hasht = 0x6 [ 5.383994] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf44, hasht = 0x6 [ 5.404307] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf44, hasht = 0x2 [ 5.404335] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf42, hasht = 0x2 [ 5.404566] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf41, hasht = 0x6 [ 5.425802] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf41, hasht = 0x2 [ 5.426078] XXX: dcbe->location = 0, type = 6, heads = 15, hashm = 0xf81, hasht = 0x6 [ 5.448789] XXX: dcbe->location = 0, type = 2, heads = 15, hashm = 0xf41, hasht = 0x2 Type 6 means the DP output. As you see, the only difference between the output physical connectors are hashes (thus index / or fields are zero): [ 25.440828] XXX: hdmi_enable: hasht = 0x2, hashm = 0xf42, index = 0 [ 25.440860] XXX: audio_enable: hasht = 0x2, hashm = 0xf42, index = 0 [ 25.440861] XXX: Notify port = 0 dev_id = 0 [ 26.391381] XXX: hdmi_enable: hasht = 0x2, hashm = 0xf44, index = 0 [ 26.391414] XXX: audio_enable: hasht = 0x2, hashm = 0xf44, index = 0 [ 26.391415] XXX: Notify port = 0 dev_id = 0 I will print more struct dcb_output fields, perhaps, the hints are there.
[ 5.456880] XXX: crtcs = 0xf [ 5.457169] XXX: dcbe->location = 0, type = 6, heads = 15 [ 5.457170] XXX: hashm = 0xf82, hasht = 0x6 [ 5.457171] XXX: connector = 0x3, bus = 0x0, location = 0x0 [ 5.457172] XXX: or = 2, link = 0 [ 5.457410] XXX: dcbe->location = 0, type = 6, heads = 15 [ 5.457412] XXX: hashm = 0xf44, hasht = 0x6 [ 5.457413] XXX: connector = 0x4, bus = 0x2, location = 0x0 [ 5.457414] XXX: or = 4, link = 0 [ 5.478858] XXX: dcbe->location = 0, type = 2, heads = 15 [ 5.478859] XXX: hashm = 0xf44, hasht = 0x2 [ 5.478861] XXX: connector = 0x4, bus = 0x2, location = 0x0 [ 5.478862] XXX: or = 4, link = 0 [ 5.478874] XXX: dcbe->location = 0, type = 2, heads = 15 [ 5.478875] XXX: hashm = 0xf42, hasht = 0x2 [ 5.478876] XXX: connector = 0x2, bus = 0x1, location = 0x0 [ 5.478877] XXX: or = 2, link = 0 [ 5.479023] XXX: dcbe->location = 0, type = 6, heads = 15 [ 5.479025] XXX: hashm = 0xf41, hasht = 0x6 [ 5.479026] XXX: connector = 0x0, bus = 0x3, location = 0x0 [ 5.479028] XXX: or = 1, link = 0 [ 5.498373] XXX: dcbe->location = 0, type = 2, heads = 15 [ 5.498375] XXX: hashm = 0xf41, hasht = 0x2 [ 5.498376] XXX: connector = 0x0, bus = 0x3, location = 0x0 [ 5.498377] XXX: or = 1, link = 0 [ 5.498501] XXX: dcbe->location = 0, type = 6, heads = 15 [ 5.498502] XXX: hashm = 0xf81, hasht = 0x6 [ 5.498503] XXX: connector = 0x1, bus = 0x4, location = 0x0 [ 5.498505] XXX: or = 1, link = 0 [ 5.517871] XXX: dcbe->location = 0, type = 2, heads = 15 [ 5.517872] XXX: hashm = 0xf41, hasht = 0x2 [ 5.517873] XXX: connector = 0x1, bus = 0x4, location = 0x0 [ 5.517875] XXX: or = 1, link = 0
Does the audio work with nouveau driver on your device at all? If yes, we can have a chance to fix for the audio component, too. As far as I see the nouveau driver sets the audio register bits in either gf119_hda_hpd() and gt215_hda_hpd(). And it receives the encoded hidx in the passed hashm, which is equal with nv_crtc->index. So I see no difference in the HPD/ELD handling without the audio component...
> Does the audio work with nouveau driver on your device at all? I was not able to get audio with the nouveau. So no regression. It works with the propriatery driver which uses HDA PIN NIDs 0x06 and 0x07. The workaround from comment#36 (skip pincfg from BIOS) makes the ELD detection / HDMI device working but no sound. It seems that a route / initialization is missing in nouveau for the TU117 chip.
OK, then I'm going to submit my last fix to DRM guys. The fix for CONFIG_SND_HDA_PREALLOC_SIZE was already merged to sound git tree, the PR to Linus is planned for tomorrow to be merged in 5.7-rc2. Jaroslav, could you open the report on freedesktop gitlab issues for the remaining problem of your device? It's a nouveau problem and should be handled there.
It seems that it's almost impossible to fill a nouveau bug. Freedesktop bugzilla is closed and gitlab does not have the nouveau driver project. I'll try to contact Ben directly. Just for the record purposes: The patch bellow will skip SOR 0 and 1 (which makes ELD pass / monitor detection working without the workaround in the audio driver, but it does not fix audio): diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c index b0597ff9a714..a022f9ed15f4 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c @@ -117,5 +117,6 @@ gv100_sor_cnt(struct nvkm_disp *disp, unsigned long *pmask) { struct nvkm_device *device = disp->engine.subdev.device; *pmask = (nvkm_rd32(device, 0x610060) & 0x0000ff00) >> 8; + *pmask = 0x0c; return (nvkm_rd32(device, 0x610074) & 0x00000f00) >> 8; }
Hello, I am just a user, but I send you messages from my system in case I gave you a clue of what is happening. Excuse my poor English All kernels before kernel 5.6 the Mate Desktop sound preferences show that my only profile is "Digital Stereo (HDMI 2) Output" But with kernel 5.6 the Mate Desktop sound preferences show just the opposite, all profiles but not HDMI 2: "Digital Stereo (HDMI) Output", "Digital Stereo (HDMI 3) Output", "Digital Stereo (HDMI 4) Output", "Digital Stereo (HDMI 5) Output" Is it problem with a boolean? $ lspci 01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) Thanks
The regression itself has been addressed, so let's close the bug here.
I moved in Debian testing from kernel 5.6.7 to kernel 5.6.14 and the problem persists
(In reply to alex from comment #47) > I moved in Debian testing from kernel 5.6.7 to kernel 5.6.14 and the problem > persists Please be patient. The fix is applied in the nouveau repo and now has to make its way into the main kernel repo. As of linux 5.7 this did not happen yet, so don't expect a fix before 5.7.x or even 5.8.
Why has this not landed in 5.6.x series yet? I think this is a serious bug.
The last fix is present in 5.7.6. Normal sound is working again, but I still have to provide a buffer size to speaker-test. Looks like the CONFIG_SND_HDA_PREALLOC_SIZE patch from #9 has not made it into the 5.7.x branch yet.
Working fine in Debian Testing with kernel 5.7.6 . Fixed
Actually the patch in comment #9 doesn't fix the things. It allows to set back to the right value, while the value 0 is still allowed and kept until the distro corrects the kconfig again.
I confirm that it works with kernel 5.7.8(-200) on Fedora 32.