Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
Hi! > > > > > > 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 Hmm. So audio here is broken in more than one way, but revert of 20e3f985 seems to make it better. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Thu, Dec 28, 2017 at 11:41:45AM +0100, Thomas Gleixner wrote: > On Sun, 24 Dec 2017, vcap...@pengaru.com wrote: > > On Sat, Dec 23, 2017 at 09:33:37PM +0100, Thomas Gleixner wrote: > > > > It seems like the affinity changes are assuming a strict adherence to > > > > the CPU mask when the underlying hardware is treating it more as a hint. > > > > Perhaps handlers still need to be maintained on all CPUs in a given apic > > > > domain, regardless of what the masks are configured as, to cover these > > > > situations. > > > > > > That's odd. I'll have a look after the holidays. > > > > > > > Ok, just FYI I've reproduced it on rc5 as well. > > > > I may be offline a bit at the start of the new year, in case you've got > > something for me to test and I'm unresponsive. > > Can you try the patch below? > Looks fixed so far, I'll try living in 4.15-rc5 now and will report back if anything goes sideways. Thanks Thomas! > Thanks, > > tglx > > 8<--- > --- a/arch/x86/kernel/apic/apic_flat_64.c > +++ b/arch/x86/kernel/apic/apic_flat_64.c > @@ -151,7 +151,7 @@ static struct apic apic_flat __ro_after_ > .apic_id_valid = default_apic_id_valid, > .apic_id_registered = flat_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > .irq_dest_mode = 1, /* logical */ > > .disable_esr= 0, > --- a/arch/x86/kernel/apic/probe_32.c > +++ b/arch/x86/kernel/apic/probe_32.c > @@ -105,7 +105,7 @@ static struct apic apic_default __ro_aft > .apic_id_valid = default_apic_id_valid, > .apic_id_registered = default_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > /* logical delivery broadcast to all CPUs: */ > .irq_dest_mode = 1, > > --- a/arch/x86/kernel/apic/x2apic_cluster.c > +++ b/arch/x86/kernel/apic/x2apic_cluster.c > @@ -184,7 +184,7 @@ static struct apic apic_x2apic_cluster _ > .apic_id_valid = x2apic_apic_id_valid, > .apic_id_registered = x2apic_apic_id_registered, > > - .irq_delivery_mode = dest_LowestPrio, > + .irq_delivery_mode = dest_Fixed, > .irq_dest_mode = 1, /* logical */ > > .disable_esr= 0,
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Sun, 24 Dec 2017, vcap...@pengaru.com wrote: > On Sat, Dec 23, 2017 at 09:33:37PM +0100, Thomas Gleixner wrote: > > > It seems like the affinity changes are assuming a strict adherence to > > > the CPU mask when the underlying hardware is treating it more as a hint. > > > Perhaps handlers still need to be maintained on all CPUs in a given apic > > > domain, regardless of what the masks are configured as, to cover these > > > situations. > > > > That's odd. I'll have a look after the holidays. > > > > Ok, just FYI I've reproduced it on rc5 as well. > > I may be offline a bit at the start of the new year, in case you've got > something for me to test and I'm unresponsive. Can you try the patch below? Thanks, tglx 8<--- --- a/arch/x86/kernel/apic/apic_flat_64.c +++ b/arch/x86/kernel/apic/apic_flat_64.c @@ -151,7 +151,7 @@ static struct apic apic_flat __ro_after_ .apic_id_valid = default_apic_id_valid, .apic_id_registered = flat_apic_id_registered, - .irq_delivery_mode = dest_LowestPrio, + .irq_delivery_mode = dest_Fixed, .irq_dest_mode = 1, /* logical */ .disable_esr= 0, --- a/arch/x86/kernel/apic/probe_32.c +++ b/arch/x86/kernel/apic/probe_32.c @@ -105,7 +105,7 @@ static struct apic apic_default __ro_aft .apic_id_valid = default_apic_id_valid, .apic_id_registered = default_apic_id_registered, - .irq_delivery_mode = dest_LowestPrio, + .irq_delivery_mode = dest_Fixed, /* logical delivery broadcast to all CPUs: */ .irq_dest_mode = 1, --- a/arch/x86/kernel/apic/x2apic_cluster.c +++ b/arch/x86/kernel/apic/x2apic_cluster.c @@ -184,7 +184,7 @@ static struct apic apic_x2apic_cluster _ .apic_id_valid = x2apic_apic_id_valid, .apic_id_registered = x2apic_apic_id_registered, - .irq_delivery_mode = dest_LowestPrio, + .irq_delivery_mode = dest_Fixed, .irq_dest_mode = 1, /* logical */ .disable_esr= 0,
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
Hi! > It's this allocation domain mask hook which has been bypassed by the > offending commit. The existing approach is more robust in the face of > relaxed adherence to destination cpumasks since it's all-inclusive, > whereas the new code is exclusive to a specific cpu. > > Is it possible what I'm observing is just another manifestation of > what's being described in that comment? This is a core 2 duo, so not > hyper-threaded. But maybe something funny happens when switching > cstates in response to interrupts - like maybe the wrong cpu can be used > if it can save power vs. powering up another? Just thinking out loud > here. > > In any case, 4.15-rc4 is quite unusable on my machine because of this. > > Pavel, do you observe the same behavior on your x60, WRT AC power? No.. no Monitor-Mwait messages, and audio works if I unplug AC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
Hi! > > > > > > > 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. Hmm. Yes, I do experience something similar, but that has been there for long time now. Audio does not work with chromium (looping weirdly) for first few minutes after boot. Then I restart chromium and it starts to work ok... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Sat, Dec 23, 2017 at 09:33:37PM +0100, Thomas Gleixner wrote: > On Sat, 23 Dec 2017, vcap...@pengaru.com wrote: > > On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote: > > Added the following instrumentation: > > > > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > > index 93edc2236282..7034eda4d494 100644 > > --- a/arch/x86/kernel/apic/vector.c > > +++ b/arch/x86/kernel/apic/vector.c > > @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct > > apic_chip_data *d, > > cpumask_and(vector_searchmask, vector_searchmask, mask); > > BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata, > > &d->cfg.dest_apicid)); > > + > > + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector, > > cpumask_first(vector_searchmask)); > > + > > return 0; > > } > > > > This is what I see: > > > > Upon playing song in cmus (on AC power since boot): > > Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1 > > > > Yank AC: > > Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1 > > Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector > > > > So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in > > the added printk. > > > > It seems like the affinity changes are assuming a strict adherence to > > the CPU mask when the underlying hardware is treating it more as a hint. > > Perhaps handlers still need to be maintained on all CPUs in a given apic > > domain, regardless of what the masks are configured as, to cover these > > situations. > > That's odd. I'll have a look after the holidays. > Ok, just FYI I've reproduced it on rc5 as well. I may be offline a bit at the start of the new year, in case you've got something for me to test and I'm unresponsive. Regards, Vito Caputo
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Sat, 23 Dec 2017, vcap...@pengaru.com wrote: > On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote: > Added the following instrumentation: > > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index 93edc2236282..7034eda4d494 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct > apic_chip_data *d, > cpumask_and(vector_searchmask, vector_searchmask, mask); > BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata, > &d->cfg.dest_apicid)); > + > + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector, > cpumask_first(vector_searchmask)); > + > return 0; > } > > This is what I see: > > Upon playing song in cmus (on AC power since boot): > Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1 > > Yank AC: > Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1 > Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector > > So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in > the added printk. > > It seems like the affinity changes are assuming a strict adherence to > the CPU mask when the underlying hardware is treating it more as a hint. > Perhaps handlers still need to be maintained on all CPUs in a given apic > domain, regardless of what the masks are configured as, to cover these > situations. That's odd. I'll have a look after the holidays. Merry Christmas! Thanks, tglx
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote: > On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote: > > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > > > You forgot to mention commit id :-). > > > > > > > > > > That is very strange, anyhow: > > > > > > commit fdba46ffb4c203b6e6794163493fd310f98bb4be > > > Author: Thomas Gleixner > > > Date: Wed Sep 13 23:29:27 2017 +0200 > > > > > > x86/apic: Get rid of multi CPU affinity > > > > > > > > > Will try reverting soon, just a bit busy today out in the desert and the > > > sun > > > is going down so my solar panel is useless. > > > > The revert is not trivial. > > > > What is the exact problem and how do you reproduce that? > > > > Thanks, > > > > So I had some time today to poke at this some more. Since it looks to > be easily reproduced by simply pulling the AC power while playing music > or doing IO, and dmesg clearly reports using mwait, I tried booting with > idle=nomwait to see if that made any difference. It didn't, the same > thing still occurs. > > In trying to make sense of this totally unfamiliar apic code and better > understand these changes, I came across this comment which seemed a bit > telling: > > 40 void flat_vector_allocation_domain(int cpu, struct cpumask *retmask, > 41const struct cpumask *mask) > 42 { > 43 /* > 44 * Careful. Some cpus do not strictly honor the set of cpus > 45 * specified in the interrupt destination when using lowest > 46 * priority interrupt delivery mode. > 47 * > 48 * In particular there was a hyperthreading cpu observed to > 49 * deliver interrupts to the wrong hyperthread when only one > 50 * hyperthread was specified in the interrupt desitination. > 51 */ > 52 cpumask_clear(retmask); > 53 cpumask_bits(retmask)[0] = APIC_ALL_CPUS; > 54 } > > It's this allocation domain mask hook which has been bypassed by the > offending commit. The existing approach is more robust in the face of > relaxed adherence to destination cpumasks since it's all-inclusive, > whereas the new code is exclusive to a specific cpu. > > Is it possible what I'm observing is just another manifestation of > what's being described in that comment? This is a core 2 duo, so not > hyper-threaded. But maybe something funny happens when switching > cstates in response to interrupts - like maybe the wrong cpu can be used > if it can save power vs. powering up another? Just thinking out loud > here. > > In any case, 4.15-rc4 is quite unusable on my machine because of this. > Some more food for thought: Added the following instrumentation: diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c index 93edc2236282..7034eda4d494 100644 --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct apic_chip_data *d, cpumask_and(vector_searchmask, vector_searchmask, mask); BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata, &d->cfg.dest_apicid)); + + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector, cpumask_first(vector_searchmask)); + return 0; } This is what I see: Upon playing song in cmus (on AC power since boot): Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1 Yank AC: Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1 Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in the added printk. It seems like the affinity changes are assuming a strict adherence to the CPU mask when the underlying hardware is treating it more as a hint. Perhaps handlers still need to be maintained on all CPUs in a given apic domain, regardless of what the masks are configured as, to cover these situations. Regards, Vito Caputo
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > > You forgot to mention commit id :-). > > > > > > > That is very strange, anyhow: > > > > commit fdba46ffb4c203b6e6794163493fd310f98bb4be > > Author: Thomas Gleixner > > Date: Wed Sep 13 23:29:27 2017 +0200 > > > > x86/apic: Get rid of multi CPU affinity > > > > > > Will try reverting soon, just a bit busy today out in the desert and the sun > > is going down so my solar panel is useless. > > The revert is not trivial. > > What is the exact problem and how do you reproduce that? > > Thanks, > So I had some time today to poke at this some more. Since it looks to be easily reproduced by simply pulling the AC power while playing music or doing IO, and dmesg clearly reports using mwait, I tried booting with idle=nomwait to see if that made any difference. It didn't, the same thing still occurs. In trying to make sense of this totally unfamiliar apic code and better understand these changes, I came across this comment which seemed a bit telling: 40 void flat_vector_allocation_domain(int cpu, struct cpumask *retmask, 41const struct cpumask *mask) 42 { 43 /* 44 * Careful. Some cpus do not strictly honor the set of cpus 45 * specified in the interrupt destination when using lowest 46 * priority interrupt delivery mode. 47 * 48 * In particular there was a hyperthreading cpu observed to 49 * deliver interrupts to the wrong hyperthread when only one 50 * hyperthread was specified in the interrupt desitination. 51 */ 52 cpumask_clear(retmask); 53 cpumask_bits(retmask)[0] = APIC_ALL_CPUS; 54 } It's this allocation domain mask hook which has been bypassed by the offending commit. The existing approach is more robust in the face of relaxed adherence to destination cpumasks since it's all-inclusive, whereas the new code is exclusive to a specific cpu. Is it possible what I'm observing is just another manifestation of what's being described in that comment? This is a core 2 duo, so not hyper-threaded. But maybe something funny happens when switching cstates in response to interrupts - like maybe the wrong cpu can be used if it can save power vs. powering up another? Just thinking out loud here. In any case, 4.15-rc4 is quite unusable on my machine because of this. Pavel, do you observe the same behavior on your x60, WRT AC power? I've dropped Takashi from the CC list as this pretty clearly isn't a sound-specific problem. Thanks, Vito Caputo
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > > You forgot to mention commit id :-). > > > > > > > That is very strange, anyhow: > > > > commit fdba46ffb4c203b6e6794163493fd310f98bb4be > > Author: Thomas Gleixner > > Date: Wed Sep 13 23:29:27 2017 +0200 > > > > x86/apic: Get rid of multi CPU affinity > > > > > > Will try reverting soon, just a bit busy today out in the desert and the sun > > is going down so my solar panel is useless. > > The revert is not trivial. > > What is the exact problem and how do you reproduce that? > Dang. Ostensibly the problem is audio playback looping what seems to be stuck in a DMA buffer when I pause the audio. I also saw once during the bisect on a 'bad' commit, a reproduction of this, which hung everything doing IO until it the ata1 reset happened: [ 36.606657] Monitor-Mwait will be used to enter C-3 state [ 36.628663] do_IRQ: 0.35 No irq handler for vector [ 37.875724] do_IRQ: 0.194 No irq handler for vector [ 69.099090] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 69.099165] ata1.00: failed command: FLUSH CACHE EXT [ 69.099211] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 6 res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 69.099285] ata1.00: status: { DRDY } [ 69.099309] ata1: hard resetting link [ 69.406185] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 69.409255] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded [ 69.409259] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out [ 69.409261] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out [ 69.409433] ata1.00: supports DRM functions and may not be fully accessible [ 69.409819] ata1.00: NCQ Send/Recv Log not supported [ 69.411644] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded [ 69.411649] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out [ 69.411654] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out [ 69.411842] ata1.00: supports DRM functions and may not be fully accessible [ 69.412242] ata1.00: NCQ Send/Recv Log not supported [ 69.412719] ata1.00: configured for UDMA/133 [ 69.412721] ata1.00: retrying FLUSH 0xea Emask 0x4 [ 69.412964] ata1: EH complete But that is more difficult to reproduce, it doesn't seem to happen regularly. Infact, I thought that was independent from the audio problem at first but now it's become clear they're all related. The 'bad' commits always showed the 'do_IRQ: No irq handler for vector' lines, sometimes they appear for the first time on the console when I yanked the power cord while playing music in the quick repro cycle without running X or anything. What I've been doing to reproduce this is simply boot to multi-user.target, login, run `cmus`, and play a song. Next pull the AC power from the thinkpad x61s. Immediately the audio gets messed up, pausing the audio doesn't pause it, it just loops the last tiny buffer contents. That's all I've got right now, but it doesn't seem to be limited to the audio problem as shown by the ata1 reset. Also I've searched through all my stored journals for anything resembling that ata1 problem, and there's not a single occurrence going back ~300 boots across a handful of kernel versions. If you'd like to prep a patch for me to test, I'm happy to test, but I'm not sure how online I'll be for the next 24 hours. It's some kind of miracle we're communicating as-is, I'm in the middle of the damn desert but somehow there's a cell signal. Thanks, Vito Caputo
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > You forgot to mention commit id :-). > > > > That is very strange, anyhow: > > commit fdba46ffb4c203b6e6794163493fd310f98bb4be > Author: Thomas Gleixner > Date: Wed Sep 13 23:29:27 2017 +0200 > > x86/apic: Get rid of multi CPU affinity > > > Will try reverting soon, just a bit busy today out in the desert and the sun > is going down so my solar panel is useless. The revert is not trivial. What is the exact problem and how do you reproduce that? Thanks, tglx
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > Hi! > > > > > > > > > > > > Reappeared, 4.15-rc1. > > > > > > > > > > > > > > > > > > > > > > [ 40.473822] PM: suspend exit > > > > > > > > > > > [ 40.526027] sdhci-pci :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 :15:00.2: Will use DMA mode > > > > > > > > > > > even though > > > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode > > > > > > > > > > > even though > > > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > > > [ 40.737339] sdhci-pci :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 :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
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
Hi! > > > > > > > > > > Reappeared, 4.15-rc1. > > > > > > > > > > > > > > > > > > > > [ 40.473822] PM: suspend exit > > > > > > > > > > [ 40.526027] sdhci-pci :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 :15:00.2: Will use DMA mode > > > > > > > > > > even though > > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode > > > > > > > > > > even though > > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > > [ 40.737339] sdhci-pci :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 :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: You forgot to mention commit id :
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, vcap...@pengaru.com wrote: > On Mon, Dec 18, 2017 at 06:06:58PM -0800, vcap...@pengaru.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 :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 :15:00.2: Will use DMA mode even > > > > > > > > > though > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even > > > > > > > > > though > > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > > [ 40.737339] sdhci-pci :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 :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 > > > > in
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 06:06:58PM -0800, vcap...@pengaru.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 :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 :15:00.2: Will use DMA mode even > > > > > > > > though > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even > > > > > > > > though > > > > > > > > HW doesn't fully claim to support it. > > > > > > > > [ 40.737339] sdhci-pci :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 :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 > > 20e3f985bb875fea4f86b04eb
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even > > > > > > > though > > > > > > > HW doesn't fully claim to support it. > > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even > > > > > > > though > > > > > > > HW doesn't fully claim to support it. > > > > > > > [ 40.737339] sdhci-pci :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 :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 t
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 40.737339] sdhci-pci :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 :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 :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > > > > > HW doesn't fully claim to support it. > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > HW doesn't fully claim to support it. > > > > > [ 40.737339] sdhci-pci :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 :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. Takashi
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > > > > HW doesn't fully claim to support it. > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > > > HW doesn't fully claim to support it. > > > > [ 40.737339] sdhci-pci :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 :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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > > > HW doesn't fully claim to support it. > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > > HW doesn't fully claim to support it. > > > [ 40.737339] sdhci-pci :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 :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? Takashi
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > > HW doesn't fully claim to support it. > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > HW doesn't fully claim to support it. > > [ 40.737339] sdhci-pci :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 :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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though > HW doesn't fully claim to support it. > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > HW doesn't fully claim to support it. > [ 40.737339] sdhci-pci :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 :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... thanks, Takashi
thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
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 :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 :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though HW doesn't fully claim to support it. [ 40.737339] sdhci-pci :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 :00:1b.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature