> When I attempt to play any mp3's on my N800 running the latest
> OS I get
>
> [ 7884.390808] omapdsp: tadd address is ABORTADR.
> [ 7884.390899] omapdsp: task attach failed for mp3dec!
> [ 7886.147644] omapdsp: tadd address is ABORTADR.
> [ 7886.147735] omapdsp: task attach failed for mp3dec!
> [ 7888.402557] omapdsp: tadd address is ABORTADR.
> [ 7888.402618] omapdsp: task attach failed for mp3dec!
> [ 7890.338684] omapdsp: tadd address is ABORTADR.
> [ 7890.338775] omapdsp: task attach failed for mp3dec!
> [ 7890.494537] EAC mode: play disabled, rec disabled
> [ 7890.588256] EAC mode: play enabled, rec enabled
> [ 7892.154693] omapdsp: tadd address is ABORTADR.
> [ 7892.154754] omapdsp: task attach failed for mp3dec!
> [ 7894.137054] omapdsp: tadd address is ABORTADR.
> [ 7894.137145] omapdsp: task attach failed for mp3dec!
>
> I can play mpeg video/audio clips. Just mp3's seem to be
> hated. A fresh power cycle does not help.
>
> The other sorts of audio type things the N800 does work
> as expected.
Interesting. Can you play pcm (wav) data (or anything else that uses
the DSP)? When you say you can play MPEG video/audio do you mean you
can play mp2 files or videos with audio (not sure if this uses the DSP
for the audio)?
I've looked at the dspgateway/kernel code related to this, and the
message is produced in plat-omap/dsp/task.c, what I can't work out is
where this value might be set. The code looks like this:
if (adr == TADD_ABORTADR) {
/* aborting tadd intentionally */
printk(KERN_INFO "omapdsp: tadd address is ABORTADR.\n");
goto fail_out;
}
The definition of TADD_ABORTADR is in dsp.h, but I can't find any code
that sets adr to this value (I've not searched for the hex value,
0xffffffff, just the DEFINE'd name).
The value adr is of type dsp_long_t. This is defined in
plat-omap/dsp/dsp_common.h like so:
extern dsp_long_t dspmem_base, dspmem_size,
daram_base, daram_size,
saram_base, saram_size;
dsp_tadd_minor() calls dsp_tadd() where the error message is generated.
I've no idea where dsp_tadd_minor() is called from, it doesn't appear
to be from anywhere in the kernel source at least. You'll need to find
this to track down the problem.
It's curious that this memory information is passed for every new task,
unless it's task dependent, in which case you might try looking at the
.cmd file in /lib/dsp/modules/ to see if there's something in there
causing a problem. The other one to try is the kernel configuration
file (in /lib/dsp/avs_kernelcfg.cmd iirc). These are just guesses based
on the variable names though.
That probably hasn't helped much, but it might give you an idea of
where to start looking. Anyone else have any insight?
Simon
