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

Re: [alsa-devel] [BUG] New Kernel Bugs
by Neil Brown 16 Nov '07

16 Nov '07

On Wednesday November 14, bfields(a)fieldses.org wrote: > On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > so please stop this "too busy and too noisy" nonsense already. It was > > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > > what? Deal with it and be intelligent about filtering your information > > > influx instead of imposing a hard pre-filtering criteria that restricts > > > intelligent processing of information. > > > > So you have a preferred method of handling email. Please don't > > force it on the rest of us. > > I'd be curious for any pointers on tools, actually. I "read" (ok, skim) > lkml but still overlook relevant bug reports occasionally. > (Fortunately, between Trond and Andrew and others forwarding things it's > not actually a problem, but I'm still curious). Virtual Folders. I use VM mode in EMACS, but I believe some other mail readers have the same functionality. I have a virtual folder called "nfs" which shows me all mail in my inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject field. When I visit that folder, I see all mail about nfs, whether it was sent to me personally, or to a relevant list, or to lkml. Admittedly if someone doesn't bother to choose a meaningful Subject, then I might miss that. I think this mostly happens when Andrew sends a "-mm" announcement, asked people to change the subject line when following up, and someone follows up without changing the subject line and say "NFS doesn't work any more". I have another virtual folder which matches "md" and "raid" and "mdadm" in any header (so when the people from coraid.com talk about ATA over Ethernet, that gets badly filed, but it is a small cost). Then I have the "bkernel" (boring kernel) folder for all mail from lkml that doesn't mention nfs or raid or md, and isn't from or to me. That folder I skim every week or so and just read the juicy debates and look for interesting tidbits from interesting people - then delete the whole folder, mostly unread. I don't think I could cope with mail without virtual folders. NeilBrown

2 1

[alsa-devel] Mitac 8252D hda_intel
by glv 15 Nov '07

15 Nov '07

(Second attempt, hope this works) Hello, I have a Mitac 8252D computer with hda_intel, it has 3 sockets in front: microphone, audio(headphones)and S/PDIF. When using 5.1 the manual says: Microphone: rear speakers Audio: front speakers S/PDIF: center and subwoofer Modprobing without any options gives me sound to the headphone and digital socket and Modprobing with model=6stack-hp gives me sound to the speakers to but they stay on when headph. are pluged in Output from alsa-info.sh: http://pastebin.ca/772406 Output from lspci -vv: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Subsystem: Mitac Unknown device 8253 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at fc200000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) thank you.

3 3

[alsa-devel] Removal of indirect access in control API
by Takashi Iwai 15 Nov '07

15 Nov '07

Hi, ALSA control elements have "indirect" flag, which is supposed to allow the indirect access via pointer. But, as far as I know, this feature has never been used nor implemented, and unsupported via 32/64bit compat layer. So, I'd like to get rid of this now. The clean-up patch is below. If you have objections, please let me know. thanks, Takashi --- diff -r 34e3c66d7a5c core/control.c --- a/core/control.c Mon Nov 12 18:04:54 2007 +0100 +++ b/core/control.c Mon Nov 12 18:05:16 2007 +0100 @@ -232,8 +232,6 @@ struct snd_kcontrol *snd_ctl_new1(const access = ncontrol->access == 0 ? SNDRV_CTL_ELEM_ACCESS_READWRITE : (ncontrol->access & (SNDRV_CTL_ELEM_ACCESS_READWRITE| SNDRV_CTL_ELEM_ACCESS_INACTIVE| - SNDRV_CTL_ELEM_ACCESS_DINDIRECT| - SNDRV_CTL_ELEM_ACCESS_INDIRECT| SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE| SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK)); kctl.info = ncontrol->info; @@ -692,7 +690,7 @@ int snd_ctl_elem_read(struct snd_card *c struct snd_kcontrol *kctl; struct snd_kcontrol_volatile *vd; unsigned int index_offset; - int result, indirect; + int result; down_read(&card->controls_rwsem); kctl = snd_ctl_find_id(card, &control->id); @@ -701,17 +699,12 @@ int snd_ctl_elem_read(struct snd_card *c } else { index_offset = snd_ctl_get_ioff(kctl, &control->id); vd = &kctl->vd[index_offset]; - indirect = vd->access & SNDRV_CTL_ELEM_ACCESS_INDIRECT ? 1 : 0; - if (control->indirect != indirect) { - result = -EACCES; - } else { - if ((vd->access & SNDRV_CTL_ELEM_ACCESS_READ) && kctl->get != NULL) { - snd_ctl_build_ioff(&control->id, kctl, index_offset); - result = kctl->get(kctl, control); - } else { - result = -EPERM; - } - } + if ((vd->access & SNDRV_CTL_ELEM_ACCESS_READ) && + kctl->get != NULL) { + snd_ctl_build_ioff(&control->id, kctl, index_offset); + result = kctl->get(kctl, control); + } else + result = -EPERM; } up_read(&card->controls_rwsem); return result; @@ -748,7 +741,7 @@ int snd_ctl_elem_write(struct snd_card * struct snd_kcontrol *kctl; struct snd_kcontrol_volatile *vd; unsigned int index_offset; - int result, indirect; + int result; down_read(&card->controls_rwsem); kctl = snd_ctl_find_id(card, &control->id); @@ -757,23 +750,19 @@ int snd_ctl_elem_write(struct snd_card * } else { index_offset = snd_ctl_get_ioff(kctl, &control->id); vd = &kctl->vd[index_offset]; - indirect = vd->access & SNDRV_CTL_ELEM_ACCESS_INDIRECT ? 1 : 0; - if (control->indirect != indirect) { - result = -EACCES; + if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || + kctl->put == NULL || + (file && vd->owner && vd->owner != file)) { + result = -EPERM; } else { - if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || - kctl->put == NULL || - (file && vd->owner != NULL && vd->owner != file)) { - result = -EPERM; - } else { - snd_ctl_build_ioff(&control->id, kctl, index_offset); - result = kctl->put(kctl, control); - } - if (result > 0) { - up_read(&card->controls_rwsem); - snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, &control->id); - return 0; - } + snd_ctl_build_ioff(&control->id, kctl, index_offset); + result = kctl->put(kctl, control); + } + if (result > 0) { + up_read(&card->controls_rwsem); + snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, + &control->id); + return 0; } } up_read(&card->controls_rwsem); diff -r 34e3c66d7a5c include/asound.h --- a/include/asound.h Mon Nov 12 18:04:54 2007 +0100 +++ b/include/asound.h Mon Nov 12 18:05:16 2007 +0100 @@ -738,8 +738,7 @@ typedef int __bitwise snd_ctl_elem_iface #define SNDRV_CTL_ELEM_ACCESS_OWNER (1<<10) /* write lock owner */ #define SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK (1<<28) /* kernel use a TLV callback */ #define SNDRV_CTL_ELEM_ACCESS_USER (1<<29) /* user space element */ -#define SNDRV_CTL_ELEM_ACCESS_DINDIRECT (1<<30) /* indirect access for matrix dimensions in the info structure */ -#define SNDRV_CTL_ELEM_ACCESS_INDIRECT (1<<31) /* indirect access for element value in the value structure */ +/* bits 30 and 31 are obsoleted (for indirect access) */ /* for further details see the ACPI and PCI power management specification */ #define SNDRV_CTL_POWER_D0 0x0000 /* full On */ @@ -793,30 +792,25 @@ struct snd_ctl_elem_info { } value; union { unsigned short d[4]; /* dimensions */ - unsigned short *d_ptr; /* indirect */ } dimen; unsigned char reserved[64-4*sizeof(unsigned short)]; }; struct snd_ctl_elem_value { struct snd_ctl_elem_id id; /* W: element ID */ - unsigned int indirect: 1; /* W: use indirect pointer (xxx_ptr member) */ + unsigned int indirect: 1; /* W: indirect access - obsoleted */ union { union { long value[128]; - long *value_ptr; } integer; union { long long value[64]; - long long *value_ptr; } integer64; union { unsigned int item[128]; - unsigned int *item_ptr; } enumerated; union { unsigned char data[512]; - unsigned char *data_ptr; } bytes; struct snd_aes_iec958 iec958; } value; /* RO */

2 2

[alsa-devel] interrupting snd_pcm_writei or snd_pcm_drain?
by Mike Gorse 15 Nov '07

15 Nov '07

I've noticed that it is unsafe to call snd_pcm_writei or snd_pcm_drain in a pthread with its cancelation type set to asynchronous. snd_pcm_dmix_sync_area can lower a semaphore, and, if the thread is canceled while the semaphore is down, then a subsequent call to the sound device (calling snd_pcm_close, for instance) will also lower the semaphore and cause deadlock. Is this a known issue, and is there a way around it other than to always use deferred cancelation when calling these functions? Thanks, -Mike G-

2 1

Re: [alsa-devel] [BUG] New Kernel Bugs
by Neil Brown 15 Nov '07

15 Nov '07

On Tuesday November 13, vda.linux(a)googlemail.com wrote: > On Tuesday 13 November 2007 07:08, Mark Lord wrote: > > Ingo Molnar wrote: > > .. > > > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > > it's just that these sorts of things have been largely ignored for > > > years, in favor of the all-too-easy "open source means many eyeballs and > > > that is our QA" answer, which is a _good_ answer but by far not the most > > > intelligent answer! Today "many eyeballs" is simply not good enough and > > > nature (and other OS projects) will route us around if we dont change. > > > > .. > > > > QA-101 and "many eyeballs" are not at all in opposition. > > The latter is how we find out about bugs on uncommon hardware, > > and the former is what we need to track them and overall quality. > > > > A HUGE problem I have with current "efforts", is that once someone > > reports a bug, the onus seems to be 99% on the *reporter* to find > > the exact line of code or commit. Ghad what a repressive method. > > This is the only method that scales. That sounds overly hash, and the rest of you mail sounds much more moderate and sensible - I can only assume you were using hyperbole?? Putting the "onus on the reporter" is simply not going to work unless you have a business relationship. In the community, we are all volunteering our time (well, maybe my employer is volunteering my time to do community support, but the effect is the same). I would hope that the focus of developers is to empower bug reporters to provide further information (and as has been said, "git bisect" is a great empowerer). Some people will be incredibly help, especially if you ask politely and say thankyou. Others won't for any of a number of reasons - and maybe that means their bug won't get fixed. To my eyes, the "only method that scales" is investing effort in encouraging and training bug reporters. Some of that effort might not produce results, but when others among those you have encouraged start answering the newbee questions on the list and save you the time, you get a distinct feeling that it was all worth while. I think we are in agreement - I just wanted to take issue with that one sentence :-) The rest is great. NeilBrown > > Developer has only 24 hours in each day, and sometimes he needs to eat, > sleep, and maybe even pay attention to e.g. his kids. > > But bug reporters are much more numerous and they have more > hours in one day combined. > > BUT - it means that developers should try to increase user base, > not scare users away. > > > And if the "developer" who broke the damn thing, or who at least > > "claims" to be supporting that code, cannot "reproduce" the bug, > > they drop it completely. > > Developer should let reporter know that reporter needs to help > a bit here. Sometimes a bit of hand holding is needed, but it > pays off because you breed more qualified testers/bug reporters. > > > Contrast that flawed approach with how Linus does things.. > > he thinks through the symptoms, matches them to the code, > > and figures out what the few possibilities might be, > > and feeds back some trial balloon patches for the bug reporter to try. > > > > MUCH better. > > > > And remember, *I'm* an old-time Linux kernel developer.. just think about > > the people reporting bugs who haven't been around here since 1992.. > > Yes. Developers should not grow more and more unhelpful > and arrogant towards their users just because inexperienced > users send incomplete/poorly written bug reports. > They need to provide help, not humiliate/ignore. > > I think we agree here. > -- > vda > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/

