ALSA + jack + xrun = kernel crash

ALSA + jack + xrun = kernel crash

[Arthur Peters]

Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
prints a message saying it will reboot then doesn't). The crash happens
when jackd xruns. I've been reproducing it using "jackd -d alsa" (other
options don't make a difference) then "ladccad". Once the system crashs
the only way to get any responce is with SysRq. Keys don't echo to the
console and I can't switch VTs.

Generally there is no error message or oops that I can see, even when
debug=full is enable in ALSA. Early on I saw a message from jackd to the
tune of "error write 512 somethings to device", but I have not been able
to reproduce it. I am willing to run any tests that might help. I use
journaling filesystems ;-) 

My hardware is:
Dual PIII 1Ghz with 512M RAM on a Tyan MB.
SoundBlaster Live! Value
ATI Radeon 8500 (using the closed-source ATI drivers; version 2.9.8)

My software is:
ALSA drivers 0.9.3a or current CVS
Linux 2.4.20 (vanilla or gentoo patched)
Jack 0.71.2
Current Gentoo with testing packages enabled (~x86)

Thanks.

-Arthur

PS: I have sporadic hard freezes when I use Xv heavily and I had to
lower the AGP rate from 4x to 2x to prevent a crash when my X server
loaded. This is just in case it might be related. It could be my MB I
guess. [shiver]


-- 
Arthur Peters <amp@singingwizard.org>



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Paul Davis]

>Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
>prints a message saying it will reboot then doesn't). The crash happens
  [ ... ]
>My hardware is:
>Dual PIII 1Ghz with 512M RAM on a Tyan MB.
  [ .... ]
>My software is:
>ALSA drivers 0.9.3a or current CVS

current CVS (and presumably 0.9.3a) has a severe bug with SMP
systems. i reported it last week, along with as much output as i could
get from my machine when it locked up. nobody has been able to do
anything about it since then.

you will need to back to the cvs snapshot of april 27th to get a
working version for SMP systems.

jaroslav or takashi - any ideas about fixing this?


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Jaroslav Kysela]

On Sat, 17 May 2003, Paul Davis wrote:

> >Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
> >prints a message saying it will reboot then doesn't). The crash happens
>   [ ... ]
> >My hardware is:
> >Dual PIII 1Ghz with 512M RAM on a Tyan MB.
>   [ .... ]
> >My software is:
> >ALSA drivers 0.9.3a or current CVS
> 
> current CVS (and presumably 0.9.3a) has a severe bug with SMP
> systems. i reported it last week, along with as much output as i could
> get from my machine when it locked up. nobody has been able to do
> anything about it since then.
> 
> you will need to back to the cvs snapshot of april 27th to get a
> working version for SMP systems.
> 
> jaroslav or takashi - any ideas about fixing this?

Paul, could you, please, enable spinlock debug in your SMP kernel?

include/linux/spinlock.h:

#define DEBUG_SPINLOCKS 0       /* 0 == no debugging, 1 == maintain lock state, 2 == full debug */

Use full debug. I am sorry, but I have not a SMP machine around.


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Arthur Peters]

I tried this, but I didn't get any additional output. I looked at
include/linux/spinlock.h and it appears that the line you are refering
to only affects UP compiles. This explains why I didn't get any output.

Am I doing something wrong? Anything else I could do to help?

-Arthur

On Sat, 2003-05-17 at 07:47, Jaroslav Kysela wrote:

> Paul, could you, please, enable spinlock debug in your SMP kernel?
> 
> include/linux/spinlock.h:
> 
> #define DEBUG_SPINLOCKS 0       /* 0 == no debugging, 1 == maintain lock state, 2 == full debug */
> 
> Use full debug. I am sorry, but I have not a SMP machine around.
> 
> 
> 						Jaroslav

-- 
Arthur Peters <amp@singingwizard.org>



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Takashi Iwai]

At Sat, 17 May 2003 08:27:29 -0400,
Paul Davis wrote:
> 
> >Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
> >prints a message saying it will reboot then doesn't). The crash happens
>   [ ... ]
> >My hardware is:
> >Dual PIII 1Ghz with 512M RAM on a Tyan MB.
>   [ .... ]
> >My software is:
> >ALSA drivers 0.9.3a or current CVS
> 
> current CVS (and presumably 0.9.3a) has a severe bug with SMP
> systems. i reported it last week, along with as much output as i could
> get from my machine when it locked up. nobody has been able to do
> anything about it since then.
> 
> you will need to back to the cvs snapshot of april 27th to get a
> working version for SMP systems.
> 
> jaroslav or takashi - any ideas about fixing this?

it's likely spin dead locks, but it's difficult to guess where this
happens.

after auditing the new codes, i fixed some possible dead locks.
most of the fixed places, however, happen in suspend/resume
conditions or timeout after 10sec, so this unlikely fixes your case.


could you check whether snd_pcm_stream_linked() returns really only
zero?  if yes, the code path shouldn't include the complicated locks
in snd_pcm_action_group(), and it will narrow the possible bugggy
points much...


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Paul Davis]

>could you check whether snd_pcm_stream_linked() returns really only
>zero?  if yes, the code path shouldn't include the complicated locks

aw shoot. of course it returns true: jack tries to link
capture+playback so that we only have to issue single commands to
start+stop. damn, i forgot that, sorry.

--p


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Benny Sjostrand]

>
>
>aw shoot. of course it returns true: jack tries to link
>capture+playback so that we only have to issue single commands to
>start+stop. damn, i forgot that, sorry.
>
>  
>
One thing that would be interesting to known more about is
why does jack not the hangup the machine at once when I start it
without the "-R" flag. (wich will results in a lot more xruns)

Without the "-R" flag: (almost all the times ...)
- jackd runs without locking up the machine
 until I try to connect any client.
- after stopping jackd (Ctrl-C) without conecting any client,
the machine dont behave correctly after this, for example
when a 'A' key in the terminal I got any other character, programs
does not start correctly, the machine does not shutdown
correctly, but have not seen any "oops" (but maybe just a random
coincidence ....)
But if it's a spin_lock(...) problem why does not just lock up my 
machine in this
case ?

I would interesting to known what happens  if someone else could try 
starting
the jackd without the "-R" and latest ALSA CVS. (on a SMP machine .. -;)

/Benny




-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Takashi Iwai]

At Mon, 19 May 2003 12:38:14 -0400,
Paul Davis wrote:
> 
> >could you check whether snd_pcm_stream_linked() returns really only
> >zero?  if yes, the code path shouldn't include the complicated locks
> 
> aw shoot. of course it returns true: jack tries to link
> capture+playback so that we only have to issue single commands to
> start+stop. damn, i forgot that, sorry.

ok, i found a serious typo in pcm_native.c, which i guess as the
culprit.
could you try the cvs version?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Pieter Palmers]

  Ok, second try:

alsa 0.9.3c fresh from CVS
   ---------------------------------------
    /proc/asound/version:
   Advanced Linux Sound Architecture Driver Version 0.9.3c.
   Compiled on May 21 2003 for kernel 2.4.20-LL with versioned symbols.

    /proc/asound/cards:
   0 [AudioPCI       ]: ENS1371 - Ensoniq AudioPCI
                        Ensoniq AudioPCI ENS1371 at 0xb000, irq 5

   ---------------------------------------

jack 0.71.2 fresh from CVS
spiralsynthmodular

the first error:

jack -R -d alsa    (as root)
   ---------------------------------------
jackd 0.71.2
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support
loading driver ..
creating alsa driver ... default|1024|2|48000|swmon|swmeter|rt
open
You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a ~/.asoundrc file
to define a hardware audio device rather than using the plug layer

You appear to be using the ALSA software "plug" layer, probably
a result of using the "default" ALSA device. This is less
efficient than it could be. Consider using a ~/.asoundrc file
to define a hardware audio device rather than using the plug layer

port alsa_pcm:capture_1 has mixdown = 0x4003410e
port alsa_pcm:capture_2 has mixdown = 0x4003410e
port alsa_pcm:playback_1 has mixdown = 0x4003410e
port alsa_pcm:playback_2 has mixdown = 0x4003410e
starting engine

**** alsa_pcm: xrun of at least 78.613 msecs
**** alsa_pcm: xrun of at least 0.194 msecs
**** alsa_pcm: xrun of at least 0.030 msecs
**** alsa_pcm: xrun of at least 0.025 msecs
port SSM:In0 has mixdown = 0x4003410e
port SSM:In1 has mixdown = 0x4003410e
port SSM:In2 has mixdown = 0x4003410e
port SSM:In3 has mixdown = 0x4003410e
port SSM:In4 has mixdown = 0x4003410e
port SSM:In5 has mixdown = 0x4003410e
port SSM:In6 has mixdown = 0x4003410e
port SSM:In7 has mixdown = 0x4003410e
port SSM:Out0 has mixdown = 0x4003410e
port SSM:Out1 has mixdown = 0x4003410e
port SSM:Out2 has mixdown = 0x4003410e
port SSM:Out3 has mixdown = 0x4003410e
port SSM:Out4 has mixdown = 0x4003410e
port SSM:Out5 has mixdown = 0x4003410e
port SSM:Out6 has mixdown = 0x4003410e
port SSM:Out7 has mixdown = 0x4003410e
could not complete playback of 1024 frames
cycle execution failure, exiting
telling signal thread that the engine is done
jack main caught signal 1
   ---------------------------------------

no problem up to this point (but for the fact that jack terminates)

Then I try to restart jack with the same command. It starts, but after 
the second xrun it hangs the system.

Pieter


Takashi Iwai wrote:

>At Mon, 19 May 2003 12:38:14 -0400,
>Paul Davis wrote:
>  
>
>>>could you check whether snd_pcm_stream_linked() returns really only
>>>zero?  if yes, the code path shouldn't include the complicated locks
>>>      
>>>
>>aw shoot. of course it returns true: jack tries to link
>>capture+playback so that we only have to issue single commands to
>>start+stop. damn, i forgot that, sorry.
>>    
>>
>
>ok, i found a serious typo in pcm_native.c, which i guess as the
>culprit.
>could you try the cvs version?
>
>
>Takashi
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>  
>





-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

At Wed, 21 May 2003 02:32:02 +0200,
Pieter Palmers wrote:
> 
>   Ok, second try:
> 
> alsa 0.9.3c fresh from CVS
>    ---------------------------------------
>     /proc/asound/version:
>    Advanced Linux Sound Architecture Driver Version 0.9.3c.
>    Compiled on May 21 2003 for kernel 2.4.20-LL with versioned symbols.
> 
>     /proc/asound/cards:
>    0 [AudioPCI       ]: ENS1371 - Ensoniq AudioPCI
>                         Ensoniq AudioPCI ENS1371 at 0xb000, irq 5
> 
>    ---------------------------------------

how about this one?  this should fix another deadlock
(including the simplified expression of stream lock)


Takashi

[-- Attachment #2: pcm-lock-fix.dif --]
[-- Type: application/octet-stream, Size: 6696 bytes --]

Index: alsa-kernel/include/pcm.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/pcm.h,v
retrieving revision 1.35
diff -u -r1.35 pcm.h
--- alsa-kernel/include/pcm.h	15 May 2003 09:46:39 -0000	1.35
+++ alsa-kernel/include/pcm.h	21 May 2003 09:54:41 -0000
@@ -388,7 +388,7 @@
 	snd_pcm_substream_t *next;
 	/* -- linked substreams -- */
 	struct list_head link_list;	/* linked list member */
-	snd_pcm_group_t self_group;	/* fake group for non linked substream (with substream lock inside) */
+	spinlock_t lock;		/* lock per stream */
 	snd_pcm_group_t *group;		/* pointer to current group */
 	/* -- assigned files -- */
 	snd_pcm_file_t *file;
@@ -578,42 +578,42 @@
 
 static inline int snd_pcm_stream_linked(snd_pcm_substream_t *substream)
 {
-	return substream->group != &substream->self_group;
+	return substream->group != NULL;
 }
 
 static inline void snd_pcm_stream_lock(snd_pcm_substream_t *substream)
 {
 	read_lock(&snd_pcm_link_rwlock);
-	spin_lock(&substream->self_group.lock);
+	spin_lock(&substream->lock);
 }
 
 static inline void snd_pcm_stream_unlock(snd_pcm_substream_t *substream)
 {
-	spin_unlock(&substream->self_group.lock);
+	spin_unlock(&substream->lock);
 	read_unlock(&snd_pcm_link_rwlock);
 }
 
 static inline void snd_pcm_stream_lock_irq(snd_pcm_substream_t *substream)
 {
 	read_lock_irq(&snd_pcm_link_rwlock);
-	spin_lock(&substream->self_group.lock);
+	spin_lock(&substream->lock);
 }
 
 static inline void snd_pcm_stream_unlock_irq(snd_pcm_substream_t *substream)
 {
-	spin_unlock(&substream->self_group.lock);
+	spin_unlock(&substream->lock);
 	read_unlock_irq(&snd_pcm_link_rwlock);
 }
 
 #define snd_pcm_stream_lock_irqsave(substream, flags) \
 do { \
 	read_lock_irqsave(&snd_pcm_link_rwlock, (flags)); \
-	spin_lock(&substream->self_group.lock); \
+	spin_lock(&substream->lock); \
 } while (0)
 
 #define snd_pcm_stream_unlock_irqrestore(substream, flags) \
 do { \
-	spin_unlock(&substream->self_group.lock); \
+	spin_unlock(&substream->lock); \
 	read_unlock_irqrestore(&snd_pcm_link_rwlock, (flags)); \
 } while (0)
 
Index: alsa-kernel/core/pcm.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm.c,v
retrieving revision 1.28
diff -u -r1.28 pcm.c
--- alsa-kernel/core/pcm.c	5 May 2003 10:09:09 -0000	1.28
+++ alsa-kernel/core/pcm.c	21 May 2003 10:06:04 -0000
@@ -593,10 +593,8 @@
 			snd_magic_kfree(substream);
 			return err;
 		}
-		substream->group = &substream->self_group;
-		spin_lock_init(&substream->self_group.lock);
-		INIT_LIST_HEAD(&substream->self_group.substreams);
-		list_add_tail(&substream->link_list, &substream->self_group.substreams);
+		substream->group = NULL;
+		INIT_LIST_HEAD(&substream->link_list);
 		spin_lock_init(&substream->timer_lock);
 		prev = substream;
 	}
Index: alsa-kernel/core/pcm_native.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm_native.c,v
retrieving revision 1.52
diff -u -r1.52 pcm_native.c
--- alsa-kernel/core/pcm_native.c	20 May 2003 08:43:44 -0000	1.52
+++ alsa-kernel/core/pcm_native.c	21 May 2003 10:27:21 -0000
@@ -624,7 +624,7 @@
 	snd_pcm_group_for_each(pos, substream) {
 		s = snd_pcm_group_substream_entry(pos);
 		if (s != substream)
-			spin_lock(&s->self_group.lock);
+			spin_lock(&s->lock);
 		res = ops->pre_action(s, state);
 		if (res < 0)
 			break;
@@ -640,7 +640,7 @@
 				ops->post_action(s, state);
 			}
 			if (s != substream)
