Re: [regression] ALSA: hda - Handle open while transitioning to D3.

Re: [regression] ALSA: hda - Handle open while transitioning to D3.

[Dylan Reid]

On Jul 13, 2012 11:01 PM, "Oleksij Rempel (fishor)" <
bug-track@fisher-privat.net> wrote:
>
> Hallo Dylan, Takashi,
>
> I have regression after patch b4a91cf05c3 "ALSA: hda - Handle open while
transitioning to D3."
>
> This regression i can reproduce only if my laptop works on batteries.
After this patch it needs almost 1 minute more to start. The login screen
usually plays start sound, but after this patch it wait until sound card is
ready.
>
> My hardware: asus zenbook ux31e.
>
> Codec: Realtek ALC269VB
>
> 00:1b.0 0403: 8086:1c20 (rev 05)
>         Subsystem: 1043:1427
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 50
>         Region 0: Memory at dfe00000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: <access denied>
>         Kernel driver in use: snd_hda_intel
>         Kernel modules: snd-hda-intel
>

Could you enable config_snd_debug and send the output during startup?  I'm
actually using the same codec on one of our systems.

Thanks for testing.

Dylan

Re: [regression] ALSA: hda - Handle open while transitioning to D3.

[Dylan Reid]

On Sat, Jul 14, 2012 at 6:36 AM, Oleksij Rempel (fishor)
<bug-track@fisher-privat.net> wrote:
> dmesg is in attachment
Thanks Oleksij,

I didn't get much from that though.  What is your powersave timeout
set to?  If you have time could you try adding the following and send
me the output, I have two guesses about where it is spending it's time
(no guesses about why yet though).  I've got a couple of systems with
a 269, I'll try to get some tests run on those tomorrow.

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 20580bf..fd8ce9e 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -4383,9 +4383,11 @@ static void hda_power_work(struct work_struct *work)
        }
        spin_unlock(&codec->power_lock);

+       snd_printd("power_work start %p\n", codec);;
        hda_call_codec_suspend(codec);
        if (bus->ops.pm_notify)
                bus->ops.pm_notify(bus);
+       snd_printd("power_work done %p\n", codec);;
 }

 static void hda_keep_power_on(struct hda_codec *codec)
@@ -4426,7 +4428,9 @@ static void __snd_hda_power_up(struct hda_codec
*codec, bool wait_power_down)
        }
        spin_unlock(&codec->power_lock);

+       snd_printd("power_up cancel sync start %p\n", codec);
        cancel_delayed_work_sync(&codec->power_work);
+       snd_printd("power_up cancel sync done %p\n", codec);

        spin_lock(&codec->power_lock);
        /* If the power down delayed work was cancelled above before starting,

>
>
> On 14.07.2012 11:21, Dylan Reid wrote:
>>
>> On Jul 13, 2012 11:01 PM, "Oleksij Rempel (fishor)"
>> <bug-track@fisher-privat.net <mailto:bug-track@fisher-privat.net>> wrote:
>>  >
>>  > Hallo Dylan, Takashi,
>>  >
>>  > I have regression after patch b4a91cf05c3 "ALSA: hda - Handle open
>> while transitioning to D3."
>>  >
>>  > This regression i can reproduce only if my laptop works on batteries.
>> After this patch it needs almost 1 minute more to start. The login
>> screen usually plays start sound, but after this patch it wait until
>> sound card is ready.
>>  >
>>  > My hardware: asus zenbook ux31e.
>>  >
>>  > Codec: Realtek ALC269VB
>>  >
>>  > 00:1b.0 0403: 8086:1c20 (rev 05)
>>  >         Subsystem: 1043:1427
>>  >         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>  >         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>>  >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>  >         Latency: 0, Cache Line Size: 64 bytes
>>  >         Interrupt: pin A routed to IRQ 50
>>  >         Region 0: Memory at dfe00000 (64-bit, non-prefetchable)
>> [size=16K]
>>  >         Capabilities: <access denied>
>>  >         Kernel driver in use: snd_hda_intel
>>  >         Kernel modules: snd-hda-intel
>>  >
>>
>> Could you enable config_snd_debug and send the output during startup?
>> I'm actually using the same codec on one of our systems.
>>
>> Thanks for testing.
>>
>> Dylan
>>
>
>

Re: [regression] ALSA: hda - Handle open while transitioning to D3.

[Dylan Reid]

On Wed, Jul 18, 2012 at 10:26 PM, Oleksij Rempel (fishor)
<bug-track@fisher-privat.net> wrote:
> On 17.07.2012 07:26, Dylan Reid wrote:
>>
>> On Sat, Jul 14, 2012 at 6:36 AM, Oleksij Rempel (fishor)
>> <bug-track@fisher-privat.net> wrote:
>>>
>>> dmesg is in attachment
>>
>> Thanks Oleksij,
>>
>> I didn't get much from that though.  What is your powersave timeout
>> set to?
>
>
> I do not know, it should be some default value.
>
>
>>  If you have time could you try adding the following and send
>> me the output, I have two guesses about where it is spending it's time
>> (no guesses about why yet though).  I've got a couple of systems with
>> a 269, I'll try to get some tests run on those tomorrow.
>
>
> result is attached.
>
Great, thanks Oleksij,

I tried this on an ACER AC700 which also has the ALC269VB and could
not get anything like this to happen.  So I'm sorry to keep bothering
you for more information.  I attached the alsa-info.sh output, if you
see any interesting differences let me know.

>From the output it looks like something is opening the driver about
three times a second, do you know what is doing that?  It appears to
be doing what it should be in this case, although it is a little hard
to tell.  If you could strace the process doing all the opens that
might provide some good info.

Thanks again for the help.
Dylan

Re: [regression] ALSA: hda - Handle open while transitioning to D3.

[Dylan Reid]

On Thu, Jul 19, 2012 at 12:29 AM, Oleksij Rempel (fishor)
<bug-track@fisher-privat.net> wrote:
> On 19.07.2012 08:44, Dylan Reid wrote:
>>
>> On Wed, Jul 18, 2012 at 10:26 PM, Oleksij Rempel (fishor)
>> <bug-track@fisher-privat.net> wrote:
>>>
>>> On 17.07.2012 07:26, Dylan Reid wrote:
>>>>
>>>>
>>>> On Sat, Jul 14, 2012 at 6:36 AM, Oleksij Rempel (fishor)
>>>> <bug-track@fisher-privat.net> wrote:
>>>>>
>>>>>
>>>>> dmesg is in attachment
>>>>
>>>>
>>>> Thanks Oleksij,
>>>>
>>>> I didn't get much from that though.  What is your powersave timeout
>>>> set to?
>>>
>>>
>>>
>>> I do not know, it should be some default value.
>>>
>>>
>>>>   If you have time could you try adding the following and send
>>>> me the output, I have two guesses about where it is spending it's time
>>>> (no guesses about why yet though).  I've got a couple of systems with
>>>> a 269, I'll try to get some tests run on those tomorrow.
>>>
>>>
>>>
>>> result is attached.
>>>
>> Great, thanks Oleksij,
>>
>> I tried this on an ACER AC700 which also has the ALC269VB and could
>> not get anything like this to happen.  So I'm sorry to keep bothering
>> you for more information.  I attached the alsa-info.sh output, if you
>> see any interesting differences let me know.
>>
>>  From the output it looks like something is opening the driver about
>> three times a second, do you know what is doing that?  It appears to
>> be doing what it should be in this case, although it is a little hard
>> to tell.  If you could strace the process doing all the opens that
>> might provide some good info.
>>
>> Thanks again for the help.
>> Dylan
>
>
>
> Ok, i did some more testing compared the difference between battery and
> non-battery mode.
>
> first of all on non-battery mode, this part of code is not executed. I have
> no messages about "power_up cancel sync".
> Then i found some difference in syslog.
>
> Here is what pulse audio say if i reproduce this issue:
> [pulseaudio] module-alsa-card.c: Failed to open hctl/mixer for jack
> detection
Interesting, I'll try to get pulseaudio installed on my system to test
tomorrow.  Does it give any more info if you turn up the verbosity?
(set log-level to debug in /etc/pulse/daemon.conf)

Re: [regression] ALSA: hda - Handle open while transitioning to D3.

[Dylan Reid]

On Thu, Jul 19, 2012 at 2:23 AM, Dylan Reid <dgreid@chromium.org> wrote:
> On Thu, Jul 19, 2012 at 12:29 AM, Oleksij Rempel (fishor)
> <bug-track@fisher-privat.net> wrote:
>> On 19.07.2012 08:44, Dylan Reid wrote:
>>>
>>> On Wed, Jul 18, 2012 at 10:26 PM, Oleksij Rempel (fishor)
>>> <bug-track@fisher-privat.net> wrote:
>>>>
>>>> On 17.07.2012 07:26, Dylan Reid wrote:
>>>>>
>>>>>
>>>>> On Sat, Jul 14, 2012 at 6:36 AM, Oleksij Rempel (fishor)
>>>>> <bug-track@fisher-privat.net> wrote:
>>>>>>
>>>>>>
>>>>>> dmesg is in attachment
>>>>>
>>>>>
>>>>> Thanks Oleksij,
>>>>>
>>>>> I didn't get much from that though.  What is your powersave timeout
>>>>> set to?
>>>>
>>>>
>>>>
>>>> I do not know, it should be some default value.
>>>>
>>>>
>>>>>   If you have time could you try adding the following and send
>>>>> me the output, I have two guesses about where it is spending it's time
>>>>> (no guesses about why yet though).  I've got a couple of systems with
>>>>> a 269, I'll try to get some tests run on those tomorrow.
>>>>
>>>>
>>>>
>>>> result is attached.
>>>>
>>> Great, thanks Oleksij,
>>>
>>> I tried this on an ACER AC700 which also has the ALC269VB and could
>>> not get anything like this to happen.  So I'm sorry to keep bothering
>>> you for more information.  I attached the alsa-info.sh output, if you
>>> see any interesting differences let me know.
>>>
>>>  From the output it looks like something is opening the driver about
>>> three times a second, do you know what is doing that?  It appears to
>>> be doing what it should be in this case, although it is a little hard
>>> to tell.  If you could strace the process doing all the opens that
>>> might provide some good info.
>>>
>>> Thanks again for the help.
>>> Dylan
>>
>>
>>
>> Ok, i did some more testing compared the difference between battery and
>> non-battery mode.
>>
>> first of all on non-battery mode, this part of code is not executed. I have
>> no messages about "power_up cancel sync".
>> Then i found some difference in syslog.
>>
>> Here is what pulse audio say if i reproduce this issue:
>> [pulseaudio] module-alsa-card.c: Failed to open hctl/mixer for jack
>> detection
> Interesting, I'll try to get pulseaudio installed on my system to test
> tomorrow.  Does it give any more info if you turn up the verbosity?
> (set log-level to debug in /etc/pulse/daemon.conf)

I got pulse running on my system again, and faked out the quirk in
patch_realtek to pretend I was running a UX31.  I still can't see the
issue.  Any more info you can provide about what pulse is doing on
your system would be great.

Thanks,

Dylan