1 0

[alsa-devel] params_buffer_size() and params_period_bytes() are returning the same value
by Timur Tabi 14 Nov '07

14 Nov '07

I have an ASOC v1 driver that I'm wrapping up. I've noticed something weird in my hw_params() function. I have this code: size_t buffer_size = params_buffer_size(hw_params); size_t period_size = params_period_bytes(hw_params); printk(KERN_INFO "%s: buffer_size=%x period_size=%x\n", __FUNCTION__, buffer_size, period_size); printk(KERN_INFO "%s: params_periods=%u\n", __FUNCTION__, params_periods(hw_params)); And it produces this output: fsl_dma_hw_params: buffer_size=5dc0 period_size=5dc0 fsl_dma_hw_params: params_periods=4 Why am I getting the same value for buffer_size and period_size? buffer_size should be four times period_size. -- Timur Tabi Linux kernel developer at Freescale

1 1

Re: [alsa-devel] [PATCH] ASoC TLV320AIC3X codec driver
by Vladimir A. Barinov 14 Nov '07

14 Nov '07

Hello Takashi, Thank you for the review. Takashi Iwai wrote: > At Tue, 13 Nov 2007 22:41:25 +0300, > Vladimir Barinov wrote: > >> --- /dev/null >> +++ linux-2.6.24.rc2.alsa/sound/soc/codecs/tlv320aic3x.c >> > (snip) > >> + >> +struct snd_soc_codec_device soc_codec_dev_aic3x; >> > > Do you need this here? It's defined in the later position. > You are right. Thanks for pointing to this. That is an artefact of the driver that I based on. > >> +/* >> + * All input lines are connected when !0xf and disconnected with 0xf bit field, >> > > Please keep the line within 80 chars. Try to run checkpatch.pl in > linuxkernel/scripts for checking such minor coding-style issues. > But this line is less then 80 chars :) I've applied checkpatch.pl before sending the patch. The driver really has 3 lines with 80 chars warning, but they are less then 82 char. It's in the codec interconnection map for DAPM. If that is a strong demand with 80 chars _warning_ then I'll try to rename the mixers/path/endpoint names to match, if not then the code will be more understandable. That lines are: + {"Right HPCOM Mux", "differential of HPROUT", "Right Line2 Bypass Mixer"}, + {"Right HPCOM Mux", "differential of HPLCOM", "Right Line2 Bypass Mixer"}, If I'll split it with 2 lines each then will it be good to watch in accordance with DAPM usage strategy? Destination Widget <=== Path Name <=== Source Widget > >> +static const char *aic3x_left_dac_mux[] = { "DAC_L1", "DAC_L3", "DAC_L2" }; >> +static const char *aic3x_right_dac_mux[] = { "DAC_R1", "DAC_R3", "DAC_R2" }; >> +static const char *aic3x_left_hpcom_mux[] = >> + { "differential of HPLOUT", "constant VCM", "single-ended" }; >> +static const char *aic3x_right_hpcom_mux[] = >> + { "differential of HPROUT", "constant VCM", "single-ended", >> + "differential of HPLCOM", "external feedback" }; >> +static const char *aic3x_linein_mode_mux[] = { "single-ended", "differential" }; >> > > Ditto. > Ditto :) These lines are less then 80 chars. > >> +#define AIC3X_RATES SNDRV_PCM_RATE_8000_96000 >> +#define AIC3X_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \ >> + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) >> > > Are you sure that it's FMTBIT_S24_LE? It's not packed in 3 bytes but > uses lower 3 bytes of 4 bytes frame. > > Aic3x supports 16/20/24/32 bits data word length and in accordance with aic33 documentation the number of clocks per half-frame for each channel are equal to exact number of bits of the word. Unfortunately, now I have no h/w to test 24bits mode. > >> Index: linux-2.6.24.rc2.alsa/sound/soc/codecs/Kconfig >> =================================================================== >> --- linux-2.6.24.rc2.alsa.orig/sound/soc/codecs/Kconfig >> +++ linux-2.6.24.rc2.alsa/sound/soc/codecs/Kconfig >> @@ -37,3 +37,6 @@ config SND_SOC_CS4270_VD33_ERRATA >> bool >> depends on SND_SOC_CS4270 >> >> +config SND_SOC_TLV320AIC3X >> + tristate >> + depends on SND_SOC >> > > Currently, there is a known problem with dependency on I2C over soc > codecs drivers. If CONFIG_I2C=m and CONFIG_SND_SOC_*=y, you'll get > unresolved symbols. > > I don't know how to resolve this issue right now. But, the drivers > that support *only* I2C right now can add "depends on I2C" to its > Kconfig. That doesn't work for CS4270 which may work without I2C as > standalone mode, though. > Ok, will add I2C dependency. Regards, Vladimir

