pcm->private_data is NULL in alsa core!!

pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Hi
I am writing an alsa driver for my omap based board. I am testing it using
cat /dev/audio currently, i.e. I have OSS emulation turned on. This is
an initial round of testing and I will use alsa-libs and utils later.

My problem is:

I have set the pcm->private_data = my_chip after registering the pcm ops,
after referring various standard drivers in alsa tree. My module is
insmoded properly but after I do snd_card_register(card) the
pcm->private_data is corrupted !! Before this step, the
pcm->private_data is intact.  But after looking at the
snd_card_register(), I realized that it doesn't even touch the pcm
pointer.

So, when I cat the device I get huge segfault in
snd_pcm_attach_substream(), since pcm->private_data is NULL but
surprisingly all the other fields are intact in pcm pointer.

 Even the OSS code doesn't touch the pcm pointer, what must be wrong?
I have checked my source atleast 5 times and couldn't find anything in it.

-pharaoh.

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

On 6/16/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> Hi
> I am writing an alsa driver for my omap based board. I am testing it using
> cat /dev/audio currently, i.e. I have OSS emulation turned on. This is
> an initial round of testing and I will use alsa-libs and utils later.
>
> My problem is:
>
> I have set the pcm->private_data = my_chip after registering the pcm ops,
> after referring various standard drivers in alsa tree. My module is
> insmoded properly but after I do snd_card_register(card) the
> pcm->private_data is corrupted !! Before this step, the
> pcm->private_data is intact.  But after looking at the
> snd_card_register(), I realized that it doesn't even touch the pcm
> pointer.
>
> So, when I cat the device I get huge segfault in
> snd_pcm_attach_substream(), since pcm->private_data is NULL but
> surprisingly all the other fields are intact in pcm pointer.
>
>  Even the OSS code doesn't touch the pcm pointer, what must be wrong?
> I have checked my source atleast 5 times and couldn't find anything in it.
>
> -pharaoh.
>



Is the above post visible? I didn't receive it like all the other
mails sent to this list.

Re: pcm->private_data is NULL in alsa core!!

[Clemens Ladisch]

Pharaoh . wrote:
> I have set the pcm->private_data = my_chip after registering the pcm ops,

Should work.

> ... but after I do snd_card_register(card) the pcm->private_data is
> corrupted !!
> 
> I have checked my source atleast 5 times and couldn't find anything in it.

I couldn't find anything either.  Not even your source code.


Regards,
Clemens

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Hi Clemens,
Sorry, I forgot to attach the source files. I am attaching the
corressponding files, the code is still pretty much in development and
messy. One thing

-pharaoh.

On 6/18/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> Pharaoh . wrote:
> > I have set the pcm->private_data = my_chip after registering the pcm ops,
>
> Should work.
>
> > ... but after I do snd_card_register(card) the pcm->private_data is
> > corrupted !!
> >
> > I have checked my source atleast 5 times and couldn't find anything in it.
>
> I couldn't find anything either.  Not even your source code.
>
>
> Regards,
> Clemens
>

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Ignore that one thing in above post, it's accidental.

On 6/18/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> Hi Clemens,
> Sorry, I forgot to attach the source files. I am attaching the
> corressponding files, the code is still pretty much in development and
> messy. One thing
>
> -pharaoh.
>
> On 6/18/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> > Pharaoh . wrote:
> > > I have set the pcm->private_data = my_chip after registering the pcm
> ops,
> >
> > Should work.
> >
> > > ... but after I do snd_card_register(card) the pcm->private_data is
> > > corrupted !!
> > >
> > > I have checked my source atleast 5 times and couldn't find anything in
> it.
> >
> > I couldn't find anything either.  Not even your source code.
> >
> >
> > Regards,
> > Clemens
> >
>

Re: pcm->private_data is NULL in alsa core!!

[Clemens Ladisch]

Pharaoh . wrote:
> > > I have set the pcm->private_data = my_chip after registering the pcm ops,
> > > ... but after I do snd_card_register(card) the pcm->private_data is
> > > corrupted !!

snd_card_omap_alsa_pcm() should be __devinit, and full duplex is implied
when no other XXX_DUPLEX flag is set, but I couldn't find any obvious
errors related to private_data.

Does the changing of private_data really occur in snd_card_register(),
i.e., the output you get is:

| in register codec 4 pvt data is (something)
| in register codec 5 pvt data is 0

And the new value is NULL?

snd_card_register() calls callbacks for all registered devices.  It
could be possible that some callback registered by eac_register_mixer()
does something, but I don't know what this function does.


Regards,
Clemens

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

On 6/19/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> Pharaoh . wrote:
> > > > I have set the pcm->private_data = my_chip after registering the pcm
> ops,
> > > > ... but after I do snd_card_register(card) the pcm->private_data is
> > > > corrupted !!
>
> snd_card_omap_alsa_pcm() should be __devinit, and full duplex is implied
> when no other XXX_DUPLEX flag is set, but I couldn't find any obvious
> errors related to private_data.
>
> Does the changing of private_data really occur in snd_card_register(),
> i.e., the output you get is:
>
> | in register codec 4 pvt data is (something)
> | in register codec 5 pvt data is 0
>
> And the new value is NULL?
>
> snd_card_register() calls callbacks for all registered devices.  It
> could be possible that some callback registered by eac_register_mixer()
> does something, but I don't know what this function does.
>
>
> Regards,
> Clemens
>

Thanks Clemens for pondering over it.

> snd_card_omap_alsa_pcm() should be __devinit, and full duplex is implied
> when no other XXX_DUPLEX flag is set, but I couldn't find any obvious
> errors related to private_data.

I got it.

> Does the changing of private_data really occur in snd_card_register(),
> i.e., the output you get is:
>
> | in register codec 4 pvt data is (something)
> | in register codec 5 pvt data is 0
>
> And the new value is NULL?

I get the following outputs:

in register codec 2 pvt data is c3d81180
in register codec 3 pvt data is c3d81180
in register codec 4 pvt data is c3d81180
Registering the sound card
in register codec 5 pvt data is c3998f20

i.e. after registering the sound card the value changes/gets
corrupted, and c3998f20
is not the value I get everytime, so I am thinking it is corrrupted somehow.

But back in probe, after above function are executed, i.e. after
register codec is over, I get the correct value for
eac->pcm->private_data i.e. c3d81180, but by now the value of
pcm->private_data is corrupted! I am missing something here, I am
sure.

> snd_card_register() calls callbacks for all registered devices.  It
> could be possible that some callback registered by eac_register_mixer()
> does something, but I don't know what this function does.

eac_register_mixer was added later on, so I am sure it doesn't do
anything with pcm.
The error/fault predates the addition of this function and is
reproduced without it too.

When I open the device I get,

# cat /dev/audio
Inside snd_pcm_attach_substream
pcm name is omap alsa pcm   /*This is correct.*/
pcm id is OMAP PCM                /*This is correct.*/
pcm private is 00000000       /*This shouldn't be NULL !!*/
In RECORD
Copying the pvt_data            /* i.e. substream->private_data =
pcm->private_data;*/
pcm is not NULL
pvt data is NULL                   /*This shouldn't be NULL !!*/
Done Copying the pvt_data
Unable to handle kernel paging request at virtual address e5963230

pgd = c3e78000
[e5963230] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in: omap_audio
CPU: 0
PC is at snd_pcm_oss_open+0x338/0x52c
LR is at 0xc39afe14
pc : [<c01808f8>]    lr : [<c39afe14>]    Not tainted
sp : c39afdb4  ip : c008fbcc  fp : c39afe60
r10: c039c4a0  r9 : 00000004  r8 : 0000000d
r7 : c001fc00  r6 : c3dcc980  r5 : c39afe04  r4 : c008fb0c
r3 : 00000000  r2 : 00000000  r1 : e5963014  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F
Table: 13E78000  DAC: 00000015
Process cat (pid: 218, stack limit = 0xc39ae250)
Stack: (0xc39afdb4 to 0xc39b0000)
fda0:                                              c001fce8 00000001 00000004
fdc0: c001fd18 c001fd24 c39ae000 00000001 c38ec198 c008fb0c 00000000 00000000
fde0: c03a2040 c003a8e8 c001fd24 c001fd24 00000000 00000000 00000000 00000000
fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00746163 00726500
fe20: 00000000 00000000 c39afe00 c39afe38 c00892e8 c010cb0c c39ae000 c0267ff0
fe40: 00000003 00000000 00000003 c039c4a0 c0268df0 c39afe90 c39afe64 c0163954
fe60: c01805d0 c38ec198 c39ae000 c3d64a20 c38ec198 00000000 00000001 c39ae000
fe80: c039c4a0 c39afebc c39afe94 c00895cc c016372c 00000004 c00893e8 c039c4a0
fea0: c38ec198 c03542a0 c38f7724 00000001 c39afee4 c39afec0 c0084f50 c00893f8
fec0: c039c4a0 c39aff04 00000003 ffffff9c c0023fe4 c0397000 c39afefc c39afee8
fee0: c00850d8 c0084e1c 00000000 00000000 c39aff68 c39aff00 c0085130 c00850b4
ff00: c39aff04 c38f7724 c03542a0 00000000 00000000 c3e78000 00000101 00000001
ff20: 00000000 c0368a48 c0368a40 ffffffe8 c39ae000 c0397000 c39aff68 c39aff48
ff40: c00852f4 c009d9c0 00000001 00000000 c039c4a0 00000000 000001b6 c39aff94
ff60: c39aff6c c00854f0 c00850fc 000081e4 bed18f95 000e72a0 000cac34 00000005
ff80: c0023fe4 00000000 c39affa4 c39aff98 c00855a4 c00854ac 00000000 c39affa8
ffa0: c0023e40 c0085590 bed18f95 000e72a0 bed18f95 00000000 000001b6 00000000
ffc0: bed18f95 000e72a0 000cac34 00000008 000080c0 000081e4 00000000 bed18e64
ffe0: 00000001 bed18e1c 0004de1c 000704d4 20000010 bed18f95 00000000 00000000
Backtrace:
[<c01805c0>] (snd_pcm_oss_open+0x0/0x52c) from [<c0163954>]
(soundcore_open+0x238/0x3ec)
[<c016371c>] (soundcore_open+0x0/0x3ec) from [<c00895cc>]
(chrdev_open+0x1e4/0x208)
[<c00893e8>] (chrdev_open+0x0/0x208) from [<c0084f50>]
(__dentry_open+0x144/0x298)
[<c0084e0c>] (__dentry_open+0x0/0x298) from [<c00850d8>]
(nameidata_to_filp+0x34/0x48)
[<c00850a4>] (nameidata_to_filp+0x0/0x48) from [<c0085130>]
(do_filp_open+0x44/0x4c)
 r4 = 00000000
[<c00850ec>] (do_filp_open+0x0/0x4c) from [<c00854f0>] (do_sys_open+0x54/0xe4)
 r5 = 000001B6  r4 = 00000000
[<c008549c>] (do_sys_open+0x0/0xe4) from [<c00855a4>] (sys_open+0x24/0x28)
[<c0085580>] (sys_open+0x0/0x28) from [<c0023e40>] (ret_fast_syscall+0x0/0x2c)
Code: e59430a4 e3c33b02 e58430a4 e5941070 (e5d1321c)
 Segmentation fault

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Further debugging revealed the following.

Registering the sound card
In snd_device_register_all

Inside snd_pcm_dev_register
Inside snd_pcm_dev_register, private_data is 00000000   /* Why NULL*/
card registered

card registered
etc.


Now I have a very fundamental question, what I am doing in my driver code is
setting pcm->private_data = my_local_chip_struct, but there is no way the ALSA
core layer knows this, i.e. I am passing the name and id etc while
allocating the pcm
via snd_pcm_new(), but after that when I set  pcm->private_data =
my_local_chip_struct, how  the alsa core will know this? I am not
passing pcm to alsa core after this, right? Am I being too paranoid
witht the entire thing?



On 6/19/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> On 6/19/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> > Pharaoh . wrote:
> > > > > I have set the pcm->private_data = my_chip after registering the pcm
> > ops,
> > > > > ... but after I do snd_card_register(card) the pcm->private_data is
> > > > > corrupted !!
> >
> > snd_card_omap_alsa_pcm() should be __devinit, and full duplex is implied
> > when no other XXX_DUPLEX flag is set, but I couldn't find any obvious
> > errors related to private_data.
> >
> > Does the changing of private_data really occur in snd_card_register(),
> > i.e., the output you get is:
> >
> > | in register codec 4 pvt data is (something)
> > | in register codec 5 pvt data is 0
> >
> > And the new value is NULL?
> >
> > snd_card_register() calls callbacks for all registered devices.  It
> > could be possible that some callback registered by eac_register_mixer()
> > does something, but I don't know what this function does.
> >
> >
> > Regards,
> > Clemens
> >
>
> Thanks Clemens for pondering over it.
>
> > snd_card_omap_alsa_pcm() should be __devinit, and full duplex is implied
> > when no other XXX_DUPLEX flag is set, but I couldn't find any obvious
> > errors related to private_data.
>
> I got it.
>
> > Does the changing of private_data really occur in snd_card_register(),
> > i.e., the output you get is:
> >
> > | in register codec 4 pvt data is (something)
> > | in register codec 5 pvt data is 0
> >
> > And the new value is NULL?
>
> I get the following outputs:
>
> in register codec 2 pvt data is c3d81180
> in register codec 3 pvt data is c3d81180
> in register codec 4 pvt data is c3d81180
> Registering the sound card
> in register codec 5 pvt data is c3998f20
>
> i.e. after registering the sound card the value changes/gets
> corrupted, and c3998f20
> is not the value I get everytime, so I am thinking it is corrrupted somehow.
>
> But back in probe, after above function are executed, i.e. after
> register codec is over, I get the correct value for
> eac->pcm->private_data i.e. c3d81180, but by now the value of
> pcm->private_data is corrupted! I am missing something here, I am
> sure.
>
> > snd_card_register() calls callbacks for all registered devices.  It
> > could be possible that some callback registered by eac_register_mixer()
> > does something, but I don't know what this function does.
>
> eac_register_mixer was added later on, so I am sure it doesn't do
> anything with pcm.
> The error/fault predates the addition of this function and is
> reproduced without it too.
>
> When I open the device I get,
>
> # cat /dev/audio
> Inside snd_pcm_attach_substream
> pcm name is omap alsa pcm   /*This is correct.*/
> pcm id is OMAP PCM                /*This is correct.*/
> pcm private is 00000000       /*This shouldn't be NULL !!*/
> In RECORD
> Copying the pvt_data            /* i.e. substream->private_data =
> pcm->private_data;*/
> pcm is not NULL
> pvt data is NULL                   /*This shouldn't be NULL !!*/
> Done Copying the pvt_data
> Unable to handle kernel paging request at virtual address e5963230
>
> pgd = c3e78000
> [e5963230] *pgd=00000000
> Internal error: Oops: 5 [#1]
> Modules linked in: omap_audio
> CPU: 0
> PC is at snd_pcm_oss_open+0x338/0x52c
> LR is at 0xc39afe14
> pc : [<c01808f8>]    lr : [<c39afe14>]    Not tainted
> sp : c39afdb4  ip : c008fbcc  fp : c39afe60
> r10: c039c4a0  r9 : 00000004  r8 : 0000000d
> r7 : c001fc00  r6 : c3dcc980  r5 : c39afe04  r4 : c008fb0c
> r3 : 00000000  r2 : 00000000  r1 : e5963014  r0 : 00000000
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 5317F
> Table: 13E78000  DAC: 00000015
> Process cat (pid: 218, stack limit = 0xc39ae250)
> Stack: (0xc39afdb4 to 0xc39b0000)
> fda0:                                              c001fce8 00000001
> 00000004
> fdc0: c001fd18 c001fd24 c39ae000 00000001 c38ec198 c008fb0c 00000000
> 00000000
> fde0: c03a2040 c003a8e8 c001fd24 c001fd24 00000000 00000000 00000000
> 00000000
> fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00746163
> 00726500
> fe20: 00000000 00000000 c39afe00 c39afe38 c00892e8 c010cb0c c39ae000
> c0267ff0
> fe40: 00000003 00000000 00000003 c039c4a0 c0268df0 c39afe90 c39afe64
> c0163954
> fe60: c01805d0 c38ec198 c39ae000 c3d64a20 c38ec198 00000000 00000001
> c39ae000
> fe80: c039c4a0 c39afebc c39afe94 c00895cc c016372c 00000004 c00893e8
> c039c4a0
> fea0: c38ec198 c03542a0 c38f7724 00000001 c39afee4 c39afec0 c0084f50
> c00893f8
> fec0: c039c4a0 c39aff04 00000003 ffffff9c c0023fe4 c0397000 c39afefc
> c39afee8
> fee0: c00850d8 c0084e1c 00000000 00000000 c39aff68 c39aff00 c0085130
> c00850b4
> ff00: c39aff04 c38f7724 c03542a0 00000000 00000000 c3e78000 00000101
> 00000001
> ff20: 00000000 c0368a48 c0368a40 ffffffe8 c39ae000 c0397000 c39aff68
> c39aff48
> ff40: c00852f4 c009d9c0 00000001 00000000 c039c4a0 00000000 000001b6
> c39aff94
> ff60: c39aff6c c00854f0 c00850fc 000081e4 bed18f95 000e72a0 000cac34
> 00000005
> ff80: c0023fe4 00000000 c39affa4 c39aff98 c00855a4 c00854ac 00000000
> c39affa8
> ffa0: c0023e40 c0085590 bed18f95 000e72a0 bed18f95 00000000 000001b6
> 00000000
> ffc0: bed18f95 000e72a0 000cac34 00000008 000080c0 000081e4 00000000
> bed18e64
> ffe0: 00000001 bed18e1c 0004de1c 000704d4 20000010 bed18f95 00000000
> 00000000
> Backtrace:
> [<c01805c0>] (snd_pcm_oss_open+0x0/0x52c) from [<c0163954>]
> (soundcore_open+0x238/0x3ec)
> [<c016371c>] (soundcore_open+0x0/0x3ec) from [<c00895cc>]
> (chrdev_open+0x1e4/0x208)
> [<c00893e8>] (chrdev_open+0x0/0x208) from [<c0084f50>]
> (__dentry_open+0x144/0x298)
> [<c0084e0c>] (__dentry_open+0x0/0x298) from [<c00850d8>]
> (nameidata_to_filp+0x34/0x48)
> [<c00850a4>] (nameidata_to_filp+0x0/0x48) from [<c0085130>]
> (do_filp_open+0x44/0x4c)
>  r4 = 00000000
> [<c00850ec>] (do_filp_open+0x0/0x4c) from [<c00854f0>]
> (do_sys_open+0x54/0xe4)
>  r5 = 000001B6  r4 = 00000000
> [<c008549c>] (do_sys_open+0x0/0xe4) from [<c00855a4>] (sys_open+0x24/0x28)
> [<c0085580>] (sys_open+0x0/0x28) from [<c0023e40>]
> (ret_fast_syscall+0x0/0x2c)
> Code: e59430a4 e3c33b02 e58430a4 e5941070 (e5d1321c)
>  Segmentation fault
>

Re: pcm->private_data is NULL in alsa core!!

[Clemens Ladisch]

Pharaoh . wrote:
> in register codec 4 pvt data is c3d81180
> Registering the sound card
> in register codec 5 pvt data is c3998f20
> 
> i.e. after registering the sound card the value changes/gets
> corrupted, and c3998f20
> is not the value I get everytime, so I am thinking it is corrrupted somehow.

I'd guess the memory gets overwritten.

> But back in probe, after above function are executed, i.e. after
> register codec is over, I get the correct value for
> eac->pcm->private_data i.e. c3d81180, but by now the value of
> pcm->private_data is corrupted!

This implies that eac->pcm != pcm.

It seems quite a lot of memory gets corrupted.
Try to check which one of the various "eac" and "pcm" pointers changes
its value.


HTH
Clemens

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

I think I have fixed the problem, atleast the value of
pcm->private_data doesn't get currupted anymore...After enabling
kernel debugging for semaphores/mutexes, I realised that code was
sleeping in a place where it was not supposed to. I dont know/didn't
check where exactly the memory was getting corrupted but after doing
appropriate lock/unlock the pcm->private_data seems looks healthy.

But now when I do cat /dev/audio/ the machine just hangs!! Looking in to it.

Clemens, I was holding mutexes in register_codec(), there it was
corrupting. Thanks for help.

-pharaoh.

On 6/19/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> Pharaoh . wrote:
> > in register codec 4 pvt data is c3d81180
> > Registering the sound card
> > in register codec 5 pvt data is c3998f20
> >
> > i.e. after registering the sound card the value changes/gets
> > corrupted, and c3998f20
> > is not the value I get everytime, so I am thinking it is corrrupted
> somehow.
>
> I'd guess the memory gets overwritten.
>
> > But back in probe, after above function are executed, i.e. after
> > register codec is over, I get the correct value for
> > eac->pcm->private_data i.e. c3d81180, but by now the value of
> > pcm->private_data is corrupted!
>
> This implies that eac->pcm != pcm.
>
> It seems quite a lot of memory gets corrupted.
> Try to check which one of the various "eac" and "pcm" pointers changes
> its value.
>
>
> HTH
> Clemens
>

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

On 6/20/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> I think I have fixed the problem, atleast the value of
> pcm->private_data doesn't get currupted anymore...After enabling
> kernel debugging for semaphores/mutexes, I realised that code was
> sleeping in a place where it was not supposed to. I dont know/didn't
> check where exactly the memory was getting corrupted but after doing
> appropriate lock/unlock the pcm->private_data seems looks healthy.
>
> But now when I do cat /dev/audio/ the machine just hangs!! Looking in to it.
>
> Clemens, I was holding mutexes in register_codec(), there it was
> corrupting. Thanks for help.
>
> -pharaoh.
>
> On 6/19/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> > Pharaoh . wrote:
> > > in register codec 4 pvt data is c3d81180
> > > Registering the sound card
> > > in register codec 5 pvt data is c3998f20
> > >
> > > i.e. after registering the sound card the value changes/gets
> > > corrupted, and c3998f20
> > > is not the value I get everytime, so I am thinking it is corrrupted
> > somehow.
> >
> > I'd guess the memory gets overwritten.
> >
> > > But back in probe, after above function are executed, i.e. after
> > > register codec is over, I get the correct value for
> > > eac->pcm->private_data i.e. c3d81180, but by now the value of
> > > pcm->private_data is corrupted!
> >
> > This implies that eac->pcm != pcm.
> >
> > It seems quite a lot of memory gets corrupted.
> > Try to check which one of the various "eac" and "pcm" pointers changes
> > its value.
> >
> >
> > HTH
> > Clemens
> >
>

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

The problem still persists!! I get the following:

While insmoding :

.....................
Registering the sound card
pcm->private in snd_device_register_all is c1d7d310 //correct
Inside snd_pcm_dev_register, pcm is c1f05d44(correct), pcm->pvt_data
is 00000000(This shouldn't be NULL)
In snd_device_register, eac is c1d7d310 //correct
In snd_device_register, eac is c1d7d310
......................



# cat a.sh > dev/audio
pcm name is omap  alsa pcm
pcm id is OMAP PCM
pcm private is 00000000
PLAYBACK
Unable to handle kernel paging request at virtual address e591321c
pgd = c1fb4000
[e591321c] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in: omap_audio
CPU: 0
PC is at snd_pcm_oss_open+0x374/0x578
LR is at 0xc1f23e00
pc : [<c0192e14>]    lr : [<c1f23e00>]    Not tainted
sp : c1f23db4  ip : c0118cd0  fp : c1f23e60
r10: c1f22000  r9 : 00000004  r8 : c0118c10
r7 : 00000000  r6 : c199e1c8  r5 : c1f05df4  r4 : c1f23df0
r3 : 00000000  r2 : 00000000  r1 : e5913000  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F
Table: 11FB4000  DAC: 00000015
Process sh (pid: 209, stack limit = 0xc1f22250)
Stack: (0xc1f23db4 to 0xc1f24000)
3da0:                                              c1f05e8c c1f05e74 0000000e
3dc0: 00000000 00000001 c1f05d44 c0374e3c c18e834c c0118c10 00000000 00000000
3de0: c0370580 c003c1f4 c1f05e8c c1f05e8c 00000000 00000000 00000000 00000000
3e00: 00000000 00000000 00000000 00000000 00000000 00000000 74006873 00726500
3e20: 00000000 00000000 c022d400 c005d088 c1d67b68 00000000 c028220c c1f22000
3e40: 00000000 00000003 c028306c c18e834c c0374e3c c1f23e90 c1f23e64 c0174cc0
3e60: c0192ab0 00000001 c1f22000 c1d37f08 c18e834c 00000000 00000001 c1f22000
3e80: c0374e3c c1f23ebc c1f23e94 c009145c c0174a2c 00000004 c0374e3c c18e834c
3ea0: c00912c0 c1e5feec c032a280 00000001 c1f23ee4 c1f23ec0 c008cb78 c00912d0
3ec0: c0374e3c c1f23f04 00000003 ffffff9c c0025024 c1955000 c1f23efc c1f23ee8
3ee0: c008ccbc c008c9c4 00000000 00000241 c1f23f68 c1f23f00 c008cd20 c008cc98
3f00: c1f23f04 c1e5feec c032a280 10bc8063 00000005 c1955004 00000300 00000000
3f20: 00000000 c033913c c1f22000 ffffffe8 c1f22000 c1955000 c1f23f68 c1f23f48
3f40: c008ceb8 c00a65dc 00000242 000001b6 c0374e3c 00000241 000001b6 c1f23f94
3f60: c1f23f6c c008d118 c008cce4 0003fe80 ffffffff 000ddd9c 000ddd24 00000005
3f80: c0025024 000e7460 c1f23fa4 c1f23f98 c008d1cc c008d0cc 00000000 c1f23fa8
3fa0: c0024e80 c008d1b8 ffffffff 000ddd9c 000ddd9c 00000241 000001b6 00000000
3fc0: ffffffff 000ddd9c 000ddd24 bed0ed24 bed0ed7c 00000003 000e7460 000ddd8c
3fe0: 00000fe0 bed0eb58 0002cdac 000704d4 60000010 000ddd9c 00000000 00000000
Backtrace:
[<c0192aa0>] (snd_pcm_oss_open+0x0/0x578) from [<c0174cc0>]
(soundcore_open+0x2a4/0x408)
[<c0174a1c>] (soundcore_open+0x0/0x408) from [<c009145c>]
(chrdev_open+0x19c/0x218)
[<c00912c0>] (chrdev_open+0x0/0x218) from [<c008cb78>]
(__dentry_open+0x1c4/0x2d4)
[<c008c9b4>] (__dentry_open+0x0/0x2d4) from [<c008ccbc>]
(nameidata_to_filp+0x34/0x4c)
[<c008cc88>] (nameidata_to_filp+0x0/0x4c) from [<c008cd20>]
(do_filp_open+0x4c/0x50)
 r4 = 00000241
[<c008ccd4>] (do_filp_open+0x0/0x50) from [<c008d118>] (do_sys_open+0x5c/0xec)
 r5 = 000001B6  r4 = 00000241
[<c008d0bc>] (do_sys_open+0x0/0xec) from [<c008d1cc>] (sys_open+0x24/0x28)
[<c008d1a8>] (sys_open+0x0/0x28) from [<c0024e80>] (ret_fast_syscall+0x0/0x2c)
Code: e59830a4 e3c33b02 e58830a4 e5981070 (e5d1321c)

On 6/20/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> On 6/20/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> > I think I have fixed the problem, atleast the value of
> > pcm->private_data doesn't get currupted anymore...After enabling
> > kernel debugging for semaphores/mutexes, I realised that code was
> > sleeping in a place where it was not supposed to. I dont know/didn't
> > check where exactly the memory was getting corrupted but after doing
> > appropriate lock/unlock the pcm->private_data seems looks healthy.
> >
> > But now when I do cat /dev/audio/ the machine just hangs!! Looking in to
> it.
> >
> > Clemens, I was holding mutexes in register_codec(), there it was
> > corrupting. Thanks for help.
> >
> > -pharaoh.
> >
> > On 6/19/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> > > Pharaoh . wrote:
> > > > in register codec 4 pvt data is c3d81180
> > > > Registering the sound card
> > > > in register codec 5 pvt data is c3998f20
> > > >
> > > > i.e. after registering the sound card the value changes/gets
> > > > corrupted, and c3998f20
> > > > is not the value I get everytime, so I am thinking it is corrrupted
> > > somehow.
> > >
> > > I'd guess the memory gets overwritten.
> > >
> > > > But back in probe, after above function are executed, i.e. after
> > > > register codec is over, I get the correct value for
> > > > eac->pcm->private_data i.e. c3d81180, but by now the value of
> > > > pcm->private_data is corrupted!
> > >
> > > This implies that eac->pcm != pcm.
> > >
> > > It seems quite a lot of memory gets corrupted.
> > > Try to check which one of the various "eac" and "pcm" pointers changes
> > > its value.
> > >
> > >
> > > HTH
> > > Clemens
> > >
> >
>

Re: pcm->private_data is NULL in alsa core!!

[Clemens Ladisch]

Pharaoh . wrote:
> Registering the sound card
> pcm->private in snd_device_register_all is c1d7d310 //correct
> Inside snd_pcm_dev_register, pcm is c1f05d44(correct), pcm->pvt_data
> is 00000000(This shouldn't be NULL)

Does the value of pcm itself change?
Do other fields in pcm change?


Regards,
Clemens

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Value of pcm pointer doesn't change. Other fields which are populated
by me do not change except private_data.

The following shows it:

# cat a.sh > dev/audio
pcm name is omap  alsa pcm //Intact
pcm id is OMAP PCM               //Intact
pcm private is 00000000       //Only this changes

On 6/20/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> Pharaoh . wrote:
> > Registering the sound card
> > pcm->private in snd_device_register_all is c1d7d310 //correct
> > Inside snd_pcm_dev_register, pcm is c1f05d44(correct), pcm->pvt_data
> > is 00000000(This shouldn't be NULL)
>
> Does the value of pcm itself change?
> Do other fields in pcm change?
>
>
> Regards,
> Clemens
>

Re: pcm->private_data is NULL in alsa core!!

[Pharaoh .]

Problem solved guys...many misc things were wrong..after fixing them
it worked. Thank you all.

On 6/20/07, Pharaoh . <pharaoh137@gmail.com> wrote:
> Value of pcm pointer doesn't change. Other fields which are populated
> by me do not change except private_data.
>
> The following shows it:
>
> # cat a.sh > dev/audio
> pcm name is omap  alsa pcm //Intact
> pcm id is OMAP PCM               //Intact
> pcm private is 00000000       //Only this changes
>
> On 6/20/07, Clemens Ladisch <cladisch@fastmail.net> wrote:
> > Pharaoh . wrote:
> > > Registering the sound card
> > > pcm->private in snd_device_register_all is c1d7d310 //correct
> > > Inside snd_pcm_dev_register, pcm is c1f05d44(correct), pcm->pvt_data
> > > is 00000000(This shouldn't be NULL)
> >
> > Does the value of pcm itself change?
> > Do other fields in pcm change?
> >
> >
> > Regards,
> > Clemens
> >
>