May 2008 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [Bug #10679] 2.6.26-rc1 regression: e5e1d3cb20034a3cbcfff1f0bae12201aa2ce17e breaks artsd
by Stas Sergeev 22 May '08

22 May '08

Hello. Dave Jones wrote: > More seriously, it doesn't seem that there's any way we can build > this driver modular without it screwing up already working systems Actually, I have just upgraded f8->f9, and guess what? Lost the sound... And not because of snd-pcsp, but rather because snd-hda-intel started to take the first slot and snd-intel8x0 takes the second. On f8 snd-hda-intel have never been loaded for me at all. I don't need it, it finds a HDA chip on an ATI video board, which it never did before. So... it doesn't look like this problem is specific to snd-pcsp. Anyone can get into that trouble it seems.

2 3

[alsa-devel] No audio from laptop speakers, and very faint audio through headphones
by Adam Wiseman 22 May '08

22 May '08

Note: I originally posted my problem on the alsa-user list, but due to the fact that I've got an intel "integrated-everything" chipset, which alsa apparently seems to be having all sorts of trouble with, I was referred to the devel list. So here's my problem: On my Panasonic Toughbook, I get no sound from the laptop speakers, and just barely audible sound from the headphones. I've googled, searched the ubuntu forums, and chatted with a very helpful individual (wishie) on IRC, to no avail. Here is my pastebin of my alsa-info.sh output: http://pastebin.ca/1021657 Here is my pastebin of my amixer output: http://pastebin.ca/1021660 I would be ridiculously grateful if anyone can help me get the sound working on this thing. Thanks, Adam

1 0

[alsa-devel] Asynchronous notification in ALSA - I/O Plugin - Pulseaudio
by Juha Erkkilä 22 May '08

22 May '08

I'm trying to get Abode Flash Player working properly on a thin client, with sound, using Pulseaudio as a sound server. I'm using ALSA version 1.10.15 and Pulseaudio version 0.9.10 on Ubuntu Hardy, with Pulseaudio server running as a system-wide daemon on the thin client. I already outlined the issues on Pulseaudio mailing list on this post: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001793.html, see also Lennart Poettering's answer: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001796.html. I feel the proper solution would involve writing support for asynchronous notification into ALSA library and I/O-plugin layer. Currently, Pulse I/O-plugin does not work in the Flash case, because Flash requires the asynchronous API. On the other hand, Pulse requires the I/O-plugin layer to work. See the posts by Alexander Indenbaum, http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007033.html, and Takashi Iwai, http://mailman.alsa-project.org/pipermail/alsa-devel/2008-April/007335.html, on this subject. I tried to tackle this issue, and did get the signal handling code to call the Flash audio callback, but I'm new to both ALSA and Pulseaudio, and it appears there are some issues with it I don't fully understand. Thus I'm asking: are there any other people who have been looking into this, or anyone who can tell whether this is a sane thing to do or not, will it require some nasty hack, or can help with some pointers to relevant information? I'm hoping that implementing the asynchronous API on I/O-plugin layer would not only fix Flash audio, but might help some other programs too to achieve network transparent audio. Juha

3 5

[alsa-devel] Will ALSA ever call _prepare or _hw_params while it's playing?
by Timur Tabi 21 May '08

21 May '08

I have an ASoC driver with a _hw_params, _prepare, and _trigger functions. I've recently discovered that I need to keep one of my devices disabled until playback starts. So I would like to know if ALSA will ever call _hw_params, _prepare, or _startup if playback or capture is currently in process, or will ALSA first call the _trigger to stop/pause the driver. If ALSA does stop/pause the driver before changing parameters, then I can safely assume the device is always disabled during those functions. -- Timur Tabi Linux kernel developer at Freescale

2 2

[alsa-devel] Possible problem with snd_pcm_oss_sync()
by Timur Tabi 21 May '08

21 May '08

-------- Original Message -------- Subject: RE: Regarding MPC8610 BSP question and issue Date: Tue, 20 May 2008 08:55:46 -0700 From: Hayasaka Manabu <manabu.hayasaka(a)freescale.com> To: Hayasaka Manabu <manabu.hayasaka(a)freescale.com>, Johnson Kelly <Kelly.Johnson(a)freescale.com> CC: sun york <yorksun(a)freescale.com>, Namiki Ayumi <namiki(a)freescale.com>, Beck Glenn <Glenn.Beck(a)freescale.com>, Cox Kevin <K.Cox(a)freescale.com>, Hamano Masahiro <M.Hamano(a)freescale.com>, Tabi Timur <timur(a)freescale.com> References: <E03EE6E38549E949AE8138F60493E1E801C49A0C(a)zja67exm20.fsl.freescale.net> <4807899D.3000901(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801DA1B11(a)zja67exm20.fsl.freescale.net> <48110FCF.7070302(a)freescale.com> <BD243C8D8F65694A966948E9D51F9815C29409(a)zja67exm21.fsl.freescale.net> <48189540.9060309(a)freescale.com> <BD243C8D8F65694A966948E9D51F9815C29422(a)zja67exm21.fsl.freescale.net> <E03EE6E38549E949AE8138F60493E1E801DA25D9(a)zja67exm20.fsl.freescale.net> <4821CA02.2020504(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801FA11C8(a)zja67exm20.fsl.freescale.net> <4829C444.7010206(a)freescale.com> <E03EE6E38549E949AE8138F60493E1E801FA13D2(a)zja67exm20.fsl.freescale.net> <482B1D10.7090402(a)freescale.com> <482B2699.8020409(a)freescale.com> I'm working with a customer that has discovered a possible problem with OSS emulation. Unfortunately, I don't have a lot of experience with OSS, so I need help understanding whether the customer's observations point to a real problem or not. The customer is using an old application called "bplay" to test OSS audio support on our hardware. The application works fine on x86, but fails on our PowerPC board. It could be an endian issue, but I doubt it. Here is the forwarded email (slightly edited). Can someone familiar with the OSS "sync" functionality comment? --------------- They reported that it seemed some ioctl commands in the OSS emulation did not work correctly. The tested procedure of the ioctl commands are as following, #1) Stopped audio stream output after doing followings: 1. Opening /dev/mixer 2. Getting a channel value (0x00000001) that is used for "ioctl(fd, SOUND_MIXER_READ_DEVMASK, &Sndsts);". 3. Write audio volume information by "ioctl(fd, SOUND_MIXER_WRITE_VOLUME, &Value);", #2) Stopped audio stream output after doing following: 1. Opening /dev/dsp 2. Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);", XXXX found that by commenting out the "sync_audio" function on the source code of "bplay" made "bplay" work. So XXXX suspects the implementation of the ioctl on the OSS emulation may have a problem. -- Timur Tabi Linux kernel developer at Freescale

3 4

[alsa-devel] AC'97 recording on AT91sam9263
by Sedji Gaouaou 21 May '08

21 May '08

Hi, I am trying to write the AC'97 driver(recording) and I encounter some problems. I would like to set up some constraints but if I do so I will have a seg fault when running arecord. here is my open function: /* define the constraints */ static unsigned int rates[] = { 8000, 44100, }; static struct snd_pcm_hw_constraint_list hw_constraints_rates = { .count = ARRAY_SIZE(rates), .list = rates, .mask = 0, }; ... static int snd_at91_ac97_capture_open(struct snd_pcm_substream *substream) { at91_ac97_t *chip = snd_pcm_substream_chip(substream); struct snd_pcm_runtime *runtime = substream->runtime; int err; runtime->hw = snd_at91_ac97_capture_hw; chip->capture_substream = substream; chip->period = 0; if ((err = snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, &hw_constraints_rates)) < 0) return err; snd_printd(KERN_DEBUG "%s : snd_at91_ac97_capture_open\n\r", driver_name); return 0; } I have another problem if I try to set up some constraint on the format. Indeed I do exactly the same as for the rate, but then it will fail in aplay.c in the function set_params, returning the error message:"Broken configuration for this PCM: no configuration available." Do I miss something when trying to set up the constraints? Is there any particular way for setting the format constraints? Regards, Sedji

1 0

[alsa-devel] External Plugin Non-Interleaved
by Charles Eidsness 21 May '08

21 May '08

I'm working on a small ALSA pcm/ctl plugin to add support for LADSPA modules that include real-time controls (unless I'm missing something it looks like the native ALSA LADSPA module doesn't include real-time adjustable controls). I want to use it as a system wide equalizer. I'm using snd_pcm_extplug, I want to force access to be non-interleaved only but I can't figure out how. Is there some way to force non-interleaved access for an extplug? If you're interested you can find the first pass of my plugin here: http://www.thedigitalmachine.net/alsaequal.html Thanks, Charles

2 2

[alsa-devel] Kernel crash in snd-aloop
by Benjamin van den Hout 21 May '08

21 May '08

Hello all, Thanks to the excellent advice here on the list, I'm one step further with getting my project running with the snd-aloop driver! Now I'm looking to scale my solution to more concurrent users. If I check aloop-kernel.c (in the alsa 10.0.16 release tarball), there are two lines that interest me: #define MAX_PCM_SUBSTREAMS 8 and static int pcm_substreams[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 8}; The standard aloop driver supplies 8 loopback devices; I need to have more, so I changed both occurences of '8' to 16 and there are no problems. I'm bundling all these subdevices with a 'type multi' in .asoundrc to one device that is used as a JACK backend. So far so good! If I change the 16 to 32 (and modifying .asoundrc to bundle all 32 devices to the 'multi' device) however, restarting JACK will sometimes panic my kernel. I'm running a stock 2.6.22-4 kernel (64 bit) and this is the oops output (redirected to a serial console luckily, otherwise it would be a lot of typing): ----Start oops output---- ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026669d>] get_page_from_freelist+0x2b/0x534 [<ffffffff80266d0b>] __alloc_pages+0x5a/0x2bc [<ffffffff8026664f>] get_zeroed_page+0x11/0x34 [<ffffffff8026eba6>] __pte_alloc+0x1a/0xb8 [<ffffffff8026ed7f>] __handle_mm_fault+0x13b/0xa35 [<ffffffff80220e9a>] do_page_fault+0x42b/0x7ad [<ffffffff80273f66>] do_mmap_pgoff+0x60a/0x776 [<ffffffff803fe7dd>] error_exit+0x0/0x84 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026e33b>] unmap_vmas+0x3a0/0x741 [<ffffffff8026e26e>] unmap_vmas+0x2d3/0x741 [<ffffffff80272394>] exit_mmap+0x80/0x117 [<ffffffff8022fdfe>] mmput+0x2c/0x9e [<ffffffff8028aee7>] flush_old_exec+0x69d/0x9b6 [<ffffffff8028702b>] vfs_read+0x13f/0x153 [<ffffffff802b60e2>] load_elf_binary+0x462/0x1979 [<ffffffff80244a85>] autoremove_wake_function+0x0/0x2e [<ffffffff80266d0b>] __alloc_pages+0x5a/0x2bc [<ffffffff802b5c80>] load_elf_binary+0x0/0x1979 [<ffffffff8028a135>] search_binary_handler+0xf1/0x27e [<ffffffff8028bbae>] do_execve+0x188/0x231 [<ffffffff80208b6f>] sys_execve+0x36/0x90 [<ffffffff8020a207>] stub_execve+0x67/0xb0 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff8026655a>] free_hot_cold_page+0x135/0x167 [<ffffffff802665ad>] __pagevec_free+0x21/0x2e [<ffffffff80268e15>] release_pages+0x123/0x169 [<ffffffff8026945d>] __pagevec_release+0x19/0x22 [<ffffffff80269988>] truncate_inode_pages_range+0xc5/0x28d [<ffffffff8027ffd2>] shmem_delete_inode+0x3f/0xe7 [<ffffffff8027ff93>] shmem_delete_inode+0x0/0xe7 [<ffffffff802991a7>] generic_delete_inode+0xc5/0x13d [<ffffffff80296307>] d_kill+0x38/0x59 [<ffffffff80296435>] dput+0x10d/0x119 [<ffffffff802877dd>] __fput+0x145/0x16e [<ffffffff802d1141>] shm_destroy+0x41/0x5a [<ffffffff802d1e5f>] sys_shmctl+0x49d/0x632 [<ffffffff8023d659>] sys_kill+0x133/0x15c [<ffffffff80286ed7>] vfs_write+0x142/0x157 [<ffffffff802873c1>] sys_write+0x45/0x6e [<ffffffff80209e3e>] system_call+0x7e/0x83 ALSA */home/benjamin/alsa/alsa-driver-1.0.16/acore/*..*/alsa-kernel/core/*pcm_lib.c) Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf divide error: 0000 [1] PREEMPT SMP CPU 2 Modules linked in: snd_aloop snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snn Pid: 0, comm: swapper Not tainted 2.6.22-4-amd64-preempt-blktrace #1 RIP: 0010:[<ffffffff882e73dd>] [<ffffffff882e73dd>] :snd_aloop:snd_card_loopba0 RSP: 0018:ffff81042faefed0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff810404cd78a8 RCX: 00000001003d172d RDX: 0000000000000000 RSI: 0000000000000217 RDI: 0000000000000001 RBP: ffff810404cd78b0 R08: 0000000000000091 R09: 00000001003d172d R10: 0000000000000000 R11: 0000000000000217 R12: ffff81042fadc000 R13: ffffffff882e7391 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff81042fa7d440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000005b2b50 CR3: 0000000000201000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffff81042fae8000, task ffff81042fae75a0) Stack: ffff810404cd78a8 ffff810404cd78a8 0000000000000102 ffffffff8023a720 ffff81042faefef0 ffff81042faefef0 0000012c0000000a 0000000000000021 ffffffff804f1110 000000000000000a 0000000000000002 ffffffff8023723b Call Trace: <IRQ> [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf Code: f7 73 64 8b 4b 68 89 93 80 00 00 00 8b 53 7c 39 ca 72 35 89 RIP [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 RSP <ffff81042faefed0> Kernel panic - not syncing: Aiee, killing interrupt handler! Unable to handle kernel paging request at ffff81042af0c800 RIP: [<ffff81042af0c800>] PGD 8063 PUD 19063 PMD 800000042ae001e3 PTE 0 Oops: 0011 [2] PREEMPT SMP CPU 2 Modules linked in: snd_aloop snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snn Pid: 0, comm: swapper Not tainted 2.6.22-4-amd64-preempt-blktrace #1 RIP: 0010:[<ffff81042af0c800>] [<ffff81042af0c800>] RSP: 0018:ffff81042faefb60 EFLAGS: 00010003 RAX: ffff81042fae9fd8 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffffffff8059e900 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff81042faefb90 R08: 0000000000000000 R09: ffff81042af0c800 R10: ffffffff8046d656 R11: 00000000000000fc R12: ffff81042af0c800 R13: 0000000000000000 R14: 000000000000000b R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff81042fa7d440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff81042af0c800 CR3: 0000000000201000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffff81042fae8000, task ffff81042fae75a0) Stack: ffffffff802189f1 ffffffff8046d636 ffff81042fae75a0 ffffffff80468144 ffffffff8020a9c6 ffff81042faefb90 0000000000000000 00000000000000fc ffffffff8046d656 ffff81042af0c800 0000000000000000 ffffffff8037f3ca Call Trace: <IRQ> [<ffffffff802189f1>] smp_call_function_interrupt+0x40/0x5e [<ffffffff8020a9c6>] call_function_interrupt+0x66/0x70 [<ffffffff8037f3ca>] i8042_panic_blink+0x1/0x147 [<ffffffff80232206>] panic+0x126/0x148 [<ffffffff80232193>] panic+0xb3/0x148 [<ffffffff802298b0>] __wake_up_common+0x3e/0x68 [<ffffffff802352ec>] do_exit+0x8a/0x849 [<ffffffff8020b964>] kernel_math_error+0x0/0x71 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff8020be38>] do_divide_error+0x7f/0x89 [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff80232b1f>] printk+0x4e/0x56 [<ffffffff8024d569>] __module_text_address+0x5e/0x68 [<ffffffff803fe7dd>] error_exit+0x0/0x84 [<ffffffff882e7391>] :snd_aloop:snd_card_loopback_timer_function+0x0/0xa0 [<ffffffff882e73dd>] :snd_aloop:snd_card_loopback_timer_function+0x4c/0xa0 [<ffffffff8023a720>] run_timer_softirq+0x15b/0x1cf [<ffffffff8023723b>] __do_softirq+0x49/0xb8 [<ffffffff8020affc>] call_softirq+0x1c/0x28 [<ffffffff8020ca75>] do_softirq+0x2c/0x7d [<ffffffff802371e6>] irq_exit+0x36/0x42 [<ffffffff8021a549>] smp_apic_timer_interrupt+0x49/0x5c [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff80208e05>] mwait_idle+0x0/0x45 [<ffffffff8020aaa6>] apic_timer_interrupt+0x66/0x70 <EOI> [<ffffffff80208e47>] mwait_idle+0x42/0x45 [<ffffffff80208d89>] cpu_idle+0x88/0xbf Code: 00 00 00 00 00 00 00 00 00 a0 f2 2b 04 81 ff ff 00 20 18 29 RIP [<ffff81042af0c800>] RSP <ffff81042faefb60> CR2: ffff81042af0c800 Kernel panic - not syncing: Aiee, killing interrupt handler! ----End oops output---- This crash can be reproduced by automatically restarting jackd in a 'while true' loop and simultaneously killing it every 0.5 seconds from a different terminal. That seems like a nasty thing to do, but I have had it happen some times when jackd was running for a few hours and I needed to restart it for testing something else. Sometimes it takes down the machine, sometimes it doesn't. This constant starting/killing will reproduce it within a minute or so. I'm convinced that jackd should never be able to crash the kernel right? Is there anything I'm missing here by blindly changing the value from 16 to 32, anything else I need to consider? Any input is greatly appreciated. Thanks in advance! Kind regards, Benjamin

1 0

[alsa-devel] [PATCH][ASoC V2] Fix null-pointer dereference in soc_create_pcm()
by Timur Tabi 21 May '08

21 May '08

When soc_create_pcm() finds all four components it needs, it displays a status message. This message references the local variables 'codec_dai' and 'cpu_dai', but these variables are initialized only when the codec DAI and the cpu DAI are the last to be registered. This patch changes the code to use the stored values instead of the local variables. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/soc-core.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7dc6d68..520469b 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -921,8 +921,8 @@ check: } pcm->private_free = platform->pcm_free; - printk(KERN_INFO "asoc: %s <-> %s mapping ok\n", codec_dai->name, - cpu_dai->name); + printk(KERN_INFO "asoc: %s <-> %s mapping ok\n", + pcm_runtime->codec_dai->name, pcm_runtime->cpu_dai->name); list_add(&pcm_runtime->list, &soc_card->pcm_list); return 1; err: -- 1.5.5

3 4

[alsa-devel] MIDI on ice1724 - preliminary findings and questions
by Pavel Hofman 20 May '08

20 May '08

Hi, I am trying to fix the ancient MIDI problem with ice1724 cards. I applied Takashi's patch from http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000641.html and made some minor changes (MPU401_INFO_INPUT | MPU401_INFO_OUTPUT to mpu401_uart info_flags, added a few debugs for testing). I can test only MIDI input using my MIDI keyboard, I have no MIDI output device available. The input works fine now, the output most probably too since the method snd_vt1724_mpu401_write gets called when transmitting some data with amidi. But here is the problem I do not understand: When no MIDI input/output is used, the interrupt handler snd_vt1724_interrupt gets called with interrupt status 0x10 which correctly refers to the audio data interrupt (VT1724_IRQ_MTPCM). However, when MIDI input or output is used (opened) even for a short time after the module is loaded, any subsequent audio playback generates interrupt status of 0x30 which refers to VT1724_IRQ_MTPCM AND VT1724_IRQ_MPU_TX. I have no idea why VT1724_IRQ_MPU_TX gets generated. The first run of the snd_vt1724_interrupt loop tries to handle the MPU TX status, calling uart_interrupt_tx in mpu401_uart.c: if (test_bit(MPU401_MODE_BIT_OUTPUT, &mpu->mode) && test_bit(MPU401_MODE_BIT_OUTPUT_TRIGGER, &mpu->mode)) { spin_lock_irqsave(&mpu->output_lock, flags); snd_mpu401_uart_output_write(mpu); spin_unlock_irqrestore(&mpu->output_lock, flags); } However, since the MPU output is not open at this time (no MIDI is being transmitted), the call to snd_mpu401_uart_output_write is skipped. Even though I think the interrupt status should get cleared by outb(status, ICEREG1724(ice, IRQSTAT)) the loop repeats with the MPU TX interrupt status enabled until the timeout check breaks the while loop, returning to the interrupt handler the next moment again. Apr 19 22:20:47 nahore kernel: [ 2402.938245] uart interrupt: status 0x30 Apr 19 22:20:47 nahore kernel: [ 2402.938260] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938267] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938274] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938281] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938288] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938295] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938302] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938309] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938316] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938323] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.938326] ice1724: Too long irq loop, status = 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961247] uart interrupt: status 0x30 Apr 19 22:20:47 nahore kernel: [ 2402.961278] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961285] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961292] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961299] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961306] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961313] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961320] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961327] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961334] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961341] uart interrupt: status 0x20 Apr 19 22:20:47 nahore kernel: [ 2402.961344] ice1724: Too long irq loop, status = 0x20 After the playback stops, the interrupts are gone too. It seems as if the playback interrupt initiates the MPU TX interrupt. If we could avoid generating the MPU TX interrupt during regular playback, I believe the major problem would be resolved. Even if I mask the interrupts (CCS01) and do not explicitly unmask them (according to proc ice1724 the CCS01 register stays at 0xa0), the interrupt gets generated. I am enclosing the testing patch producing the above given results. Thanks a lot for any suggestion or help. Regards, Pavel.

3 19