-				spin_unlock(&s->self_group.lock);
+				spin_unlock(&s->lock);
 		}
 	} else {
 		snd_pcm_substream_t *s1;
@@ -648,7 +648,7 @@
 		snd_pcm_group_for_each(pos, substream) {
 			s1 = snd_pcm_group_substream_entry(pos);
 			if (s1 != substream)
-				spin_unlock(&s1->self_group.lock);
+				spin_unlock(&s1->lock);
 			if (s1 == s)	/* end */
 				break;
 		}
@@ -686,9 +686,9 @@
 
 	if (snd_pcm_stream_linked(substream)) {
 		if (!spin_trylock(&substream->group->lock)) {
-			spin_unlock(&substream->self_group.lock);
+			spin_unlock(&substream->lock);
 			spin_lock(&substream->group->lock);
-			spin_lock(&substream->self_group.lock);
+			spin_lock(&substream->lock);
 		}
 		res = snd_pcm_action_group(ops, substream, state);
 		spin_unlock(&substream->group->lock);
@@ -710,14 +710,14 @@
 	read_lock_irq(&snd_pcm_link_rwlock);
 	if (snd_pcm_stream_linked(substream)) {
 		spin_lock(&substream->group->lock);
-		spin_lock(&substream->self_group.lock);
+		spin_lock(&substream->lock);
 		res = snd_pcm_action_group(ops, substream, state);
-		spin_unlock(&substream->self_group.lock);
+		spin_unlock(&substream->lock);
 		spin_unlock(&substream->group->lock);
 	} else {
-		spin_lock(&substream->self_group.lock);
+		spin_lock(&substream->lock);
 		res = snd_pcm_action_single(ops, substream, state);
-		spin_unlock(&substream->self_group.lock);
+		spin_unlock(&substream->lock);
 	}
 	read_unlock_irq(&snd_pcm_link_rwlock);
 	return res;
@@ -1136,23 +1136,17 @@
 
 	if (snd_pcm_stream_linked(substream)) {
 		if (!spin_trylock(&substream->group->lock)) {
-			spin_unlock(&substream->self_group.lock);
+			spin_unlock(&substream->lock);
 			spin_lock(&substream->group->lock);
-			spin_lock(&substream->self_group.lock);
+			spin_lock(&substream->lock);
 		}
 		snd_pcm_group_for_each(pos, substream) {
 			s = snd_pcm_group_substream_entry(pos);
 			if (s != substream)
-				spin_lock(&substream->self_group.lock);
-		}
-		snd_pcm_group_for_each(pos, substream) {
-			s = snd_pcm_group_substream_entry(pos);
+				spin_lock(&s->lock);
 			s->runtime->status->state = state;
-		}
-		snd_pcm_group_for_each(pos, substream) {
-			s = snd_pcm_group_substream_entry(pos);
 			if (s != substream)
-				spin_unlock(&substream->self_group.lock);
+				spin_unlock(&s->lock);
 		}
 		spin_unlock(&substream->group->lock);
 	} else {
@@ -1485,13 +1479,6 @@
 	return res;
 }
 
-static void relink_to_local(snd_pcm_substream_t *substream)
-{
-	substream->group = &substream->self_group;
-	INIT_LIST_HEAD(&substream->self_group.substreams);
-	list_add_tail(&substream->link_list, &substream->self_group.substreams);
-}
-
 static int snd_pcm_unlink(snd_pcm_substream_t *substream)
 {
 	struct list_head *pos;
@@ -1509,12 +1496,13 @@
 	}
 	if (count == 1) {	/* detach the last stream, too */
 		snd_pcm_group_for_each(pos, substream) {
-			relink_to_local(snd_pcm_group_substream_entry(pos));
+			snd_pcm_substream_t *s = snd_pcm_group_substream_entry(pos);
+			s->group = NULL;
 			break;
 		}
 		kfree(substream->group);
 	}
-	relink_to_local(substream);
+	substream->group = NULL;
        _end:
 	write_unlock_irq(&snd_pcm_link_rwlock);
 	return 0;

Re: ALSA + jack + xrun = kernel crash

[Jaroslav Kysela]

On Wed, 21 May 2003, Takashi Iwai wrote:

> At Wed, 21 May 2003 02:32:02 +0200,
> Pieter Palmers wrote:
> > 
> >   Ok, second try:
> > 
> > alsa 0.9.3c fresh from CVS
> >    ---------------------------------------
> >     /proc/asound/version:
> >    Advanced Linux Sound Architecture Driver Version 0.9.3c.
> >    Compiled on May 21 2003 for kernel 2.4.20-LL with versioned symbols.
> > 
> >     /proc/asound/cards:
> >    0 [AudioPCI       ]: ENS1371 - Ensoniq AudioPCI
> >                         Ensoniq AudioPCI ENS1371 at 0xb000, irq 5
> > 
> >    ---------------------------------------
> 
> how about this one?  this should fix another deadlock
> (including the simplified expression of stream lock)

Takashi, the self_group is designed to avoid mess in the lowlevel drivers. 
Now, the code is same for both linked and standalone streams. Please, do 
not remove it.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Takashi Iwai]

At Wed, 21 May 2003 13:35:39 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 21 May 2003, Takashi Iwai wrote:
> 
> > At Wed, 21 May 2003 02:32:02 +0200,
> > Pieter Palmers wrote:
> > > 
> > >   Ok, second try:
> > > 
> > > alsa 0.9.3c fresh from CVS
> > >    ---------------------------------------
> > >     /proc/asound/version:
> > >    Advanced Linux Sound Architecture Driver Version 0.9.3c.
> > >    Compiled on May 21 2003 for kernel 2.4.20-LL with versioned symbols.
> > > 
> > >     /proc/asound/cards:
> > >    0 [AudioPCI       ]: ENS1371 - Ensoniq AudioPCI
> > >                         Ensoniq AudioPCI ENS1371 at 0xb000, irq 5
> > > 
> > >    ---------------------------------------
> > 
> > how about this one?  this should fix another deadlock
> > (including the simplified expression of stream lock)
> 
> Takashi, the self_group is designed to avoid mess in the lowlevel drivers. 

which mess do you mean?
as far as i see, only self_group.lock is used in the code.
(so i replaced self_group with a single spinlock.)

> Now, the code is same for both linked and standalone streams. Please, do 
> not remove it.

ok.

meanwhile, i committed my fixes (without the self_group change) to cvs
now.  i hope this is the last fix for this problem...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Jaroslav Kysela]

