[alsa-devel] pcm->private_data is NULL in alsa core!!
Pharaoh .
pharaoh137 at gmail.com
Tue Jun 19 14:17:03 CEST 2007
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 at gmail.com> wrote:
> On 6/19/07, Clemens Ladisch <cladisch at 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
>
More information about the Alsa-devel
mailing list