BUG: soft lockup during suspend

BUG: soft lockup during suspend

[Pavel Machek]

Hi!

I got this nastinness in my syslog... perhaps HDA intel takes too long
to play with its hardware? Or should we just kill the softlockup
watchdog since Linux is not realtime system, yet?
								Pavel 

HDA Intel 0000:00:1b.0: freeze
BUG: soft lockup detected on CPU#0!
 [<c014fdd9>] softlockup_tick+0xa9/0xd0
 [<c0131d63>] update_process_times+0x33/0x80
 [<c0142f52>] tick_periodic+0x22/0x70
 [<c0142fb7>] tick_handle_periodic+0x17/0x80
 [<c014359a>] tick_do_broadcast+0x6a/0x80
 [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
 [<c01435fb>] tick_handle_periodic_broadcast+0x1b/0x60
 [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
 [<c01077cc>] timer_interrupt+0x2c/0x40
 [<c0150005>] handle_IRQ_event+0x25/0x60
 [<c0151d87>] handle_edge_irq+0xe7/0x130
 [<c0106adb>] do_IRQ+0x3b/0x80
 [<c0106ae0>] do_IRQ+0x40/0x80
 [<c01049eb>] common_interrupt+0x23/0x28
 [<c063007b>] ieee80211_wx_get_scan+0x2b/0x130
 [<c02588f4>] delay_tsc+0x14/0x20
 [<c0258936>] __delay+0x6/0x10
 [<c052f3da>] azx_send_cmd+0xfa/0x110
 [<c053089e>] snd_hda_codec_write+0x3e/0x60
 [<c05314fb>] hda_set_power_state+0xab/0xe0
 [<c0532518>] snd_hda_suspend+0x48/0x60
 [<c0530302>] azx_suspend+0x52/0xd0
 [<c0266b13>] pci_device_suspend+0x23/0x70
 [<c0332dbb>] suspend_device+0x11b/0x2e0
 [<c0333032>] device_suspend+0xb2/0x170
 [<c012a28b>] printk+0x1b/0x20
 [<c014c7ad>] pm_suspend_disk+0x4d/0x2b0
 [<c014b395>] enter_state+0x195/0x220
 [<c014b4c9>] state_store+0xa9/0xc0
 [<c014b420>] state_store+0x0/0xc0
 [<c01ae789>] subsys_attr_store+0x29/0x40
 [<c01af07c>] sysfs_write_file+0xac/0x130
 [<c0172156>] vfs_write+0xa6/0x140
 [<c01aefd0>] sysfs_write_file+0x0/0x130
 [<c0104050>] syscall_call+0x7/0xb
 [<c0630000>] ieee80211_translate_scan+0xa00/0xa50
 =======================
ACPI: PCI interrupt for device 0000:00:1b.0 disabled

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Tue, 20 Mar 2007 13:32:53 +0100,
Pavel Machek wrote:
> 
> Hi!
> 
> I got this nastinness in my syslog... perhaps HDA intel takes too long
> to play with its hardware? Or should we just kill the softlockup
> watchdog since Linux is not realtime system, yet?

X60/T60 is known to be often broken regarding the communication
between the controller and the codec chip.  When this kind of thing
happens, the driver tries to switch to a single-shot I/O without using
ring-buffers and IRQs, and even in such a mode, the communication gets
broken.  FWIW, it doesn't happen on other machines with HD-audio, so
it's fairly specific to X60/T60.  No idea why.


Takashi


> 								Pavel 
> 
> HDA Intel 0000:00:1b.0: freeze
> BUG: soft lockup detected on CPU#0!
>  [<c014fdd9>] softlockup_tick+0xa9/0xd0
>  [<c0131d63>] update_process_times+0x33/0x80
>  [<c0142f52>] tick_periodic+0x22/0x70
>  [<c0142fb7>] tick_handle_periodic+0x17/0x80
>  [<c014359a>] tick_do_broadcast+0x6a/0x80
>  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
>  [<c01435fb>] tick_handle_periodic_broadcast+0x1b/0x60
>  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
>  [<c01077cc>] timer_interrupt+0x2c/0x40
>  [<c0150005>] handle_IRQ_event+0x25/0x60
>  [<c0151d87>] handle_edge_irq+0xe7/0x130
>  [<c0106adb>] do_IRQ+0x3b/0x80
>  [<c0106ae0>] do_IRQ+0x40/0x80
>  [<c01049eb>] common_interrupt+0x23/0x28
>  [<c063007b>] ieee80211_wx_get_scan+0x2b/0x130
>  [<c02588f4>] delay_tsc+0x14/0x20
>  [<c0258936>] __delay+0x6/0x10
>  [<c052f3da>] azx_send_cmd+0xfa/0x110
>  [<c053089e>] snd_hda_codec_write+0x3e/0x60
>  [<c05314fb>] hda_set_power_state+0xab/0xe0
>  [<c0532518>] snd_hda_suspend+0x48/0x60
>  [<c0530302>] azx_suspend+0x52/0xd0
>  [<c0266b13>] pci_device_suspend+0x23/0x70
>  [<c0332dbb>] suspend_device+0x11b/0x2e0
>  [<c0333032>] device_suspend+0xb2/0x170
>  [<c012a28b>] printk+0x1b/0x20
>  [<c014c7ad>] pm_suspend_disk+0x4d/0x2b0
>  [<c014b395>] enter_state+0x195/0x220
>  [<c014b4c9>] state_store+0xa9/0xc0
>  [<c014b420>] state_store+0x0/0xc0
>  [<c01ae789>] subsys_attr_store+0x29/0x40
>  [<c01af07c>] sysfs_write_file+0xac/0x130
>  [<c0172156>] vfs_write+0xa6/0x140
>  [<c01aefd0>] sysfs_write_file+0x0/0x130
>  [<c0104050>] syscall_call+0x7/0xb
>  [<c0630000>] ieee80211_translate_scan+0xa00/0xa50
>  =======================
> ACPI: PCI interrupt for device 0000:00:1b.0 disabled
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 

Re: BUG: soft lockup during suspend

[Pavel Machek]

Hi!

> > I got this nastinness in my syslog... perhaps HDA intel takes too long
> > to play with its hardware? Or should we just kill the softlockup
> > watchdog since Linux is not realtime system, yet?
> 
> X60/T60 is known to be often broken regarding the communication
> between the controller and the codec chip.  When this kind of thing
> happens, the driver tries to switch to a single-shot I/O without using
> ring-buffers and IRQs, and even in such a mode, the communication gets
> broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> it's fairly specific to X60/T60.  No idea why.

Is adding touch_softlockup_watchdog() to hd_audio right solution? Or
should watchdog just disappear?
								Pavel

> > HDA Intel 0000:00:1b.0: freeze
> > BUG: soft lockup detected on CPU#0!
> >  [<c014fdd9>] softlockup_tick+0xa9/0xd0
> >  [<c0131d63>] update_process_times+0x33/0x80
> >  [<c0142f52>] tick_periodic+0x22/0x70
> >  [<c0142fb7>] tick_handle_periodic+0x17/0x80
> >  [<c014359a>] tick_do_broadcast+0x6a/0x80
> >  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
> >  [<c01435fb>] tick_handle_periodic_broadcast+0x1b/0x60
> >  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
> >  [<c01077cc>] timer_interrupt+0x2c/0x40
> >  [<c0150005>] handle_IRQ_event+0x25/0x60
> >  [<c0151d87>] handle_edge_irq+0xe7/0x130
> >  [<c0106adb>] do_IRQ+0x3b/0x80
> >  [<c0106ae0>] do_IRQ+0x40/0x80
> >  [<c01049eb>] common_interrupt+0x23/0x28
> >  [<c063007b>] ieee80211_wx_get_scan+0x2b/0x130
> >  [<c02588f4>] delay_tsc+0x14/0x20
> >  [<c0258936>] __delay+0x6/0x10
> >  [<c052f3da>] azx_send_cmd+0xfa/0x110
> >  [<c053089e>] snd_hda_codec_write+0x3e/0x60
> >  [<c05314fb>] hda_set_power_state+0xab/0xe0
> >  [<c0532518>] snd_hda_suspend+0x48/0x60
> >  [<c0530302>] azx_suspend+0x52/0xd0
> >  [<c0266b13>] pci_device_suspend+0x23/0x70
> >  [<c0332dbb>] suspend_device+0x11b/0x2e0
> >  [<c0333032>] device_suspend+0xb2/0x170
> >  [<c012a28b>] printk+0x1b/0x20
> >  [<c014c7ad>] pm_suspend_disk+0x4d/0x2b0
> >  [<c014b395>] enter_state+0x195/0x220
> >  [<c014b4c9>] state_store+0xa9/0xc0
> >  [<c014b420>] state_store+0x0/0xc0
> >  [<c01ae789>] subsys_attr_store+0x29/0x40
> >  [<c01af07c>] sysfs_write_file+0xac/0x130
> >  [<c0172156>] vfs_write+0xa6/0x140
> >  [<c01aefd0>] sysfs_write_file+0x0/0x130
> >  [<c0104050>] syscall_call+0x7/0xb
> >  [<c0630000>] ieee80211_translate_scan+0xa00/0xa50
> >  =======================
> > ACPI: PCI interrupt for device 0000:00:1b.0 disabled
> > 
> > -- 
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Tue, 20 Mar 2007 14:22:03 +0100,
Pavel Machek wrote:
> 
> Hi!
> 
> > > I got this nastinness in my syslog... perhaps HDA intel takes too long
> > > to play with its hardware? Or should we just kill the softlockup
> > > watchdog since Linux is not realtime system, yet?
> > 
> > X60/T60 is known to be often broken regarding the communication
> > between the controller and the codec chip.  When this kind of thing
> > happens, the driver tries to switch to a single-shot I/O without using
> > ring-buffers and IRQs, and even in such a mode, the communication gets
> > broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> > it's fairly specific to X60/T60.  No idea why.
> 
> Is adding touch_softlockup_watchdog() to hd_audio right solution? Or
> should watchdog just disappear?

This should be at a loop in azx_single_send_cmd(),

	int timeout = 50;

	...
	while (timeout--) {
		/* check ICB busy bit */
		if (! (azx_readw(chip, IRS) & ICH6_IRS_BUSY)) {
			...
			return 0;
		}
		udelay(1);
	}

and this function is not in spinlock by itself.
Hence I feel the softlockup is too sensitive in this regard.
But calling touch_softlockup_watchdog() is surely a workaround.


Takashi

> 								Pavel
> 
> > > HDA Intel 0000:00:1b.0: freeze
> > > BUG: soft lockup detected on CPU#0!
> > >  [<c014fdd9>] softlockup_tick+0xa9/0xd0
> > >  [<c0131d63>] update_process_times+0x33/0x80
> > >  [<c0142f52>] tick_periodic+0x22/0x70
> > >  [<c0142fb7>] tick_handle_periodic+0x17/0x80
> > >  [<c014359a>] tick_do_broadcast+0x6a/0x80
> > >  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
> > >  [<c01435fb>] tick_handle_periodic_broadcast+0x1b/0x60
> > >  [<c01435cc>] tick_do_periodic_broadcast+0x1c/0x30
> > >  [<c01077cc>] timer_interrupt+0x2c/0x40
> > >  [<c0150005>] handle_IRQ_event+0x25/0x60
> > >  [<c0151d87>] handle_edge_irq+0xe7/0x130
> > >  [<c0106adb>] do_IRQ+0x3b/0x80
> > >  [<c0106ae0>] do_IRQ+0x40/0x80
> > >  [<c01049eb>] common_interrupt+0x23/0x28
> > >  [<c063007b>] ieee80211_wx_get_scan+0x2b/0x130
> > >  [<c02588f4>] delay_tsc+0x14/0x20
> > >  [<c0258936>] __delay+0x6/0x10
> > >  [<c052f3da>] azx_send_cmd+0xfa/0x110
> > >  [<c053089e>] snd_hda_codec_write+0x3e/0x60
> > >  [<c05314fb>] hda_set_power_state+0xab/0xe0
> > >  [<c0532518>] snd_hda_suspend+0x48/0x60
> > >  [<c0530302>] azx_suspend+0x52/0xd0
> > >  [<c0266b13>] pci_device_suspend+0x23/0x70
> > >  [<c0332dbb>] suspend_device+0x11b/0x2e0
> > >  [<c0333032>] device_suspend+0xb2/0x170
> > >  [<c012a28b>] printk+0x1b/0x20
> > >  [<c014c7ad>] pm_suspend_disk+0x4d/0x2b0
> > >  [<c014b395>] enter_state+0x195/0x220
> > >  [<c014b4c9>] state_store+0xa9/0xc0
> > >  [<c014b420>] state_store+0x0/0xc0
> > >  [<c01ae789>] subsys_attr_store+0x29/0x40
> > >  [<c01af07c>] sysfs_write_file+0xac/0x130
> > >  [<c0172156>] vfs_write+0xa6/0x140
> > >  [<c01aefd0>] sysfs_write_file+0x0/0x130
> > >  [<c0104050>] syscall_call+0x7/0xb
> > >  [<c0630000>] ieee80211_translate_scan+0xa00/0xa50
> > >  =======================
> > > ACPI: PCI interrupt for device 0000:00:1b.0 disabled
> > > 
> > > -- 
> > > (english) http://www.livejournal.com/~pavelmachek
> > > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > > 
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 

Re: BUG: soft lockup during suspend

[Chuck Ebbert]

Takashi Iwai wrote:
> 
> X60/T60 is known to be often broken regarding the communication
> between the controller and the codec chip.  When this kind of thing
> happens, the driver tries to switch to a single-shot I/O without using
> ring-buffers and IRQs, and even in such a mode, the communication gets
> broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> it's fairly specific to X60/T60.  No idea why.

What about Acer Aspire 5102?

http://lkml.org/lkml/2006/12/3/9

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Tue, 20 Mar 2007 12:05:07 -0400,
Chuck Ebbert wrote:
> 
> Takashi Iwai wrote:
> > 
> > X60/T60 is known to be often broken regarding the communication
> > between the controller and the codec chip.  When this kind of thing
> > happens, the driver tries to switch to a single-shot I/O without using
> > ring-buffers and IRQs, and even in such a mode, the communication gets
> > broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> > it's fairly specific to X60/T60.  No idea why.
> 
> What about Acer Aspire 5102?
> 
> http://lkml.org/lkml/2006/12/3/9

This is a different problem.
A known workaround is to provide probe_mask=1 module option.


Takashi

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Tue, 20 Mar 2007 17:08:48 +0100,
I wrote:
> 
> At Tue, 20 Mar 2007 12:05:07 -0400,
> Chuck Ebbert wrote:
> > 
> > Takashi Iwai wrote:
> > > 
> > > X60/T60 is known to be often broken regarding the communication
> > > between the controller and the codec chip.  When this kind of thing
> > > happens, the driver tries to switch to a single-shot I/O without using
> > > ring-buffers and IRQs, and even in such a mode, the communication gets
> > > broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> > > it's fairly specific to X60/T60.  No idea why.
> > 
> > What about Acer Aspire 5102?
> > 
> > http://lkml.org/lkml/2006/12/3/9
> 
> This is a different problem.
> A known workaround is to provide probe_mask=1 module option.

BTW, does this happen on the latest linus git tree?  (rc4 may work,
though)

If yes, could you try the patch below?


thanks,

Takashi

diff -r 1dd843b6ffa7 sound/pci/hda/hda_intel.c
--- a/sound/pci/hda/hda_intel.c	Tue Mar 20 11:33:46 2007 +0100
+++ b/sound/pci/hda/hda_intel.c	Tue Mar 20 17:16:20 2007 +0100
@@ -198,6 +198,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO
 #define RIRB_INT_MASK		0x05
 
 /* STATESTS int mask: SD2,SD1,SD0 */
+#define AZX_MAX_CODECS		3
 #define STATESTS_INT_MASK	0x07
 
 /* SD_CTL bits */
@@ -991,7 +992,7 @@ static int __devinit azx_codec_create(st
 		return err;
 
 	codecs = 0;
-	for (c = 0; c < azx_max_codecs[chip->driver_type]; c++) {
+	for (c = 0; c < AZX_MAX_CODECS; c++) {
 		if ((chip->codec_mask & (1 << c)) & probe_mask) {
 			err = snd_hda_codec_new(chip->bus, c, NULL);
 			if (err < 0)
@@ -999,7 +1000,18 @@ static int __devinit azx_codec_create(st
 			codecs++;
 		}
 	}
-	if (! codecs) {
+	if (!codecs) {
+		/* probe additional slots if no codec is found */
+		for (; c < azx_max_codecs[chip->driver_type]; c++) {
+			if ((chip->codec_mask & (1 << c)) & probe_mask) {
+				err = snd_hda_codec_new(chip->bus, c, NULL);
+				if (err < 0)
+					continue;
+				codecs++;
+			}
+		}
+	}
+	if (!codecs) {
 		snd_printk(KERN_ERR SFX "no codecs initialized\n");
 		return -ENXIO;
 	}

Re: BUG: soft lockup during suspend

[Chuck Ebbert]

Takashi Iwai wrote:
> At Tue, 20 Mar 2007 17:08:48 +0100,
> I wrote:
>> At Tue, 20 Mar 2007 12:05:07 -0400,
>> Chuck Ebbert wrote:
>>> Takashi Iwai wrote:
>>>> X60/T60 is known to be often broken regarding the communication
>>>> between the controller and the codec chip.  When this kind of thing
>>>> happens, the driver tries to switch to a single-shot I/O without using
>>>> ring-buffers and IRQs, and even in such a mode, the communication gets
>>>> broken.  FWIW, it doesn't happen on other machines with HD-audio, so
>>>> it's fairly specific to X60/T60.  No idea why.
>>> What about Acer Aspire 5102?
>>>
>>> http://lkml.org/lkml/2006/12/3/9
>> This is a different problem.
>> A known workaround is to provide probe_mask=1 module option.
> 
> BTW, does this happen on the latest linus git tree?  (rc4 may work,
> though)
> 
> If yes, could you try the patch below?
> 

I can't easily test 2.6.21-rc, but "probe_mask=1" works on 2.6.20.4, which spews
errors without that. Should I try your patch on 2.6.20?

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Tue, 20 Mar 2007 12:32:50 -0400,
Chuck Ebbert wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 20 Mar 2007 17:08:48 +0100,
> > I wrote:
> >> At Tue, 20 Mar 2007 12:05:07 -0400,
> >> Chuck Ebbert wrote:
> >>> Takashi Iwai wrote:
> >>>> X60/T60 is known to be often broken regarding the communication
> >>>> between the controller and the codec chip.  When this kind of thing
> >>>> happens, the driver tries to switch to a single-shot I/O without using
> >>>> ring-buffers and IRQs, and even in such a mode, the communication gets
> >>>> broken.  FWIW, it doesn't happen on other machines with HD-audio, so
> >>>> it's fairly specific to X60/T60.  No idea why.
> >>> What about Acer Aspire 5102?
> >>>
> >>> http://lkml.org/lkml/2006/12/3/9
> >> This is a different problem.
> >> A known workaround is to provide probe_mask=1 module option.
> > 
> > BTW, does this happen on the latest linus git tree?  (rc4 may work,
> > though)
> > 
> > If yes, could you try the patch below?
> > 
> 
> I can't easily test 2.6.21-rc, but "probe_mask=1" works on 2.6.20.4, which spews
> errors without that. Should I try your patch on 2.6.20?

Well, 2.6.21 has really tons of fixes/improvements regarding HD-audio,
so I basically prefer tests on 2.6.21.  But, at least, the patch can
be applied on the top of Greg's latest 2.6.20.x patches...


Takashi

Re: BUG: soft lockup during suspend

[Chuck Ebbert]

Takashi Iwai wrote:
> At Tue, 20 Mar 2007 17:08:48 +0100,
> I wrote:
>> At Tue, 20 Mar 2007 12:05:07 -0400,
>>>
>>> http://lkml.org/lkml/2006/12/3/9
>> This is a different problem.
>> A known workaround is to provide probe_mask=1 module option.
> 
> BTW, does this happen on the latest linus git tree?  (rc4 may work,
> though)
> 

2.6.21-rc4 works perfectly, detecting my Acer notebook's model
properly and adding the sound devices to the bus. Very nice...

Re: BUG: soft lockup during suspend

[Takashi Iwai]

At Fri, 23 Mar 2007 15:22:46 -0400,
Chuck Ebbert wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 20 Mar 2007 17:08:48 +0100,
> > I wrote:
> >> At Tue, 20 Mar 2007 12:05:07 -0400,
> >>>
> >>> http://lkml.org/lkml/2006/12/3/9
> >> This is a different problem.
> >> A known workaround is to provide probe_mask=1 module option.
> > 
> > BTW, does this happen on the latest linus git tree?  (rc4 may work,
> > though)
> > 
> 
> 2.6.21-rc4 works perfectly, detecting my Acer notebook's model
> properly and adding the sound devices to the bus. Very nice...

Could you try rc5?  I'm afraid that one of fix patches on rc5 may
break the probing on your laptop (this path had to be applied to
recover another regression...) 

If it happened, try the patch below from the latest ALSA tree.

thanks,

Takashi


[PATCH] [ALSA] hda-intel - Probe additional slots only if necessary

Probing the codec slots on ATI controller causes problems on some
devices like Acer laptops.  On these devices, reading from codec
slot 3 results in the communication failure with the codec chip.
Meanwhile, some laptops (e.g. Gateway) have the codec connection
only on slot 3, and probing this slot is mandatory for them.
The patch improves the probing robustness.  The additional slots
are now checked only when no codecs are found in the primary three
slots.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>

---
commit a239a9ff89307a0a65fd9cbb02afb020bdb13de0
tree 72603176c199d3fedaeba030f3ea5691c4b5d882
parent 66753e652a094e0ab856417a5092297dbabe5fd6
author Takashi Iwai <tiwai@suse.de> Wed, 21 Mar 2007 15:14:35 +0100
committer Jaroslav Kysela <perex@suse.cz> Wed, 21 Mar 2007 15:15:24 +0100

 sound/pci/hda/hda_intel.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 517a8d7..5e478b9 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -198,6 +198,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO
 #define RIRB_INT_MASK		0x05
 
 /* STATESTS int mask: SD2,SD1,SD0 */
+#define AZX_MAX_CODECS		3
 #define STATESTS_INT_MASK	0x07
 
 /* SD_CTL bits */
@@ -991,7 +992,7 @@ static int __devinit azx_codec_create(st
 		return err;
 
 	codecs = 0;
-	for (c = 0; c < azx_max_codecs[chip->driver_type]; c++) {
+	for (c = 0; c < AZX_MAX_CODECS; c++) {
 		if ((chip->codec_mask & (1 << c)) & probe_mask) {
 			err = snd_hda_codec_new(chip->bus, c, NULL);
 			if (err < 0)
@@ -999,7 +1000,18 @@ static int __devinit azx_codec_create(st
 			codecs++;
 		}
 	}
-	if (! codecs) {
+	if (!codecs) {
+		/* probe additional slots if no codec is found */
+		for (; c < azx_max_codecs[chip->driver_type]; c++) {
+			if ((chip->codec_mask & (1 << c)) & probe_mask) {
+				err = snd_hda_codec_new(chip->bus, c, NULL);
+				if (err < 0)
+					continue;
+				codecs++;
+			}
+		}
+	}
+	if (!codecs) {
 		snd_printk(KERN_ERR SFX "no codecs initialized\n");
 		return -ENXIO;
 	}