3 4

[alsa-devel] Naming multiple USB devices (solved)
by Giovanni Maruzzelli 14 Nov '07

14 Nov '07

Hi list, I've added the following script to http://alsa.opensrc.org/index.php/Udev (it's not the most elegant solution, but it works for me): BEWARE of the linebreaks, they are mangled by the mail client ================================= #!/usr/bin/perl # fixed persistent naming for multiple usb soundcards # gmaruzz (at) celliax.org # This is to be executed by udev with the following rules: # KERNEL=="controlC[0-9]*", DRIVERS=="usb",PROGRAM="/usr/bin/alsa_name.pl %k", NAME="snd/%c{1}" # KERNEL=="hwC[D0-9]*", DRIVERS=="usb", PROGRAM="/usr/bin/alsa_name.pl %k", NAME="snd/%c{1}" # KERNEL=="midiC[D0-9]*", DRIVERS=="usb",PROGRAM="/usr/bin/alsa_name.pl %k", NAME="snd/%c{1}" # KERNEL=="pcmC[D0-9cp]*", DRIVERS=="usb",PROGRAM="/usr/bin/alsa_name.pl %k", NAME="snd/%c{1}" use strict; use warnings; my $alsaname = $ARGV[0]; #udev called us with this argument (%k) my $physdevpath = $ENV{PHYSDEVPATH}; #udev put this in our environment my $alsanum = "cucu"; #you can find the physdevpath of a device with "udevinfo -a -p $(udevinfo -q path -n /dev/snd/pcmC0D0c)" $physdevpath =~ s/.*\/([^\/]*)/$1/; #eliminate until last slash $physdevpath =~ s/([^:]*):.*/$1/; #eliminate from twopoint (:) to end_of_line if($physdevpath eq "1-5.2") # you can find this value with "dmesg" { $alsanum="11"; #start from "10" (easier for debugging), "0" is for motherboard soundcard, max is "31" } if($physdevpath eq "1-5.3") # you can find this value with "dmesg" { $alsanum="12"; #start from "10" (easier for debugging), "0" is for motherboard soundcard, max is "31" } if($physdevpath eq "1-5.4") # you can find this value with "dmesg" { $alsanum="13"; #start from "10" (easier for debugging), "0" is for motherboard soundcard, max is "31" } if($physdevpath eq "3-2") # you can find this value with "dmesg" { $alsanum="14"; #start from "10" (easier for debugging), "0" is for motherboard soundcard, max is "31" } # other bus positions.... if($alsanum ne "cucu") { $alsaname=~ s/(.*)C([0-9]+)(.*)/$1C$alsanum$3/; } print $alsaname; exit 0; ======================= Ciao, Giovanni On Feb 10, 2007 8:31 PM, Jean-Michel Pouré <jmpoure(a)free.fr> wrote: > Le samedi 10 février 2007 à 18:53 +0100, Ingo Müller a écrit : > > I'm going to play with udev now, too, so if I find something, I'll > > tell > > you. In return, it would be awesome if you could write down - even it > > is > > only short - a howto about how to manage two identical devices, once > > we > > got it working. > > > > Fantastic. > > Thank you very much for your help. > I will add a page on the wiki about udev rules. > > Kind regards, > Jean-Michel > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-devel >

