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@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