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 built
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 between
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 about:
ef6f5494faf6a37c74990689a3bb3cee76d2544c it changes how HDMI are
assigned and as a machine board present on EVE makes use of HDMI, it 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.
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 those
tools try to check all FEs and this may be breaking something during
enumeration.
Thanks,
Amadeusz
On Wed, Feb 1, 2023 at 9:33 AM Jason Montleon <jmontleo@xxxxxxxxxx> wrote:
On Wed, Feb 1, 2023 at 6:05 AM Amadeusz Sławiński
<amadeuszx.slawinski@xxxxxxxxxxxxxxx> wrote:
On 1/31/2023 4:16 PM, Jason Montleon wrote:
On Tue, Jan 31, 2023 at 7:37 AM Cezary Rojewski
<cezary.rojewski@xxxxxxxxx> wrote:
On 2023-01-30 1:22 PM, Sasa Ostrouska wrote:
Dear Czarek, many thanks for the answer and taking care of it. 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 present 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 pointing 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, and it
looks a little different than this. Those can be downloaded like so:
https://gist.github.com/jmontleon/8899cb83138f2653f520fbbcc5b830a0
After placing the topology file you'll see these errors and audio 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 with
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 reproducing on
our end once we started playing with kernel versions (moved away from
status quo with Fedora). Neither on Lukasz EVE nor on my SKL RVP.
However, we might be using newer configuration files when compared 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 about the
progress.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.7&id=21e996306a6afaae88295858de0ffb8955173a15
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 we look
at? I assume that kernel builds are done using upstream stable kernel
(from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.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 bug from
6.0 and up. It wasn't added to 6.1 until rc6, I believe. If there's a
better way to work around the multiple bugs I can try again, otherwise
I will start working on builds from tags and see if I learn anything.
FWIW, I've seen two people complain that Arch isn't working either
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, but
thought I'd share in case it helps point someone else to something.
https://github.com/jmontleon/pixelbook-fedora/issues/51#issuecomment-1410222840
https://github.com/jmontleon/pixelbook-fedora/issues/51#issuecomment-1410673371
https://github.com/jmontleon/pixelbook-fedora/issues/53#issuecomment-1408699252
Probably less relevant since they aren't from upstream and I know 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 build
from tags and see if I can learn anything.
Thank you,
Jason Montleon
--
Jason Montleon | email: jmontleo@xxxxxxxxxx
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663 | irc: jmontleo / jmontleon
