[Tohsiba Portege Z20T-C] Internal speakers don't work after standby

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1612916

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.8 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc2/

The line "UpgradeStatus: No upgrade log present (probably fresh install)" is correct - it was a clean 16.04 install, and I had the problem from the beginning.

I'll try the mainline Kernel at the next opportunity for a restart :-)

Problem exists with 4.8.0-040800rc2-generic as well.

Michael, to keep this relevant to upstream, one would want to test the latest mainline kernel (now 4.8-rc4) as it is released.

Could you please advise?

Same problem with 4.8-rc4.

Michael, could you please provide the missing information from https://wiki.ubuntu.com/DebuggingKernelSuspend ?

I suspended using the gui, resumed using the power button.

root@michis-toshiba:~# cat /sys/kernel/debug/suspend_stats
success: 1
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
  last_failed_dev:

  last_failed_errno: 0
   0
  last_failed_step:

root@michis-toshiba:~# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEGP S4 *disabled
PEG2 S4 *disabled
PEGP S4 *disabled
UAR1 S3 *disabled
ECIR S4 *disabled
GLAN S4 *enabled pci:0000:00:1f.6
XHC S3 *enabled pci:0000:00:14.0
XDCI S4 *disabled
HDAS S4 *disabled pci:0000:00:1f.3
RP09 S4 *disabled
PWRB S4 *enabled platform:PNP0C0C:00

The trace thing doesn't work for me:
michi@michis-toshiba:~$ sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"
[sudo] Passwort für michi:
sh: 1: cannot create /sys/power/pm_trace: Permission denied

michi@michis-toshiba:/sys/power$ ls
disk image_size pm_async pm_freeze_timeout pm_print_times pm_test pm_wakeup_irq reserved_size resume state wakeup_count

michi@michis-toshiba:/sys/power$ uname -a
Linux michis-toshiba 4.8.0-040800rc4-generic #201608312129 SMP Thu Sep 1 01:31:59 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Michael, I'll mark this Triaged for now given you have tested the latest upstream kernel, and hopefully the Ubuntu Audio Team would speak further to this issue.

Any news? restarting pulseaudio or reloading snd_soc_skl doesn't help.

pavucontrol shows sound output at the soundcard if playing music.

You could try getting the latest ALSA driver code, which is not all necessarily in the latest mainline released kernel... https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS.

Sadly didn't helped :-(

Michael, to keep this relevant to upstream, one would want check for, and test the latest mainline kernel (now 4.9-rc4) as it is released.

Could you please advise?

No change with 4.9-rc4.

This problems happens with current Debian stretch as well.

I've made a bug report in Debian's bug tracker system as well (already some time ago, but forgot to mention it) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404

Looks like the issue has not been resoled yet. I can confirm I have the same issue on a Toshiba z20t-B with Ubuntu 19.10 ( 5.3.0-18-generic kernel).

Michael, it wouldn't hurt to update your BIOS to the latest (now. 6.30), given it includes multiple, high severity security vulnerability fixes.

Once done, could you please advise if this changes anything, and post the results of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

If still reproducible, to keep this relevant, please attempt a suspend via live environment of http://cdimage.ubuntu.com/daily-live/current/ and advise on the outcome.

I have the same problem with a Z20T-C (Z20T-C-11H m7-6y75).

I am using Ubuntu 18.04.3 (kernel 5.0.0-32-generic).

I updated to BIOS 6.30, but unfortunately this didn't make any difference.

Can confirm the problem still exists with Ubuntu 19.10, all up-to-date.

Where can I dig to debug?

Thanks!

penalvch: in view of the fact that we have independently confirmed the bug with the latest BIOS and the latest Ubuntu, would it now make sense to change the status back to Confirmed (and remove the bios-outdated tag)?

Also, can I ask why you changed the importance down to Low? Having sound not working is a major usability problem, in my opinion.

Thanks.

apsaras, it's helpful for developers if folks report their own bug so logs may be obtained from the hardware, regardless of similarities, via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

To do otherwise risks issues being ignored as unconfirmable noise.

Thank you for the reply.

Are you saying that you need confirmation from the original bug reporter (Michael) that his problem still exists with the latest BIOS and latest Ubuntu, and that confirmation from other people won't do because we might have a different problem?

I can understand the reasoning behind that policy, but I think in this case it's reasonably clear that we all have the same problem here. If we were all to create separate bug reports describing exactly the same symptoms then that would create confusing distractions and dilute the good efforts of people like you, would it not?

Of course, if it's the only way to proceed then we can create a new report. (Can we be sure that it won't immediately get closed as a duplicate?)

I, the original reporter, can confirm that this problem persists with current BIOS and Ubuntu.

Arch is affected as well: https://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109296.html

It's a pity - it's a great laptop apart from this problem, but not being able to shut the lid without losing sound is a significant drawback. It wouldn't be so bad if there were a workaround of some sort, but I've not seen one and I don't know how to go about looking for one.

I tried it with Ubuntu 20.04 (live USB version) and get the same problem.

Only workaround is to not use suspend to ram, but suspend to disk.

This bug is very annoying. This problem still exists with every kernel and pulse/pipe combination I'm capable of (tested also with a 6.0 kernel).
No workwaround works but suspend to disk.

Can you please attach dmesg?

I am using Kubuntu 20.10 on a Toshiba Z20T-C-140 and this bug still exists.

Any way I can help to solve this issue by providing logfiles?

It would be a shame not being able to use this laptop because of this old bug.