All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Takashi Iwai <tiwai@suse.de>, Ingo Molnar <mingo@elte.hu>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang
Date: Fri, 07 Nov 2008 10:36:59 -0800	[thread overview]
Message-ID: <1226083019.20569.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1226081557.20569.5.camel@localhost.localdomain>

On Fri, 2008-11-07 at 10:12 -0800, Fernando Lopez-Lezcano wrote:
> On Fri, 2008-11-07 at 10:12 +0100, Clemens Ladisch wrote:
> > Fernando Lopez-Lezcano wrote:
> > > I'm seeing a realtime patch related hard hang in the kernel alsa
> > > subsystem (MIDI input/output). In a nutshell:
> > >
> > > - alsa rawmidi works (ie: "rawmidi -v -i hw:0" outputs a stream of
> > > messages when pointed to a midi capable card that has an external
> > > keyboard connected).
> > >
> > > - the alsa sequencer interface works (ie: aplaymidi connected to
> > > aseqdump transfers data just fine).
> > >
> > > - BOTH combined do NOT work (ie: use aconnect to connect the port that
> > > corresponds to the external midi interface to aseqdump: aseqdump hangs
> > > forever after transferring the first message and the only way out is a
> > > reboot).
> > 
> > Please try the snd-virmidi driver, then we'd have a test case that does
> > not require MIDI hardware.
> > 
> > > ... including the output of a "echo t >/proc/sysrq-trigger" that
> > > should show where aseqdump currently hangs (or so I think).
> > 
> > It hangs in tasklet_kill(), which gets called while it tries to close
> > the rawmidi port.
> > 
> > The rawmidi framework uses this tasklet to notify the sequencer that new
> > MIDI data is available.  The handler function is
> > snd_rawmidi_input_event_tasklet() in sound/core/rawmidi.c; the sequencer
> > callback that gets called from there is snd_midi_input_event() in
> > core/seq/seq_midi.c.
> > 
> > You say that the first event gets delivered, so it might be

Nope, different this time. Maybe this one points closer to the culprit?
(BTW, snd_midi_input_event only gets called _once_, I added a few more
printk's there):

--------
Nov  7 10:34:51 host kernel: aseqdump      S [f15ce070] f7910d70     0
5341   5247
Nov  7 10:34:51 host kernel:       f3691bd4 00000086 f3691b88 f7910d70
00000001 f15ce070 f15ce304 c4852700 
Nov  7 10:34:51 host kernel:       00000002 c4852700 9a9894aa 0000002c
c484f054 00000000 fffeb4bf 00000246 
Nov  7 10:34:51 host kernel:       f35cf274 00000000 00000000 00000000
ffffffff 00000000 7fffffff f3691e98 
Nov  7 10:34:51 host kernel: Call Trace:
Nov  7 10:34:51 host kernel: [<c0643ba5>] schedule+0xbf/0xd8
Nov  7 10:34:51 host kernel: [<c0643c72>] schedule_timeout+0x17/0xbc
Nov  7 10:34:51 host kernel: [<c0496c8f>] ? __pollwait+0xad/0xb6
Nov  7 10:34:51 host kernel: [<f893cb34>] ? snd_seq_fifo_poll_wait
+0x18/0x25 [snd_seq]
Nov  7 10:34:51 host kernel: [<f8939fad>] ? snd_seq_poll+0x4d/0x9f
[snd_seq]
Nov  7 10:34:51 host kernel: [<c0495d92>] do_sys_poll+0x292/0x348
Nov  7 10:34:51 host kernel: [<c0496be2>] ? __pollwait+0x0/0xb6
Nov  7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function
+0x0/0x12
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<c04752f7>] ? page_address+0x88/0xaa
Nov  7 10:34:51 host kernel: [<c047596d>] ? kmap_high+0x421/0x42a
Nov  7 10:34:51 host kernel: [<c04ff574>] ? radix_valid_always+0x0/0xa
Nov  7 10:34:51 host kernel: [<c046430b>] ? __rcu_read_unlock+0x6d/0x72
Nov  7 10:34:51 host kernel: [<c04699ec>] ? find_get_page+0xfa/0x120
Nov  7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<c0420afc>] ? __enqueue_entity+0xe3/0xeb
Nov  7 10:34:51 host kernel: [<c041f87b>] ? task_rq_lock+0x44/0x6e
Nov  7 10:34:51 host kernel: [<c0425c76>] ? try_to_wake_up+0x212/0x21d
Nov  7 10:34:51 host kernel: [<c0425c91>] ? default_wake_function
+0x10/0x12
Nov  7 10:34:51 host kernel: [<c041ddd8>] ? __wake_up_common+0x35/0x5b
Nov  7 10:34:51 host kernel: [<c0423172>] ? __wake_up+0x28/0x32
Nov  7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf
+0xfa9/0xff7
Nov  7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf
+0xfa9/0xff7
Nov  7 10:34:51 host kernel: [<c0447cef>] ? rt_mutex_up_read+0x1b7/0x25d
Nov  7 10:34:51 host kernel: [<c0448f40>] ? rt_up_read+0x8/0xa
Nov  7 10:34:51 host kernel: [<c0647c26>] ? do_page_fault+0x45f/0x7d8
Nov  7 10:34:51 host kernel: [<c043e441>] ? hrtimer_start+0x133/0x162
Nov  7 10:34:51 host kernel: [<c04249d0>] ? hrtick_set+0x97/0xe5
Nov  7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<f893cc46>] ? snd_seq_fifo_cell_out
+0x47/0xee [snd_seq]
Nov  7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function
+0x0/0x12
Nov  7 10:34:51 host kernel: [<f893a041>] ? snd_seq_read+0x0/0x1d8
[snd_seq]
Nov  7 10:34:51 host kernel: [<f893a11e>] ? snd_seq_read+0xdd/0x1d8
[snd_seq]
Nov  7 10:34:51 host kernel: [<c04d73d3>] ? security_file_permission
+0xf/0x11
Nov  7 10:34:51 host kernel: [<c045e231>] ? audit_syscall_entry
+0xf9/0x123
Nov  7 10:34:51 host kernel: [<c049606a>] sys_poll+0x3a/0x6a
Nov  7 10:34:51 host kernel: [<c0404be6>] syscall_call+0x7/0xb
Nov  7 10:34:51 host kernel: =======================
--------

