Re: [alsa-devel] [3.6.9 -> 3.7.1 regression] sound: snd_hda_intel codec probing issue?
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=0x020c0000 [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c0000 [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c0000 [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:fffff7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 00007f44e454bca0 sp 00007f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+180000]
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
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=0x020c0000 [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c0000 [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c0000 [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:fffff7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 00007f44e454bca0 sp 00007f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+180000]
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
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=0x020c0000 [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c0000 [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c0000 [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:fffff7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 00007f44e454bca0 sp 00007f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+180000]
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.
thanks,
Takashi
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=0x020c0000 [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c0000 [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c0000 [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:fffff7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 00007f44e454bca0 sp 00007f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+180000]
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
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, 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=0x020c0000 [ 7897.173444] hda-intel: No response from codec, disabling MSI: last cmd=0x020c0000 [ 7898.179932] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x020c0000 [ 7898.179983] hda-codec: out of range cmd 0:0:20:400:fffff7ff [ 9445.034371] plugin-containe[5873]: segfault at 7f44bb95e639 ip 00007f44e454bca0 sp 00007f44c91165f8 error 4 in libc-2.13.so[7f44e442c000+180000]
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.
OK. So it's not the driver code but really a problem in the deeper level.
I'll test with enable_msi=0 later.
Thanks.
FWIW, below is a patch I'm considering to merge (after testing, of course). Could you buys check it?
Takashi
--- From: Takashi Iwai tiwai@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.debian@free.fr Reported-by: Maurizio Avogadro mavoga@gmail.com Cc: stable@vger.kernel.org [v3.7] Signed-off-by: Takashi Iwai tiwai@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 },
On 01/08/2013 01:56 PM, Takashi Iwai wrote:
I'll test with enable_msi=0 later.
Thanks.
FWIW, below is a patch I'm considering to merge (after testing, of course). Could you buys check it?
Takashi
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co
For reference, I'm seeing some of this too, and have asked for people to test with enable_msi=0 and/or power_save_controller=0. I'm waiting for replies from people with the hardware.
At Tue, 08 Jan 2013 15:32:13 +0100, David Henningsson wrote:
On 01/08/2013 01:56 PM, Takashi Iwai wrote:
I'll test with enable_msi=0 later.
Thanks.
FWIW, below is a patch I'm considering to merge (after testing, of course). Could you buys check it?
Takashi
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable runtime D3 for Intel CPT & co
For reference, I'm seeing some of this too, and have asked for people to test with enable_msi=0 and/or power_save_controller=0. I'm waiting for replies from people with the hardware.
OK, good to know!
So far, I disabled the runtime PM up to PantherPoint in the patch. LynxPoint, Haswell and 3400 are still with runtime PM, as these were the platforms mostly tested for the feature.
Takashi
Takashi Iwai <tiwai <at> suse.de> writes:
[...]
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
same codec here (ALC269VB on a Clevo W150HRM), same kernel, same issue. Disabling power_save_controller solves the issue, but I could achieve the same result by setting enable_msi=0, which I chose in the hope to preserve power saving capabilities.
thanks, Maurizio
At Tue, 08 Jan 2013 09:23:14 +0100, Maurizio Avogadro wrote:
Takashi Iwai <tiwai <at> suse.de> writes:
[...]
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
same codec here (ALC269VB on a Clevo W150HRM), same kernel, same issue. Disabling power_save_controller solves the issue, but I could achieve the same result by setting enable_msi=0, which I chose in the hope to preserve power saving capabilities.
Interesting. Vincent, does disabling MSI help in your case, too?
BTW, the problem is related rather with the controller chip, not the codec chip. In Vincent's case, it's 8086:1e20, Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
thanks,
Takashi
08/01/2013 09:28 Takashi Iwai wrote:
[...]
BTW, the problem is related rather with the controller chip, not the codec chip. In Vincent's case, it's 8086:1e20, Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
Here I have
00:1b.0 0403: 8086:1c20 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
Thanks
Maurizio
Le mardi 08 janvier 2013 à 09:28 +0100, Takashi Iwai a écrit :
At Tue, 08 Jan 2013 09:23:14 +0100, Maurizio Avogadro wrote:
Takashi Iwai <tiwai <at> suse.de> writes:
[...]
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
same codec here (ALC269VB on a Clevo W150HRM), same kernel, same issue. Disabling power_save_controller solves the issue, but I could achieve the same result by setting enable_msi=0, which I chose in the hope to preserve power saving capabilities.
Interesting. Vincent, does disabling MSI help in your case, too?
BTW, the problem is related rather with the controller chip, not the codec chip. In Vincent's case, it's 8086:1e20, Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
Hi,
Will test, I'm not on this sistem right now, so I'll report back this afternoon.
thanks,
Takashi
Cheers, Vincent
participants (4)
-
David Henningsson -
Maurizio Avogadro -
Takashi Iwai -
Vincent Blut