crash trace under gdb

crash trace under gdb

[Paul Davis]

well, it appears that the lock up occurs in a call to
__read_lock_failed, with the PC toward the end of __kill_fasync. it
alternates between two address that are both within that function,
different by 9 bytes.

ctrl-alt-sysreq couldn't provide a trace more than 1 call back. not
sure why.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Takashi Iwai]

At Fri, 9 May 2003 10:05:36 -0400,
Paul Davis wrote:
> 
> well, it appears that the lock up occurs in a call to
> __read_lock_failed, with the PC toward the end of __kill_fasync. it
> alternates between two address that are both within that function,
> different by 9 bytes.

IIRC, your machine is SMP, right?
if it's related lock, it might be related with the recent change of
handling of linked pcm streams...

> 
> ctrl-alt-sysreq couldn't provide a trace more than 1 call back. not
> sure why.

how about alt-sysrq-T ?


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Paul Davis]

>IIRC, your machine is SMP, right?
>if it's related lock, it might be related with the recent change of
>handling of linked pcm streams...

yes, its SMP. that's what i suspected. i can't compare anything right
now, because sf.net is doing its cvs-blockout stuff. when, oh when
will i remember to always archive my alsa CVS tree before updating?

>> ctrl-alt-sysreq couldn't provide a trace more than 1 call back. not
>> sure why.
>
>how about alt-sysrq-T ?

ah, right, i should have tried that. i'll see if i feel like crashing
my machine again rather than working on automation line editing for
ardour :)


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Paul Davis]

>how about alt-sysrq-T ?

all this "proves" is that yes, its the lock code because we're running
in interrupt context, not in process context. 

so something in the code jaroslav added is broken, at least for SMP.

i just hope sf.net will let me get my hands on an older copy so i can
keep working ...



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Takashi Iwai]

At Fri, 09 May 2003 11:39:42 -0400,
Paul Davis wrote:
> 
> >how about alt-sysrq-T ?
> 
> all this "proves" is that yes, its the lock code because we're running
> in interrupt context, not in process context. 
> 
> so something in the code jaroslav added is broken, at least for SMP.
> 
> i just hope sf.net will let me get my hands on an older copy so i can
> keep working ...

you can use the CVS snapshot tarball for the old versions.  the
changes for pcm substreams were done from Apr. 28, so Apr. 27 should
be fine for this regard.
or, the CVS repositry backup would be nice to track down the whole
changes, but it's big (13MB).


ciao,

Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Abramo Bagnara]

Takashi Iwai ha scritto:
> At Fri, 09 May 2003 11:39:42 -0400,
> Paul Davis wrote:
> 
>>>how about alt-sysrq-T ?
>>
>>all this "proves" is that yes, its the lock code because we're running
>>in interrupt context, not in process context. 
>>
>>so something in the code jaroslav added is broken, at least for SMP.
>>
>>i just hope sf.net will let me get my hands on an older copy so i can
>>keep working ...
> 
> 
> you can use the CVS snapshot tarball for the old versions.  the
> changes for pcm substreams were done from Apr. 28, so Apr. 27 should
> be fine for this regard.
> or, the CVS repositry backup would be nice to track down the whole
> changes, but it's big (13MB).

However it would be nice if Paul help us to track down the source of the 
bug, or give a test case for someone willing to help and with access to 
SMP hardware.

Theoretically the new code should work, I guess there's only a trivial typo.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Paul Davis]

>However it would be nice if Paul help us to track down the source of the 
>bug, or give a test case for someone willing to help and with access to 
>SMP hardware.

i'm happy to help out, but there's very little information available
from the system when it happens. it also turns out (unsuprisingly) not
to require gdb at all: the last time it happened, i started JACK up
and within a few seconds the system was locked.

if there's something i can try (adding printk's, whatever), let me
know. i have both tree in place now, so its not painful to switch back
and forth. 

i also note that as far as i can tell, the dependency of the hdsp
driver on snd-hwdep is still not in place. i had to add:

obj-$(CONFIG_SND_HDSP) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o snd-hwdep.o

to alsa-driver/acore/Makefile for the Apr. 27th version, although i
didn't notice a problem with this for the most recent CVS version. i
grepped for hwdep in the recent tree, and couldn't see where it was
added, but perhaps it was. jaroslav?

--p


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Abramo Bagnara]

Paul Davis ha scritto:
>>However it would be nice if Paul help us to track down the source of the 
>>bug, or give a test case for someone willing to help and with access to 
>>SMP hardware.
> 
> 
> i'm happy to help out, but there's very little information available
> from the system when it happens. it also turns out (unsuprisingly) not
> to require gdb at all: the last time it happened, i started JACK up
> and within a few seconds the system was locked.

1) Are you using linked streams?
2) What's the complete call trace on lock (alt-sysrq-T)?

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Paul Davis]

>1) Are you using linked streams?
>2) What's the complete call trace on lock (alt-sysrq-T)?

1) no linked streams.
2) alt-sysrq-T doesn't do anything on my system.

ctrl-alt-sysrq-P shows just one level of trackback.



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: crash trace under gdb

[Takashi Iwai]

At Fri, 09 May 2003 13:48:19 -0400,
Paul Davis wrote:
> 
> i also note that as far as i can tell, the dependency of the hdsp
> driver on snd-hwdep is still not in place. i had to add:
> 
> obj-$(CONFIG_SND_HDSP) += snd-pcm.o snd-timer.o snd-page-alloc.o snd.o snd-rawmidi.o snd-hwdep.o
> 
> to alsa-driver/acore/Makefile for the Apr. 27th version, although i
> didn't notice a problem with this for the most recent CVS version. i
> grepped for hwdep in the recent tree, and couldn't see where it was
> added, but perhaps it was. jaroslav?

it was very recently, namely one minute ago ;)
thanks, now fixed.


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com