-- Fernando

WARNING: multiple messages have this Message-ID (diff)
From: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Takashi Iwai <tiwai@suse.de>, Ingo Molnar <mingo@elte.hu>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang
Date: Fri, 07 Nov 2008 10:36:59 -0800	[thread overview]
Message-ID: <1226083019.20569.9.camel@localhost.localdomain> (raw)
In-Reply-To: <1226081557.20569.5.camel@localhost.localdomain>

On Fri, 2008-11-07 at 10:12 -0800, Fernando Lopez-Lezcano wrote:
> On Fri, 2008-11-07 at 10:12 +0100, Clemens Ladisch wrote:
> > Fernando Lopez-Lezcano wrote:
> > > I'm seeing a realtime patch related hard hang in the kernel alsa
> > > subsystem (MIDI input/output). In a nutshell:
> > >
> > > - alsa rawmidi works (ie: "rawmidi -v -i hw:0" outputs a stream of
> > > messages when pointed to a midi capable card that has an external
> > > keyboard connected).
> > >
> > > - the alsa sequencer interface works (ie: aplaymidi connected to
> > > aseqdump transfers data just fine).
> > >
> > > - BOTH combined do NOT work (ie: use aconnect to connect the port that
> > > corresponds to the external midi interface to aseqdump: aseqdump hangs
> > > forever after transferring the first message and the only way out is a
> > > reboot).
> > 
> > Please try the snd-virmidi driver, then we'd have a test case that does
> > not require MIDI hardware.
> > 
> > > ... including the output of a "echo t >/proc/sysrq-trigger" that
> > > should show where aseqdump currently hangs (or so I think).
> > 
> > It hangs in tasklet_kill(), which gets called while it tries to close
> > the rawmidi port.
> > 
> > The rawmidi framework uses this tasklet to notify the sequencer that new
> > MIDI data is available.  The handler function is
> > snd_rawmidi_input_event_tasklet() in sound/core/rawmidi.c; the sequencer
> > callback that gets called from there is snd_midi_input_event() in
> > core/seq/seq_midi.c.
> > 
> > You say that the first event gets delivered, so it might be

