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

[Takashi Iwai]

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.


thanks,

Takashi

---
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 7bbc5f2..9e37200 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -1933,7 +1933,6 @@ static int cxt5051_init(struct hda_codec *codec)
 	struct conexant_spec *spec = codec->spec;
 
 	conexant_init(codec);
-	conexant_init_jacks(codec);
 
 	if (spec->auto_mic & AUTO_MIC_PORTB)
 		cxt5051_init_mic_port(codec, 0x17, CXT5051_PORTB_EVENT);
@@ -2066,6 +2065,7 @@ static int patch_cxt5051(struct hda_codec *codec)
 	if (spec->beep_amp)
 		snd_hda_attach_beep_device(codec, spec->beep_amp);
 
+	conexant_init_jacks(codec);
 	return 0;
 }