[alsa-devel] pcm->private_data is NULL in alsa core!!
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (2)
-
Clemens Ladisch -
Pharaoh .