Message-ID: <20171219231256.dpizizz55o27op3s@shells.gnugeneration.com>
Date:   Tue, 19 Dec 2017 15:12:57 -0800
From:   vcaputo@...garu.com
To:     tglx@...utronix.de
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Pavel Machek <pavel@....cz>, Takashi Iwai <tiwai@...e.de>
Subject: Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60:
 sound problems in 4.14.0-next-20171114

On Mon, Dec 18, 2017 at 08:54:15PM -0800, vcaputo@...garu.com wrote:
> On Mon, Dec 18, 2017 at 06:06:58PM -0800, vcaputo@...garu.com wrote:
> > On Thu, Dec 14, 2017 at 10:57:30AM +0100, Pavel Machek wrote:
> > > On Tue 2017-11-28 08:00:20, Takashi Iwai wrote:
> > > > On Mon, 27 Nov 2017 19:44:12 +0100,
> > > > Pavel Machek wrote:
> > > > > 
> > > > > On Mon 2017-11-27 19:35:32, Takashi Iwai wrote:
> > > > > > On Mon, 27 Nov 2017 19:31:51 +0100,
> > > > > > Pavel Machek wrote:
> > > > > > > 
> > > > > > > On Mon 2017-11-27 17:33:28, Takashi Iwai wrote:
> > > > > > > > On Mon, 27 Nov 2017 17:30:11 +0100,
> > > > > > > > Pavel Machek wrote:
> > > > > > > > > 
> > > > > > > > > On Wed 2017-11-15 12:11:20, Pavel Machek wrote:
> > > > > > > > > > On Wed 2017-11-15 11:43:34, Takashi Iwai wrote:
> > > > > > > > > > > On Wed, 15 Nov 2017 11:05:33 +0100,
> > > > > > > > > > > Pavel Machek wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi!
> > > > > > > > > > > > 
> > > > > > > > > > > > There are some sound problems in 4.14.0-next-20171114:
> > > > > > > > > > > > 
> > > > > > > > > > > > mplayer shows pictures from video, but does not play.
> > > > > > > > > > > > 
> > > > > > > > > > > > vlc plays video, but w/o sound
> > > > > > > > > > > > 
> > > > > > > > > > > > mpg123 works.
> > > > > > > > > > > > 
> > > > > > > > > > > > Hw is thinkpad X60. Any ideas?
> > > > > > > > > > > 
> > > > > > > > > > > Nothing comes to my mind for now, sorry.
> > > > > > > > > > > 
> > > > > > > > > > > Is it a regression, right?  There are only few changes in both
> > > > > > > > > > > HD-audio and ALSA core sides, and they should be fairly harmless.
> > > > > > > > > > 
> > > > > > > > > > Regression: yes. Reproducible: not sure. It went away after a reboot
> > > > > > > > > > :-(.
> > > > > > > > > 
> > > > > > > > > Reappeared, 4.15-rc1.
> > > > > > > > > 
> > > > > > > > > [   40.473822] PM: suspend exit
> > > > > > > > > [   40.526027] sdhci-pci 0000:15:00.2: Will use DMA mode even though
> > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > [   40.569765] e1000e: eth1 NIC Link is Down
> > > > > > > > > [   40.578257] sdhci-pci 0000:15:00.2: Will use DMA mode even though
> > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > [   40.648476] sdhci-pci 0000:15:00.2: Will use DMA mode even though
> > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > [   40.737339] sdhci-pci 0000:15:00.2: Will use DMA mode even though
> > > > > > > > > HW doesn't fully claim to support it.
> > > > > > > > > [   43.018955] wlan0: authenticate with 00:00:00:00:00:01
> > > > > > > > > [   43.019072] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
> > > > > > > > > [   43.023955] wlan0: authenticated
> > > > > > > > > [   43.031721] wlan0: associate with 00:00:00:00:00:01 (try 1/3)
> > > > > > > > > [   43.039733] wlan0: RX AssocResp from 00:00:00:00:00:01 (capab=0x401
> > > > > > > > > status=0 aid=1)
> > > > > > > > > [   43.042712] wlan0: associated
> > > > > > > > > [  480.662456] snd_hda_intel 0000:00:1b.0: IRQ timing workaround is
> > > > > > > > > activated for card #0. Suggest a bigger bdl_pos_adj.
> > > > > > > > 
> > > > > > > > This message is often superfluous, so don't take this too seriously.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > pavel@amd:~$
> > > > > > > > > 
> > > > > > > > > Again, mplayer has problems, mpg123 works. This time mplayer started
> > > > > > > > > playing video (w/o sound) after long delay.
> > > > > > > > > 
> > > > > > > > > Uh. huh. And now problems appeared in mpg123, too, and then went away
> > > > > > > > > in mpg123 _and_ mplayer. Interesting.
> > > > > > > > > 
> > > > > > > > > I suspect some pulseaudio fun. chromium always has sound problems,
> > > > > > > > > then I restart chromium and everything is ok. But something changed in
> > > > > > > > > -next and 4.15-rc1, because mplayer did not have problems before.
> > > > > > > > 
> > > > > > > > Hm, there is no code change at all in sound/*.  If it happens only in
> > > > > > > > linux-next, it must be something else...
> > > > > > > 
> > > > > > > It happened first in -next, now it is in 4.15-rc1.
> > > > > > 
> > > > > > So you meant a possible regression between 4.14 and 4.15-rc1?
> > > > > 
> > > > > Yes.
> > > > 
> > > > Hm, as far as I see, the only significant difference is the commit
> > > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71
> > > >     ALSA: pcm: update tstamp only if audio_tstamp changed
> > > >     
> > > > Another change d6c0615f510bc1ee26cfb2b9a3343ac99b9c46fb
> > > >     ALSA: hda - Fix yet remaining issue with vmaster 0dB
> > > >     initialization
> > > > is basically for fixing a previous wrong fix, and it should influence
> > > > on all use cases, not only for a specific application.
> > > 
> > > Happened again, this time on -rc3. It is more than "audio is silent"
> > > -- apps behave strangely. Let me test with
> > > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 reverted.
> > > 
> > > Hmm. This is 4th regression this release cycle :-(.
> > 
> > 
> > Today I jumped to 4.15-rc4 from 4.14-rc6, and have noticed some oddities
> > with audio in youtube under firefox which I never experienced before.
> > 
> > If I pause the playback, the audio seems to infinitely loop on whatever
> > is in the dma buffer.  Resuming playback works but now the expected
> > audio has repeated pops and clicks mixed in with it.
> > 
> > Even closing firefox doesn't seem to stop the looping buffer...
> > 
> > Machine is an x61s 1.8ghz thinkpad, x86_64, debian stretch, .config attached.
> > 
> > This for me is a 4.15 blocker, and I presume it's related to Pavel's
> > experience as the x60 isn't much different AFAIK.
> > 
> 
> Just reproduced this, it seems to be trivial to repro and doesn't
> actually require pausing or anything.  Simply watching a youtube video
> causes the audio to get messed up after a short period.
> 
> I monitored `journalctl --dmesg --follow` while reproducing this and saw
> this line appear at the very moment the audio got messed up:
> 
>   kernel: Monitor-Mwait will be used to enter C-3 state
> 
> Prior to that, everything seemed to be owrking fine.
> 

After a lengthy bisect, I ended up with this being the bad commit:

> Regards,
> Vito Caputo


Have not tested a revert yet, but it's reliably reproducible.

I mess up the audio by pulling the AC power while listening to music, causing
things to run from battery.

Addressed to tglx since it's his commit...

Regards,
Vito Caputo

Powered by blists - more mailing lists