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

[Russell King - ARM Linux]

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.