Nope, different this time. Maybe this one points closer to the culprit?
(BTW, snd_midi_input_event only gets called _once_, I added a few more
printk's there):

--------
Nov  7 10:34:51 host kernel: aseqdump      S [f15ce070] f7910d70     0
5341   5247
Nov  7 10:34:51 host kernel:       f3691bd4 00000086 f3691b88 f7910d70
00000001 f15ce070 f15ce304 c4852700 
Nov  7 10:34:51 host kernel:       00000002 c4852700 9a9894aa 0000002c
c484f054 00000000 fffeb4bf 00000246 
Nov  7 10:34:51 host kernel:       f35cf274 00000000 00000000 00000000
ffffffff 00000000 7fffffff f3691e98 
Nov  7 10:34:51 host kernel: Call Trace:
Nov  7 10:34:51 host kernel: [<c0643ba5>] schedule+0xbf/0xd8
Nov  7 10:34:51 host kernel: [<c0643c72>] schedule_timeout+0x17/0xbc
Nov  7 10:34:51 host kernel: [<c0496c8f>] ? __pollwait+0xad/0xb6
Nov  7 10:34:51 host kernel: [<f893cb34>] ? snd_seq_fifo_poll_wait
+0x18/0x25 [snd_seq]
Nov  7 10:34:51 host kernel: [<f8939fad>] ? snd_seq_poll+0x4d/0x9f
[snd_seq]
Nov  7 10:34:51 host kernel: [<c0495d92>] do_sys_poll+0x292/0x348
Nov  7 10:34:51 host kernel: [<c0496be2>] ? __pollwait+0x0/0xb6
Nov  7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function
+0x0/0x12
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<c04752f7>] ? page_address+0x88/0xaa
Nov  7 10:34:51 host kernel: [<c047596d>] ? kmap_high+0x421/0x42a
Nov  7 10:34:51 host kernel: [<c04ff574>] ? radix_valid_always+0x0/0xa
Nov  7 10:34:51 host kernel: [<c046430b>] ? __rcu_read_unlock+0x6d/0x72
Nov  7 10:34:51 host kernel: [<c04699ec>] ? find_get_page+0xfa/0x120
Nov  7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<c0420afc>] ? __enqueue_entity+0xe3/0xeb
Nov  7 10:34:51 host kernel: [<c041f87b>] ? task_rq_lock+0x44/0x6e
Nov  7 10:34:51 host kernel: [<c0425c76>] ? try_to_wake_up+0x212/0x21d
Nov  7 10:34:51 host kernel: [<c0425c91>] ? default_wake_function
+0x10/0x12
Nov  7 10:34:51 host kernel: [<c041ddd8>] ? __wake_up_common+0x35/0x5b
Nov  7 10:34:51 host kernel: [<c0423172>] ? __wake_up+0x28/0x32
Nov  7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf
+0xfa9/0xff7
Nov  7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf
+0xfa9/0xff7
Nov  7 10:34:51 host kernel: [<c0447cef>] ? rt_mutex_up_read+0x1b7/0x25d
Nov  7 10:34:51 host kernel: [<c0448f40>] ? rt_up_read+0x8/0xa
Nov  7 10:34:51 host kernel: [<c0647c26>] ? do_page_fault+0x45f/0x7d8
Nov  7 10:34:51 host kernel: [<c043e441>] ? hrtimer_start+0x133/0x162
Nov  7 10:34:51 host kernel: [<c04249d0>] ? hrtick_set+0x97/0xe5
Nov  7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61
Nov  7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b
Nov  7 10:34:51 host kernel: [<f893cc46>] ? snd_seq_fifo_cell_out
+0x47/0xee [snd_seq]
Nov  7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function
+0x0/0x12
Nov  7 10:34:51 host kernel: [<f893a041>] ? snd_seq_read+0x0/0x1d8
[snd_seq]
Nov  7 10:34:51 host kernel: [<f893a11e>] ? snd_seq_read+0xdd/0x1d8
[snd_seq]
Nov  7 10:34:51 host kernel: [<c04d73d3>] ? security_file_permission
+0xf/0x11
Nov  7 10:34:51 host kernel: [<c045e231>] ? audit_syscall_entry
+0xf9/0x123
Nov  7 10:34:51 host kernel: [<c049606a>] sys_poll+0x3a/0x6a
Nov  7 10:34:51 host kernel: [<c0404be6>] syscall_call+0x7/0xb
Nov  7 10:34:51 host kernel: =======================
--------

-- Fernando



  reply	other threads:[~2008-11-07 18:52 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07  0:58 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang Fernando Lopez-Lezcano
2008-11-07  9:12 ` Clemens Ladisch
2008-11-07  9:37   ` Clemens Ladisch
2008-11-07 18:12   ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-07 18:36     ` Fernando Lopez-Lezcano [this message]
2008-11-07 18:36       ` Fernando Lopez-Lezcano
2008-11-07 23:12     ` Fernando Lopez-Lezcano
2008-11-07 23:12       ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-08  0:48       ` Fernando Lopez-Lezcano
2008-11-08  0:48         ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-08  1:14         ` Fernando Lopez-Lezcano
2008-11-08  1:14           ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-13 21:01   ` Fernando Lopez-Lezcano
2008-11-13 22:56     ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-14  0:12       ` [alsa-devel] 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang (tasklet_hi_schedule?) Fernando Lopez-Lezcano
2008-11-14  8:15         ` Clemens Ladisch
2008-11-14  8:46           ` Takashi Iwai
2008-11-14 18:57           ` Fernando Lopez-Lezcano
2008-11-14 18:57             ` [alsa-devel] " Fernando Lopez-Lezcano
2008-11-19 11:44             ` Takashi Iwai
2008-11-19 11:44               ` [alsa-devel] " Takashi Iwai
2008-11-27 16:50               ` Takashi Iwai
2008-11-27 16:50                 ` [alsa-devel] " Takashi Iwai
2008-12-11 11:58                 ` Takashi Iwai
2008-12-11 11:58                   ` [alsa-devel] " Takashi Iwai
2008-11-13 22:56     ` 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang Fernando Lopez-Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1226083019.20569.9.camel@localhost.localdomain \
    --to=nando@ccrma.stanford.edu \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.