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

Takashi Iwai tiwai at suse.de
Wed Feb 22 12:47:08 CET 2012


At Wed, 22 Feb 2012 11:26:12 +0000,
Russell King - ARM Linux wrote:
> 
> On Wed, Feb 22, 2012 at 11:43:40AM +0100, Takashi Iwai wrote:
> > At Wed, 22 Feb 2012 10:38:01 +0000,
> > Russell King - ARM Linux wrote:
> > > 
> > > On Wed, Feb 22, 2012 at 10:15:43AM +0100, Takashi Iwai wrote:
> > > > At Wed, 22 Feb 2012 09:04:35 +0000,
> > > > Russell King - ARM Linux wrote:
> > > > > 
> > > > > On Wed, Feb 22, 2012 at 09:59:51AM +0100, Takashi Iwai wrote:
> > > > > > 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.
> > > > > 
> > > > > I have to point out that suspend/resume had nothing to do with this
> > > > > appearing.  It appeared after the machine hadn't been suspended/resumed
> > > > > for a couple of weeks.
> > > > 
> > > > Then it must be the power-saving.  Almost the same suspend/resume path
> > > > is called when the driver enters into the power-saving mode.
> > > > 
> > > > Setting /sys/module/snd_hda_intel/power_save=1, and close all sound
> > > > stuff (at best go to runlevel 3 and kill PulseAudio).
> > > > Then doing something like
> > > > 	echo -n | aplay -Dplughw
> > > > will wake up the device, then soon sleep again after 1 second after
> > > > close.  Running echo a few times should trigger the warning with the
> > > > debug check patch.
> > > 
> > > It seems not to cause any warning, so I guess it's fixed.  Thanks.
> > > 
> > > Tested-by: Russell King <rmk+kernel at arm.linux.org.uk>
> > 
> > OK, thanks for a quick check!
> 
> Actually, I'm not entirely convinced that I've tested it or that your
> method of testing it works.  I think I tested the old module back in
> place rather than loading the new fixed module.  Thanks to the addition
> of '+' on the version string for having modified the kernel source.

Hrm, OK, please let me know if you find anything positive or negative
with the right module.


Takashi


More information about the Alsa-devel mailing list