1 0

[alsa-devel] Query regarding snd_pcm_lib_preallocate_pages_for_all()
by Pharaoh . 14 Nov '07

14 Nov '07

Hi, I am trying to use snd_pcm_lib_preallocate_pages_for_all() on an arm based platform for preallocating the DMA buffer. I am using it as snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, NULL, 64 * 1024, 64 * 1024); since I dont know what should be passed as the 3'rd param. I tried passing my device pointer i.e. card->dev after correctly populating it but I get an error as 'DMA coherent mask in not set' and buffer is not allocated. If I pass NULL as shown above, which I think is appropriate, the allocation is done well and I can play some samples too using aplay, but when I do a rmmod all hell breaks free. I am thinking this is corrupting memory some where, since when I preallocate using SNDRV_DMA_TYPE_CONTINUOUS, everything works well but I since I need to mmap the buffer I dont use it. I get following: c001f7e0 c001f7e0 c001f814 c03b3040 0000000b c34c1c98 c34c1c88 1c80: c003642c c0071978 c34c0000 c34c1cb8 c34c1c9c c003b780 c00363fc c34c0000 1ca0: c34c0000 c03b3040 00000001 c34c1cd4 c34c1cbc c003bd94 c003b690 c34c1ce8 1cc0: 60000093 00000001 c34c1ce8 c34c1cd8 c002908c c003bbe8 bf000000 c34c1d08 1ce0: c34c1cec c002b2ac c0028d84 ffffffec c03b3040 c34733c8 c001f7e0 c34c1d40 1d00: c34c1d0c c002b588 c002b250 c03a7060 c34c1d94 00000017 ffffffff c026dd40 1d20: 00000017 c34c1dec 00000004 00000093 40130000 c34c1de8 c34c1d44 c002b688 1d40: c002b3a0 0000007e 00000000 00000000 00000000 00000000 00000000 00000000 1d60: 00000000 c03a7060 c34c1e14 c03b3040 c022eef4 c34c1f14 00000000 00000a00 1d80: c34c1e80 c34c1d90 c019ee84 c01bb390 00000000 7a035438 00000005 00000000 1da0: 00000a00 c03a7060 c0271cdc c34c1d50 00000000 c34c1e08 c34c1dc4 c0063a94 1dc0: c0063984 00000044 ffffffff c34c1e20 00000000 c02eabe0 c347317c c34c1e44 1de0: c34c1dec c00249a0 c002b65c c02eabe0 00000000 00000013 00000093 c34c0000 1e00: c0306200 00000000 c02eabe0 c347317c c001f7e0 40130000 c34c1e44 c02eabe0 1e20: c34c1e34 c02c0bfc c0067478 00000093 ffffffff 10d5f0ff c34c1e7c c34c1e48 1e40: c006d658 c0067444 c3541cc0 00000000 00000002 11b100df 000004c0 c347317c 1e60: c34c0000 00000001 c001f7e0 40130000 c34c1ecc c34c1e80 c006e61c c006d1b8 1e80: c3545000 c001f820 11b100df 0000007e 00000000 00000010 c3545000 00000800 1ea0: c34c0000 ffffffeb c03b3040 c347317c c001f7e0 c001f814 c34c1fb0 40130958 1ec0: c34c1f04 c34c1ed0 c002b470 c006dedc c004822c c03b307c 0000081f ffffffff 1ee0: c026ddc0 0000081f c34c1fb0 40130958 00000055 4012f000 c34c1fac c34c1f08 1f00: c002b688 c002b3a0 c34c1f14 c0222148 c0221a50 c34c1e94 0000000c c34c1e84 1f20: 00000001 00000000 00000000 c1b01040 00000000 00000009 0001d2b4 00000066 1f40: c0024fe4 00000001 c34c1f6c c34c1f58 c01a02c0 c01a01c0 00000000 00000000 1f60: c34c1fa4 c34c1f70 c01a09d0 c01a02b0 c34c1e70 c34c1e74 00000004 0001d2b4 1f80: 00000a00 00000000 0000008e ffffffff 00000115 0001d2dd 00000000 00000000 1fa0: 00000000 c34c1fb0 c0024de8 c002b65c 00000000 0000b05c 54434100 00000001 1fc0: 40130958 00000115 0001d2dd 00000000 00000000 00000055 4012f000 00000007 1fe0: 0001d150 be8ba5ec 0000b05c 40082fbc 60000010 ffffffff 00000000 00000000 Backtrace: [<c0073880>] (page_remove_rmap+0x0/0x118) from [<c006c628>] (unmap_vmas+0x3c4/0x60c) r4 = C02EABE0 [<c006c264>] (unmap_vmas+0x0/0x60c) from [<c00719e8>] (exit_mmap+0x80/0x150) [<c0071968>] (exit_mmap+0x0/0x150) from [<c003642c>] (mmput+0x40/0xe4) r8 = 0000000B r7 = C03B3040 r6 = C001F814 r5 = C001F7E0 r4 = C001F7E0 [<c00363ec>] (mmput+0x0/0xe4) from [<c003b780>] (exit_mm+0x100/0x10c) r4 = C34C0000 [<c003b680>] (exit_mm+0x0/0x10c) from [<c003bd94>] (do_exit+0x1bc/0x9c4) r7 = 00000001 r6 = C03B3040 r5 = C34C0000 r4 = C34C0000 [<c003bbd8>] (do_exit+0x0/0x9c4) from [<c002908c>] (die+0x318/0x36c) [<c0028d74>] (die+0x0/0x36c) from [<c002b2ac>] (__do_kernel_fault+0x6c/0x7c) [<c002b240>] (__do_kernel_fault+0x0/0x7c) from [<c002b588>] (do_page_fault+0x1f8/0x210) r7 = C001F7E0 r6 = C34733C8 r5 = C03B3040 r4 = FFFFFFEC [<c002b390>] (do_page_fault+0x0/0x210) from [<c002b688>] (do_DataAbort+0x3c/0xa0) [<c002b64c>] (do_DataAbort+0x0/0xa0) from [<c00249a0>] (__dabt_svc+0x40/0x60) r8 = C347317C r7 = C02EABE0 r6 = 00000000 r5 = C34C1E20 r4 = FFFFFFFF [<c0067434>] (lru_cache_add_active+0x0/0xa0) from [<c006d658>] (do_wp_page+0x4b0/0x574) r4 = 10D5F0FF [<c006d1a8>] (do_wp_page+0x0/0x574) from [<c006e61c>] (__handle_mm_fault+0x750/0x824) [<c006decc>] (__handle_mm_fault+0x0/0x824) from [<c002b470>] (do_page_fault+0xe0/0x210) [<c002b390>] (do_page_fault+0x0/0x210) from [<c002b688>] (do_DataAbort+0x3c/0xa0) [<c002b64c>] (do_DataAbort+0x0/0xa0) from [<c0024de8>] (ret_from_exception+0x0/0x10) r8 = 00000000 r7 = 00000000 r6 = 0001D2DD r5 = 00000115 r4 = FFFFFFFF Code: e3130901 e1a03004 1594300c e59f008c (e5931004) <1>Fixing recursive fault but reboot is needed! BUG: scheduling while atomic: udevd/0x00000004/245 Bad page state in process 'exe' page:c02eaa60 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaa60 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaa80 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaa80 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaaa0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaaa0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaac0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaac0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaae0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaae0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab00 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab00 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab20 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab20 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab40 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab40 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab60 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab60 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab80 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eab80 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaba0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eaba0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eabc0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Bad page state in process 'exe' page:c02eabc0 flags:0x00004000 mapping:00000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: so on

