linux-kernel - 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1226019485.3135.31.camel@localhost.localdomain>
Date:	Thu, 06 Nov 2008 16:58:05 -0800
From:	Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Ingo Molnar <mingo@...e.hu>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang

(starting a new thread with the hope of being more precise after a lot
of testing and rebooting)

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). 

Just tested this on 2.6.26.7 + rt11, Gina3G soundcard with an external
MIDI keyboard sending messages. This is not specific to the Gina card, I
have tested also USB midi interfaces and an RME hdsp card with a
Multiface interface. 

2.6.24.7 + rt21 works fine on the same hardware combinations. The
standard Fedora 9 2.6.26.x kernel works fine as well. 

I'm attaching the kernel configuration for the kernel I'm currently
testing plus a dmesg dump of the whole boot process (rt kernel hackers
can find there some additional sleeping in wrong context warning
messages there), including the output of a "echo t >/proc/sysrq-trigger"
that should show where aseqdump currently hangs (or so I think). 

Hopefully this will narrow the area affected enough so that a solution
can be found or more debugging info can be requested. Currently
2.6.26.x-rtx is unusable for musical purposes (at least when you have to
interact with external midi controllers). 

Thanks for any help...
-- Fernando

Download attachment "dmesg.bz2" of type "application/x-bzip" (38161 bytes)

Download attachment "config-2.6.26.7-1.rt11.1fc9.ccrma.i686.rt.bz2" of type "application/x-bzip" (21348 bytes)