From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D18FBC61DA4 for ; Thu, 9 Feb 2023 19:23:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229653AbjBITXJ (ORCPT ); Thu, 9 Feb 2023 14:23:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbjBITXI (ORCPT ); Thu, 9 Feb 2023 14:23:08 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 983266950E for ; Thu, 9 Feb 2023 11:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675970539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=odjslzgfJQeZsYkFt34EcHS3ke09IOK/EQikeuKIQN0=; b=i+x9EPH6csOSIHbOw42cb5mtcRM6aw0kAx3K1E46ysd4w84cZDVwkkeMKOrgNUPvkgcnWB RjWCqL3lT93Uwq3nbLZGRK1EuO1zPSsTA+UjEgNUKJnPr2Niyc9pitEv5ZFHRVOH/6c69Q gPbC3PiYflcgrwMFqt7okK7ziYQm5JQ= Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-561-PUlhfmDhOrC7UP9wUgweFg-1; Thu, 09 Feb 2023 14:22:18 -0500 X-MC-Unique: PUlhfmDhOrC7UP9wUgweFg-1 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-4fa63c84621so28232537b3.20 for ; Thu, 09 Feb 2023 11:22:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=odjslzgfJQeZsYkFt34EcHS3ke09IOK/EQikeuKIQN0=; b=p+/whT9JGQdYSOm70ulColN8gawM5APQR0FYC3b1BmbRSXrKGnmzAOV/EBehPU4UMa 9n2NCdO+SrlA/UfbffXXtJ6WTZsCEy3WI8tje2G3t9zecCY7L0rFipmqFm3bczHCDIlz lisZaAP28qiloPhEzADP8d58b5OO+X10+iupwd0KSUajojmuXwT+Ki2VYZuLanXhYY2o pB2u6Vr9i1lefUzZetesUSBdLASloF+vxrMMWeHbCPweWJsBg+QObuCTMQTfM6xxIcf1 3+8b/be6QuOo7Xv3vHnMeYAW4W6gOcO76gyN8mUttmK0dRL++UFICyK5Z70aKqAWwjVB ynwg== X-Gm-Message-State: AO0yUKWS7s9RaSrK6dYyr58HX/m+3VgyAJ+W1SwDUBhWDdmhstA/KzdM Nzm0XMYUUpgWQZLAH9xq9XhKWrsl26gnc5aYdvaW1CjcBCH6Tyt+uLagtFR65xAY+IgkZD1ZLv/ U/ypUPUxg+UZGM8oon5CSNs5ysti8S3Ui X-Received: by 2002:a81:9e04:0:b0:509:bd6:4d4b with SMTP id m4-20020a819e04000000b005090bd64d4bmr1221878ywj.282.1675970536850; Thu, 09 Feb 2023 11:22:16 -0800 (PST) X-Google-Smtp-Source: AK7set+1AIEPwZDLEkmtLCQ19uJLBZ0qJj44vOuvdsNAf61QTRcJrF1GxtYwVYeGvWhGHfxGlAO/LRfsvANEZkcrglY= X-Received: by 2002:a81:9e04:0:b0:509:bd6:4d4b with SMTP id m4-20020a819e04000000b005090bd64d4bmr1221875ywj.282.1675970536521; Thu, 09 Feb 2023 11:22:16 -0800 (PST) MIME-Version: 1.0 References: <02834fa9-4fb0-08fb-4b5f-e9646c1501d6@leemhuis.info> <288d7ff4-75aa-7ad1-c49c-579373cab3ed@intel.com> <04a9f939-8a98-9a46-e165-8e9fb8801a83@intel.com> <6262bd72-cc2b-9d2a-e8f0-55c2b2bb7861@linux.intel.com> In-Reply-To: From: Jason Montleon Date: Thu, 9 Feb 2023 14:22:05 -0500 Message-ID: Subject: Re: Google Pixelbook EVE, no sound in kernel 6.1.x To: =?UTF-8?B?QW1hZGV1c3ogU8WCYXdpxYRza2k=?= Cc: Cezary Rojewski , Sasa Ostrouska , Linux regressions mailing list , Greg KH , lma@semihalf.com, Pierre-Louis Bossart , stable@vger.kernel.org, Takashi Iwai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org I have a hung task call trace from a debug kernel in case it's helpful: https://gist.github.com/jmontleon/a6dff2ad949cc50bb8f162d7b306b320 On Thu, Feb 9, 2023 at 11:13 AM Jason Montleon wrote: > > I've done some more digging. The only line that needs to be reverted > from f2bd1c5ae2cb0cf9525c9bffc0038c12dd7e1338, moving from > snd_hda_codec_device_init back to snd_hda_codec_device_new is: > codec->core.exec_verb =3D codec_exec_verb; > (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/so= und/pci/hda/hda_codec.c?h=3Dv6.1.11#n931) > > I added a bunch of debug statements and all the code in > codec_exec_verb runs at boot with this in snd_hda_codec_device_init, > whereas it does not when in snd_hda_codec_device_new. > > From what I can tell we end up in snd_hda_power_up_pm and then get > hung up at snd_hdac_power_up. > > There are a bunch of pin port messages that show up from > hdac_hdmi_query_port_connlist when things are working, that never > appear when broken: > [ 14.618805] HDMI HDA Codec ehdaudio0D2: No connections found for pin:p= ort 5:0 > [ 14.619242] HDMI HDA Codec ehdaudio0D2: No connections found for pin:p= ort 5:1 > [ 14.619703] HDMI HDA Codec ehdaudio0D2: No connections found for pin:p= ort 5:2 > ... > > I do see hdac_hdmi_runtime_suspend run a moment before things go bad, > but I have no idea if it is related. > > Without patching anything and CONFIG_PM unset everything works. > > I don't know if that helps anyone see where the problem is. If not > I'll keep plugging away. > > Incidentally, commit 3fd63658caed9494cca1d4789a66d3d2def2a0ab, pointed > to by my second bisect, starts making using of skl_codec_device_init > where I believe snd_hda_codec_device_init is called and starts the > problem. I believe this is why reverting either of the two works > around the problem. > > > > On Mon, Feb 6, 2023 at 2:57 PM Jason Montleon wrote= : > > > > On Mon, Feb 6, 2023 at 8:51 AM Jason Montleon wro= te: > > > > > > On Mon, Feb 6, 2023 at 4:04 AM Amadeusz S=C5=82awi=C5=84ski > > > wrote: > > > > > > > > On 2/4/2023 4:16 PM, Jason Montleon wrote: > > > > > I have built kernels for 6.0.19 (I don't think anyone confirmed > > > > > whether or not it worked), plus every 6.1 tag from 6.1-rc1 up to > > > > > 6.1.7. 6.0.19 worked. No 6.1 kernels worked. For rc1 to rc5 I bui= lt > > > > > with and without the legacy dai renaming patch added in rc6 that = I > > > > > believe would be necessary, but it made no difference either way. > > > > > > > > Hi, > > > > > > > > thank you for trying to narrow it down, if I understand correctly -= rc1 > > > > doesn't work, which means that problem was introduced somewhere bet= ween > > > > 6.0 and 6.1-rc1 (just for the sake of being sure, can you test 6.0 > > > > instead of 6.0.19?) There is one commit which I'm bit suspicious ab= out: > > > > ef6f5494faf6a37c74990689a3bb3cee76d2544c it changes how HDMI are > > > > assigned and as a machine board present on EVE makes use of HDMI, i= t may > > > > potentially cause some problems. Can you try reverting it? > > > > (If reverting on top of v6.1.8 you need to revert both > > > > f9aafff5448b1d8d457052271cd9a11b24e4d0bd and > > > > ef6f5494faf6a37c74990689a3bb3cee76d2544c which has minor conflict, > > > > easily resolved with just adding both lines. > > > > > > > > > > Yes, happy to give that a shot and will report back. > > > > > > > Removing f9aafff5448b1d8d457052271cd9a11b24e4d0bd and > > ef6f5494faf6a37c74990689a3bb3cee76d2544c did not make things work. > > > > You may be onto something with pulseaudio and/or HDMI, however. > > When setting up Slackware I saw an interesting aplay hang. > > Normally aplay -l will list like this with working audio: > > $ aplay -l > > **** List of PLAYBACK Hardware Devices **** > > card 0: kblr55145663max [kbl-r5514-5663-max], device 0: Audio (*) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > card 0: kblr55145663max [kbl-r5514-5663-max], device 2: Headset Audio (= *) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > card 0: kblr55145663max [kbl-r5514-5663-max], device 6: Hdmi1 (*) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > card 0: kblr55145663max [kbl-r5514-5663-max], device 7: Hdmi2 (*) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > > > Both on Slackware and Fedora with broken audio it hangs like so > > (haven't tried on Arch): > > $ aplay -l > > **** List of PLAYBACK Hardware Devices **** > > card 0: kblr55145663max [kbl-r5514-5663-max], device 0: Audio (*) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > card 0: kblr55145663max [kbl-r5514-5663-max], device 2: Headset Audio (= *) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > card 0: kblr55145663max [kbl-r5514-5663-max], device 6: Hdmi1 (*) [] > > Subdevices: 1/1 > > Subdevice #0: subdevice #0 > > > > If I remove or disable pulseaudio it lists without hanging, but it's > > difficult for me to tell whether it's working since aplay, etc. seem > > to want pulseaudio to play anything. Shutdown hangs persist > > regardless. > > > > Also, Slackware with 6.1.9 behaves as badly for me as everything else. > > If Sasa has working audio I do not know how he has managed to > > configure it. On each distro, as soon as I add topology and firmware > > files everything goes bad, regardless of whether I add ucm > > configuration or not, etc. > > > > > > I also still wonder, why problem reproduces only on some > > > > distributions... any chance you can try and boot with > > > > pipewire/pulseaudio disabled and see if it still happens, iirc thos= e > > > > tools try to check all FEs and this may be breaking something durin= g > > > > enumeration. > > > > > > I can definitely try disabling pulseaudio and switching to pipewire > > > and seeing if anything changes as well. > > > > > > FWIW, I installed Arch on a thumb drive this weekend and was able to > > > reproduce the issue and work around it by reverting the commit from m= y > > > first bisect. So, for me it behaves just like Fedora. The instruction= s > > > for Arch for building a custom kernel are great except they generaliz= e > > > the bootloader instructions, so you need to know what to do at the en= d > > > to add the grub boot entries, if using grub for example, and I suspec= t > > > that may be where the confusion came from, though I don't know. I'm > > > trying to get one of the two to reproduce my results to confirm and a= t > > > least get them a workaround. > > > > > > I have slackware on another thumb drive already, but I have yet to > > > even get it updated to 6.1.8. > > > > > > If any of them behave differently I was hoping to tease out whether > > > it's firmware, kernel config, or something else, but so far the first > > > has been more of the same. > > > > > > > Thanks, > > > > Amadeusz > > > > > > > > > > > > > > On Wed, Feb 1, 2023 at 9:33 AM Jason Montleon wrote: > > > > >> > > > > >> On Wed, Feb 1, 2023 at 6:05 AM Amadeusz S=C5=82awi=C5=84ski > > > > >> wrote: > > > > >>> > > > > >>> On 1/31/2023 4:16 PM, Jason Montleon wrote: > > > > >>>> On Tue, Jan 31, 2023 at 7:37 AM Cezary Rojewski > > > > >>>> wrote: > > > > >>>>> > > > > >>>>> On 2023-01-30 1:22 PM, Sasa Ostrouska wrote: > > > > >>>>> > > > > >>>>>> Dear Czarek, many thanks for the answer and taking care of i= t. If > > > > >>>>>> needed something from my side please jest let me know > > > > >>>>>> and I will try to do it. > > > > >>>>> > > > > >>>>> > > > > >>>>> Hello Sasa, > > > > >>>>> > > > > >>>>> Could you provide us with the topology and firmware binary pr= esent on > > > > >>>>> your machine? > > > > >>>>> > > > > >>>>> Audio topology is located at /lib/firmware and named: > > > > >>>>> > > > > >>>>> 9d71-GOOGLE-EVEMAX-0-tplg.bin > > > > >>>>> -or- > > > > >>>>> dfw_sst.bin > > > > >>>>> > > > > >>>>> Firmware on the other hand is found in /lib/firmware/intel/. > > > > >>>>> 'dsp_fw_kbl.bin' will lie there, it shall be a symlink pointi= ng to an > > > > >>>>> actual AudioDSP firmware binary. > > > > >>>>> > > > > >>>> Maybe this is the problem. > > > > >>>> > > > > >>>> I think most of us are pulling the topology and firmware from = the > > > > >>>> chromeos recovery images for lack of any other known source, a= nd it > > > > >>>> looks a little different than this. Those can be downloaded li= ke so: > > > > >>>> https://gist.github.com/jmontleon/8899cb83138f2653f520fbbcc5b8= 30a0 > > > > >>>> > > > > >>>> After placing the topology file you'll see these errors and au= dio will > > > > >>>> not work until they're also copied in place. > > > > >>>> snd_soc_skl 0000:00:1f.3: Direct firmware load for > > > > >>>> dsp_lib_dsm_core_spt_release.bin failed with error -2 > > > > >>>> snd_soc_skl 0000:00:1f.3: Direct firmware load for > > > > >>>> intel/dsp_fw_C75061F3-F2B2-4DCC-8F9F-82ABB4131E66.bin failed w= ith > > > > >>>> error -2 > > > > >>>> > > > > >>>> Once those were in place, up to 6.0.18 audio worked. > > > > >>>> > > > > >>>> Is there a better source for the topology file? > > > > >>>> > > > > >>>>> The reasoning for these asks is fact that problem stopped rep= roducing on > > > > >>>>> our end once we started playing with kernel versions (moved a= way from > > > > >>>>> status quo with Fedora). Neither on Lukasz EVE nor on my SKL = RVP. > > > > >>>>> However, we might be using newer configuration files when com= pared to > > > > >>>>> equivalent of yours. > > > > >>>>> > > > > >>>>> Recent v6.2-rc5 broonie/sound/for-next - no repro > > > > >>>>> Our internal tree based on Mark's for-next - no repro > > > > >>>>> 6.1.7 stable [1] - no repro > > > > >>>>> > > > > >>>>> Of course we will continue with our attempts. Will notify abo= ut the > > > > >>>>> progress. > > > > >>>>> > > > > >>>>> > > > > >>>>> [1]: > > > > >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.= git/commit/?h=3Dv6.1.7&id=3D21e996306a6afaae88295858de0ffb8955173a15 > > > > >>>>> > > > > >>>>> > > > > >>>>> Kind regards, > > > > >>>>> Czarek > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> Hi Jason, > > > > >>> > > > > >>> as I understand you've tried to do bisect, can you instead try = building > > > > >>> kernels checking out following tags: > > > > >>> v6.1 v6.1.1 v6.1.2 v6.1.3 v6.1.4 v6.1.5 v6.= 1.6 > > > > >>> v6.1.7 v6.1.8 > > > > >>> and report when it stops working, so it narrows scope of what w= e look > > > > >>> at? I assume that kernel builds are done using upstream stable = kernel > > > > >>> (from https://git.kernel.org/pub/scm/linux/kernel/git/stable/li= nux.git/). > > > > >>> > > > > >>> Thanks, > > > > >>> Amadeusz > > > > >>> > > > > >> Hi Amadeusz, > > > > >> Yes, I did the bisects using > > > > >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git= / > > > > >> > > > > >> The only thing I did to these was add > > > > >> 392cc13c5ec72ccd6bbfb1bc2339502cc59dd285, otherwise audio breaks= with > > > > >> the dai not registered error message in dmesg from the rt5514 bu= g from > > > > >> 6.0 and up. It wasn't added to 6.1 until rc6, I believe. If ther= e's a > > > > >> better way to work around the multiple bugs I can try again, oth= erwise > > > > >> I will start working on builds from tags and see if I learn anyt= hing. > > > > >> > > > > >> FWIW, I've seen two people complain that Arch isn't working eith= er > > > > >> since it moved to 6.1. For the one who was trying, patching out = the > > > > >> commit I came to with the first bisect did not regain them sound= like > > > > >> it did for me. And yet Sasa reports Slackware is mostly working = for > > > > >> him with 6.1.8 on Slackware. I don't know what to make of it, bu= t > > > > >> thought I'd share in case it helps point someone else to somethi= ng. > > > > >> https://github.com/jmontleon/pixelbook-fedora/issues/51#issuecom= ment-1410222840 > > > > >> https://github.com/jmontleon/pixelbook-fedora/issues/51#issuecom= ment-1410673371 > > > > >> https://github.com/jmontleon/pixelbook-fedora/issues/53#issuecom= ment-1408699252 > > > > >> > > > > >> Probably less relevant since they aren't from upstream and I kno= w they > > > > >> don't mean as much, but I have tried 6.1.5-6.1.8 Fedora packages= for > > > > >> certain, and went back trying several others from koji back into= rc > > > > >> builds, although using prebuilt kernels, anything before 6.1-rc6= won't > > > > >> work, as mentioned above. Nothing worked. But as I said I'll bui= ld > > > > >> from tags and see if I can learn anything. > > > > >> > > > > >> Thank you, > > > > >> Jason Montleon > > > > >> > > > > >> -- > > > > >> Jason Montleon | email: jmontleo@redhat.com > > > > >> Red Hat, Inc. | gpg key: 0x069E3022 > > > > >> Cell: 508-496-0663 | irc: jmontleo / jmontleon > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Jason Montleon | email: jmontleo@redhat.com > > > Red Hat, Inc. | gpg key: 0x069E3022 > > > Cell: 508-496-0663 | irc: jmontleo / jmontleon > > > > > > > > -- > > Jason Montleon | email: jmontleo@redhat.com > > Red Hat, Inc. | gpg key: 0x069E3022 > > Cell: 508-496-0663 | irc: jmontleo / jmontleon > > > > -- > Jason Montleon | email: jmontleo@redhat.com > Red Hat, Inc. | gpg key: 0x069E3022 > Cell: 508-496-0663 | irc: jmontleo / jmontleon --=20 Jason Montleon | email: jmontleo@redhat.com Red Hat, Inc. | gpg key: 0x069E3022 Cell: 508-496-0663 | irc: jmontleo / jmontleon