On Wed, 21 May 2003, Takashi Iwai wrote:

> At Wed, 21 May 2003 13:35:39 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Wed, 21 May 2003, Takashi Iwai wrote:
> > 
> > > At Wed, 21 May 2003 02:32:02 +0200,
> > > Pieter Palmers wrote:
> > > > 
> > > >   Ok, second try:
> > > > 
> > > > alsa 0.9.3c fresh from CVS
> > > >    ---------------------------------------
> > > >     /proc/asound/version:
> > > >    Advanced Linux Sound Architecture Driver Version 0.9.3c.
> > > >    Compiled on May 21 2003 for kernel 2.4.20-LL with versioned symbols.
> > > > 
> > > >     /proc/asound/cards:
> > > >    0 [AudioPCI       ]: ENS1371 - Ensoniq AudioPCI
> > > >                         Ensoniq AudioPCI ENS1371 at 0xb000, irq 5
> > > > 
> > > >    ---------------------------------------
> > > 
> > > how about this one?  this should fix another deadlock
> > > (including the simplified expression of stream lock)
> > 
> > Takashi, the self_group is designed to avoid mess in the lowlevel drivers. 
> 
> which mess do you mean?
> as far as i see, only self_group.lock is used in the code.
> (so i replaced self_group with a single spinlock.)

