I've a Toshiba x20t-C-121 (Skylake m7-6Y75 based). On initial boot, sound on internal speakers is working. After standby it doesn work anymore, but a analog headset does. Switching around in pavucontrol doesn't work... Internal microphone works. This problem also exists on Ubuntu 16.04 - see the bug report under https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 .
Still applies on 4.9.0-2. Interesting thing: if I do a rmmod -f snd_hda_codec_conexant modprobe snd_hda_codec_conexant while the sound does NOT work, I get [888251.375219] snd_hda_codec_conexant hdaudioC0D0: CX20753/4: BIOS auto-probing. [888251.375863] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20753/4: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker [888251.375874] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [888251.375882] snd_hda_codec_conexant hdaudioC0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0) [888251.375887] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0 [888251.375892] snd_hda_codec_conexant hdaudioC0D0: inputs: [888251.375900] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x1a [888251.375906] snd_hda_codec_conexant hdaudioC0D0: Mic=0x19 [888251.385961] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input68 [888251.386459] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input69 [888251.386766] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1f.3/sound/card0/input67 As seen on the speaker_outs=0 line, it seems that somehow the speaker is disabled? I'll try the same after a reboot (which "fixes" the sound) in a moment.
Ok, on a reboot (and working sound), it says root@michis-toshiba:~# dmesg | grep -i hda [ 8.891550] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) [ 8.983225] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 9.036758] snd_hda_codec_conexant hdaudioC0D0: CX20753/4: BIOS auto-probing. [ 9.037147] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20753/4: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker [ 9.037149] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 9.037151] snd_hda_codec_conexant hdaudioC0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0) [ 9.037152] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0 [ 9.037153] snd_hda_codec_conexant hdaudioC0D0: inputs: [ 9.037155] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x1a [ 9.037156] snd_hda_codec_conexant hdaudioC0D0: Mic=0x19 [ 9.037947] snd_hda_codec_conexant hdaudioC0D0: Enable sync_write for stable communication [ 9.072373] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13 [ 9.073172] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input14 [ 9.073256] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15 [ 9.073335] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input16 [ 9.073417] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input17 [ 9.073496] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18 So no difference it seems. After a rmmod -f snd_hda_codec_conexant modprobe snd_hda_codec_conexant again, sound does not work anymore. dmesg says: [ 253.530739] snd_hda_codec_conexant hdaudioC0D0: CX20753/4: BIOS auto-probing. [ 253.531366] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20753/4: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker [ 253.531370] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 253.531374] snd_hda_codec_conexant hdaudioC0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0) [ 253.531377] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0 [ 253.531379] snd_hda_codec_conexant hdaudioC0D0: inputs: [ 253.531383] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x1a [ 253.531386] snd_hda_codec_conexant hdaudioC0D0: Mic=0x19 [ 253.536530] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input23 [ 253.536677] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input24 [ 253.536825] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1f.3/sound/card0/input22 How can I debug this further?
Ok, a pulseaudio --kill pulseaudio --start works if the rmmod/modprobe thing was done on a freshly started system (when internal sound worked), but it is NOT usable to get the internal sound running again if the system was on standby.
Hi This bug was filed for a very old kernel or the bug is old itself without resolution. If you can reproduce it with - the current version in unstable/testing - the latest kernel from backports please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Regards, Salvatore
Hi This bug was filed for a very old kernel or the bug is old itself without resolution. If you can reproduce it with - the current version in unstable/testing - the latest kernel from backports please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Regards, Salvatore
Am 2021-05-15 13:57, schrieb Debian Bug Tracking System: Good day, sadly, I can still reproduce this bug with 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux. Best regards, Michael Fritscher
Hi This bug was filed for a very old kernel or the bug is old itself without resolution. If you can reproduce it with - the current version in unstable/testing - the latest kernel from backports please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Regards, Salvatore
Hi This bug was filed for a very old kernel or the bug is old itself without resolution. If you can reproduce it with - the current version in unstable/testing - the latest kernel from backports please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Regards, Salvatore
Good day, the bug still exists on current trixie, kernel version > 6.12.33+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.33-1 (2025-06-19) x86_64 GNU/Linux Best regards Michael Fritscher
Control: tag -1 + moreinfo To triage the problem, can you try if reloading the driver works? The exact commands to do that differ a bit, on my system this works as follows: /root# cd -P /sys/class/sound/card0/device/driver /sys/bus/pci/drivers/snd_hda_intel# ls 0000:00:1f.3 bind module new_id remove_id uevent unbind /sys/bus/pci/drivers/snd_hda_intel# echo 0000:00:1f.3 > unbind /sys/bus/pci/drivers/snd_hda_intel# echo 0000:00:1f.3 > bind Maybe this is enough for you to see how it works on your system. If not please ask back. Does audio work after reloading the driver on a system that wasn't suspended before? Does reloading the driver make audio work again after a suspend? Does audio also break if you do: unbind suspend resume bind ? Is your driver also snd_hda_intel? Best regards Uwe
Hello Uwe, thanks for stepping in! One additional info from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916: Newer Windows drivers do have the same problem . Regarding binding/unbinding: Yes, it is using snd_hda_intel as well, the card is even on the same port ( 0000:00:1f.3 ). 1. unbinding/binding on the system works flawlessly, if the system was not suspended before. 2. unbinding, suspend, resume, bind does not help, 3. unbinding and binding after resume does not help as well. I think(!) that it has something to do with the codec. Perhaps missing GPIO or something like that. Best regards Michael
Hello Michael, There it's also indicated that the microphone continues to work and pavucontrol indicates output but there isn't. ok, the most likely interpretation is that this is a firmware issue then. I didn't recheck, but the statement that you're on the newest BIOS version is still true? Yeah, something like a GPIO that resets the output path that is asserted at suspend, and deasserted at boot but not resume. I guess someone with Windows driver debugging skills could work out the relevant difference between the driver versions 8.66.47.50 and 8.66.47.56. Maybe there is also a changelog that could give an indication?! Maybe it also helps to bring this to the attention of the hda-intel maintainers, though there doesn't seem to be a dedicated maintainer for that driver. Best regards Uwe
Am 03.07.25 um 07:49 schrieb Uwe Kleine-König: Yes, thats right. Yes, 6.30 ist still the last version (according https://support.dynabook.com/support/modelHome?freeText=1200013722&osId=3333785 ). I just analyzed them a bit ( https://support.dynabook.com/support/modelHome?freeText=1200013722&osId=3333785). They are self extracting zip files. The main difference in the inf file is the addition of HKR,Settings\OEM,ResumeDelayPeriodInMs,1,40,00,00,00 And they disabled HKR,"EP\\0",%PKEY_SRS30_XmlLocation%,,%11%\SRSLabs\slconfig.xml in some locations. This file is in the exe (which is a self extracting zip after all), and seems about "SRS Premium Sound 2". Seems to be gain-/equalizer related settings. This xml file itself is unchanged between the versions. There are 2 new files: 1. "DisablePuma.ini": HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\AUDIO",DisableProtectedAudioDG,0x10001,0x00000001 2. tossaemaxapo32.dll. (Description: "TOSHIBA Speaker Audio Enhancement Maximizer" The only other changed files are tosasfapo32.dll (way smaller, 880 kB ->790 KB, Description: "Toshiba Audio Source Filtering APO)" and SAII.cab (the same size, the content being almost the same. Only difference: The version number in SA2VER.INI) The main driver, *.sys, are indeed the same. Best regards Michael
Hello Michael, the pointed out differences is the relevant that breaks the driver. I bet it's not SAII.cab :-) Best regards Uwe
Hi Michael, Any news here on the question from Uwe? Oherwise I suggest that we finally close it as beeing unactionable on our end. We cannot keep bugs open idefintively for years. Regards, Salvatore
Hello Salvatore, I hope that I find some time next week. The Problem: The SSD died on my z20t main maschine... Best regards MIchael On Sat, 13 Sep 2025 22:40:44 +0200 Salvatore Bonaccorso <carnil@debian.org> wrote: