alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
* Re: Crash 2.6.32.x, Echo 3G, Alsa, SCSI
       [not found] <73211.74714.qm@web180714.mail.sp1.yahoo.com>
@ 2010-02-02 15:30 ` Clemens Ladisch
  2010-02-02 16:02   ` [alsa-devel] " Giuliano Pochini
  2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
  0 siblings, 2 replies; 13+ messages in thread
From: Clemens Ladisch @ 2010-02-02 15:30 UTC (permalink / raw)
  To: Frederick V Heitkamp, Giuliano Pochini, Takashi Iwai
  Cc: alsa-devel, linux-kernel

Frederick V Heitkamp wrote:
> Repeatable Hard Crash.
> What else do I need to provide?
> 
> [ 5484.995249] WriteControlReg: not written, no change
> [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok
> [ 5485.070159] Prepare rate=44100 format=2 channels=2
> [ 5485.070161] set_audio_format[14] = 5
> [ 5485.070166] Prepare rate=44100 format=2 channels=2
> [ 5485.070167] set_audio_format[14] = 5
> [ 5485.070003] PREEMPT SMP 
> ...
> [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g]
> ...
> [ 5485.965788]  [<c10041c0>] ? do_divide_error+0x0/0x90
> [ 5485.980619]  [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g]
> [ 5485.998047]  [<c104764e>] ? run_timer_softirq+0x17e/0x2e0
> [ 5486.014175]  [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g]
> [ 5486.033940]  [<c107a5d5>] ? handle_IRQ_event+0x45/0x190

bytes_to_frames() divides by runtime->frame_bits which is not set until
after the hw_params callback has succeeded, but the corresponding
chip->substream[] entry is set in that callback, by init_engine().  It
should probably have been set in the prepare callback.

Frederick, please try the patch below.

Takashi, is there any reason why the runtime-> fields are initialized
after the hw_params callback?  


Regards,
Clemens


--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -403,12 +403,6 @@
 	if (err < 0)
 		goto _error;
 
-	if (substream->ops->hw_params != NULL) {
-		err = substream->ops->hw_params(substream, params);
-		if (err < 0)
-			goto _error;
-	}
-
 	runtime->access = params_access(params);
 	runtime->format = params_format(params);
 	runtime->subformat = params_subformat(params);
@@ -446,6 +440,13 @@
 		runtime->boundary *= 2;
 
 	snd_pcm_timer_resolution_change(substream);
+
+	if (substream->ops->hw_params != NULL) {
+		err = substream->ops->hw_params(substream, params);
+		if (err < 0)
+			goto _error;
+	}
+
 	runtime->status->state = SNDRV_PCM_STATE_SETUP;
 
 	pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 15:30 ` Crash 2.6.32.x, Echo 3G, Alsa, SCSI Clemens Ladisch
@ 2010-02-02 16:02   ` Giuliano Pochini
  2010-02-03  2:48     ` Frederick V Heitkamp
  2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
  1 sibling, 1 reply; 13+ messages in thread
From: Giuliano Pochini @ 2010-02-02 16:02 UTC (permalink / raw)
  To: Clemens Ladisch
  Cc: Frederick V Heitkamp, Takashi Iwai, linux-kernel, alsa-devel



On Tue, 2 Feb 2010, Clemens Ladisch wrote:

>> [ 5485.965788]  [<c10041c0>] ? do_divide_error+0x0/0x90
>> [ 5485.980619]  [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g]
>> [ 5485.998047]  [<c104764e>] ? run_timer_softirq+0x17e/0x2e0
>> [ 5486.014175]  [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g]
>> [ 5486.033940]  [<c107a5d5>] ? handle_IRQ_event+0x45/0x190
>
> bytes_to_frames() divides by runtime->frame_bits which is not set until
> after the hw_params callback has succeeded, but the corresponding
> chip->substream[] entry is set in that callback, by init_engine().  It
> should probably have been set in the prepare callback.

How can an irq arrive before hw_params() and prepare() ?

Frederick, are you using the midi interface ?


--
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 15:30 ` Crash 2.6.32.x, Echo 3G, Alsa, SCSI Clemens Ladisch
  2010-02-02 16:02   ` [alsa-devel] " Giuliano Pochini
@ 2010-02-02 22:09   ` Giuliano Pochini
  2010-02-03  2:51     ` Frederick V Heitkamp
                       ` (2 more replies)
  1 sibling, 3 replies; 13+ messages in thread
From: Giuliano Pochini @ 2010-02-02 22:09 UTC (permalink / raw)
  To: Clemens Ladisch
  Cc: Frederick V Heitkamp, Takashi Iwai, linux-kernel, alsa-devel

On Tue, 02 Feb 2010 16:30:27 +0100
Clemens Ladisch <clemens@ladisch.de> wrote:

> Frederick V Heitkamp wrote:
> > Repeatable Hard Crash.
> > What else do I need to provide?
> > 
> > [ 5484.995249] WriteControlReg: not written, no change
> > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok
> > [ 5485.070159] Prepare rate=44100 format=2 channels=2
> > [ 5485.070161] set_audio_format[14] = 5
> > [ 5485.070166] Prepare rate=44100 format=2 channels=2
> > [ 5485.070167] set_audio_format[14] = 5
> > [ 5485.070003] PREEMPT SMP 
> > ...
> > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g]
> > ...
> > [ 5485.965788]  [<c10041c0>] ? do_divide_error+0x0/0x90
> > [ 5485.980619]  [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g]
> > [ 5485.998047]  [<c104764e>] ? run_timer_softirq+0x17e/0x2e0
> > [ 5486.014175]  [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g]
> > [ 5486.033940]  [<c107a5d5>] ? handle_IRQ_event+0x45/0x190
> 
> bytes_to_frames() divides by runtime->frame_bits which is not set until
> after the hw_params callback has succeeded, but the corresponding
> chip->substream[] entry is set in that callback, by init_engine().  It
> should probably have been set in the prepare callback.

