[alsa-devel] v3.1.8: hda-intel broken

[Takashi Iwai]

At Wed, 22 Feb 2012 08:42:15 +0000,
Russell King - ARM Linux wrote:
> 
> On Wed, Feb 22, 2012 at 09:26:27AM +0100, Takashi Iwai wrote:
> > At Tue, 21 Feb 2012 23:58:07 +0000,
> > Russell King - ARM Linux wrote:
> > > 
> > > v3.1.8:
> > > 
> > > <4>[1641072.853409] WARNING: at sound/pci/hda/hda_codec.c:5152 snd_array_new+0x47/0x9b [snd_hda_codec]()
> > > <4>[1641072.853412] Hardware name: 2081CTO
> > > <4>[1641072.853413] BUG? (num >= 4096)
> > > <4>[1641072.853415] Modules linked in: lp cdc_ether usbnet mii cdc_acm cdc_wdm usblp ftdi_sio usbserial parport_jtag fuse joydev cpufreq_ondemand acpi_cpufreq mperf nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device arc4 snd_pcm snd_timer r852 sm_common nand nand_ids nand_ecc mtd iwlagn mac80211 snd_page_alloc ppdev iTCO_wdt parport_pc cfg80211 iTCO_vendor_support i2c_i801 thinkpad_acpi rfkill e1000e snd soundcore parport pcspkr wmi microcode firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: ftdi_sio]
> > > <4>[1641072.853459] Pid: 3089, comm: bash Tainted: G        W   3.1.8 #2
> > > <4>[1641072.853461] Call Trace:
> > > <4>[1641072.853466]  [<c04387eb>] warn_slowpath_common+0x6a/0x7f
> > > <4>[1641072.853472]  [<f861d5d0>] ? snd_array_new+0x47/0x9b [snd_hda_codec]
> > > <4>[1641072.853475]  [<c0438873>] warn_slowpath_fmt+0x2b/0x2f
> > > <4>[1641072.853481]  [<f861d5d0>] snd_array_new+0x47/0x9b [snd_hda_codec]
> > > <4>[1641072.853488]  [<f861d65c>] snd_hda_input_jack_add+0x38/0xa2 [snd_hda_codec]
> > > <4>[1641072.853493]  [<f872dcc4>] cxt5051_init+0x62/0xea [snd_hda_codec_conexant]
> > > <4>[1641072.853500]  [<f8621c51>] hda_call_codec_resume+0xa5/0xba [snd_hda_codec]
> > > <4>[1641072.853506]  [<f861f369>] snd_hda_power_up+0x46/0x5c [snd_hda_codec]
> > > <4>[1641072.853513]  [<f861f3b9>] codec_exec_verb+0x3a/0xc7 [snd_hda_codec]
> > > <4>[1641072.853519]  [<f861f482>] snd_hda_codec_write+0x3c/0x43 [snd_hda_codec]
> > > <4>[1641072.853526]  [<f861f4b9>] set_pincfg+0x30/0x45 [snd_hda_codec]
> > > <4>[1641072.853532]  [<f861f507>] restore_pincfgs+0x39/0x46 [snd_hda_codec]
> > > <4>[1641072.853539]  [<f861fa0a>] snd_hda_codec_free+0x6c/0x1f8 [snd_hda_codec]
> > > <4>[1641072.853545]  [<f861fbdb>] snd_hda_bus_free+0x45/0x7c [snd_hda_codec]
> > > <4>[1641072.853552]  [<f861fdb9>] snd_hda_bus_dev_free+0x17/0x19 [snd_hda_codec]<4>[1641072.853560]  [<f80979a4>] snd_device_free+0x91/0xde [snd]
> > > <4>[1641072.853566]  [<f8097c9c>] snd_device_free_all+0x68/0x80 [snd]
> > > <4>[1641072.853572]  [<f80936e3>] snd_card_do_free+0x4e/0xdf [snd]
> > > <4>[1641072.853577]  [<f8094160>] snd_card_free+0x89/0x94 [snd]
> > > <4>[1641072.853581]  [<c044fcee>] ? wake_up_bit+0x20/0x20
> > > <4>[1641072.853585]  [<f86ccddf>] azx_remove+0x13/0x1f [snd_hda_intel]
> > > <4>[1641072.853589]  [<c05de80d>] pci_device_remove+0x2c/0x74
> > > <4>[1641072.853593]  [<c066371d>] __device_release_driver+0x66/0x9c
> > > <4>[1641072.853596]  [<c0663770>] device_release_driver+0x1d/0x28
> > > <4>[1641072.853599]  [<c0662caf>] driver_unbind+0x4d/0x7b
> > > <4>[1641072.853601]  [<c0662c62>] ? store_drivers_probe+0x33/0x33
> > > <4>[1641072.853604]  [<c06627fb>] drv_attr_store+0x24/0x28
> > > <4>[1641072.853607]  [<c05263a6>] sysfs_write_file+0xb3/0xec
> > > <4>[1641072.853609]  [<c05262f3>] ? sysfs_poll+0x73/0x73
> > > <4>[1641072.853612]  [<c04df254>] vfs_write+0x87/0xde
> > > <4>[1641072.853615]  [<c04e678e>] ? path_put+0x1a/0x1d
> > > <4>[1641072.853617]  [<c04df428>] sys_write+0x40/0x62
> > > <4>[1641072.853621]  [<c07c751f>] sysenter_do_call+0x12/0x28
> > > <4>[1641072.853623] ---[ end trace 3d590d4bbb62d735 ]---
> > > 
> > > >From what I can see, this uses the suspend/resume methods on device open/
> > > close.  The suspend method does nothing apart from "shutting up pins".  The
> > > resume method adds new jacks via snd_array_new(), which eventually ends up
> > > getting (after many many days of uptime) to 4096 entries.  And then it
> > > starts exploding with warnings every so often, filling my screen from top
> > > to bottom with abrtd boxes warning me that my kernel is doing this.
> > 
> > It looks like a problem in Conexant codec driver that tries to add the
> > input-jack entries in the init method.  The bug was probably triggered
> > since it's in the device free, i.e. the jack layer was already
> > released beforehand.  Actually there is no merit to call
> > snd_hda_input_jack_add() in the init callback.  It should be called
> > rather only once at the probing time.
> > 
> > A simple solution would be the patch like below.  Could you check
> > whether it fixes?
> > 
> > The patch is needed only up to 3.2, so it won't go to Linus tree with
> > Cc to stable like a normal fix.  I'm going to send a patch to stable
> > ML once after confirming that it works.
> 
> Note that it's taken about 20 days for the problem to show up in the
> first place, so confirming that it's fixed will similarly take a long
> time.

OK, then try to put the debug check below.  Without the fix patch, you
should get a warning after a few times of suspend/resume.


Takashi

---
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 45b4a8d..28278b1 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -5076,6 +5076,8 @@ int snd_hda_input_jack_add(struct hda_codec *codec, hda_nid_t nid, int type,
 	int err;
 
 	snd_array_init(&codec->jacks, sizeof(*jack), 32);
+	if (WARN_ON(codec->jacks.used >= 4)
+		return -ENOMEM;
 	jack = snd_array_new(&codec->jacks);
 	if (!jack)
 		return -ENOMEM;