At Mon, 6 Jul 2009 17:03:52 +0200, Andreas Nüßlein wrote:

On Monday 06 July 2009 16:47:48 you wrote:

...

At Mon, 6 Jul 2009 16:36:09 +0200,

Andreas Nüßlein wrote:

...

On Monday 06 July 2009 16:16:06 you wrote:

...

At Mon, 6 Jul 2009 16:03:04 +0200,

Andreas Nüßlein wrote:

...

On Monday 06 July 2009 15:39:09 you wrote:

...

At Mon, 6 Jul 2009 14:59:09 +0200,

Andreas Nüßlein wrote: > On Monday 06 July 2009 14:44:56 you wrote: > > At Mon, 6 Jul 2009 12:19:11 +0200, > > > > Andreas Nüßlein wrote: > > > On Monday 06 July 2009 12:08:11 you wrote: > > > > At Mon, 6 Jul 2009 11:45:07 +0200, > > > > > > > > Andreas Nüßlein wrote: > > > > > [1 <text/plain; iso-8859-1 (quoted-printable)>] > > > > > > > > > > On Monday 06 July 2009 09:23:07 you wrote: > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200, > > > > > > > > > > > > > however i was able to reproduce the "bad kfree", by > > > > > > > changing the volumes in alsamixer. it always gave me > > > > > > > the same "called from ID" so i tried "while (true) do > > > > > > > cat /proc/kallsyms | grep ffffffffa001b08b; done" and > > > > > > > then changed the volume, but the grep never returned > > > > > > > anything, dmesg of course got more and more of those > > > > > > > kfree-errors. > > > > > > > > > > > > The address won't match exactly in /proc/kasllsyms. > > > > > > But you can guess which function by address. First > > > > > > sort /proc/kallsyms then check the position that fits > > > > > > with the given address. > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > well i'm not really sure _I_ can guess ;) i guess it's > > > > > either "t snd_ctl_ioctl [snd]" or "t > > > > > snd_ctl_ioctl_compat [snd]". > > > > > > > > > > here are the greps, "snd: bad kfree (called from > > > > > ffffffffa001b08b)" being the error: > > > > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a > > > > > ffffffffa001a045 t snd_ctl_elem_info [snd] > > > > > ffffffffa001a17a t copy_ctl_value_from_user [snd] > > > > > ffffffffa001a34f t snd_ctl_elem_read [snd] > > > > > ffffffffa001a413 t snd_ctl_elem_write [snd] > > > > > ffffffffa001a515 T snd_ctl_rename_id [snd] > > > > > ffffffffa001a5b5 T snd_ctl_activate_id [snd] > > > > > ffffffffa001a66e T snd_ctl_remove_id [snd] > > > > > ffffffffa001a6ed T snd_ctl_add [snd] > > > > > ffffffffa001a6ed u snd_ctl_add [snd_hda_codec] > > > > > ffffffffa001a947 t snd_ctl_elem_add [snd] > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat [snd] > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user [snd] > > > > > ffffffffa001ada6 t snd_ctl_ioctl [snd] > > > > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd] > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd] > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec] > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus] > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd] > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec] > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel] > > > > > ffffffffa001bb93 T snd_verbose_printk [snd] > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hda_codec] > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hda_intel] > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_hwdep] > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_pcm] > > > > > ffffffffa001bb93 u snd_verbose_printk [snd_timer] > > > > > ffffffffa001bc7b T release_and_free_resource [snd] > > > > > ffffffffa001bcd4 t snd_device_register_all [snd] > > > > > ffffffffa001bd76 T snd_device_register [snd] > > > > > ffffffffa001bd76 u snd_device_register [snd_pcm] > > > > > ffffffffa001be67 t snd_device_disconnect [snd] > > > > > ffffffffa001bf5d t snd_device_disconnect_all [snd] > > > > > > > > > > > > > > > hope that helps =) > > > > > > > > Maybe the patch below can give a better clue. > > > > This will spew stack traces when this error is triggered. > > > > Don't be surprised. > > > > > > oki - new output =) > > > > > > > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f) > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P > > > W 2.6.30.1 #2 [16306.365610] Call Trace: > > > [16306.365632] [<ffffffffa001b08f>] ? > > > snd_ctl_ioctl+0x2e5/0x71e [snd] [16306.365645] > > > [<ffffffff802b8bf9>] ? > > > __inc_zone_state+0x20/0x9b [16306.365655] > > > [<ffffffff802cfffc>] ? alloc_page_vma+0x197/0x1e1 > > > [16306.365666] [<ffffffff802afb63>] ? > > > __lru_cache_add+0x93/0xdd [16306.365676] > > > [<ffffffff802ea651>] ? vfs_ioctl+0x35/0x97 > > > [16306.365686] [<ffffffff802eaae5>] ? > > > do_vfs_ioctl+0x432/0x482 [16306.365696] [<ffffffff806336bf>] > > > ? > > > _spin_lock_irqsave+0x28/0x5c [16306.365705] > > > [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e > > > [16306.365715] [<ffffffff802eab82>] ? sys_ioctl+0x4d/0x81 > > > [16306.365726] [<ffffffff8022af2b>] ? > > > system_call_fastpath+0x16/0x1b > > > > Try the very latest alsa-driver-unstable snapshot. > > This bug should have been fixed, also possibly with CS420x > > parser bug, too. > > > > > > Takashi > > so dmesg knows the following: > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> > GSI 23 (level, low) -> IRQ 23 [18042.848623] HDA Intel > 0000:00:08.0: setting latency timer to 64 [18043.007568] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3851: autoconfig: line_outs=1 > (0xa/0x0/0x0/0x0/0x0) [18043.007584] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3855: speaker_outs=1 > (0xb/0x0/0x0/0x0/0x0) [18043.007596] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3859: hp_outs=1 (0x9/0x0/0x0/0x0/0x0) > [18043.007608] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3860: mono: mono_out=0x0 [18043.007618] > ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3863: dig-out=0x10/0x15 [18043.007628] > ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3871: inputs: mic=0xd, fmic=0x0, > line=0xc, fline=0x0, cd=0x0, aux=0x0 > [18043.007642] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne >l/pc i/hd a/hda_codec.c:3873: dig-in=0x12 [18043.121187] ALSA > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337: > control 2:0:0:IEC958 Capture Switch:0 is already present > [18043.121204] hda_codec: cannot build controlsfor #0 (error -16) > > > and i don't have a mixer anymore ;)