I've just had another look at my code. Although it never happened to me, it
is indeed possible when hw_params() completes if another substream is
already running. The reason is that the card delivers an irq when it
executes an irq instruction in any of the running s-g lists. The irq
handler cannot know which substream caused it, so it has to call the
pointer() function for each of the configured substreams (ie. the ones
which completed one of the pcm_*_hw_params() callbacks.

There is another possible fix. I tested it briefly. It looks ok wrt race
conditions because pipe->state is set only in the trigger callback. I hope
I didn't overlook anything again...


Signed-off-by: Giuliano Pochini <pochini@shiny.it>

--- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig	2010-02-02 22:37:33.000000000 +0100
+++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c	2010-02-02 22:44:03.000000000 +0100
@@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
 	/* The hardware doesn't tell us which substream caused the irq,
 	thus we have to check all running substreams. */
 	for (ss = 0; ss < DSP_MAXPIPES; ss++) {
-		if ((substream = chip->substream[ss])) {
+		substream = chip->substream[ss];
+		if (substream && ((struct audiopipe *)substream->runtime->
+				private_data)->state == PIPE_STATE_STARTED) {
 			period = pcm_pointer(substream) /
 				substream->runtime->period_size;
 			if (period != chip->last_period[ss]) {


-- 
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 16:02   ` [alsa-devel] " Giuliano Pochini
@ 2010-02-03  2:48     ` Frederick V Heitkamp
  0 siblings, 0 replies; 13+ messages in thread
From: Frederick V Heitkamp @ 2010-02-03  2:48 UTC (permalink / raw)
  To: Giuliano Pochini, Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, linux-kernel





Frederick, are you using the midi interface ?

No.

--
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
@ 2010-02-03  2:51     ` Frederick V Heitkamp
  2010-02-03  2:53     ` [alsa-devel] " Frederick V Heitkamp
  2010-05-31 19:05     ` [LAU] " F. Heitkamp
  2 siblings, 0 replies; 13+ messages in thread
From: Frederick V Heitkamp @ 2010-02-03  2:51 UTC (permalink / raw)
  To: Giuliano Pochini, Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, linux-kernel

There is another possible fix. I tested it briefly. It looks ok wrt race

conditions because pipe->state is set only in the trigger callback. I hope
I didn't overlook anything again...


Signed-off-by: Giuliano Pochini <pochini@shiny.it>

--- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig    2010-02-02 22:37:33.000000000 +0100
+++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c    2010-02-02 22:44:03.000000000 +0100
@@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
    /* The hardware doesn't tell us which substream caused the irq,
    thus we have to check all running substreams. */
    for (ss = 0; ss < DSP_MAXPIPES; ss++) {
-        if ((substream = chip->substream[ss])) {
+        substream = chip->substream[ss];
+        if (substream && ((struct audiopipe *)substream->runtime->
+                private_data)->state == PIPE_STATE_STARTED) {
            period = pcm_pointer(substream) /
                substream->runtime->period_size;
            if (period != chip->last_period[ss]) {


-- 
Giuliano.

I am using this patch.  So far, no crash.


Fred

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
  2010-02-03  2:51     ` Frederick V Heitkamp
@ 2010-02-03  2:53     ` Frederick V Heitkamp
  2010-05-31 19:05     ` [LAU] " F. Heitkamp
  2 siblings, 0 replies; 13+ messages in thread
From: Frederick V Heitkamp @ 2010-02-03  2:53 UTC (permalink / raw)
  To: Giuliano Pochini, Clemens Ladisch; +Cc: Takashi Iwai, linux-kernel, alsa-devel


There is another possible fix. I tested it briefly. It looks ok wrt race
conditions because pipe->state is set only in the trigger callback. I hope
I didn't overlook anything again...


Signed-off-by: Giuliano Pochini <pochini@shiny.it>

--- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig    2010-02-02 22:37:33.000000000 +0100
+++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c    2010-02-02 22:44:03.000000000 +0100
@@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
    /* The hardware doesn't tell us which substream caused the irq,
    thus we have to check all running substreams. */
    for (ss = 0; ss < DSP_MAXPIPES; ss++) {
-        if ((substream = chip->substream[ss])) {
+        substream = chip->substream[ss];
+        if (substream && ((struct audiopipe *)substream->runtime->
+                private_data)->state == PIPE_STATE_STARTED) {
            period = pcm_pointer(substream) /
                substream->runtime->period_size;
            if (period != chip->last_period[ss]) {


-- 
Giuliano.


I am using this patch.  So far, no crash.


Fred


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [LAU] [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
  2010-02-03  2:51     ` Frederick V Heitkamp
  2010-02-03  2:53     ` [alsa-devel] " Frederick V Heitkamp
@ 2010-05-31 19:05     ` F. Heitkamp
  2010-05-31 20:59       ` Giuliano Pochini
  2 siblings, 1 reply; 13+ messages in thread
From: F. Heitkamp @ 2010-05-31 19:05 UTC (permalink / raw)
  To: Giuliano Pochini,
	linux-audio-user-cunTk1MwBs/CEJeg2xFRV2D2FQJk+8+b,
	alsa-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Clemens Ladisch,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On 02/02/10 17:09, Giuliano Pochini wrote:
> On Tue, 02 Feb 2010 16:30:27 +0100
> Clemens Ladisch<clemens-P6GI/4k7KOmELgA04lAiVw@public.gmane.org>  wrote:
>
>    
>> Frederick V Heitkamp wrote:
>>      
>>> Repeatable Hard Crash.
>>> What else do I need to provide?
>>>
>>> [ 5484.995249] WriteControlReg: not written, no change
>>> [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok
>>> [ 5485.070159] Prepare rate=44100 format=2 channels=2
>>> [ 5485.070161] set_audio_format[14] = 5
>>> [ 5485.070166] Prepare rate=44100 format=2 channels=2
>>> [ 5485.070167] set_audio_format[14] = 5
>>> [ 5485.070003] PREEMPT SMP
>>> ...
>>> [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g]
>>> ...
>>> [ 5485.965788]  [<c10041c0>] ? do_divide_error+0x0/0x90
>>> [ 5485.980619]  [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g]
>>> [ 5485.998047]  [<c104764e>] ? run_timer_softirq+0x17e/0x2e0
>>> [ 5486.014175]  [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g]
>>> [ 5486.033940]  [<c107a5d5>] ? handle_IRQ_event+0x45/0x190
>>>        
>> bytes_to_frames() divides by runtime->frame_bits which is not set until
>> after the hw_params callback has succeeded, but the corresponding
>> chip->substream[] entry is set in that callback, by init_engine().  It
>> should probably have been set in the prepare callback.
>>      
> I've just had another look at my code. Although it never happened to me, it
> is indeed possible when hw_params() completes if another substream is
> already running. The reason is that the card delivers an irq when it
> executes an irq instruction in any of the running s-g lists. The irq
> handler cannot know which substream caused it, so it has to call the
> pointer() function for each of the configured substreams (ie. the ones
> which completed one of the pcm_*_hw_params() callbacks.
>
> There is another possible fix. I tested it briefly. It looks ok wrt race
> conditions because pipe->state is set only in the trigger callback. I hope
> I didn't overlook anything again...
>
>
> Signed-off-by: Giuliano Pochini<pochini-JrPinEReyO8@public.gmane.org>
>
> --- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig	2010-02-02 22:37:33.000000000 +0100
> +++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c	2010-02-02 22:44:03.000000000 +0100
> @@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
>   	/* The hardware doesn't tell us which substream caused the irq,
>   	thus we have to check all running substreams. */
>   	for (ss = 0; ss<  DSP_MAXPIPES; ss++) {
> -		if ((substream = chip->substream[ss])) {
> +		substream = chip->substream[ss];
> +		if (substream&&  ((struct audiopipe *)substream->runtime->
> +				private_data)->state == PIPE_STATE_STARTED) {
>   			period = pcm_pointer(substream) /
>   				substream->runtime->period_size;
>   			if (period != chip->last_period[ss]) {
>
>
>    
I've tried some newer kernels.  Still having problems with the echo 3G.  
This is kernel version:
2.6.32.13.  The above patches posted to the linux kernel list seemed to 
get rid of the crashes, but evidently did not go into the main kernel tree.
Any help appreciated.  I am willing to help to the best of my ability. 
Thanks!

Fred

This segment keeps looping to infinity:
[ 9331.528043] pcm_hw_free(0)
[ 9331.529200] free_pipes: Pipe 0
[ 9331.545230] pcm_hw_freed
[ 9331.552808] pcm_hw_freed
[ 9331.560365] pcm_close
[ 9331.567145] pcm_close  oc=0  cs=1  rs=1
[ 9331.578595] pcm_close2 oc=0  cs=1  rs=0
[ 9490.665630] pcm_analog_out_open
[ 9490.675009] max_channels=6
[ 9490.683109] pcm_analog_out_open  cs=1  oc=1  r=44100
[ 9490.698046] allocate_pipes: ch=0 int=2
[ 9490.702428] allocate_pipes: ok
[ 9490.718350] allocate_pipes()=0
[ 9490.727466] pcm_hw_params (bufsize=131072B periods=2 persize=65536B)
[ 9490.746450] SetSampleRate: 44100 clock d63
[ 9490.756870] WriteControlReg: Setting 0xd63, 0x3bfe
[ 9490.768468] WriteControlReg: not written, no change
[ 9490.787532] pcm_hw_params ok
[ 9490.796155] Prepare rate=44100 format=2 channels=2
[ 9490.810464] set_audio_format[0] = 5
[ 9490.820922] Prepare rate=44100 format=2 channels=2
[ 9490.835233] set_audio_format[0] = 5
[ 9490.845758] pcm_trigger start
[ 9490.847582] start_transport 1
[ 9497.317297] pcm_trigger stop
[ 9497.318517] stop_transport 1
[ 9497.334516] pcm_hw_free(0)
[ 9497.335483] free_pipes: Pipe 0
[ 9497.351709] pcm_hw_freed
[ 9497.359278] pcm_hw_freed
[ 9497.366836] pcm_close
[ 9497.373613] pcm_close  oc=0  cs=1  rs=1
[ 9497.385061] pcm_close2 oc=0  cs=1  rs=0
[ 9503.442232] pcm_analog_out_open
[ 9503.451611] max_channels=6
[ 9503.459713] pcm_analog_out_open  cs=1  oc=1  r=44100
[ 9503.474663] allocate_pipes: ch=0 int=2
[ 9503.484394] allocate_pipes: ok
[ 9503.494962] allocate_pipes()=0
[ 9503.504081] pcm_hw_params (bufsize=131072B periods=2 persize=65536B)
[ 9503.523069] SetSampleRate: 44100 clock d63
[ 9503.532174] WriteControlReg: Setting 0xd63, 0x3bfe
[ 9503.545805] WriteControlReg: not written, no change
[ 9503.564143] pcm_hw_params ok
[ 9503.572765] Prepare rate=44100 format=2 channels=2
[ 9503.587074] set_audio_format[0] = 5
[ 9503.597490] Prepare rate=44100 format=2 channels=2
[ 9503.611839] set_audio_format[0] = 5
[ 9503.622355] pcm_trigger start
[ 9503.623236] start_transport 1
[ 9510.095872] pcm_trigger stop
[ 9510.096578] stop_transport 1
[ 9510.113193] pcm_hw_free(0)
[ 9510.114163] free_pipes: Pipe 0
[ 9510.130405] pcm_hw_freed
[ 9510.137982] pcm_hw_freed
[ 9510.145541] pcm_close
[ 9510.152317] pcm_close  oc=0  cs=1  rs=1

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-05-31 19:05     ` [LAU] " F. Heitkamp
@ 2010-05-31 20:59       ` Giuliano Pochini
  2010-06-01  5:37         ` Takashi Iwai
  2010-06-01 12:25         ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
  0 siblings, 2 replies; 13+ messages in thread
From: Giuliano Pochini @ 2010-05-31 20:59 UTC (permalink / raw)
  To: F. Heitkamp
  Cc: alsa-devel, Takashi Iwai, linux-audio-user, Clemens Ladisch,
	linux-kernel, alsa-user

On Mon, 31 May 2010 15:05:08 -0400
"F. Heitkamp" <heitkamp@ameritech.net> wrote:

> On 02/02/10 17:09, Giuliano Pochini wrote:
> > On Tue, 02 Feb 2010 16:30:27 +0100
> > Clemens Ladisch<clemens@ladisch.de>  wrote:
> >
> >    
> >> Frederick V Heitkamp wrote:
> >>      
> >>> Repeatable Hard Crash.
> >>> What else do I need to provide?
[...]
> > Signed-off-by: Giuliano Pochini<pochini@shiny.it>
> >
> > --- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig	2010-02-02 22:37:33.000000000 +0100
> > +++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c	2010-02-02 22:44:03.000000000 +0100
> > @@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
> >   	/* The hardware doesn't tell us which substream caused the irq,
> >   	thus we have to check all running substreams. */
> >   	for (ss = 0; ss<  DSP_MAXPIPES; ss++) {
> > -		if ((substream = chip->substream[ss])) {
> > +		substream = chip->substream[ss];
> > +		if (substream&&  ((struct audiopipe *)substream->runtime->
> > +				private_data)->state == PIPE_STATE_STARTED) {
> >   			period = pcm_pointer(substream) /
> >   				substream->runtime->period_size;
> >   			if (period != chip->last_period[ss]) {
> >
> >
> >    
> I've tried some newer kernels.  Still having problems with the echo 3G.  
> This is kernel version:
> 2.6.32.13.  The above patches posted to the linux kernel list seemed to 
> get rid of the crashes, but evidently did not go into the main kernel tree.

Indeed. I've just checked 2.6.33 and the patch isn't there. It's in 2.6.34.

If you need 2.6.32.13 you can apply the above patch to the kernel tree or
download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.23.tar.bz2,
otherwise just use the latest kernel.


-- 
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-05-31 20:59       ` Giuliano Pochini
@ 2010-06-01  5:37         ` Takashi Iwai
  2010-06-01 12:25         ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
  1 sibling, 0 replies; 13+ messages in thread
From: Takashi Iwai @ 2010-06-01  5:37 UTC (permalink / raw)
  To: Giuliano Pochini
  Cc: alsa-devel, F. Heitkamp, linux-audio-user, Clemens Ladisch,
	linux-kernel, alsa-user

At Mon, 31 May 2010 22:59:36 +0200,
Giuliano Pochini wrote:
> 
> On Mon, 31 May 2010 15:05:08 -0400
> "F. Heitkamp" <heitkamp@ameritech.net> wrote:
> 
> > On 02/02/10 17:09, Giuliano Pochini wrote:
> > > On Tue, 02 Feb 2010 16:30:27 +0100
> > > Clemens Ladisch<clemens@ladisch.de>  wrote:
> > >
> > >    
> > >> Frederick V Heitkamp wrote:
> > >>      
> > >>> Repeatable Hard Crash.
> > >>> What else do I need to provide?
> [...]
> > > Signed-off-by: Giuliano Pochini<pochini@shiny.it>
> > >
> > > --- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig	2010-02-02 22:37:33.000000000 +0100
> > > +++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c	2010-02-02 22:44:03.000000000 +0100
> > > @@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
> > >   	/* The hardware doesn't tell us which substream caused the irq,
> > >   	thus we have to check all running substreams. */
> > >   	for (ss = 0; ss<  DSP_MAXPIPES; ss++) {
> > > -		if ((substream = chip->substream[ss])) {
> > > +		substream = chip->substream[ss];
> > > +		if (substream&&  ((struct audiopipe *)substream->runtime->
> > > +				private_data)->state == PIPE_STATE_STARTED) {
> > >   			period = pcm_pointer(substream) /
> > >   				substream->runtime->period_size;
> > >   			if (period != chip->last_period[ss]) {
> > >
> > >
> > >    
> > I've tried some newer kernels.  Still having problems with the echo 3G.  
> > This is kernel version:
> > 2.6.32.13.  The above patches posted to the linux kernel list seemed to 
> > get rid of the crashes, but evidently did not go into the main kernel tree.
> 
> Indeed. I've just checked 2.6.33 and the patch isn't there. It's in 2.6.34.
> 
> If you need 2.6.32.13 you can apply the above patch to the kernel tree or
> download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.23.tar.bz2,
> otherwise just use the latest kernel.

Care to send the patch to stable kernel (with the upstream commit id)?


thanks,

Takashi

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [LAU] [Alsa-user] [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-05-31 20:59       ` Giuliano Pochini
  2010-06-01  5:37         ` Takashi Iwai
@ 2010-06-01 12:25         ` F. Heitkamp
  2010-06-02 22:08           ` [Alsa-user] " Giuliano Pochini
  1 sibling, 1 reply; 13+ messages in thread
From: F. Heitkamp @ 2010-06-01 12:25 UTC (permalink / raw)
  To: Giuliano Pochini
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	linux-audio-user-cunTk1MwBs/CEJeg2xFRV2D2FQJk+8+b,
	Clemens Ladisch, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	alsa-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

On 05/31/10 16:59, Giuliano Pochini wrote:
> On Mon, 31 May 2010 15:05:08 -0400
> "F. Heitkamp"<heitkamp-yWtbtysYrB+LZ21kGMrzwg@public.gmane.org>  wrote:
>
>    
>> On 02/02/10 17:09, Giuliano Pochini wrote:
>>      
>>> On Tue, 02 Feb 2010 16:30:27 +0100
>>> Clemens Ladisch<clemens-P6GI/4k7KOmELgA04lAiVw@public.gmane.org>   wrote:
>>>
>>>
>>>        
>>>> Frederick V Heitkamp wrote:
>>>>
>>>>          
>>>>> Repeatable Hard Crash.
>>>>> What else do I need to provide?
>>>>>            
> [...]
>    
>>> Signed-off-by: Giuliano Pochini<pochini-JrPinEReyO8@public.gmane.org>
>>>
>>> --- alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c__orig	2010-02-02 22:37:33.000000000 +0100
>>> +++ alsa-driver-1.0.22.1/alsa-kernel/pci/echoaudio/echoaudio.c	2010-02-02 22:44:03.000000000 +0100
>>> @@ -1821,7 +1821,9 @@ static irqreturn_t snd_echo_interrupt(in
>>>    	/* The hardware doesn't tell us which substream caused the irq,
>>>    	thus we have to check all running substreams. */
>>>    	for (ss = 0; ss<   DSP_MAXPIPES; ss++) {
>>> -		if ((substream = chip->substream[ss])) {
>>> +		substream = chip->substream[ss];
>>> +		if (substream&&   ((struct audiopipe *)substream->runtime->
>>> +				private_data)->state == PIPE_STATE_STARTED) {
>>>    			period = pcm_pointer(substream) /
>>>    				substream->runtime->period_size;
>>>    			if (period != chip->last_period[ss]) {
>>>
>>>
>>>
>>>        
>> I've tried some newer kernels.  Still having problems with the echo 3G.
>> This is kernel version:
>> 2.6.32.13.  The above patches posted to the linux kernel list seemed to
>> get rid of the crashes, but evidently did not go into the main kernel tree.
>>      
> Indeed. I've just checked 2.6.33 and the patch isn't there. It's in 2.6.34.
>
> If you need 2.6.32.13 you can apply the above patch to the kernel tree or
> download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.23.tar.bz2,
> otherwise just use the latest kernel.
>    
I tried 2.6.34.   I have jack 1.9..5 installed.  I was able to use 
rhythmbox to play mp3s.  I could not use the echomixer app.  It complained
about a channels mismatch.

My goal is to be able to plug in a MIDI keyboard, or USB guitar 
interface and play along with songs etc.

I plugged in a MIDI keyboard, "/proc/asound/cards" showed the keyboard 
was recognized.  The keyboard has a USB and MIDI interface.
I am not sure if they both work at the same time.  I had the MIDI cable 
plugged into the Gina3G, but I could not tell if the keyboard was 
recognized.
I compiled csound5.  When I engaged it the system immediately froze and 
started spitting out:

5831.768583] set_audio_format[0] = 86
[ 5831.768610] pcm_trigger start
[ 5831.768611] start_transport 4001
[ 5831.790538] pcm_trigger stop
[ 5831.790539] stop_transport 4001
[ 5831.790576] Prepare rate=48000 format=10 channels=2
[ 5831.790578] set_audio_format[14] = 7
[ 5831.790579] Prepare rate=48000 format=10 channels=6
[ 5831.790580] set_audio_format[0] = 86
[ 5831.790608] pcm_trigger start
[ 5831.790609] start_transport 4001
[ 5831.812538] pcm_trigger stop
[ 5831.812540] stop_transport 4001
[ 5831.812576] Prepare rate=48000 format=10 channels=2
[ 5831.812577] set_audio_format[14] = 7
[ 5831.812578] Prepare rate=48000 format=10 channels=6
[ 5831.812580] set_audio_format[0] = 86
[ 5831.812607] pcm_trigger start
[ 5831.812608] start_transport 4001
[ 5831.834537] pcm_trigger stop
[ 5831.834539] stop_transport 4001
[ 5831.834576] Prepare rate=48000 format=10 channels=2
[ 5831.834577] set_audio_format[14] = 7
[ 5831.834579] Prepare rate=48000 format=10 channels=6
[ 5831.834580] set_audio_format[0] = 86
[ 5831.834607] pcm_trigger start
[ 5831.834608] start_transport 4001
[ 5831.856536] pcm_trigger stop
[ 5831.856538] stop_transport 4001
[ 5831.856574] Prepare rate=48000 format=10 channels=2
[ 5831.856576] set_audio_format[14] = 7
[ 5831.856577] Prepare rate=48000 format=10 channels=6
[ 5831.856579] set_audio_format[0] = 86
[ 5831.856606] pcm_trigger start
[ 5831.856607] start_transport 4001
[ 5831.878536] pcm_trigger stop
[ 5831.878538] stop_transport 4001
[ 5831.878575] Prepare rate=48000 format=10 channels=2
[ 5831.878576] set_audio_format[14] = 7
[ 5831.878578] Prepare rate=48000 format=10 channels=6
[ 5831.878579] set_audio_format[0] = 86
[ 5831.878606] pcm_trigger start
[ 5831.878607] start_transport 4001
[ 5831.900535] pcm_trigger stop
[ 5831.900537] stop_transport 4001
[ 5831.900575] Prepare rate=48000 format=10 channels=2
[ 5831.900576] set_audio_format[14] = 7
[ 5831.900578] Prepare rate=48000 format=10 channels=6
[ 5831.900579] set_audio_format[0] = 86
[ 5831.900606] pcm_trigger start
[ 5831.900607] start_transport 4001
[ 5831.922535] pcm_trigger stop
[ 5831.922537] stop_transport 4001
[ 5831.922576] Prepare rate=48000 format=10 channels=2
[ 5831.922578] set_audio_format[14] = 7
[ 5831.922579] Prepare rate=48000 format=10 channels=6
[ 5831.922580] set_audio_format[0] = 86
[ 5831.922608] pcm_trigger start
[ 5831.922609] start_transport 4001
[ 5831.944535] pcm_trigger stop
[ 5831.944537] stop_transport 4001
[ 5831.944575] Prepare rate=48000 format=10 channels=2
[ 5831.944576] set_audio_format[14] = 7
[ 5831.944578] Prepare rate=48000 format=10 channels=6
[ 5831.944579] set_audio_format[0] = 86
[ 5831.944607] pcm_trigger start
[ 5831.944608] start_transport 4001
[ 5831.966536] pcm_trigger stop
[ 5831.966538] stop_transport 4001
[ 5831.966576] Prepare rate=48000 format=10 channels=2
[ 5831.966578] set_audio_format[14] = 7
[ 5831.966579] Prepare rate=48000 format=10 channels=6
[ 5831.966580] set_audio_format[0] = 86
[ 5831.966609] pcm_trigger start
[ 5831.966610] start_transport 4001
[ 5831.988533] pcm_trigger stop
[ 5831.988535] stop_transport 4001
[ 5831.988572] Prepare rate=48000 format=10 channels=2
[ 5831.988574] set_audio_format[14] = 7
[ 5831.988576] Prepare rate=48000 format=10 channels=6
[ 5831.988577] set_audio_format[0] = 86
[ 5831.988604] pcm_trigger start
[ 5831.988605] start_transport 4001
[ 5832.010532] pcm_trigger stop
[ 5832.010534] stop_transport 4001
[ 5832.010572] Prepare rate=48000 format=10 channels=2
[ 5832.010574] set_audio_format[14] = 7
[ 5832.010575] Prepare rate=48000 format=10 channels=6
[ 5832.010576] set_audio_format[0] = 86
[ 5832.010604] pcm_trigger start
[ 5832.010605] start_transport 4001
[ 5832.032531] pcm_trigger stop
[ 5832.032533] stop_transport 4001
[ 5832.032569] Prepare rate=48000 format=10 channels=2
[ 5832.032570] set_audio_format[14] = 7
[ 5832.032572] Prepare rate=48000 format=10 channels=6
[ 5832.032573] set_audio_format[0] = 86
[ 5832.032600] pcm_trigger start
[ 5832.032601] start_transport 4001
[ 5832.054532] pcm_trigger stop
[ 5832.054534] stop_transport 4001
[ 5832.054571] Prepare rate=48000 format=10 channels=2
[ 5832.054573] set_audio_format[14] = 7
[ 5832.054574] Prepare rate=48000 format=10 channels=6
[ 5832.054575] set_audio_format[0] = 86
[ 5832.054602] pcm_trigger start
[ 5832.054603] start_transport 4001
[ 5832.076529] pcm_trigger stop
[ 5832.076531] stop_transport 4001
[ 5832.076567] Prepare rate=48000 format=10 channels=2
[ 5832.076568] set_audio_format[14] = 7
[ 5832.076570] Prepare rate=48000 format=10 channels=6
[ 5832.076571] set_audio_format[0] = 86
[ 5832.076598] pcm_trigger start
[ 5832.076599] start_transport 4001
[ 5832.098530] pcm_trigger stop
[ 5832.098532] stop_transport 4001
[ 5832.098568] Prepare rate=48000 format=10 channels=2
[ 5832.098569] set_audio_format[14] = 7
[ 5832.098570] Prepare rate=48000 format=10 channels=6
[ 5832.098571] set_audio_format[0] = 86
[ 5832.098599] pcm_trigger start
[ 5832.098600] start_transport 4001
[ 5832.120532] pcm_trigger stop
[ 5832.120533] stop_transport 4001
[ 5832.120573] Prepare rate=48000 format=10 channels=2
[ 5832.120575] set_audio_format[14] = 7
[ 5832.120576] Prepare rate=48000 format=10 channels=6
[ 5832.120577] set_audio_format[0] = 86
[ 5832.120606] pcm_trigger start
[ 5832.120607] start_transport 4001
[ 5832.142529] pcm_trigger stop
[ 5832.142530] stop_transport 4001
[ 5832.142569] Prepare rate=48000 format=10 channels=2
[ 5832.142570] set_audio_format[14] = 7
[ 5832.142571] Prepare rate=48000 format=10 channels=6
[ 5832.142573] set_audio_format[0] = 86
[ 5832.142600] pcm_trigger start
[ 5832.142601] start_transport 4001
[ 5832.164529] pcm_trigger stop
[ 5832.164530] stop_transport 4001
[ 5832.164568] Prepare rate=48000 format=10 channels=2
[ 5832.164569] set_audio_format[14] = 7
[ 5832.164571] Prepare rate=48000 format=10 channels=6
[ 5832.164572] set_audio_format[0] = 86
[ 5832.164599] pcm_trigger start
[ 5832.164600] start_transport 4001
[ 5832.186528] pcm_trigger stop
[ 5832.186529] stop_transport 4001
[ 5832.186567] Prepare rate=48000 format=10 channels=2
[ 5832.186568] set_audio_format[14] = 7
[ 5832.186570] Prepare rate=48000 format=10 channels=6
[ 5832.186571] set_audio_format[0] = 86
[ 5832.186601] pcm_trigger start
[ 5832.186602] start_transport 4001
[ 5832.208527] pcm_trigger stop
[ 5832.208528] stop_transport 4001
[ 5832.208564] Prepare rate=48000 format=10 channels=2
[ 5832.208566] set_audio_format[14] = 7
[ 5832.208567] Prepare rate=48000 format=10 channels=6
[ 5832.208569] set_audio_format[0] = 86
[ 5832.208596] pcm_trigger start
[ 5832.208597] start_transport 4001
[ 5832.230526] pcm_trigger stop
[ 5832.230527] stop_transport 4001
[ 5832.230565] Prepare rate=48000 format=10 channels=2
[ 5832.230566] set_audio_format[14] = 7
[ 5832.230567] Prepare rate=48000 format=10 channels=6
[ 5832.230568] set_audio_format[0] = 86
[ 5832.230596] pcm_trigger start
[ 5832.230597] start_transport 4001
[ 5832.252545] pcm_trigger stop
[ 5832.252547] stop_transport 4001
[ 5832.252583] Prepare rate=48000 format=10 channels=2
[ 5832.252584] set_audio_format[14] = 7
[ 5832.252586] Prepare rate=48000 format=10 channels=6
[ 5832.252587] set_audio_format[0] = 86
[ 5832.252614] pcm_trigger start
[ 5832.252615] start_transport 4001
[ 5832.274524] pcm_trigger stop
[ 5832.274526] stop_transport 4001
[ 5832.274561] Prepare rate=48000 format=10 channels=2
[ 5832.274563] set_audio_format[14] = 7
[ 5832.274564] Prepare rate=48000 format=10 channels=6
[ 5832.274565] set_audio_format[0] = 86
[ 5832.274593] pcm_trigger start
[ 5832.274594] start_transport 4001
[ 5832.296536] pcm_trigger stop
[ 5832.296538] stop_transport 4001
[ 5832.296576] Prepare rate=48000 format=10 channels=2
[ 5832.296577] set_audio_format[14] = 7
[ 5832.296578] Prepare rate=48000 format=10 channels=6
[ 5832.296579] set_audio_format[0] = 86
[ 5832.296606] pcm_trigger start
[ 5832.296607] start_transport 4001
[ 5832.318525] pcm_trigger stop
[ 5832.318527] stop_transport 4001
[ 5832.318566] Prepare rate=48000 format=10 channels=2
[ 5832.318567] set_audio_format[14] = 7
[ 5832.318569] Prepare rate=48000 format=10 channels=6
[ 5832.318570] set_audio_format[0] = 86
[ 5832.318598] pcm_trigger start
[ 5832.318599] start_transport 4001
[ 5832.340523] pcm_trigger stop
[ 5832.340524] stop_transport 4001
[ 5832.340563] Prepare rate=48000 format=10 channels=2
[ 5832.340564] set_audio_format[14] = 7
[ 5832.340566] Prepare rate=48000 format=10 channels=6
[ 5832.340567] set_audio_format[0] = 86
[ 5832.340594] pcm_trigger start
[ 5832.340595] start_transport 4001
[ 5832.362522] pcm_trigger stop
[ 5832.362524] stop_transport 4001
[ 5834.003252] SysRq : Terminate All Tasks
[ 5846.410995] pcm_close
[ 5846.410997] pcm_close  oc=2  cs=0  rs=1
[ 5846.410998] pcm_close2 oc=2  cs=0  rs=1
[ 5846.449499] Prepare rate=48000 format=10 channels=2
[ 5846.473577] set_audio_format[14] = 7
[ 5846.484293] Prepare rate=48000 format=10 channels=6
[ 5846.503645] set_audio_format[0] = 86
[ 5846.514449] pcm_trigger start
[ 5846.515307] start_transport 4001
[ 5846.533291] pcm_trigger stop
[ 5846.534001] stop_transport 4001
[ 5846.567444] pcm_hw_free(14)
[ 5846.568002] free_pipes: Pipe 14
[ 5846.585146] pcm_hw_freed
[ 5846.592757] pcm_hw_freed
[ 5846.600307] pcm_close
[ 5846.607086] pcm_close  oc=1  cs=0  rs=1
[ 5846.618528] pcm_close2 oc=1  cs=1  rs=1
[ 5846.630021] pcm_hw_free(0)
[ 5846.631001] free_pipes: Pipe 0
[ 5846.647193] pcm_hw_freed
[ 5846.654751] pcm_hw_freed
[ 5846.662303] pcm_close
[ 5846.669072] pcm_close  oc=0  cs=1  rs=1
[ 5846.680516] pcm_close2 oc=0  cs=1  rs=0
[ 5846.706051] uhci_hcd 0000:00:1d.2: release dev 4 ep81-INT, period 8, 
phase 4s
[ 5846.783378] [drm] Resetting GPU

>
>    

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Alsa-user]  Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-06-01 12:25         ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
@ 2010-06-02 22:08           ` Giuliano Pochini
  2010-06-17 12:11             ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
  0 siblings, 1 reply; 13+ messages in thread
From: Giuliano Pochini @ 2010-06-02 22:08 UTC (permalink / raw)
  To: F. Heitkamp
  Cc: alsa-devel, Takashi Iwai, linux-audio-user, Clemens Ladisch,
	linux-kernel, alsa-user

On Tue, 01 Jun 2010 08:25:35 -0400
"F. Heitkamp" <heitkamp@ameritech.net> wrote:

> >> I've tried some newer kernels.  Still having problems with the echo 3G.
> >> This is kernel version:
> >> 2.6.32.13.  The above patches posted to the linux kernel list seemed to
> >> get rid of the crashes, but evidently did not go into the main kernel tree.
> >>      
> > Indeed. I've just checked 2.6.33 and the patch isn't there. It's in 2.6.34.
> >
> > If you need 2.6.32.13 you can apply the above patch to the kernel tree or
> > download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.23.tar.bz2,
> > otherwise just use the latest kernel.
> >    
> I tried 2.6.34.   I have jack 1.9..5 installed.  I was able to use 
> rhythmbox to play mp3s.  I could not use the echomixer app.  It complained
> about a channels mismatch.

I'm running 2.6.34 now. Both a very old version of echomixer (2005!) and
the latest version I just compiled from alsa-tools-1.0.23 work fine with my
Gina3G. Please quote the error message.


> My goal is to be able to plug in a MIDI keyboard, or USB guitar 
> interface and play along with songs etc.
> 
> I plugged in a MIDI keyboard, "/proc/asound/cards" showed the keyboard 
> was recognized.  The keyboard has a USB and MIDI interface.
> I am not sure if they both work at the same time.  I had the MIDI cable 
> plugged into the Gina3G, but I could not tell if the keyboard was 
> recognized.
> I compiled csound5.  When I engaged it the system immediately froze and 
> started spitting out:
> [...]

Ok, I compiled csound, but I don't know how to use it. How can I reproduce
the problem ?


-- 
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [LAU] [Alsa-user] [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-06-02 22:08           ` [Alsa-user] " Giuliano Pochini
@ 2010-06-17 12:11             ` F. Heitkamp
  2010-06-18 11:55               ` [Alsa-user] " Giuliano Pochini
  0 siblings, 1 reply; 13+ messages in thread
From: F. Heitkamp @ 2010-06-17 12:11 UTC (permalink / raw)
  To: Giuliano Pochini
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	linux-audio-user-cunTk1MwBs/CEJeg2xFRV2D2FQJk+8+b,
	Clemens Ladisch, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	alsa-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

  On 06/02/10 18:08, Giuliano Pochini wrote:
> On Tue, 01 Jun 2010 08:25:35 -0400
> "F. Heitkamp"<heitkamp-yWtbtysYrB+LZ21kGMrzwg@public.gmane.org>  wrote:
>
>>>> I've tried some newer kernels.  Still having problems with the echo 3G.
>>>> This is kernel version:
>>>> 2.6.32.13.  The above patches posted to the linux kernel list seemed to
>>>> get rid of the crashes, but evidently did not go into the main kernel tree.
>>>>
>>> Indeed. I've just checked 2.6.33 and the patch isn't there. It's in 2.6.34.
>>>
>>> If you need 2.6.32.13 you can apply the above patch to the kernel tree or
>>> download ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.23.tar.bz2,
>>> otherwise just use the latest kernel.
>>>
>> I tried 2.6.34.   I have jack 1.9..5 installed.  I was able to use
>> rhythmbox to play mp3s.  I could not use the echomixer app.  It complained
>> about a channels mismatch.
> I'm running 2.6.34 now. Both a very old version of echomixer (2005!) and
> the latest version I just compiled from alsa-tools-1.0.23 work fine with my
> Gina3G. Please quote the error message.
>
>
>> My goal is to be able to plug in a MIDI keyboard, or USB guitar
>> interface and play along with songs etc.
>>
>> I plugged in a MIDI keyboard, "/proc/asound/cards" showed the keyboard
>> was recognized.  The keyboard has a USB and MIDI interface.
>> I am not sure if they both work at the same time.  I had the MIDI cable
>> plugged into the Gina3G, but I could not tell if the keyboard was
>> recognized.
>> I compiled csound5.  When I engaged it the system immediately froze and
>> started spitting out:
>> [...]
> Ok, I compiled csound, but I don't know how to use it. How can I reproduce
> the problem ?
>
Sorry I took so long to get back to you.
It turns out Csound is not related to the problem.

In this case I am only using kernel 2.6.33.5-rt23-amd64, alsa lib 1.0.2, 
but 2.6.34 does it too.
I bring up firefox.  Web pages attempt to play sound.   The kernel 
begans doing:

[ 2879.766331] allocate_pipes: ch=1 int=2
[ 2879.766332] allocate_pipes: channel already open
[ 2879.766333] allocate_pipes(1) err=-11
[ 2879.766334] pcm_hw_freed
[ 2.821190] pcm_analog_out_open  cs=0  oc=2  r=44100
[ 2879.821266] allocate_pipes: ch=1 int=2
[ 2879.821267] allocate_pipes: channel already open

,infinitely.  The system is unusable at this point and I have to 
Alt-SysRq-k to get back in.

Let me know what other information to provide.

Here is hwinfo on the system:
cpu:
                        Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz, 
2400 MHz
                        Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz, 
2400 MHz
keyboard:
   /dev/input/input0    EzKEY USB-compliant keyboard
printer:
                        HP deskjet 5600
graphics card:
                        PC Partner VGA compatible controller
sound:
                        PC Partner Audio device
storage:
                        LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI
                        LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI
                        Intel 82801G (ICH7 Family) IDE Controller
network:
   eth1                 Tyan 82573E Gigabit Ethernet Controller (Copper)
   eth0                 Tyan 82573E Gigabit Ethernet Controller (Copper)
network interface:
   eth1                 Ethernet network interface
   eth0                 Ethernet network interface
   lo                   Loopback network interface
usb controller:
                        Intel 82801G (ICH7 Family) USB2 EHCI Controller
                        Intel 82801G (ICH7 Family) USB UHCI #4
                        Intel 82801G (ICH7 Family) USB UHCI #3
                        Intel 82801G (ICH7 Family) USB UHCI #2
                        Intel 82801G (ICH7 Family) USB UHCI #1
bios:
                        BIOS
bridge:
                        Texas Instruments PCI bridge
                        Intel 6702PXH PCI Express-to-PCI Bridge A
                        Intel 82801GB/GR (ICH7 Family) LPC Interface Bridge
                        Intel 82801 PCI Bridge
                        Intel 82801GR/GH/GHM (ICH7 Family) PCI Express 
Port 6
                        Intel 82801GR/GH/GHM (ICH7 Family) PCI Express 
Port 5
                        Intel 82801G (ICH7 Family) PCI Express Port 1
                        Intel 975X Express PCI Express Root Port
                        Intel E7230 PCI Express Root Port
                        Intel E7230 Memory Controller Hub
hub:
                        ATEN International Hub
                        Linux 2.6.33.5-rt23-amd64 uhci_hcd UHCI Host 
Controller
                        Linux 2.6.33.5-rt23-amd64 uhci_hcd UHCI Host 
Controller
                        Linux 2.6.33.5-rt23-amd64 uhci_hcd UHCI Host 
Controller
                        Linux 2.6.33.5-rt23-amd64 uhci_hcd UHCI Host 
Controller
                        Linux 2.6.33.5-rt23-amd64 ehci_hcd EHCI Host 
Controller
memory:
                        Main Memory
firewire controller:
                        Timedia TSB82AA2 IEEE-1394b Link Layer Controller
unknown:
                        FPU
                        DMA controller
                        PIC
                        Timer
                        Keyboard controller
   /dev/lp0             Parallel controller
                        Echo Digital Audio 3G
                        Intel 82801G (ICH7 Family) SMBus Controller
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        PnP Unclassified device
                        Serial controller
   /dev/input/input2    Logitech Trackball
   /dev/input/input1    EzKEY USB-compliant keyboard
                        Belkin UPS

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Alsa-user]  Crash 2.6.32.x, Echo 3G, Alsa, SCSI
  2010-06-17 12:11             ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
@ 2010-06-18 11:55               ` Giuliano Pochini
  0 siblings, 0 replies; 13+ messages in thread
From: Giuliano Pochini @ 2010-06-18 11:55 UTC (permalink / raw)
  To: F. Heitkamp
  Cc: alsa-devel, Takashi Iwai, linux-audio-user, Clemens Ladisch,
	linux-kernel, alsa-user

On Thu, 17 Jun 2010 08:11:06 -0400
"F. Heitkamp" <heitkamp@ameritech.net> wrote:

> >> My goal is to be able to plug in a MIDI keyboard, or USB guitar
> >> interface and play along with songs etc.
> >>
> >> I plugged in a MIDI keyboard, "/proc/asound/cards" showed the keyboard
> >> was recognized.  The keyboard has a USB and MIDI interface.
> >> I am not sure if they both work at the same time.  I had the MIDI cable
> >> plugged into the Gina3G, but I could not tell if the keyboard was
> >> recognized.
> >> I compiled csound5.  When I engaged it the system immediately froze and
> >> started spitting out:
> >> [...]
> > Ok, I compiled csound, but I don't know how to use it. How can I reproduce
> > the problem ?
> >
> Sorry I took so long to get back to you.
> It turns out Csound is not related to the problem.
> 
> In this case I am only using kernel 2.6.33.5-rt23-amd64, alsa lib 1.0.2, 
> but 2.6.34 does it too.
> I bring up firefox.  Web pages attempt to play sound.   The kernel 
> begans doing:
> 
> [ 2879.766331] allocate_pipes: ch=1 int=2
> [ 2879.766332] allocate_pipes: channel already open
> [ 2879.766333] allocate_pipes(1) err=-11
> [ 2879.766334] pcm_hw_freed
> [ 2.821190] pcm_analog_out_open  cs=0  oc=2  r=44100
> [ 2879.821266] allocate_pipes: ch=1 int=2
> [ 2879.821267] allocate_pipes: channel already open
> 
> ,infinitely.  The system is unusable at this point and I have to 
> Alt-SysRq-k to get back in.
> 
> Let me know what other information to provide.

Perhaps is it related with the OSS emulation ?  Do you know if the browser
plays the sound itself or if it is using an external program or plugin ?


-- 
Giuliano.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2010-06-18 11:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <73211.74714.qm@web180714.mail.sp1.yahoo.com>
2010-02-02 15:30 ` Crash 2.6.32.x, Echo 3G, Alsa, SCSI Clemens Ladisch
2010-02-02 16:02   ` [alsa-devel] " Giuliano Pochini
2010-02-03  2:48     ` Frederick V Heitkamp
2010-02-02 22:09   ` [alsa-devel] " Giuliano Pochini
2010-02-03  2:51     ` Frederick V Heitkamp
2010-02-03  2:53     ` [alsa-devel] " Frederick V Heitkamp
2010-05-31 19:05     ` [LAU] " F. Heitkamp
2010-05-31 20:59       ` Giuliano Pochini
2010-06-01  5:37         ` Takashi Iwai
2010-06-01 12:25         ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
2010-06-02 22:08           ` [Alsa-user] " Giuliano Pochini
2010-06-17 12:11             ` [LAU] [Alsa-user] [alsa-devel] " F. Heitkamp
2010-06-18 11:55               ` [Alsa-user] " Giuliano Pochini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).