3 4

Re: [alsa-devel] [Pkg-alsa-devel] Bug#450805: alsa-tools-gui: hdspmixer initializes only first Hammerfall DSP card
by Elimar Riesebieter 14 Nov '07

14 Nov '07

forwarded 450805 alsa-devel(a)alsa-project.org tags 450805 pending patch Thanks Hi ALSA developers, does it make sense to apply the patch to HEAD? I don't have a Hammerfall handy and can not test it. Thanks for cooperation. Elimar On Sun, 11 Nov 2007 the mental interface of Frank Heckenbach told: Package: alsa-tools-gui Version: 1.0.13-1 Severity: normal Tags: patch We are using Hammerfall DSP cards. After booting, their audio output remains silent until hdspmixer is started. No interaction in the GUI of hdspmixer is necessary to unmute the first HDSP card; however, further cards are only unmuted when activating the respective GUI page ("2", "3"). Apparently, hdspmixer does some automatic initialization of the card when activating the page. Since we'd like to have a fully automatic startup, the following patch activates the page for each existing card on startup, thereby initializing them. There are surely more elegant solutions, but this patch is tested and solves the problem for us. --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.h.orig 2007-04-16 19:49:22.000000000 +0200 +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.h 2007-04-16 19:50:51.000000000 +0200 @@ -37,6 +37,7 @@ int card; HDSPMixerWindow *basew; HDSPMixerCardSelector(int x, int y, int w, int h, int card); + void ActivateCard (int i); void draw(); int handle(int e); }; --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.cxx.orig 2007-04-16 19:49:23.000000000 +0200 +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerCardSelector.cxx 2007-04-16 19:53:45.000000000 +0200 @@ -45,27 +45,25 @@ } } +void HDSPMixerCardSelector::ActivateCard (int i) +{ + card = i + 1; + basew->current_card = i; + basew->cards[i]->setMode (basew->cards[i]->getSpeed ()); + redraw (); +} + int HDSPMixerCardSelector::handle(int e) { int xpos = Fl::event_x()-x(); switch (e) { case FL_PUSH: - if (xpos < 13 && card != 1) { - card = 1; - basew->current_card = 0; - basew->cards[0]->setMode(basew->cards[0]->getSpeed()); - redraw(); - } else if (xpos >= 24 && xpos < 37 && card != 2 && basew->cards[1] != NULL) { - card = 2; - basew->current_card = 1; - basew->cards[1]->setMode(basew->cards[1]->getSpeed()); - redraw(); - } else if (xpos >= 48 && card != 3 && basew->cards[2] != NULL) { - card = 3; - basew->current_card = 2; - basew->cards[2]->setMode(basew->cards[2]->getSpeed()); - redraw(); - } + if (xpos < 13 && card != 1) + ActivateCard (0); + else if (xpos >= 24 && xpos < 37 && card != 2 && basew->cards[1] != NULL) + ActivateCard (1); + else if (xpos >= 48 && card != 3 && basew->cards[2] != NULL) + ActivateCard (2); return 1; default: return Fl_Widget::handle(e); --- alsa-tools-1.0.13/hdspmixer/src/HDSPMixerWindow.cxx.orig 2007-04-16 19:41:21.000000000 +0200 +++ alsa-tools-1.0.13/hdspmixer/src/HDSPMixerWindow.cxx 2007-04-16 19:55:13.000000000 +0200 @@ -700,6 +701,9 @@ Fl::atclose = atclose_cb; Fl::add_handler(handler_cb); Fl::add_timeout(0.030, readregisters_cb, this); + i = 0; + while (cards[i] != NULL) + inputs->buttons->cardselector->ActivateCard (i++); } int HDSPMixerWindow::handle(int e) -- Experience is something you don't get until just after you need it!

2 1