See: snd_pcm_group_for_each()

If you remove self_group then you must use some condition in lowlevel 
drivers to distinct standalone and linked streams. I want to avoid this
condition.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Pieter Palmers]

Pieter Palmers wrote:

>>
>>
>> ok.
>>
>> meanwhile, i committed my fixes (without the self_group change) to cvs
>> now.  i hope this is the last fix for this problem...
>>
>>
>>  
>>
> So did I, but alas...
>
> installed the new CVS version.
>
> this time I tried using alsaplayer -d jack.
>
> apart from not getting any sound, all seemed to work for a while. I 
> then Ctrl-C 'd jack and restarted it. Result: instant lockup.
> I do have the impression that it takes longer for the lockup to occur.
>
> I'll try again with spiralsynthmodular, and I'll try to figure out if 
> the restarting of Jack has something to do with this.
>
> Pieter
>
and so I tried spiralsynthmodular...
it still hangs the system, but now it runs a little longer than 
yesterday (a minute instead of some seconds).
and the restarting of jack doesn't affect it, i.e. this time it crashed 
on the first jack session.

I'm sorry that I can't provide you with any more info... if you have 
some suggestions on gathering more usefull info, please let me know.

Pieter




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Tarragon Allen]

On Thursday 22 May 2003 09:08, Pieter Palmers wrote:
> Pieter Palmers wrote:
> >> ok.
> >>
> >> meanwhile, i committed my fixes (without the self_group change) to cvs
> >> now.  i hope this is the last fix for this problem...
> >
> > So did I, but alas...
> >
> > installed the new CVS version.
> >
> > this time I tried using alsaplayer -d jack.
> >
> > apart from not getting any sound, all seemed to work for a while. I
> > then Ctrl-C 'd jack and restarted it. Result: instant lockup.
> > I do have the impression that it takes longer for the lockup to occur.
> >
> > I'll try again with spiralsynthmodular, and I'll try to figure out if
> > the restarting of Jack has something to do with this.
> >
> > Pieter
>
> and so I tried spiralsynthmodular...
> it still hangs the system, but now it runs a little longer than
> yesterday (a minute instead of some seconds).
> and the restarting of jack doesn't affect it, i.e. this time it crashed
> on the first jack session.
>
> I'm sorry that I can't provide you with any more info... if you have
> some suggestions on gathering more usefull info, please let me know.
>
> Pieter

Just a longshot, and forgive me if it's already been raised : you aren't using 
ext3 by any chance? There are issues with kernel 2.4.20, ext3 which can cause 
lockups when being used to hard disk recording : this has been shown up while 
using Ardour. I don't know if it relates, but thought it might help.

t
-- 
GPG: http://n12turbo.com/tarragon/public.key


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Paul Davis]

>Just a longshot, and forgive me if it's already been raised : you aren't using
> 
>ext3 by any chance? There are issues with kernel 2.4.20, ext3 which can cause 
>lockups when being used to hard disk recording : this has been shown up while 
>using Ardour. I don't know if it relates, but thought it might help.

i haven't tried the latest CVS, but the lockups with recent CVS affect
me and my system has nothing but ext2.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Benny Sjostrand]

