Re: [alsa-devel] [CX2075] No sound after suspend/resume from front speaker
On Thu, 30 Jan 2020 12:42:01 +0100, Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote:
Hi,
this still seem to be an issue. After startup everything works well until the laptop goes to suspend.
Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens.
ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83a373
Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module. So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote:
Hi,
this still seem to be an issue. After startup everything works well until the laptop goes to suspend.
Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens.
ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83a373
Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module. So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
Btw., thanks for superquick response.
Thanks
Roman
On Thu, 30 Jan 2020 13:07:46 +0100, Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote:
Hi,
this still seem to be an issue. After startup everything works well until the laptop goes to suspend.
Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens.
ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83a373
Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module. So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote:
Hi,
this still seem to be an issue. After startup everything works well until the laptop goes to suspend.
Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens.
ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83 a373
Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
OK, so this means that this report is invalid and kernel developers should check this out?
How should i proceed now?
Thanks Roman
On Thu, 30 Jan 2020 14:17:16 +0100, Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote: > Hi, > > this still seem to be an issue. After startup everything works > well > until > the laptop goes to suspend. > > Tried pretty much everything basic user can do (unmutes, rmmods > and so > on), > still no way to wake the output. ALSA seems to be thinking, that > output is > active, you can set volume and stuff, but nothing happens. > > ALSA info: > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83 > a373 > > Related links: > https://www.reddit.com/r/archlinux/comments/4nwzua/ > no_sound_after_suspend_killing_or_restarting/ > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
OK, so this means that this report is invalid and kernel developers should check this out?
How should i proceed now?
It's all about vendor-specific implementation, so the only h/w vendor knows... Unfortunately (or fortunately) Conexant codecs are well-mannered and there are few quirks.
Takashi
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote:
Hi,
this still seem to be an issue. After startup everything works well until the laptop goes to suspend.
Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens.
ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83 a373
Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
Okay, so are there any further steps required from me, or it's just matter of time for devs for pick this bug up?
Sorry for being annoying, as said, i'm new to this :)
Regards
Roman
On Thu, 30 Jan 2020 14:29:08 +0100, Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a):
On Sat, 25 Jan 2020 23:30:32 +0100,
Roman Šmakal wrote: > Hi, > > this still seem to be an issue. After startup everything works > well > until > the laptop goes to suspend. > > Tried pretty much everything basic user can do (unmutes, rmmods > and so > on), > still no way to wake the output. ALSA seems to be thinking, that > output is > active, you can set volume and stuff, but nothing happens. > > ALSA info: > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83 > a373 > > Related links: > https://www.reddit.com/r/archlinux/comments/4nwzua/ > no_sound_after_suspend_killing_or_restarting/ > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404
The first thing to check is to compare alsa-info.sh outputs before and after the suspend.
Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF dump. This will give more information in alsa-info.sh outputs.
Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
Okay, so are there any further steps required from me, or it's just matter of time for devs for pick this bug up?
Well, if you meant us as "devs", currently there is no much thing we can do for now. As said, the issue is pretty much vendor-specific implementation details. You can try asking the h/w vendor, but the chance isn't high, unfortunately.
I suppose here that the runtime PM works; i.e. after some time without activity the chip will be suspended. Check /sys/bus/hdaudio/devices/*/power/runtime_status. If it's "suspended", and if you can play back tone after this state, runtime PM basically works, and it implies that the rest is the system-wide power up problem that is deeply involved with BIOS.
Takashi
Dne čtvrtek 30. ledna 2020 14:59:20 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 14:29:08 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 14:07:53 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 13:07:46 +0100,
Roman Šmakal wrote:
Dne čtvrtek 30. ledna 2020 12:57:32 CET, Takashi Iwai napsal(a):
On Thu, 30 Jan 2020 12:42:01 +0100,
Roman Šmakal wrote:
Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a): > On Sat, 25 Jan 2020 23:30:32 +0100, > > Roman Šmakal wrote: > > Hi, > > > > this still seem to be an issue. After startup everything works > > well > > until > > the laptop goes to suspend. > > > > Tried pretty much everything basic user can do (unmutes, > > rmmods > > and so > > on), > > still no way to wake the output. ALSA seems to be thinking, > > that > > output is > > active, you can set volume and stuff, but nothing happens. > > > > ALSA info: > > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be42 > > 0f83 > > a373 > > > > Related links: > > https://www.reddit.com/r/archlinux/comments/4nwzua/ > > no_sound_after_suspend_killing_or_restarting/ > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404 > > The first thing to check is to compare alsa-info.sh outputs > before > and > after the suspend. > > Also pass snd_hda_codec.dump_coef=1 module option to enable the > COEF > dump. This will give more information in alsa-info.sh outputs. > > > Takashi
Okay, i did some comparing with module option enabled.
Sound working http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb 7588
Sound not working: http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff 8d4d
What's wierd to me is, that on the row 521 there is change in aplay Subdevices from 1/1 to 0/1.
Also, state.PCH control 18 shows change in playback channel map.
Any other thing i can check or try to dofor debuging?
You passed a wrong option. The option is for snd_hda_codec module.
So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1
or pass snd_hda_codec.dump_coef=1 at boot cmdline option.
BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them.
Last but not least, please don't drop Cc to ML unless you need to do so.
thanks,
Takashi
Alright, my bad, i'm new to this.
Attaching alsainfos with proper module options, no big difference though.
OK, so it has the codec has COEF things and there is no significant difference between those two outputs. It implies that something outside HD-audio bus is needed and it's probably done by BIOS.
Takashi
Okay, so are there any further steps required from me, or it's just matter of time for devs for pick this bug up?
Well, if you meant us as "devs", currently there is no much thing we can do for now. As said, the issue is pretty much vendor-specific implementation details. You can try asking the h/w vendor, but the chance isn't high, unfortunately.
I suppose here that the runtime PM works; i.e. after some time without activity the chip will be suspended. Check /sys/bus/hdaudio/devices/*/power/runtime_status. If it's "suspended", and if you can play back tone after this state, runtime PM basically works, and it implies that the rest is the system-wide power up problem that is deeply involved with BIOS.
Takashi
I can confirm that runtime PM works, but there is no way to make sound work after suspend so far. At least for BIOS ver. 1.9
Gonna try, if possible, to upgrade BIOS just to confirm it's still an issue.
Thanks Roman
participants (2)
-
Roman Šmakal -
Takashi Iwai