From: "P. Christeas" <p_christ@hol.gr>
To: lkml <linux-kernel@vger.kernel.org>, alsa-devel@lists.sourceforge.net
Subject: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1
Date: Mon, 14 Jul 2003 19:17:22 +0300 [thread overview]
Message-ID: <200307141917.22813.p_christ@hol.gr> (raw)
I have been experiencing some fully reproducible deadlock when waking from
sleep, using artsd over ALSA.
The scenario is:
I use ALSA, with the maestro3 device and everything else compiled as modules.
>From userspace, I launch artsd, which uses its native ALSA support to connect
to /dev/pcmXXXXX .
I only have a custom script, which sleeps the machine by a 'echo 1>
/proc/acpi/sleep' . It does NOT stop alsa .
When the machine weaks, it has a deadlock. The suspended 'artsd' process waits
for the /dev/pcmXXXX to become available (presumably; I can see 'D' on the
'ps' line), while the maestro3 module waits for the 'artsd' process to free
/dev/pcmXXX .
I have tried to kill (w. 15, 9 etc.) the artsd process, rmmod the
'snd_maestro3' module (w. '-f' or '-l' options to rmmod). Nothing would
happen. In the worst case (after the rmmod), the whole module mechanism would
lock as well ('lsmod' would hang ).
I could not find any relevant message for this case. However, on a subsequent
sleep, the system refuses to sleep because it cannot suspend 'artsd'.
ps. My scripts (including module-init-tools) are definitely messy. However,
since 'artsd' or any ALSA client works in userspace and can be launched at
any time, I believe this problem leads to serious trouble for the system.
next reply other threads:[~2003-07-14 16:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 16:17 P. Christeas [this message]
2003-07-16 11:47 ` [Alsa-devel] Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1 Takashi Iwai
2003-07-16 14:18 ` P. Christeas
2003-07-16 15:03 ` P. Christeas
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=200307141917.22813.p_christ@hol.gr \
--to=p_christ@hol.gr \
--cc=alsa-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox