Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Op 20 sep 2008, om 13:53 heeft Arun KS het volgende geschreven: I've been testing these patches along with my Overo patches on the current l-o head. Audio is working fine, so the mcbsp changes haven't broken anything. Is the null substream pointer was the problem in the alsa-lib? We suspect it's in alsa-lib Is it fixed? Sadly not :( I saw ASOC patches for overo and beagle board. Any clue how they are testing the audio driver. I use mplayer or aplay to test it, IIRC steve uses something similar. regards, Koen PGP.sig Description: This is a digitally signed message part
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Sat, Sep 20, 2008 at 5:11 PM, Koen Kooi <[EMAIL PROTECTED]> wrote: > > Op 20 sep 2008, om 13:22 heeft Arun KS het volgende geschreven: > >> On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <[EMAIL PROTECTED]> wrote: >>> >>> On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: * Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: > > Here are two patches adding support for OMAP2430 in McBSP driver and > adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. > > These are generated from top of currect l-o head but they apply also on > top of Hiroshi's virtual clock patches with some offsets. > > If you have change to try them out on those CPUs, I would be happy to > hear. I've tested these only on N810. Second patch will naturally go > through the alsa-devel when we have necessary McBSP patches upstream. Can you please refresh these against the current l-o head? >>> >>> I've been testing these patches along with my Overo patches on the >>> current l-o head. Audio is working fine, so the mcbsp changes haven't >>> broken anything. >> >> Is the null substream pointer was the problem in the alsa-lib? > > We suspect it's in alsa-lib > >> Is it fixed? > > Sadly not :( I saw ASOC patches for over and beagle board. Any clue how they are testing the audio dirver. Regards, Arun > > regards, > > Koen >> >> I am facing similar issue when using 5912 osk with tlvaic23b codec. >> >> Regards, >> Arun >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Op 20 sep 2008, om 13:22 heeft Arun KS het volgende geschreven: On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <[EMAIL PROTECTED]> wrote: On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: * Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: Here are two patches adding support for OMAP2430 in McBSP driver and adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. These are generated from top of currect l-o head but they apply also on top of Hiroshi's virtual clock patches with some offsets. If you have change to try them out on those CPUs, I would be happy to hear. I've tested these only on N810. Second patch will naturally go through the alsa-devel when we have necessary McBSP patches upstream. Can you please refresh these against the current l-o head? I've been testing these patches along with my Overo patches on the current l-o head. Audio is working fine, so the mcbsp changes haven't broken anything. Is the null substream pointer was the problem in the alsa-lib? We suspect it's in alsa-lib Is it fixed? Sadly not :( regards, Koen I am facing similar issue when using 5912 osk with tlvaic23b codec. Regards, Arun -- To unsubscribe from this list: send the line "unsubscribe linux- omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html PGP.sig Description: This is a digitally signed message part
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <[EMAIL PROTECTED]> wrote: > On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: >> * Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: >>> Here are two patches adding support for OMAP2430 in McBSP driver and >>> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. >>> >>> These are generated from top of currect l-o head but they apply also on >>> top of Hiroshi's virtual clock patches with some offsets. >>> >>> If you have change to try them out on those CPUs, I would be happy to >>> hear. I've tested these only on N810. Second patch will naturally go >>> through the alsa-devel when we have necessary McBSP patches upstream. >> >> Can you please refresh these against the current l-o head? > > I've been testing these patches along with my Overo patches on the > current l-o head. Audio is working fine, so the mcbsp changes haven't > broken anything. Is the null substream pointer was the problem in the alsa-lib? Is it fixed? I am facing similar issue when using 5912 osk with tlvaic23b codec. Regards, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
* Steve Sakoman <[EMAIL PROTECTED]> [080905 10:24]: > > At least the first patch needs to be updated for phys_pbase instead of > > virt_base. > > Yes it does, mcbsp is likely still working by the same accident of fate. > > > Hmm, is the musb broken now? > > It is on Overo if I base my patches against current top of tree > (a376251519ced5831ed07ed234430725230ed93a) > > Doesn't crash, just quietly doesn't work. I hear from Beagle folk > that musb doesn't work there either. I have it configured as a host > port, and IIRC so do the Beagle folks > > If I base my patches against the state of the tree just prior to the > move to rc5 (81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d), musb works as > well as it ever has. Well with -rc5 we switched to the drivers/usb/musb code from mainline kernel. Maybe try to diff musb code with: $ git-diff 81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d.. drivers/usb/musb And see if there are any clues? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> At least the first patch needs to be updated for phys_pbase instead of > virt_base. Yes it does, mcbsp is likely still working by the same accident of fate. > Hmm, is the musb broken now? It is on Overo if I base my patches against current top of tree (a376251519ced5831ed07ed234430725230ed93a) Doesn't crash, just quietly doesn't work. I hear from Beagle folk that musb doesn't work there either. I have it configured as a host port, and IIRC so do the Beagle folks If I base my patches against the state of the tree just prior to the move to rc5 (81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d), musb works as well as it ever has. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
* Steve Sakoman <[EMAIL PROTECTED]> [080904 23:36]: > On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: > > * Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: > >> Here are two patches adding support for OMAP2430 in McBSP driver and > >> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. > >> > >> These are generated from top of currect l-o head but they apply also on > >> top of Hiroshi's virtual clock patches with some offsets. > >> > >> If you have change to try them out on those CPUs, I would be happy to > >> hear. I've tested these only on N810. Second patch will naturally go > >> through the alsa-devel when we have necessary McBSP patches upstream. > > > > Can you please refresh these against the current l-o head? > > I've been testing these patches along with my Overo patches on the > current l-o head. Audio is working fine, so the mcbsp changes haven't > broken anything. At least the first patch needs to be updated for phys_pbase instead of virt_base. > I do miss having functional USB though :-) Hmm, is the musb broken now? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: > * Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: >> Here are two patches adding support for OMAP2430 in McBSP driver and >> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. >> >> These are generated from top of currect l-o head but they apply also on >> top of Hiroshi's virtual clock patches with some offsets. >> >> If you have change to try them out on those CPUs, I would be happy to >> hear. I've tested these only on N810. Second patch will naturally go >> through the alsa-devel when we have necessary McBSP patches upstream. > > Can you please refresh these against the current l-o head? I've been testing these patches along with my Overo patches on the current l-o head. Audio is working fine, so the mcbsp changes haven't broken anything. I do miss having functional USB though :-) Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
* Jarkko Nikula <[EMAIL PROTECTED]> [080821 04:58]: > Here are two patches adding support for OMAP2430 in McBSP driver and > adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. > > These are generated from top of currect l-o head but they apply also on > top of Hiroshi's virtual clock patches with some offsets. > > If you have change to try them out on those CPUs, I would be happy to > hear. I've tested these only on N810. Second patch will naturally go > through the alsa-devel when we have necessary McBSP patches upstream. Can you please refresh these against the current l-o head? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Wed, 27 Aug 2008 13:57:36 -0700 "ext Steve Sakoman" <[EMAIL PROTECTED]> wrote: > So substream goes null sometime after the SNDRV_PCM_IOCTL_START but > before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are > generated by the following code in alsa-lib's > snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c: > It's also worth to check are there other fields than substream which get zeroed in pcm_file structure. I don't know does it help but worth to check probably. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> could you try removing /etc/asound.conf, it is set to dmix by default, > which might screw things up. Sadly, no effect. Same crash. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Op 27 aug 2008, om 22:57 heeft Steve Sakoman het volgende geschreven:
Hope to get back to it later today if I can finish bringing up the
new hw.
Had a few moments to look at this while waiting for a build.
This set of ioctl's are called at the failure point:
SNDRV_PCM_IOCTL_START:snd_pcm_common_ioctl1 2550 substream c7bdb900
SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream
Unable to handle kernel NULL pointer dereference at virtual address
So substream goes null sometime after the SNDRV_PCM_IOCTL_START but
before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are
generated by the following code in alsa-lib's
snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c:
ret = snd_pcm_start(spcm); <=== THIS ROUTINE GENERATES A
SNDRV_PCM_IOCTL_START IOCTL
if (ret < 0) {
SNDERR("unable to start PCM stream");
return ret;
}
if (snd_pcm_poll_descriptors_count(spcm) != 1) {
SNDERR("unable to use hardware pcm with fd more than one!!!");
return ret;
}
snd_pcm_poll_descriptors(spcm, &fd, 1);
dmix->hw_fd = fd.fd;
save_slave_setting(dmix, spcm);
/* Currently, we assume that each dmix client has the same
* hw_params setting.
* If the arbitrary hw_parmas is supported in future,
* boundary has to be taken from the slave config but
* recalculated for the native boundary size (for 32bit
* emulation on 64bit arch).
*/
dmix->slave_buffer_size = spcm->buffer_size;
dmix->slave_period_size = spcm->period_size;
dmix->slave_boundary = spcm->boundary;
spcm->donot_close = 1;
{
int ver = 0;
ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver); <===
THIS IS
THE FIRST POINT OF NULL SUBSTREAM
if (ver < SNDRV_PROTOCOL_VERSION(2, 0, 8))
dmix->shmptr->use_server = 1;
}
So this seems to narrow the area to search quite considerably! Back
to hw bringup . . .
could you try removing /etc/asound.conf, it is set to dmix by
default, which might screw things up.
regards,
Koen
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-
omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PGP.sig
Description: This is a digitally signed message part
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> Hope to get back to it later today if I can finish bringing up the new hw.
Had a few moments to look at this while waiting for a build.
This set of ioctl's are called at the failure point:
SNDRV_PCM_IOCTL_START:snd_pcm_common_ioctl1 2550 substream c7bdb900
SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream
Unable to handle kernel NULL pointer dereference at virtual address
So substream goes null sometime after the SNDRV_PCM_IOCTL_START but
before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are
generated by the following code in alsa-lib's
snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c:
ret = snd_pcm_start(spcm); <=== THIS ROUTINE GENERATES A
SNDRV_PCM_IOCTL_START IOCTL
if (ret < 0) {
SNDERR("unable to start PCM stream");
return ret;
}
if (snd_pcm_poll_descriptors_count(spcm) != 1) {
SNDERR("unable to use hardware pcm with fd more than one!!!");
return ret;
}
snd_pcm_poll_descriptors(spcm, &fd, 1);
dmix->hw_fd = fd.fd;
save_slave_setting(dmix, spcm);
/* Currently, we assume that each dmix client has the same
* hw_params setting.
* If the arbitrary hw_parmas is supported in future,
* boundary has to be taken from the slave config but
* recalculated for the native boundary size (for 32bit
* emulation on 64bit arch).
*/
dmix->slave_buffer_size = spcm->buffer_size;
dmix->slave_period_size = spcm->period_size;
dmix->slave_boundary = spcm->boundary;
spcm->donot_close = 1;
{
int ver = 0;
ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver); <===
THIS IS
THE FIRST POINT OF NULL SUBSTREAM
if (ver < SNDRV_PROTOCOL_VERSION(2, 0, 8))
dmix->shmptr->use_server = 1;
}
So this seems to narrow the area to search quite considerably! Back
to hw bringup . . .
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> One thing came to my mind that does your kernel and user space (E)ABI > match? I rememeber that there were some strange IOCTL related errors > with ALSA mixers if the kernel was compiled with CONFIG_EABI and > CONFIG_OABI_COMPAT but Debian was using legacy ABI. Both kernel and user space are EABI. I received some new hw to bring up yesterday, so I wasn't able to get much further on debugging this. But I did verify that running 'mplayer song.mp3' first before using 'mplayer -ao alsa song.mp3' resulted in an ioctl trace where substream did *not* go NULL after the START ioctl. Very strange! Hope to get back to it later today if I can finish bringing up the new hw. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Tue, 26 Aug 2008 10:18:56 -0700 "ext Steve Sakoman" <[EMAIL PROTECTED]> wrote: > > Sounds indeed strange. Can you track is the pcm_file->substream > > getting zeroed somewhere after it is set in snd_pcm_open_file? Like > > printing both address of pcm_file and pcm_file->substream. > > I don't believe that it is the SNDRV_PCM_IOCTL_START that writes a > null in substream, so it is likely something in alsa-lib :-( > One thing came to my mind that does your kernel and user space (E)ABI match? I rememeber that there were some strange IOCTL related errors with ALSA mixers if the kernel was compiled with CONFIG_EABI and CONFIG_OABI_COMPAT but Debian was using legacy ABI. > It isn't confidence inspiring to see comments like /* AB: FIXME!!! > This is definitely nonsense */ in snd_pcm_info (the function where it > finally crashes) > Heh, that's true. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> Sounds indeed strange. Can you track is the pcm_file->substream getting > zeroed somewhere after it is set in snd_pcm_open_file? Like printing > both address of pcm_file and pcm_file->substream. I added a bunch of tracking to the ioctl handling in pcm_native.c to see where the substream pointer goes null. It appears that substream is valid through the SNDRV_PCM_IOCTL_START ioctl call, and then goes null for SNDRV_PCM_IOCTL_PVERSION and SNDRV_PCM_IOCTL_INFO where it finally crashes. I don't believe that it is the SNDRV_PCM_IOCTL_START that writes a null in substream, so it is likely something in alsa-lib :-( It isn't confidence inspiring to see comments like /* AB: FIXME!!! This is definitely nonsense */ in snd_pcm_info (the function where it finally crashes) Steve [EMAIL PROTECTED]:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3 MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team CPU: ARM Playing /Watermelon_Slim-Black_Water.mp3. Audio file file format detected. Clip info: Title: Black Water Artist: Watermelon Slim Album: http://music.download.com Year: 2007 Comment: http://music.download.com/ Track: 1 Genre: Unknown == Forced audio codec: mad Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == snd_pcm_open_file 2102 substream c7bdb900 success: snd_pcm_open 2168 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_TSTAMP:snd_pcm_common_ioctl1 2520 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_HW_PARAMS:snd_pcm_common_ioctl1 2529 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_SW_PARAMS:snd_pcm_common_ioctl1 2535 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_CHANNEL_INFO:snd_pcm_common_ioctl1 2541 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_CHANNEL_INFO:snd_pcm_common_ioctl1 2541 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_PREPARE:snd_pcm_common_ioctl1 2544 substream c7bdb900 OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682 substream c7bdb900 SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900 OTHER (passing to sn
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> Sounds indeed strange. Can you track is the pcm_file->substream getting > zeroed somewhere after it is set in snd_pcm_open_file? Like printing > both address of pcm_file and pcm_file->substream. > > I don't know, can we still have some instabilities with OMAP3 and > latest 2.6.27-rcx? That is my suspicion also. I have tracked things through the exit of snd_pcm_open_file and found the substream pointer to be valid to that point. The null substream pointer seems to be coming in to a snd_pcm_playback_ioctl call that occurs after the file open (I suspect from a call to snd_pcm_hw_info in alsa-lib) Looks like I need to start adding debug printf's in alsa-lib too. I'm working on this as a background task while bringing up some new hw so progress is a bit slow :-( Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, 25 Aug 2008 12:19:16 -0700 "ext Steve Sakoman" <[EMAIL PROTECTED]> wrote: > If I run 'mplayer -ao alsa song.mp3' immediately after booting I get a > crash due to a null substream pointer (output below). > > However if I run 'mplayer song.mp3' *before* 'mplayer -ao alsa > song.mp3' then the latter command works! > Sounds indeed strange. Can you track is the pcm_file->substream getting zeroed somewhere after it is set in snd_pcm_open_file? Like printing both address of pcm_file and pcm_file->substream. I don't know, can we still have some instabilities with OMAP3 and latest 2.6.27-rcx? Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, Aug 25, 2008 at 04:34:40PM -0700, Steve Sakoman wrote: > > can you also apply this other patch: > > > > diff --git a/sound/core/pcm.c b/sound/core/pcm.c > > That patch didn't seem to have an effect, pretty much the same crash: Hmm... so more investigation is needed but now is already too late for me, it's past 3am :-p If Jarkko doesn't get a fix before me (I'm pretty sure he will :-p) I'll try to dig more when I wake up. But the problems seems to be on the file open() path. Try to track down the use of struct snd_pcm_substream, starting at pcm_native.c:snd_pcm_open_file(). Put some printks around that function and see when substream is getting nulled. Something like: printk(KERN_INFO "%s %d substream %p\n", __func__, __LINE__, substream); And go down the functional calls following the ones that have a struct snd_pcm_substream as argument. That will probably allow you to see where substream is getting NULLed and try to guess a fix for that. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> can you also apply this other patch: > > diff --git a/sound/core/pcm.c b/sound/core/pcm.c That patch didn't seem to have an effect, pretty much the same crash: [EMAIL PROTECTED]:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3 MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team CPU: ARM Playing /Watermelon_Slim-Black_Water.mp3. Audio file file format detected. Clip info: Title: Black Water Artist: Watermelon Slim Album: http://music.download.com Year: 2007 Comment: http://music.download.com/ Track: 1 Genre: Unknown == Forced audio codec: mad Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == Unable to handle kernel NULL pointer dereference at virtual address pgd = c7128000 [] *pgd=871c9031, *pte=, *ppte= Internal error: Oops: 17 [#1] Modules linked in: ipv6 rtl8187 eeprom_93cx6 CPU: 0Not tainted (2.6.27-rc3-omap1 #1) PC is at snd_pcm_info+0xc/0xe0 LR is at snd_pcm_info_user+0x38/0x94 pc : []lr : []psr: a013 sp : c71ddd98 ip : c71dddb8 fp : c71dddb4 r10: 0001 r9 : c71dc000 r8 : c002ce04 r7 : r6 : r5 : c7077600 r4 : bee1d480 r3 : 0001 r2 : 40044145 r1 : c7077600 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 87128018 DAC: 0015 Process mplayer (pid: 1720, stack limit = 0xc71dc2e8) Stack: (0xc71ddd98 to 0xc71de000) dd80: bee1d480 c7077600 dda0: c714 c71dddb8 c025643c c0256330 bee1d480 bee1d480 ddc0: 0005 c71ddefc c718 c0257530 c0256410 84e030ff c051b060 dde0: c71dde3c c71dddf0 c008373c c007e2f0 c005059c c7129018 0001 de00: 0001 001f 406d5000 c051b060 c0171ed0 0001 c71dc000 de20: c71d2160 406d5000 0354 c7128000 c71dde94 c71dde40 c0084280 c00833b8 de40: 001f 0001 c051afe0 c71dde74 0001 c7123300 c007dc38 de60: 84e030ff c051b060 c71dde94 c71dde78 c0083d8c c007e470 0003 de80: 001f c71d2160 c71ddedc c71dde98 c008474c c0083cb0 dea0: c7123300 c7866520 0003 0022 c0151c6c 0020 c71dc000 406b6000 dec0: 406b6000 c7123300 080020fb 406d6000 c71ddf0c 81204101 bee1d480 0005 dee0: c002ce04 c71dc000 0001 c71ddf2c c71ddf00 c0258b48 c0257388 df00: c71ddf54 c71ddf10 c00868dc c0085b78 81204101 bee1d480 0005 c71d3d80 df20: c71ddf3c c71ddf30 c0258c64 c0258758 c71ddf54 c71ddf40 c00a5bb8 c0258c3c df40: c71d3d80 bee1d480 c71ddf7c c71ddf58 c00a5e6c c00a5b90 406b6000 0096 df60: 0005 bee1d480 81204101 c71d3d80 c71ddfa4 c71ddf80 c00a5ebc c00a5c08 df80: c0086b54 402c0444 007ee3b0 402c0444 0036 c71ddfa8 dfa0: c002cc80 c00a5e88 402c0444 007ee3b0 0005 81204101 bee1d480 007fbf10 dfc0: 402c0444 007ee3b0 402c0444 0036 bee1d480 0016 0001 bee1d65c dfe0: 007ee3b0 bee1d458 4025a3d8 404c099c 2010 0005 Backtrace: [] (snd_pcm_info+0x0/0xe0) from [] (snd_pcm_info_user+0x38/0x94) r7: r6: r5:c7077600 r4:bee1d480 [] (snd_pcm_info_user+0x0/0x94) from [] (snd_pcm_common_ioctl1+0x1b4/0xf9c) r7: r6:0005 r5:bee1d480 r4:bee1d480 [] (snd_pcm_common_ioctl1+0x0/0xf9c) from [] (snd_pcm_playback_ioctl1+0x3fc/0x420) [] (snd_pcm_playback_ioctl1+0x0/0x420) from [] (snd_pcm_playback_ioctl+0x34/0x38) r7:c71d3d80 r6:0005 r5:bee1d480 r4:81204101 [] (snd_pcm_playback_ioctl+0x0/0x38) from [] (vfs_ioctl+0x34/0x78) [] (vfs_ioctl+0x0/0x78) from [] (do_vfs_ioctl+0x270/0x280) r5:bee1d480 r4:c71d3d80 [] (do_vfs_ioctl+0x0/0x280) from [] (sys_ioctl+0x40/0x64) r7:c71d3d80 r6:81204101 r5:bee1d480 r4:0005 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:402c0444 r5:007ee3b0 r4:402c0444 Code: e89da830 e1a0c00d e92dd8f0 e24cb004 (e5904000) ---[ end trace 7a94571fa90e8e6c ]--- Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 17 [#2] Modules linked in: ipv6 rtl8187 eeprom_93cx6 CPU: 0Tainted: G D(2.6.27-rc3-omap1 #1) PC is at snd_pcm_release+0x20/0x88 LR is at __fput+0xb8/0x170 pc : []lr : []psr: a013 sp : c71ddb60 ip : c71ddb88 fp : c71ddb84 r10: c79d8200 r9 : c71ddd50 r8 : c71d3d80 r7 : c70372a8 r6 : c71d3d80 r5 : c70da3d0 r4 : r3 : c02558cc r2 : r1 : c71d3d80 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 87180018 DAC: 0015 Process mplayer (pid: 1720, stack limit = 0xc71dc2e8) Stack: (0xc71ddb60 to 0xc71de000) db60: 0008 c70da3d0 c71d3d80 c7bf1788 c74dea80 c71ddd50 c71ddbb4 c71ddb88 db8
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Tue, Aug 26, 2008 at 01:40:06AM +0300, Felipe Balbi wrote:
> On Mon, Aug 25, 2008 at 03:30:13PM -0700, Steve Sakoman wrote:
> > > Hmm, so the crash is actually somewhere else. Could you disable debug
> > > and get the NULL pointer dereference at the right point ?
> >
> > The output is below. The crash seems to occur at the substream
> > pointer dereference in the second line of snd_pcm_info (in
> > pcm_native.c):
> >
> > struct snd_pcm *pcm = substream->pcm;
>
> yeah, at that point substream was NULL. I'm trying to trace the function
> call to see why substream is getting NULLed.
>
> I think the following patch is anyway a good thing to apply:
>
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index c49b9d9..c7c15cf 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -92,10 +92,11 @@ static inline void snd_leave_user(mm_segment_t fs)
> int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info
> *info)
> {
> struct snd_pcm_runtime *runtime;
> - struct snd_pcm *pcm = substream->pcm;
> + struct snd_pcm *pcm;
> struct snd_pcm_str *pstr = substream->pstr;
>
> snd_assert(substream != NULL, return -ENXIO);
> + pcm = substream->pcm;
> memset(info, 0, sizeof(*info));
> info->card = pcm->card->number;
> info->device = pcm->device;
can you also apply this other patch:
diff --git a/sound/core/pcm.c b/sound/core/pcm.c
index 9dd9bc7..b8f43f3 100644
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -774,7 +774,7 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int
stream,
size_t size;
snd_assert(rsubstream != NULL, return -EINVAL);
- *rsubstream = NULL;
+// *rsubstream = NULL; why NULL it ?? need to investigate more
snd_assert(pcm != NULL, return -ENXIO);
pstr = &pcm->streams[stream];
if (pstr->substream == NULL || pstr->substream_count == 0)
@@ -795,8 +795,11 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int
stream,
case SNDRV_PCM_STREAM_PLAYBACK:
if (pcm->info_flags & SNDRV_PCM_INFO_HALF_DUPLEX) {
for (substream =
pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream; substream; substream =
substream->
- if (SUBSTREAM_BUSY(substream))
+ if (!substream)
return -EAGAIN;
+
+ if (SUBSTREAM_BUSY(substream))
+ continue;
}
}
break;
@@ -875,6 +878,10 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int
stream,
substream->ref_count = 1;
substream->f_flags = file->f_flags;
pstr->substream_opened++;
+
+ if (!substream)
+ printk(KERN_INFO "substream is NULL\n");
+
*rsubstream = substream;
return 0;
}
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, Aug 25, 2008 at 03:30:13PM -0700, Steve Sakoman wrote:
> > Hmm, so the crash is actually somewhere else. Could you disable debug
> > and get the NULL pointer dereference at the right point ?
>
> The output is below. The crash seems to occur at the substream
> pointer dereference in the second line of snd_pcm_info (in
> pcm_native.c):
>
> struct snd_pcm *pcm = substream->pcm;
yeah, at that point substream was NULL. I'm trying to trace the function
call to see why substream is getting NULLed.
I think the following patch is anyway a good thing to apply:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index c49b9d9..c7c15cf 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -92,10 +92,11 @@ static inline void snd_leave_user(mm_segment_t fs)
int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info
*info)
{
struct snd_pcm_runtime *runtime;
- struct snd_pcm *pcm = substream->pcm;
+ struct snd_pcm *pcm;
struct snd_pcm_str *pstr = substream->pstr;
snd_assert(substream != NULL, return -ENXIO);
+ pcm = substream->pcm;
memset(info, 0, sizeof(*info));
info->card = pcm->card->number;
info->device = pcm->device;
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> Hmm, so the crash is actually somewhere else. Could you disable debug > and get the NULL pointer dereference at the right point ? The output is below. The crash seems to occur at the substream pointer dereference in the second line of snd_pcm_info (in pcm_native.c): struct snd_pcm *pcm = substream->pcm; The log: [EMAIL PROTECTED]:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3 MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team CPU: ARM Playing /Watermelon_Slim-Black_Water.mp3. Audio file file format detected. Clip info: Title: Black Water Artist: Watermelon Slim Album: http://music.download.com Year: 2007 Comment: http://music.download.com/ Track: 1 Genre: Unknown == Forced audio codec: mad Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == Unable to handle kernel NULL pointer dereference at virtual address pgd = c7108000 [] *pgd=87077031, *pte=, *ppte= Internal error: Oops: 17 [#1] Modules linked in: ipv6 rtl8187 eeprom_93cx6 CPU: 0Not tainted (2.6.27-rc3-omap1 #1) PC is at snd_pcm_info+0xc/0xe0 LR is at snd_pcm_info_user+0x38/0x94 pc : []lr : []psr: a013 sp : c716bd98 ip : c716bdb8 fp : c716bdb4 r10: 0001 r9 : c716a000 r8 : c002ce04 r7 : r6 : r5 : c70ed600 r4 : beaff480 r3 : 0001 r2 : 40044145 r1 : c70ed600 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 87108018 DAC: 0015 Process mplayer (pid: 1757, stack limit = 0xc716a2e8) Stack: (0xc716bd98 to 0xc716c000) bd80: beaff480 c70ed600 bda0: c716bdd4 c716bdb8 c0256450 c0256344 beaff480 beaff480 bdc0: 0005 c716befc c716bdd8 c0257544 c0256424 84cda0ff c0518b40 bde0: c716be3c c716bdf0 c008373c c007e2f0 c716be14 c7109018 0001 be00: 0001 001f 406d5000 c0518b40 c00636b4 0001 c716a000 be20: c7bc56e0 406d5000 0354 c7108000 c716be94 c716be40 c0084280 c00833b8 be40: 001f 0001 c0518ac0 c716be74 0001 c7163600 c007dc38 be60: 84cda0ff c0518b40 c716be94 c716be78 c0083d8c c007e470 0003 be80: 001f c7bc56e0 c716bedc c716be98 c008474c c0083cb0 bea0: c7163600 c7864420 0003 0022 c0151c6c 0020 c716a000 406b6000 bec0: 406b6000 c7163600 080020fb 406d6000 c716bf0c 81204101 beaff480 0005 bee0: c002ce04 c716a000 0001 c716bf2c c716bf00 c0258b5c c025739c bf00: c716bf54 c716bf10 c00868dc c0085b78 81204101 beaff480 0005 c70b7080 bf20: c716bf3c c716bf30 c0258c78 c025876c c716bf54 c716bf40 c00a5bb8 c0258c50 bf40: c70b7080 beaff480 c716bf7c c716bf58 c00a5e6c c00a5b90 406b6000 0096 bf60: 0005 beaff480 81204101 c70b7080 c716bfa4 c716bf80 c00a5ebc c00a5c08 bf80: c0086b54 402c0444 007ee3b0 402c0444 0036 c716bfa8 bfa0: c002cc80 c00a5e88 402c0444 007ee3b0 0005 81204101 beaff480 007fbf10 bfc0: 402c0444 007ee3b0 402c0444 0036 beaff480 0016 0001 beaff65c bfe0: 007ee3b0 beaff458 4025a3d8 404c099c 2010 0005 Backtrace: [] (snd_pcm_info+0x0/0xe0) from [] (snd_pcm_info_user+0x38/0x94) r7: r6: r5:c70ed600 r4:beaff480 [] (snd_pcm_info_user+0x0/0x94) from [] (snd_pcm_common_ioctl1+0x1b4/0xf9c) r7: r6:0005 r5:beaff480 r4:beaff480 [] (snd_pcm_common_ioctl1+0x0/0xf9c) from [] (snd_pcm_playback_ioctl1+0x3fc/0x420) [] (snd_pcm_playback_ioctl1+0x0/0x420) from [] (snd_pcm_playback_ioctl+0x34/0x38) r7:c70b7080 r6:0005 r5:beaff480 r4:81204101 [] (snd_pcm_playback_ioctl+0x0/0x38) from [] (vfs_ioctl+0x34/0x78) [] (vfs_ioctl+0x0/0x78) from [] (do_vfs_ioctl+0x270/0x280) r5:beaff480 r4:c70b7080 [] (do_vfs_ioctl+0x0/0x280) from [] (sys_ioctl+0x40/0x64) r7:c70b7080 r6:81204101 r5:beaff480 r4:0005 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:402c0444 r5:007ee3b0 r4:402c0444 Code: e89da830 e1a0c00d e92dd8f0 e24cb004 (e5904000) ---[ end trace 85720182f0be6892 ]--- Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 17 [#2] Modules linked in: ipv6 rtl8187 eeprom_93cx6 CPU: 0Tainted: G D(2.6.27-rc3-omap1 #1) PC is at snd_pcm_release+0x20/0x88 LR is at __fput+0xb8/0x170 pc : []lr : []psr: a013 sp : c716bb60 ip : c716bb88 fp : c716bb84 r10: c7854000 r9 : c716bd50 r8 : c70b7080 r7 : c70c72a8 r6 : c70b7080 r5 : c79f6ab0 r4 : r3 : c02558e0 r2 : r1 : c70b7080 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 871c8018 DAC: 0015 Pro
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> Hmm, so the crash is actually somewhere else. Yes, the assert is the first point at which you can detect that things are going to go badly :-) The actual crash happens two or three function calls deeper when the first substream pointer dereference occurs. > Could you disable debug > and get the NULL pointer dereference at the right point ? Will do, compiling right now. > I think it'll be easier to track down, maybe. Maybe -- but the root cause of the crash is the null substream pointer which was set way up the call chain. I'll attach the new crash log in a few minutes when the build completes. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, Aug 25, 2008 at 02:50:04PM -0700, Steve Sakoman wrote: > >> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0)) > > > > Hmmm... this looks odd. > > > > Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream > > _is_ NULL instead of !is NULL ? > > I found this odd also, but looking in > Documentation/sound/alsa/DocBook/writing-an-alsa-driver I found that > the sense of the test is indeed the reverse of what you would expect > -- you are specifying the condition that *should* be met, and the > action to take if it is not. > > I can also verify that the substream pointer is indeed null -- the > reason I enabled alsa debugging in the first place is that the kernel > was crashing due to a null pointer :-) Hmm, so the crash is actually somewhere else. Could you disable debug and get the NULL pointer dereference at the right point ? I think it'll be easier to track down, maybe. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
>> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0)) > > Hmmm... this looks odd. > > Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream > _is_ NULL instead of !is NULL ? I found this odd also, but looking in Documentation/sound/alsa/DocBook/writing-an-alsa-driver I found that the sense of the test is indeed the reverse of what you would expect -- you are specifying the condition that *should* be met, and the action to take if it is not. I can also verify that the substream pointer is indeed null -- the reason I enabled alsa debugging in the first place is that the kernel was crashing due to a null pointer :-) Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Tue, Aug 26, 2008 at 12:35:13AM +0300, Felipe Balbi wrote:
> On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> > ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
>
> Hmmm... this looks odd.
>
> Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
> _is_ NULL instead of !is NULL ?
>
> I mean:
>
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index c49b9d9..db86090 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -2570,7 +2570,7 @@ static int snd_pcm_playback_ioctl1(struct file *file,
>struct snd_pcm_substream *substream,
>unsigned int cmd, void __user *arg)
> {
> - snd_assert(substream != NULL, return -ENXIO);
> + snd_assert(substream == NULL, return -ENXIO);
> snd_assert(substream->stream == SNDRV_PCM_STREAM_PLAYBACK, return
> -EINVAL);
> switch (cmd) {
> case SNDRV_PCM_IOCTL_WRITEI_FRAMES:
>
> If you follow up the function calls, we can see that substream is
> initialized in pcm_native.c:snd_pcm_open_file():
>
> 2080 err = snd_pcm_open_substream(pcm, stream, file, &substream);
> 2081 if (err < 0)
> 2082 return err;
>
> and that initialized pointer is added to pcm_file in the same function
> a few lines later:
>
> 2089 pcm_file->substream = substream;
>
> Am I misreading something ? :-s
btw, the for loop in pcm.c:snd_pcm_attach_substream looks weird.
Couldn't it be changed to use list_for_each_entry() or any of its friends ?
797 for (substream =
pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream; substream; substream = substr
eam->next) {
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
Hmmm... this looks odd.
Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
_is_ NULL instead of !is NULL ?
I mean:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index c49b9d9..db86090 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2570,7 +2570,7 @@ static int snd_pcm_playback_ioctl1(struct file *file,
struct snd_pcm_substream *substream,
unsigned int cmd, void __user *arg)
{
- snd_assert(substream != NULL, return -ENXIO);
+ snd_assert(substream == NULL, return -ENXIO);
snd_assert(substream->stream == SNDRV_PCM_STREAM_PLAYBACK, return
-EINVAL);
switch (cmd) {
case SNDRV_PCM_IOCTL_WRITEI_FRAMES:
If you follow up the function calls, we can see that substream is
initialized in pcm_native.c:snd_pcm_open_file():
2080 err = snd_pcm_open_substream(pcm, stream, file, &substream);
2081 if (err < 0)
2082 return err;
and that initialized pointer is added to pcm_file in the same function
a few lines later:
2089 pcm_file->substream = substream;
Am I misreading something ? :-s
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> Here's the crash output (alsa debugging is enabled in the kernel):
Can you apply the following patch just to make it easier to pinpoint
from where the BUG is coming from ?
diff --git a/include/sound/core.h b/include/sound/core.h
index 558b962..d2edf98 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -400,7 +400,7 @@ void snd_verbose_printd(const char *file, int line, const
char *format, ...)
} while (0)
#define snd_BUG() do { \
- snd_printk(KERN_ERR "BUG?\n"); \
+ snd_printk(KERN_ERR "%s %d: BUG?\n", __func__, __LINE__); \
dump_stack(); \
} while (0)
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
> For testing I use Debian/testing and alsa-utils and various > players like mpg321, madplay, etc from there. I've been using mplayer, madplay, aplay, arecord, speakertest . . . I'm using a rootfs built with OpenEmbedded, the alsa lib version is 1.0.17 [EMAIL PROTECTED]:~# cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.17. > Can you share the error log and steps when this typically occurs in > order to see can I reproduce it? Certainly! First a few basics -- I can run commands like: mplayer song.mp3 madplay song.mp3 aplay rawsong with no problems. If I run 'mplayer -ao alsa song.mp3' immediately after booting I get a crash due to a null substream pointer (output below). However if I run 'mplayer song.mp3' *before* 'mplayer -ao alsa song.mp3' then the latter command works! Here's the crash output (alsa debugging is enabled in the kernel): overo login: root login[1632]: root login on `ttyS2' [EMAIL PROTECTED]:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3 MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team CPU: ARM Playing /Watermelon_Slim-Black_Water.mp3. Audio file file format detected. Clip info: Title: Black Water Artist: Watermelon Slim Album: http://music.download.com Year: 2007 Comment: http://music.download.com/ Track: 1 Genre: Unknown == Forced audio codec: mad Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0)) [] (dump_stack+0x0/0x14) from [] (snd_pcm_playback_ioctl1+0x34/0x474) [] (snd_pcm_playback_ioctl1+0x0/0x474) from [] (snd_pcm_playback_ioctl+0x34/0x38) r7:c71bc000 r6:0005 r5:bea41624 r4:80044100 [] (snd_pcm_playback_ioctl+0x0/0x38) from [] (vfs_ioctl+0x34/0x78) [] (vfs_ioctl+0x0/0x78) from [] (do_vfs_ioctl+0x270/0x280) r5:bea41624 r4:c71bc000 [] (do_vfs_ioctl+0x0/0x280) from [] (sys_ioctl+0x40/0x64) r7:c71bc000 r6:80044100 r5:bea41624 r4:0005 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:0400 r5:4001e1cc r4:bea41624 ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0)) [] (dump_stack+0x0/0x14) from [] (snd_pcm_playback_ioctl1+0x34/0x474) [] (snd_pcm_playback_ioctl1+0x0/0x474) from [] (snd_pcm_playback_ioctl+0x34/0x38) r7:c71bc000 r6:0005 r5:bea41480 r4:81204101 [] (snd_pcm_playback_ioctl+0x0/0x38) from [] (vfs_ioctl+0x34/0x78) [] (vfs_ioctl+0x0/0x78) from [] (do_vfs_ioctl+0x270/0x280) r5:bea41480 r4:c71bc000 [] (do_vfs_ioctl+0x0/0x280) from [] (sys_ioctl+0x40/0x64) r7:c71bc000 r6:81204101 r5:bea41480 r4:0005 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:402c0444 r5:007ee3b0 r4:402c0444 [AO_ALSA] alsa-lib: pcm_hw.c:261:(snd_pcm_hw_info) SNDRV_PCM_IOCTL_INFO failed: No such device or address [AO_ALSA] alsa-lib: pcm_direct.c:1100:(snd1_pcm_direct_initialize_poll_fd) unable to info for slave pcm [AO_ALSA] alsa-lib: pcm_dmix.c:1085:(snd_pcm_dmix_open) unable to initialize poll_fd [AO_ALSA] Playback open error: No such device or address Could not open/initialize audio device -> no sound. Audio: no sound Video: no video Exiting... (End of file) [EMAIL PROTECTED]:~# ALSA sound/core/pcm_native.c:2180: BUG? (substream != ((void *)0)) [] (dump_stack+0x0/0x14) from [] (snd_pcm_release+0x38/0xbc) [] (snd_pcm_release+0x0/0xbc) from [] (__fput+0xb8/0x170) r9:c7164000 r8:c74dd980 r7:c70c7634 r6:c71bc000 r5:c79faab0 r4:0008 [] (__fput+0x0/0x170) from [] (fput+0x30/0x34) [] (fput+0x0/0x34) from [] (remove_vma+0x40/0x70) [] (remove_vma+0x0/0x70) from [] (exit_mmap+0xcc/0xf8) r5:c70c7600 r4:c7167898 [] (exit_mmap+0x0/0xf8) from [] (mmput+0x3c/0xc4) r6:c791a100 r5: r4:c70c7600 [] (mmput+0x0/0xc4) from [] (exit_mm+0x110/0x118) r5:c70c7600 r4: [] (exit_mm+0x0/0x118) from [] (do_exit+0x1f0/0x6e8) r7:00f8 r6: r5:c791a100 r4:c7164000 [] (do_exit+0x0/0x6e8) from [] (do_group_exit+0x7c/0xac) [] (do_group_exit+0x0/0xac) from [] (sys_exit_group+0x18/0x1c) r5:0008c978 r4:0008c99c [] (sys_exit_group+0x0/0x1c) from [] (ret_fast_syscall+0x0/0x2c) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Hi Jarkko, I applied your patch manually on the latest omap-git and tested ASOC driver on omap2evm board with tlv320aic34 codec. It works fine. omap2evm is based on omap2430. Best Regards, Arun KS On Thu, Aug 21, 2008 at 5:25 PM, Jarkko Nikula <[EMAIL PROTECTED]> wrote: > Here are two patches adding support for OMAP2430 in McBSP driver and > adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. > > These are generated from top of currect l-o head but they apply also on > top of Hiroshi's virtual clock patches with some offsets. > > If you have change to try them out on those CPUs, I would be happy to > hear. I've tested these only on N810. Second patch will naturally go > through the alsa-devel when we have necessary McBSP patches upstream. > > -- > Jarkko > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Thu, 21 Aug 2008 14:51:04 -0700 "ext Steve Sakoman" <[EMAIL PROTECTED]> wrote: > I will submit the TWL4030 + Beagle, EVM, and Overo ASoC driver patches > as soon as I can track down a recurring crashing bug -- a null > substream pointer that seems to show up in certain circumstances. Not > quite sure my driver is causing the error, but I would like to get to > the bottom of it. It may be a compatibility issue with the version of > alsa lib I am using with the linux-omap kernel since the lib is > passing in the null pointer. Have you seen anything like this on the > N810? > Thus far I've seen only these two fixed 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e and 55502f74b56f609a84d8919b9b29390b2e0147ff OMAP DMA related dump_stacks but probably I haven't stressed enough :-) For testing I use Debian/testing and alsa-utils and various players like mpg321, madplay, etc from there. ii libasound2 1.0.16-2 ALSA library cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.17. Can you share the error log and steps when this typically occurs in order to see can I reproduce it? Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
I tried these patches with my ASoC driver for TWL4030/Overo (the Gumstix 35XX based board) and they appear to work for that combination. When I get a chance I will try them with Beagle and EVM, but I expect that should go well too. I will submit the TWL4030 + Beagle, EVM, and Overo ASoC driver patches as soon as I can track down a recurring crashing bug -- a null substream pointer that seems to show up in certain circumstances. Not quite sure my driver is causing the error, but I would like to get to the bottom of it. It may be a compatibility issue with the version of alsa lib I am using with the linux-omap kernel since the lib is passing in the null pointer. Have you seen anything like this on the N810? Regards, Steve On Thu, Aug 21, 2008 at 4:55 AM, Jarkko Nikula <[EMAIL PROTECTED]> wrote: > Here are two patches adding support for OMAP2430 in McBSP driver and > adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver. > > These are generated from top of currect l-o head but they apply also on > top of Hiroshi's virtual clock patches with some offsets. > > If you have change to try them out on those CPUs, I would be happy to > hear. I've tested these only on N810. Second patch will naturally go > through the alsa-devel when we have necessary McBSP patches upstream. > > -- > Jarkko > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