>
>
>Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
>prints a message saying it will reboot then doesn't). The crash happens
>when jackd xruns. I've been reproducing it using "jackd -d alsa" (other
>options don't make a difference) then "ladccad". Once the system crashs
>the only way to get any responce is with SysRq. Keys don't echo to the
>console and I can't switch VTs.
>
>Generally there is no error message or oops that I can see, even when
>debug=full is enable in ALSA. Early on I saw a message from jackd to the
>tune of "error write 512 somethings to device", but I have not been able
>to reproduce it. I am willing to run any tests that might help. I use
>journaling filesystems ;-) 
>
>My hardware is:
>Dual PIII 1Ghz with 512M RAM on a Tyan MB.
>SoundBlaster Live! Value
>ATI Radeon 8500 (using the closed-source ATI drivers; version 2.9.8)
>
>My software is:
>ALSA drivers 0.9.3a or current CVS
>Linux 2.4.20 (vanilla or gentoo patched)
>Jack 0.71.2
>Current Gentoo with testing packages enabled (~x86)
>  
>
Just want to tell that I'm experiencing almost the same problem (I got a 
Dual PIII 1Gz 256Mb
and two cs46xx soundcards)
After updating ALSA CVS today, jack is no longer able to start, it just 
locks up my machine, and
sometimes even the SysRQ hack dont react. (I've been several hours today 
fighting with this problem .....)
What I was able to find out from the SysRQ is that the EIP all the times 
seems
to be somewhere at: c0153804 <.text.lock.inode+135/211>, or 
sync_unlocked_inodes(...)
which dont make any sense to me. (?????????????)

One more interesting point is that if I start the jackd without the "-R" 
flag jack starts for a while,
sometimes I'm able to even stop/kill it. But after that no program is 
able to start or run correctly,
which feels like  that something is seriously corrupted in the kernel.

Now, for first time in my life I've downgraded ALSA to a previous CVS 
version, which seems
to work with JACK :(

/Benny



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

Re: ALSA + jack + xrun = kernel crash

[Jaroslav Kysela]

On Sat, 17 May 2003, Benny Sjostrand wrote:

> >
> >
> >Hello, I am experiencing a reletivly hard crash (SysRq works but SysRq-B
> >prints a message saying it will reboot then doesn't). The crash happens
> >when jackd xruns. I've been reproducing it using "jackd -d alsa" (other
> >options don't make a difference) then "ladccad". Once the system crashs
> >the only way to get any responce is with SysRq. Keys don't echo to the
> >console and I can't switch VTs.
> >
> >Generally there is no error message or oops that I can see, even when
> >debug=full is enable in ALSA. Early on I saw a message from jackd to the
> >tune of "error write 512 somethings to device", but I have not been able
> >to reproduce it. I am willing to run any tests that might help. I use
> >journaling filesystems ;-) 
> >
> >My hardware is:
> >Dual PIII 1Ghz with 512M RAM on a Tyan MB.
> >SoundBlaster Live! Value
> >ATI Radeon 8500 (using the closed-source ATI drivers; version 2.9.8)
> >
> >My software is:
> >ALSA drivers 0.9.3a or current CVS
> >Linux 2.4.20 (vanilla or gentoo patched)
> >Jack 0.71.2
> >Current Gentoo with testing packages enabled (~x86)
> >  
> >
> Just want to tell that I'm experiencing almost the same problem (I got a 
> Dual PIII 1Gz 256Mb
> and two cs46xx soundcards)
> After updating ALSA CVS today, jack is no longer able to start, it just 
> locks up my machine, and
> sometimes even the SysRQ hack dont react. (I've been several hours today 
> fighting with this problem .....)
> What I was able to find out from the SysRQ is that the EIP all the times 
> seems
> to be somewhere at: c0153804 <.text.lock.inode+135/211>, or 
> sync_unlocked_inodes(...)
> which dont make any sense to me. (?????????????)
> 
> One more interesting point is that if I start the jackd without the "-R" 
> flag jack starts for a while,
> sometimes I'm able to even stop/kill it. But after that no program is 
> able to start or run correctly,
> which feels like  that something is seriously corrupted in the kernel.
> 
> Now, for first time in my life I've downgraded ALSA to a previous CVS 
> version, which seems
> to work with JACK :(

It looks like spinlock problem. Could you recompile your kernel and ALSA
driver with spinlock debug enabled? Look for DEBUG_SPINLOCKS in
linux/include/linux/spinlock.h and change the value 0 to 2.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge