Re: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le mardi 08 janvier 2013 à 13:56 +0100, Takashi Iwai a écrit :
> At Tue, 08 Jan 2013 13:28:55 +0100,
> From: Takashi Iwai
> Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co
>
> We've got a few bug reports that the runtime D3 results in the dead
> HD-audio controller. It seems that the problem is in a deeper level
> than the sound driver itself, so as a temporal solution, disable the
> feature for these controllers again.
>
> Reported-by: Vincent Blut
> Reported-by: Maurizio Avogadro
> Cc: [v3.7]
> Signed-off-by: Takashi Iwai
> ---
> sound/pci/hda/hda_intel.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index cca8727..0b6aeba 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -573,9 +573,12 @@ enum {
> #define AZX_DCAPS_PM_RUNTIME (1 << 26) /* runtime PM support */
>
> /* quirks for Intel PCH */
> -#define AZX_DCAPS_INTEL_PCH \
> +#define AZX_DCAPS_INTEL_PCH_NOPM \
> (AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
> - AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME)
> + AZX_DCAPS_COUNT_LPIB_DELAY)
> +
> +#define AZX_DCAPS_INTEL_PCH \
> + (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
>
> /* quirks for ATI SB / AMD Hudson */
> #define AZX_DCAPS_PRESET_ATI_SB \
> @@ -3586,13 +3589,13 @@ static void azx_remove(struct pci_dev *pci)
> static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
> /* CPT */
> { PCI_DEVICE(0x8086, 0x1c20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* PBG */
> { PCI_DEVICE(0x8086, 0x1d20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Panther Point */
> { PCI_DEVICE(0x8086, 0x1e20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Lynx Point */
> { PCI_DEVICE(0x8086, 0x8c20),
> .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
Well, my sound controller behaves nicely with the above quirk.
Tested-by: Vincent Blut
Thanks Takashi for your support,
Vincent
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le mardi 08 janvier 2013 à 13:56 +0100, Takashi Iwai a écrit :
> At Tue, 08 Jan 2013 13:28:55 +0100,
> Vincent Blut wrote:
> >
> > Le lundi 07 janvier 2013 à 09:32 +0100, Takashi Iwai a écrit :
> > > At Sat, 05 Jan 2013 22:24:03 +0100,
> > >
> > > One more thing to test is whether azx_runtime_resume() is properly
> > > called before this error happens. Could you put a debug print and
> > > check it? If it's not called, it implies that the refcount or
> > > something else got broken. If it's called but the device doesn't
> > > respond, it's a hardware-specific issue, and the likely solution is to
> > > add a device-specific quirk.
> > >
> >
> > Ok, I added a debug printk() which is called:
> >
> > $ dmesg | grep -i debug
> > [ 5330.371523] [debug] Probably needs a device-specific quirk!
> >
> > As usual, when it is called the sound become very choppy.
>
> OK. So it's not the driver code but really a problem in the deeper
> level.
Sad, by the way I'm puzzled due to the fact that nobody hit this issue,
those audio controllers are quite common, no?
>
> > I'll test with enable_msi=0 later.
>
> Thanks.
There isn't any positive effect with this parameter.
>
> FWIW, below is a patch I'm considering to merge (after testing, of
> course). Could you buys check it?
I'll give it a try.
>
>
> Takashi
>
> ---
> From: Takashi Iwai
> Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co
>
> We've got a few bug reports that the runtime D3 results in the dead
> HD-audio controller. It seems that the problem is in a deeper level
> than the sound driver itself, so as a temporal solution, disable the
> feature for these controllers again.
>
> Reported-by: Vincent Blut
> Reported-by: Maurizio Avogadro
> Cc: [v3.7]
> Signed-off-by: Takashi Iwai
> ---
> sound/pci/hda/hda_intel.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index cca8727..0b6aeba 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -573,9 +573,12 @@ enum {
> #define AZX_DCAPS_PM_RUNTIME (1 << 26) /* runtime PM support */
>
> /* quirks for Intel PCH */
> -#define AZX_DCAPS_INTEL_PCH \
> +#define AZX_DCAPS_INTEL_PCH_NOPM \
> (AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
> - AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME)
> + AZX_DCAPS_COUNT_LPIB_DELAY)
> +
> +#define AZX_DCAPS_INTEL_PCH \
> + (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
>
> /* quirks for ATI SB / AMD Hudson */
> #define AZX_DCAPS_PRESET_ATI_SB \
> @@ -3586,13 +3589,13 @@ static void azx_remove(struct pci_dev *pci)
> static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
> /* CPT */
> { PCI_DEVICE(0x8086, 0x1c20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* PBG */
> { PCI_DEVICE(0x8086, 0x1d20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Panther Point */
> { PCI_DEVICE(0x8086, 0x1e20),
> - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
> /* Lynx Point */
> { PCI_DEVICE(0x8086, 0x8c20),
> .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le lundi 07 janvier 2013 à 09:32 +0100, Takashi Iwai a écrit : > At Sat, 05 Jan 2013 22:24:03 +0100, > Vincent Blut wrote: > > > > Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : > > > At Fri, 28 Dec 2012 15:25:40 +0100, > > > Vincent Blut wrote: > > > > > > > > Hi, > > > > > > > > Since I updated to Linux 3.7.1, listening to some audio/video bits > > > > frequently cause the following: > > > > > > > > [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling > > > > mode: last cmd=0x020c > > > > [ 7897.173444] hda-intel: No response from codec, disabling MSI: last > > > > cmd=0x020c > > > > [ 7898.179932] hda_intel: azx_get_response timeout, switching to > > > > single_cmd mode: last cmd=0x020c > > > > [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff > > > > [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip > > > > 7f44e454bca0 sp 7f44c91165f8 error 4 in > > > > libc-2.13.so[7f44e442c000+18] > > > > > > > > It seems to be a codec probing failure (?). This is really fatal because > > > > the sound become very choppy and can't recover until I reboot. > > > > I'll try to play with 'probe_mask' kernel parameter to see if I can > > > > narrow the correct codec slots! > > > > > > > > By the way I can't reproduce this on 3.6.9, so is there something that > > > > changed in this area in 3.7.1? > > > > > > If it's new in 3.7, this could be a regression by runtime D3. > > > Try to pass power_save_controller=0 option to snd-hda-intel module > > > (or change it via sysfs dynamically). > > > > > > > > > thanks, > > > > > > Takashi > > > > Hi Takashi, > > > > Well, power_save_controller=0 seems to do the trick but I get plenty of: > > > > > > [ 15.389270] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > [ 25.178725] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > [ 72.296536] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > [ 2318.147505] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > [ 6086.029839] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > [ 7390.772818] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 > > [snd_hda_intel] returns -11 > > > > > > which I think is fixed in 3.8 by commit 6eb827d23577 > > Yes, and should be merged in the next stable release. > > > So what's the next step? Adding a quirk for this sound card? Or is there > > a way to fix the root cause? > > One more thing to test is whether azx_runtime_resume() is properly > called before this error happens. Could you put a debug print and > check it? If it's not called, it implies that the refcount or > something else got broken. If it's called but the device doesn't > respond, it's a hardware-specific issue, and the likely solution is to > add a device-specific quirk. > Ok, I added a debug printk() which is called: $ dmesg | grep -i debug [ 5330.371523] [debug] Probably needs a device-specific quirk! As usual, when it is called the sound become very choppy. I'll test with enable_msi=0 later. > > thanks, > > Takashi Thanks, Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le lundi 07 janvier 2013 à 09:32 +0100, Takashi Iwai a écrit : At Sat, 05 Jan 2013 22:24:03 +0100, Vincent Blut wrote: Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : At Fri, 28 Dec 2012 15:25:40 +0100, Vincent Blut wrote: Hi, Since I updated to Linux 3.7.1, listening to some audio/video bits frequently cause the following: [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x020c [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 7f44e454bca0 sp 7f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+18] It seems to be a codec probing failure (?). This is really fatal because the sound become very choppy and can't recover until I reboot. I'll try to play with 'probe_mask' kernel parameter to see if I can narrow the correct codec slots! By the way I can't reproduce this on 3.6.9, so is there something that changed in this area in 3.7.1? If it's new in 3.7, this could be a regression by runtime D3. Try to pass power_save_controller=0 option to snd-hda-intel module (or change it via sysfs dynamically). thanks, Takashi Hi Takashi, Well, power_save_controller=0 seems to do the trick but I get plenty of: [ 15.389270] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 25.178725] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 72.296536] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 2318.147505] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 6086.029839] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 7390.772818] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 which I think is fixed in 3.8 by commit 6eb827d23577 Yes, and should be merged in the next stable release. So what's the next step? Adding a quirk for this sound card? Or is there a way to fix the root cause? One more thing to test is whether azx_runtime_resume() is properly called before this error happens. Could you put a debug print and check it? If it's not called, it implies that the refcount or something else got broken. If it's called but the device doesn't respond, it's a hardware-specific issue, and the likely solution is to add a device-specific quirk. Ok, I added a debug printk() which is called: $ dmesg | grep -i debug [ 5330.371523] [debug] Probably needs a device-specific quirk! As usual, when it is called the sound become very choppy. I'll test with enable_msi=0 later. thanks, Takashi Thanks, Vincent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le mardi 08 janvier 2013 à 13:56 +0100, Takashi Iwai a écrit :
At Tue, 08 Jan 2013 13:28:55 +0100,
Vincent Blut wrote:
Le lundi 07 janvier 2013 à 09:32 +0100, Takashi Iwai a écrit :
At Sat, 05 Jan 2013 22:24:03 +0100,
One more thing to test is whether azx_runtime_resume() is properly
called before this error happens. Could you put a debug print and
check it? If it's not called, it implies that the refcount or
something else got broken. If it's called but the device doesn't
respond, it's a hardware-specific issue, and the likely solution is to
add a device-specific quirk.
Ok, I added a debug printk() which is called:
$ dmesg | grep -i debug
[ 5330.371523] [debug] Probably needs a device-specific quirk!
As usual, when it is called the sound become very choppy.
OK. So it's not the driver code but really a problem in the deeper
level.
Sad, by the way I'm puzzled due to the fact that nobody hit this issue,
those audio controllers are quite common, no?
I'll test with enable_msi=0 later.
Thanks.
There isn't any positive effect with this parameter.
FWIW, below is a patch I'm considering to merge (after testing, of
course). Could you buys check it?
I'll give it a try.
Takashi
---
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT co
We've got a few bug reports that the runtime D3 results in the dead
HD-audio controller. It seems that the problem is in a deeper level
than the sound driver itself, so as a temporal solution, disable the
feature for these controllers again.
Reported-by: Vincent Blut vincent.deb...@free.fr
Reported-by: Maurizio Avogadro mav...@gmail.com
Cc: sta...@vger.kernel.org [v3.7]
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index cca8727..0b6aeba 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -573,9 +573,12 @@ enum {
#define AZX_DCAPS_PM_RUNTIME (1 26) /* runtime PM support */
/* quirks for Intel PCH */
-#define AZX_DCAPS_INTEL_PCH \
+#define AZX_DCAPS_INTEL_PCH_NOPM \
(AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
- AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME)
+ AZX_DCAPS_COUNT_LPIB_DELAY)
+
+#define AZX_DCAPS_INTEL_PCH \
+ (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
/* quirks for ATI SB / AMD Hudson */
#define AZX_DCAPS_PRESET_ATI_SB \
@@ -3586,13 +3589,13 @@ static void azx_remove(struct pci_dev *pci)
static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
/* CPT */
{ PCI_DEVICE(0x8086, 0x1c20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* PBG */
{ PCI_DEVICE(0x8086, 0x1d20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* Panther Point */
{ PCI_DEVICE(0x8086, 0x1e20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* Lynx Point */
{ PCI_DEVICE(0x8086, 0x8c20),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le mardi 08 janvier 2013 à 13:56 +0100, Takashi Iwai a écrit :
At Tue, 08 Jan 2013 13:28:55 +0100,
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT co
We've got a few bug reports that the runtime D3 results in the dead
HD-audio controller. It seems that the problem is in a deeper level
than the sound driver itself, so as a temporal solution, disable the
feature for these controllers again.
Reported-by: Vincent Blut vincent.deb...@free.fr
Reported-by: Maurizio Avogadro mav...@gmail.com
Cc: sta...@vger.kernel.org [v3.7]
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index cca8727..0b6aeba 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -573,9 +573,12 @@ enum {
#define AZX_DCAPS_PM_RUNTIME (1 26) /* runtime PM support */
/* quirks for Intel PCH */
-#define AZX_DCAPS_INTEL_PCH \
+#define AZX_DCAPS_INTEL_PCH_NOPM \
(AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE | \
- AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME)
+ AZX_DCAPS_COUNT_LPIB_DELAY)
+
+#define AZX_DCAPS_INTEL_PCH \
+ (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME)
/* quirks for ATI SB / AMD Hudson */
#define AZX_DCAPS_PRESET_ATI_SB \
@@ -3586,13 +3589,13 @@ static void azx_remove(struct pci_dev *pci)
static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
/* CPT */
{ PCI_DEVICE(0x8086, 0x1c20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* PBG */
{ PCI_DEVICE(0x8086, 0x1d20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* Panther Point */
{ PCI_DEVICE(0x8086, 0x1e20),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM },
/* Lynx Point */
{ PCI_DEVICE(0x8086, 0x8c20),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
Well, my sound controller behaves nicely with the above quirk.
Tested-by: Vincent Blut vincent.deb...@free.fr
Thanks Takashi for your support,
Vincent
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : > At Fri, 28 Dec 2012 15:25:40 +0100, > Vincent Blut wrote: > > > > Hi, > > > > Since I updated to Linux 3.7.1, listening to some audio/video bits > > frequently cause the following: > > > > [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling > > mode: last cmd=0x020c > > [ 7897.173444] hda-intel: No response from codec, disabling MSI: last > > cmd=0x020c > > [ 7898.179932] hda_intel: azx_get_response timeout, switching to > > single_cmd mode: last cmd=0x020c > > [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff > > [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip > > 7f44e454bca0 sp 7f44c91165f8 error 4 in > > libc-2.13.so[7f44e442c000+18] > > > > It seems to be a codec probing failure (?). This is really fatal because > > the sound become very choppy and can't recover until I reboot. > > I'll try to play with 'probe_mask' kernel parameter to see if I can > > narrow the correct codec slots! > > > > By the way I can't reproduce this on 3.6.9, so is there something that > > changed in this area in 3.7.1? > > If it's new in 3.7, this could be a regression by runtime D3. > Try to pass power_save_controller=0 option to snd-hda-intel module > (or change it via sysfs dynamically). > > > thanks, > > Takashi Hi Takashi, Well, power_save_controller=0 seems to do the trick but I get plenty of: [ 15.389270] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 25.178725] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 72.296536] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 2318.147505] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 6086.029839] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 7390.772818] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 which I think is fixed in 3.8 by commit 6eb827d23577 So what's the next step? Adding a quirk for this sound card? Or is there a way to fix the root cause? Cheers, Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : At Fri, 28 Dec 2012 15:25:40 +0100, Vincent Blut wrote: Hi, Since I updated to Linux 3.7.1, listening to some audio/video bits frequently cause the following: [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x020c [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 7f44e454bca0 sp 7f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+18] It seems to be a codec probing failure (?). This is really fatal because the sound become very choppy and can't recover until I reboot. I'll try to play with 'probe_mask' kernel parameter to see if I can narrow the correct codec slots! By the way I can't reproduce this on 3.6.9, so is there something that changed in this area in 3.7.1? If it's new in 3.7, this could be a regression by runtime D3. Try to pass power_save_controller=0 option to snd-hda-intel module (or change it via sysfs dynamically). thanks, Takashi Hi Takashi, Well, power_save_controller=0 seems to do the trick but I get plenty of: [ 15.389270] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 25.178725] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 72.296536] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 2318.147505] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 6086.029839] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 [ 7390.772818] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 [snd_hda_intel] returns -11 which I think is fixed in 3.8 by commit 6eb827d23577 So what's the next step? Adding a quirk for this sound card? Or is there a way to fix the root cause? Cheers, Vincent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : > At Fri, 28 Dec 2012 15:25:40 +0100, > Vincent Blut wrote: > > > > Hi, > > > > Since I updated to Linux 3.7.1, listening to some audio/video bits > > frequently cause the following: > > > > [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling > > mode: last cmd=0x020c > > [ 7897.173444] hda-intel: No response from codec, disabling MSI: last > > cmd=0x020c > > [ 7898.179932] hda_intel: azx_get_response timeout, switching to > > single_cmd mode: last cmd=0x020c > > [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff > > [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip > > 7f44e454bca0 sp 7f44c91165f8 error 4 in > > libc-2.13.so[7f44e442c000+18] > > > > It seems to be a codec probing failure (?). This is really fatal because > > the sound become very choppy and can't recover until I reboot. > > I'll try to play with 'probe_mask' kernel parameter to see if I can > > narrow the correct codec slots! > > > > By the way I can't reproduce this on 3.6.9, so is there something that > > changed in this area in 3.7.1? > > If it's new in 3.7, this could be a regression by runtime D3. > Try to pass power_save_controller=0 option to snd-hda-intel module > (or change it via sysfs dynamically). > > > thanks, > > Takashi Hi, That makes sense, however I can't reliably reproduce this so I'll report back later. Thanks and happy new year! Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit : At Fri, 28 Dec 2012 15:25:40 +0100, Vincent Blut wrote: Hi, Since I updated to Linux 3.7.1, listening to some audio/video bits frequently cause the following: [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x020c [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 7f44e454bca0 sp 7f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+18] It seems to be a codec probing failure (?). This is really fatal because the sound become very choppy and can't recover until I reboot. I'll try to play with 'probe_mask' kernel parameter to see if I can narrow the correct codec slots! By the way I can't reproduce this on 3.6.9, so is there something that changed in this area in 3.7.1? If it's new in 3.7, this could be a regression by runtime D3. Try to pass power_save_controller=0 option to snd-hda-intel module (or change it via sysfs dynamically). thanks, Takashi Hi, That makes sense, however I can't reliably reproduce this so I'll report back later. Thanks and happy new year! Vincent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Hi, Since I updated to Linux 3.7.1, listening to some audio/video bits frequently cause the following: [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x020c [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 7f44e454bca0 sp 7f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+18] It seems to be a codec probing failure (?). This is really fatal because the sound become very choppy and can't recover until I reboot. I'll try to play with 'probe_mask' kernel parameter to see if I can narrow the correct codec slots! By the way I can't reproduce this on 3.6.9, so is there something that changed in this area in 3.7.1? Cheers, Vincent [attached alsa-info output] upload=true=true= !! !!ALSA Information Script v 0.4.61 !! !!Script ran on: Fri Dec 28 13:00:55 UTC 2012 !!Linux Distribution !!-- Debian GNU/Linux 7.0 \n \l PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)" NAME="Debian GNU/Linux" ID=debian HOME_URL="http://www.debian.org/; SUPPORT_URL="http://www.debian.org/support/; BUG_REPORT_URL="http://bugs.debian.org/; !!DMI Information !!--- Manufacturer: ASUSTeK COMPUTER INC. Product Name: UX31A Product Version: 1.0 Firmware Version: UX31A.216 !!Kernel Information !!-- Kernel release:3.7-trunk-amd64 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k3.7-trunk-amd64 Library version:1.0.25 Utilities version: 1.0.25 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d18000 irq 47 !!PCI Soundcards installed in the system !!-- 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1b.0 0403: 8086:1e20 (rev 04) Subsystem: 1043:1517 !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_hda_intel: power_save=10 !!Loaded sound module options !!--- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 power_save : 1 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : Y !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC269VB Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x10431517 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=2, o=0, i=0,
[3.6.9 - 3.7.1 regression] sound: snd_hda_intel codec probing issue?
Hi, Since I updated to Linux 3.7.1, listening to some audio/video bits frequently cause the following: [ 7896.166946] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x020c [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:f7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 7f44e454bca0 sp 7f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+18] It seems to be a codec probing failure (?). This is really fatal because the sound become very choppy and can't recover until I reboot. I'll try to play with 'probe_mask' kernel parameter to see if I can narrow the correct codec slots! By the way I can't reproduce this on 3.6.9, so is there something that changed in this area in 3.7.1? Cheers, Vincent [attached alsa-info output] upload=truescript=truecardinfo= !! !!ALSA Information Script v 0.4.61 !! !!Script ran on: Fri Dec 28 13:00:55 UTC 2012 !!Linux Distribution !!-- Debian GNU/Linux 7.0 \n \l PRETTY_NAME=Debian GNU/Linux 7.0 (wheezy) NAME=Debian GNU/Linux ID=debian HOME_URL=http://www.debian.org/; SUPPORT_URL=http://www.debian.org/support/; BUG_REPORT_URL=http://bugs.debian.org/; !!DMI Information !!--- Manufacturer: ASUSTeK COMPUTER INC. Product Name: UX31A Product Version: 1.0 Firmware Version: UX31A.216 !!Kernel Information !!-- Kernel release:3.7-trunk-amd64 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k3.7-trunk-amd64 Library version:1.0.25 Utilities version: 1.0.25 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d18000 irq 47 !!PCI Soundcards installed in the system !!-- 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1b.0 0403: 8086:1e20 (rev 04) Subsystem: 1043:1517 !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_hda_intel: power_save=10 !!Loaded sound module options !!--- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 power_save : 1 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : Y !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC269VB Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x10431517 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=2, o=0, i=0,
!!Re: sound: BUG: can't load gdm greeter on battery with Linux 3.5
Le 05/08/2012 14:57, Takashi Iwai a écrit : > At Sun, 05 Aug 2012 14:36:19 +0200, > Vincent Blut wrote: >> Hi, >> >> Despite that the subject might suggest that this is a bug in the graphic >> stack, it appears that >> commit [b4a91cf0] makes the GDM greeter not loadable, however GDM has >> been correctly loaded: >> >> # service gdm3 status >> [ ok ] gdm3 is running. >> >> This issue only affects Linux 3.5 when I boot on battery, I spent some >> time to bisect and this commit seems to be the bad one: >> >> commit b4a91cf05c33d4ab5b2b3738a257a3fe49b462bd >> Author: Dylan Reid >> Date: Fri Jun 15 19:36:23 2012 -0700 >> >> ALSA: hda - Handle open while transitioning to D3. >> >> This addresses an issue encountered when a pcm is opened while >> transitioning to low power state (codec->power_on == 1 && >> codec->power_transition == -1). Add snd_pcm_power_up_d3wait to >> hda_codec. This function is used to power up from azx_open as opposed >> to snd_hda_power_up used from codec_exec_verb. When powering up from >> azx_open, wait for pending power downs to complete, avoiding the power >> up continuing in parallel with the power down on the work queue. >> >> The specific issue seen was with the CS4210 codec, it powers off the ADC >> and DAC nid in its suspend handler. If it is re-opened before the >> ~100ms power down process completes, the ADC and DAC nid are initialized >> while powered down and audio is lost until another suspend/resume cycle. >> >> Signed-off-by: Dylan Reid >> Signed-off-by: Takashi Iwai >> >> Is this a known issue? > Yes. There is a known side-effect by this change, and the fix was > already queued for 3.5.1 stable kernel. > > > thanks, > > Takashi Ok, thanks a lot Takashi for the quick answer! Cheers, Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sound: BUG: can't load gdm greeter on battery with Linux 3.5
Hi, Despite that the subject might suggest that this is a bug in the graphic stack, it appears that commit [b4a91cf0] makes the GDM greeter not loadable, however GDM has been correctly loaded: # service gdm3 status [ ok ] gdm3 is running. This issue only affects Linux 3.5 when I boot on battery, I spent some time to bisect and this commit seems to be the bad one: commit b4a91cf05c33d4ab5b2b3738a257a3fe49b462bd Author: Dylan Reid Date: Fri Jun 15 19:36:23 2012 -0700 ALSA: hda - Handle open while transitioning to D3. This addresses an issue encountered when a pcm is opened while transitioning to low power state (codec->power_on == 1 && codec->power_transition == -1). Add snd_pcm_power_up_d3wait to hda_codec. This function is used to power up from azx_open as opposed to snd_hda_power_up used from codec_exec_verb. When powering up from azx_open, wait for pending power downs to complete, avoiding the power up continuing in parallel with the power down on the work queue. The specific issue seen was with the CS4210 codec, it powers off the ADC and DAC nid in its suspend handler. If it is re-opened before the ~100ms power down process completes, the ADC and DAC nid are initialized while powered down and audio is lost until another suspend/resume cycle. Signed-off-by: Dylan Reid Signed-off-by: Takashi Iwai Is this a known issue? [alsa-info attached] Have a good day, Vincent name=brutux=33=/tmp/alsa-info.txt==Submit+Post= !! !!ALSA Information Script v 0.4.61 !! !!Script ran on: Sun Aug 5 11:33:28 UTC 2012 !!Linux Distribution !!-- !!DMI Information !!--- Manufacturer: ASUSTeK COMPUTER INC. Product Name: UX31A Product Version: 1.0 Firmware Version: UX31A.206 !!Kernel Information !!-- Kernel release:3.5.0+ Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: No !!ALSA Version !! Driver version: 1.0.25 Library version:1.0.25 Utilities version: 1.0.25 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d18000 irq 44 !!PCI Soundcards installed in the system !!-- 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1b.0 0403: 8086:1e20 (rev 04) Subsystem: 1043:1517 !!Modprobe options (Sound related) !! snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_pcsp: index=-2 snd_usb_audio: index=-2 !!Loaded sound module options !!--- !!Module: snd_hda_intel -ne align_buffer_size : -1 -ne bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne beep_mode : 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 -ne enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y -ne enable_msi : -1 -ne id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 -ne power_save : 1 -ne power_save_controller : Y -ne probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 -ne single_cmd : N -ne snoop : Y !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC269VB Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x10431517 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x560]: 44100
sound: BUG: can't load gdm greeter on battery with Linux 3.5
Hi, Despite that the subject might suggest that this is a bug in the graphic stack, it appears that commit [b4a91cf0] makes the GDM greeter not loadable, however GDM has been correctly loaded: # service gdm3 status [ ok ] gdm3 is running. This issue only affects Linux 3.5 when I boot on battery, I spent some time to bisect and this commit seems to be the bad one: commit b4a91cf05c33d4ab5b2b3738a257a3fe49b462bd Author: Dylan Reid dgr...@chromium.org Date: Fri Jun 15 19:36:23 2012 -0700 ALSA: hda - Handle open while transitioning to D3. This addresses an issue encountered when a pcm is opened while transitioning to low power state (codec-power_on == 1 codec-power_transition == -1). Add snd_pcm_power_up_d3wait to hda_codec. This function is used to power up from azx_open as opposed to snd_hda_power_up used from codec_exec_verb. When powering up from azx_open, wait for pending power downs to complete, avoiding the power up continuing in parallel with the power down on the work queue. The specific issue seen was with the CS4210 codec, it powers off the ADC and DAC nid in its suspend handler. If it is re-opened before the ~100ms power down process completes, the ADC and DAC nid are initialized while powered down and audio is lost until another suspend/resume cycle. Signed-off-by: Dylan Reid dgr...@chromium.org Signed-off-by: Takashi Iwai ti...@suse.de Is this a known issue? [alsa-info attached] Have a good day, Vincent name=brutuxtype=33description=/tmp/alsa-info.txtexpiry=s=Submit+Postcontent= !! !!ALSA Information Script v 0.4.61 !! !!Script ran on: Sun Aug 5 11:33:28 UTC 2012 !!Linux Distribution !!-- !!DMI Information !!--- Manufacturer: ASUSTeK COMPUTER INC. Product Name: UX31A Product Version: 1.0 Firmware Version: UX31A.206 !!Kernel Information !!-- Kernel release:3.5.0+ Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: No !!ALSA Version !! Driver version: 1.0.25 Library version:1.0.25 Utilities version: 1.0.25 !!Loaded ALSA modules !!--- snd_hda_intel !!Sound Servers on this system !! !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7d18000 irq 44 !!PCI Soundcards installed in the system !!-- 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1b.0 0403: 8086:1e20 (rev 04) Subsystem: 1043:1517 !!Modprobe options (Sound related) !! snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_pcsp: index=-2 snd_usb_audio: index=-2 !!Loaded sound module options !!--- !!Module: snd_hda_intel -ne align_buffer_size : -1 -ne bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne beep_mode : 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 -ne enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y -ne enable_msi : -1 -ne id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) -ne position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 -ne power_save : 1 -ne power_save_controller : Y -ne probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 -ne probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 -ne single_cmd : N -ne snoop : Y !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ALC269VB Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x10431517 Revision Id:
!!Re: sound: BUG: can't load gdm greeter on battery with Linux 3.5
Le 05/08/2012 14:57, Takashi Iwai a écrit : At Sun, 05 Aug 2012 14:36:19 +0200, Vincent Blut wrote: Hi, Despite that the subject might suggest that this is a bug in the graphic stack, it appears that commit [b4a91cf0] makes the GDM greeter not loadable, however GDM has been correctly loaded: # service gdm3 status [ ok ] gdm3 is running. This issue only affects Linux 3.5 when I boot on battery, I spent some time to bisect and this commit seems to be the bad one: commit b4a91cf05c33d4ab5b2b3738a257a3fe49b462bd Author: Dylan Reid dgr...@chromium.org Date: Fri Jun 15 19:36:23 2012 -0700 ALSA: hda - Handle open while transitioning to D3. This addresses an issue encountered when a pcm is opened while transitioning to low power state (codec-power_on == 1 codec-power_transition == -1). Add snd_pcm_power_up_d3wait to hda_codec. This function is used to power up from azx_open as opposed to snd_hda_power_up used from codec_exec_verb. When powering up from azx_open, wait for pending power downs to complete, avoiding the power up continuing in parallel with the power down on the work queue. The specific issue seen was with the CS4210 codec, it powers off the ADC and DAC nid in its suspend handler. If it is re-opened before the ~100ms power down process completes, the ADC and DAC nid are initialized while powered down and audio is lost until another suspend/resume cycle. Signed-off-by: Dylan Reid dgr...@chromium.org Signed-off-by: Takashi Iwai ti...@suse.de Is this a known issue? Yes. There is a known side-effect by this change, and the fix was already queued for 3.5.1 stable kernel. thanks, Takashi Ok, thanks a lot Takashi for the quick answer! Cheers, Vincent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
