Re: Haswell audio no longer working with new Catpt driver
Hi,
I'm taking this conversation back to the mailinglist. Hope you don't mind.
On 12/31/20 2:15 PM, Christian Labisch wrote:
Hi Amadeusz, Greg, and Lars-Peter,
Do you have a suggestion for a workaround ? A special boot parameter that I could add ? Will the drivers work in the next version ?
I had a quick look at the changes to the HDA driver between v5.9 and v5.10. And there isn't that much, expect some changes to power management.
Curiously enough pretty much your only difference between your v5.9 and v5.10 alsa-info.sh is that a few of the nodes are in D3 state (meaning powered down) in v5.10. One of them is the internal speaker.
But this could also be a coincidence, would be interesting to see what the output of alsa-info.sh looks like when the you are trying to play some audio. If it is still powered down then there is a bug.
- Lars
Regards, Christian
On Thu, 2020-12-31 at 12:20 +0100, Amadeusz Sławiński wrote:
On 12/31/2020 11:50 AM, Christian Labisch wrote:
Hi Lars-Peter,
Thank you, please find attached the requested information from both kernels. I freshly installed the fedora kernel 5.10.4 to give you the latest results.
Regards, Christian
Christian Labisch Red Hat Accelerator clnetbox.blogspot.com access.redhat.com/community access.redhat.com/accelerators
On Thu, 2020-12-31 at 11:04 +0100, Lars-Peter Clausen wrote:
On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote:
On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote: > Update : > > I've just tested the kernel 5.10.4 from ELRepo. > Unfortunately nothing changed - still no sound. Ah, sad. Can you run 'git bisect' between 5.9 and 5.10 to determine the commit that caused the problem?
The problem is that one driver was replaced with another driver. git bisect wont really help to narrow down why the new driver does not work.
Christian can you run the alsa-info.sh[1] script on your system and send back the result?
You say sound is not working, can you clarify that a bit? Is no sound card registered? Is it registered but output stays silent?
- Lars
[1] https://www.alsa-project.org/wiki/AlsaInfo https://www.alsa-project.org/wiki/AlsaInfo
Hi,
from reading provided files it seems that you use snd_intel_hda driver, it should be possible to git bisect it between 5.9 and 5.10 as it wasn't replaced.
Catpt driver is used on machines using DSP.
Amadeusz
Hi Lars,
Thanks for your response, as requested I ran alsa-info while playing audio. Please check the attached information - to me it looks like it being a bug. It should affect many users, will it be solved in the next release 5.10.5 ?
Regards, Christian
On Thu, 2020-12-31 at 16:30 +0100, Lars-Peter Clausen wrote:
Hi,
I'm taking this conversation back to the mailinglist. Hope you don't mind.
On 12/31/20 2:15 PM, Christian Labisch wrote:
Hi Amadeusz, Greg, and Lars-Peter,
Do you have a suggestion for a workaround ? A special boot parameter that I could add ? Will the drivers work in the next version ?
I had a quick look at the changes to the HDA driver between v5.9 and v5.10. And there isn't that much, expect some changes to power management.
Curiously enough pretty much your only difference between your v5.9 and v5.10 alsa-info.sh is that a few of the nodes are in D3 state (meaning powered down) in v5.10. One of them is the internal speaker.
But this could also be a coincidence, would be interesting to see what the output of alsa-info.sh looks like when the you are trying to play some audio. If it is still powered down then there is a bug.
- Lars
Regards, Christian
On Thu, 2020-12-31 at 12:20 +0100, Amadeusz Sławiński wrote:
On 12/31/2020 11:50 AM, Christian Labisch wrote:
Hi Lars-Peter,
Thank you, please find attached the requested information from both kernels. I freshly installed the fedora kernel 5.10.4 to give you the latest results.
Regards, Christian
Christian Labisch Red Hat Accelerator clnetbox.blogspot.com access.redhat.com/community access.redhat.com/accelerators
On Thu, 2020-12-31 at 11:04 +0100, Lars-Peter Clausen wrote:
On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote: > On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote: > > Update : > > > > I've just tested the kernel 5.10.4 from ELRepo. > > Unfortunately nothing changed - still no sound. > Ah, sad. Can you run 'git bisect' between 5.9 and 5.10 to determine the > commit that caused the problem? The problem is that one driver was replaced with another driver. git bisect wont really help to narrow down why the new driver does not work.
Christian can you run the alsa-info.sh[1] script on your system and send back the result?
You say sound is not working, can you clarify that a bit? Is no sound card registered? Is it registered but output stays silent?
- Lars
[1] https://www.alsa-project.org/wiki/AlsaInfo https://www.alsa-project.org/wiki/AlsaInfo
Hi,
from reading provided files it seems that you use snd_intel_hda driver, it should be possible to git bisect it between 5.9 and 5.10 as it wasn't replaced.
Catpt driver is used on machines using DSP.
Amadeusz
On Fri, 01 Jan 2021 12:10:23 +0100, Christian Labisch wrote:
Hi Lars,
Thanks for your response, as requested I ran alsa-info while playing audio. Please check the attached information - to me it looks like it being a bug. It should affect many users, will it be solved in the next release 5.10.5 ?
It's likely some runtime PM-related changes that caused this behavior change. But, there must be some program that sets the power_save option explicitly on your system. As dmesg shows, the default power_save to this device has been suppressed, but it's activated by the later action. On, 5.9.x, this didn't take effect, but on 5.10.x, this became effective, as it seems.
You can try to pass power_save=0 option to snd-hda-intel module (or boot with snd_hda_intel.power_save=0 boot option). It could work around the issue, although it's no solution.
thanks,
Takashi
Hi Takashi,
Thanks for your suggestion - unfortunately it does not work. Still no sound after adding the boot parameter and a reboot.
Regards, Christian
On Fri, 2021-01-01 at 13:09 +0100, Takashi Iwai wrote:
On Fri, 01 Jan 2021 12:10:23 +0100, Christian Labisch wrote:
Hi Lars,
Thanks for your response, as requested I ran alsa-info while playing audio. Please check the attached information - to me it looks like it being a bug. It should affect many users, will it be solved in the next release 5.10.5 ?
It's likely some runtime PM-related changes that caused this behavior change. But, there must be some program that sets the power_save option explicitly on your system. As dmesg shows, the default power_save to this device has been suppressed, but it's activated by the later action. On, 5.9.x, this didn't take effect, but on 5.10.x, this became effective, as it seems.
You can try to pass power_save=0 option to snd-hda-intel module (or boot with snd_hda_intel.power_save=0 boot option). It could work around the issue, although it's no solution.
thanks,
Takashi
On 1/1/21 2:25 PM, Christian Labisch wrote:
Hi Takashi,
Thanks for your suggestion - unfortunately it does not work. Still no sound after adding the boot parameter and a reboot.
Can you run `cat /sys/module/snd_hda_intel/parameters/power_save` and check whether it is still 0 when the system is running?
Regards, Christian
On Fri, 2021-01-01 at 13:09 +0100, Takashi Iwai wrote:
On Fri, 01 Jan 2021 12:10:23 +0100, Christian Labisch wrote:
Hi Lars,
Thanks for your response, as requested I ran alsa-info while playing audio. Please check the attached information - to me it looks like it being a bug. It should affect many users, will it be solved in the next release 5.10.5 ?
It's likely some runtime PM-related changes that caused this behavior change. But, there must be some program that sets the power_save option explicitly on your system. As dmesg shows, the default power_save to this device has been suppressed, but it's activated by the later action. On, 5.9.x, this didn't take effect, but on 5.10.x, this became effective, as it seems.
You can try to pass power_save=0 option to snd-hda-intel module (or boot with snd_hda_intel.power_save=0 boot option). It could work around the issue, although it's no solution.
thanks,
Takashi
$ cat /sys/module/snd_hda_intel/parameters/power_save 0
On Fri, 2021-01-01 at 14:29 +0100, Lars-Peter Clausen wrote:
On 1/1/21 2:25 PM, Christian Labisch wrote:
Hi Takashi,
Thanks for your suggestion - unfortunately it does not work. Still no sound after adding the boot parameter and a reboot.
Can you run `cat /sys/module/snd_hda_intel/parameters/power_save` and check whether it is still 0 when the system is running?
Regards, Christian
On Fri, 2021-01-01 at 13:09 +0100, Takashi Iwai wrote:
On Fri, 01 Jan 2021 12:10:23 +0100, Christian Labisch wrote:
Hi Lars,
Thanks for your response, as requested I ran alsa-info while playing audio. Please check the attached information - to me it looks like it being a bug. It should affect many users, will it be solved in the next release 5.10.5 ?
It's likely some runtime PM-related changes that caused this behavior change. But, there must be some program that sets the power_save option explicitly on your system. As dmesg shows, the default power_save to this device has been suppressed, but it's activated by the later action. On, 5.9.x, this didn't take effect, but on 5.10.x, this became effective, as it seems.
You can try to pass power_save=0 option to snd-hda-intel module (or boot with snd_hda_intel.power_save=0 boot option). It could work around the issue, although it's no solution.
thanks,
Takashi
On Fri, 01 Jan 2021 14:40:39 +0100, Christian Labisch wrote:
$ cat /sys/module/snd_hda_intel/parameters/power_save 0
Hm, then the best would be to run git bisect for spotting out the breaking commit. There has been no change in VIA codec driver at all between v5.9 and v5.10, so the rest possibility is either in HD-audio codec helper code or controller code (or both) -- if it's about the changes in the sound driver.
Or you can try the oneliner below as a test shot; it might keep the widget node power D0, which is currently the only possible appearance of the difference between working and non-working cases.
BTW, please avoid top-posting. It's confusing.
thanks,
Takashi
-- 8< -- --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -115,7 +115,7 @@ static struct via_spec *via_new_spec(struct hda_codec *codec) spec->gen.keep_eapd_on = 1; spec->gen.pcm_playback_hook = via_playback_pcm_hook; spec->gen.add_stereo_mix_input = HDA_HINT_STEREO_MIX_AUTO; - codec->power_save_node = 1; + // codec->power_save_node = 1; spec->gen.power_down_unused = 1; codec->patch_ops = via_patch_ops; return spec;
On Fri, 2021-01-01 at 18:24 +0100, Takashi Iwai wrote:
On Fri, 01 Jan 2021 14:40:39 +0100, Christian Labisch wrote:
$ cat /sys/module/snd_hda_intel/parameters/power_save 0
Hm, then the best would be to run git bisect for spotting out the breaking commit. There has been no change in VIA codec driver at all between v5.9 and v5.10, so the rest possibility is either in HD-audio codec helper code or controller code (or both) -- if it's about the changes in the sound driver.
Or you can try the oneliner below as a test shot; it might keep the widget node power D0, which is currently the only possible appearance of the difference between working and non-working cases.
BTW, please avoid top-posting. It's confusing.
thanks,
Takashi
-- 8< -- --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -115,7 +115,7 @@ static struct via_spec *via_new_spec(struct hda_codec *codec) spec->gen.keep_eapd_on = 1; spec->gen.pcm_playback_hook = via_playback_pcm_hook; spec->gen.add_stereo_mix_input = HDA_HINT_STEREO_MIX_AUTO; - codec->power_save_node = 1; + // codec->power_save_node = 1; spec->gen.power_down_unused = 1; codec->patch_ops = via_patch_ops; return spec;
Hi Takashi,
Thank you ! I think we have tried what we could to work around this issue. There is obviously something wrong with the kernel which has to get fixed.
Hi Greg and Lars,
From my understanding there are fundamental changes regarding the audio drivers.
The sound should (and has to) work out-of-the-box without any user interactions.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-Sound-Imp...
As you can see in the post below, other users are facing exactly the same issue. It would be great if this could be solved as soon as possible, maybe in 5.10.5 ?
https://forum.manjaro.org/t/issue-after-kernel-5-10-update-speakers-not-work...
Regards, Christian
On Sat, Jan 02, 2021 at 12:50:44PM +0100, Christian Labisch wrote:
On Fri, 2021-01-01 at 18:24 +0100, Takashi Iwai wrote:
On Fri, 01 Jan 2021 14:40:39 +0100, Christian Labisch wrote:
$ cat /sys/module/snd_hda_intel/parameters/power_save 0
Hm, then the best would be to run git bisect for spotting out the breaking commit. There has been no change in VIA codec driver at all between v5.9 and v5.10, so the rest possibility is either in HD-audio codec helper code or controller code (or both) -- if it's about the changes in the sound driver.
Or you can try the oneliner below as a test shot; it might keep the widget node power D0, which is currently the only possible appearance of the difference between working and non-working cases.
BTW, please avoid top-posting. It's confusing.
thanks,
Takashi
-- 8< -- --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -115,7 +115,7 @@ static struct via_spec *via_new_spec(struct hda_codec *codec) spec->gen.keep_eapd_on = 1; spec->gen.pcm_playback_hook = via_playback_pcm_hook; spec->gen.add_stereo_mix_input = HDA_HINT_STEREO_MIX_AUTO; - codec->power_save_node = 1; + // codec->power_save_node = 1; spec->gen.power_down_unused = 1; codec->patch_ops = via_patch_ops; return spec;
Hi Takashi,
Thank you ! I think we have tried what we could to work around this issue. There is obviously something wrong with the kernel which has to get fixed.
Yes, and that is what we are trying to figure out here. Does the above change work?
Hi Greg and Lars,
From my understanding there are fundamental changes regarding the audio drivers. The sound should (and has to) work out-of-the-box without any user interactions.
Of course, but we need to figure out the change that caused the problem here. If someone who can reproduce this can run 'git bisect' that is the fastest way to make this happen.
As you can see in the post below, other users are facing exactly the same issue. It would be great if this could be solved as soon as possible, maybe in 5.10.5 ?
https://forum.manjaro.org/t/issue-after-kernel-5-10-update-speakers-not-work...
5.10.5 will be out next week, and that's not how stable kernels work. The fix needs to be in Linus's tree first before we can take it in a stable kernel release. We need to figure out the fix first before it can go anywhere...
thanks,
greg k-h
participants (4)
-
Christian Labisch -
Greg KH -
Lars-Peter Clausen -
Takashi Iwai