It's because your chip was uninitialized by BIOS or whatever, the another state you got sometimes.

Now fixed in the driver to force to initialize pins. Try the latest tarball again.

Takashi

TAKASHIIIIIIIIIIIII =) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

digital out is working... i tried the new snapshot (eventhough, as you said my subsystem is now again uninitialized) and i got back the alsamixer- capabilities;

i ran mplayer test.wav and started playing around with the mixer-controls.

when i reached IEC958 and turned it on, my out-jack began to glow red =) so that works. i rushed over to my dorm-partners speakersystem and plugged it in - voila that actually works! (i tried a DTS video with mplayer -vc hwdts )

that is SO cool =)

however as you might've figured out, analog out is not working, yet ;( i tried the built-in speakers as well as the headphones (and of course all the

Hm, so you don't get any output although no errors with aplay?

Please give alsa-info.sh output with the latest driver to be sure.

Takashi

and here is the alsa-info with the "correct" subsystem id.

i also was able to get the wrong subsystem id again: i did /etc/init.d/alsasound stop && modprobe snd-hda-intel - that changed it. (i'll have a look into init.d/alsasound to see if there are any clues)

Interesting. So, resetting the controller alone can change the SSID. It doesn't happen on other systems.

Could you try to apply the patch below on alsa-kernel directory with -p2? This will disable the additional COEF setups, which I blindly copied from older cs4207 patch.

thanks,

Takashi

---

diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index b1fd183..fda83b2 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -933,7 +933,7 @@ static void init_input(struct hda_codec *codec) change_cur_input(codec, spec->cur_input, 1); if (spec->mic_detect) cs_automic(codec);

+#if 0 coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */ if (is_active_pin(codec, CS_DMIC2_PIN_NID)) coef |= 0x0500; /* DMIC2 enable 2 channels, disable GPIO1 */ @@ -943,6 +943,7 @@ static void init_input(struct hda_codec *codec) * IDX_SPDIF_CTL. */ cs_vendor_coef_set(codec, IDX_ADC_CFG, coef); +#endif }

static struct hda_verb cs_coef_init_verbs[] = { @@ -980,10 +981,10 @@ static int cs_init(struct hda_codec *codec) { struct cs_spec *spec = codec->spec;

• snd_hda_sequence_write(codec, cs_coef_init_verbs);

• /*snd_hda_sequence_write(codec, cs_coef_init_verbs);*/ init_output(codec); init_input(codec);

• init_digital(codec);

• /*init_digital(codec);*/ return 0;

}

wow okay... so aplay test.wav didn't give me any sound, but when i tried to stop it (Ctrl-C) i couldn't and i had to kill it from another term, which resulted in this:

When you run like below % aplay -Dplughw -vvv somefile.wav does it proceed?

If not, it means that the DMA got stuck somewhere. If it goes, then the problem is in another place.

Takashi