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 susp
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:
>
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
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
"Steve Sakoman" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 7, 2008 at 10:37 AM, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Sunday 07 September 2008, Måns Rullgård wrote:
>>> I've also had to revert the "usb: musb: pass configuration specifics
>>> via pdata" commits:
>>>
>>> ffd60d49c70b31d26
On Sun, Sep 7, 2008 at 10:37 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Sunday 07 September 2008, Måns Rullgård wrote:
>> I've also had to revert the "usb: musb: pass configuration specifics
>> via pdata" commits:
>>
>> ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap
>> ca6d1b133
On Sunday 07 September 2008, Måns Rullgård wrote:
> I've also had to revert the "usb: musb: pass configuration specifics
> via pdata" commits:
>
> ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap
> ca6d1b1333bc2e61e37982de1f28d8604c232414 in mainline
>
> I suspect there are simply some
David Brownell <[EMAIL PROTECTED]> writes:
> On Saturday 06 September 2008, Steve Sakoman wrote:
>> On Fri, Sep 5, 2008 at 10:52 AM, Tony Lindgren <[EMAIL PROTECTED]> wrote:
>> > * Steve Sakoman <[EMAIL PROTECTED]> [080905 10:24]:
>> >> > Hmm, is the musb broken now?
>> >>
>> >> It is on Overo if
On Saturday 06 September 2008, Steve Sakoman wrote:
> On Fri, Sep 5, 2008 at 10:52 AM, Tony Lindgren <[EMAIL PROTECTED]> wrote:
> > * Steve Sakoman <[EMAIL PROTECTED]> [080905 10:24]:
> >> > Hmm, is the musb broken now?
> >>
> >> It is on Overo if I base my patches against current top of tree
> >>
On Fri, Sep 5, 2008 at 10:52 AM, Tony Lindgren <[EMAIL PROTECTED]> wrote:
> * Steve Sakoman <[EMAIL PROTECTED]> [080905 10:24]:
>> > Hmm, is the musb broken now?
>>
>> It is on Overo if I base my patches against current top of tree
>> (a376251519ced5831ed07ed234430725230ed93a)
>>
>> Doesn't crash,
* 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 ag
> 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)
* 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 A
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 to
* 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
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_sl
> 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.
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_c
> 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_com
> 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 EAB
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
> 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
> 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
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 th
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
> 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
Playin
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. T
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 se
> 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
> 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 th
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
>> 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-driv
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 substr
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_
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
ind
> 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/versi
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 a
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
> qui
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 pa
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
40 matches
Mail list logo
