Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

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.

Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

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.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: [Alsa-devel] Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[Takashi Iwai]

At Mon, 14 Jul 2003 19:17:22 +0300,
P. Christeas <p_christ@hol.gr> wrote:
> 
> 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 .

could you check whether m3_suspend() and m3_resume() in
sound/pci/maestro3.c are really called?


Takashi

Re: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[Takashi Iwai]

At Mon, 14 Jul 2003 19:17:22 +0300,
P. Christeas <p_christ@hol.gr> wrote:
> 
> 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 .

could you check whether m3_suspend() and m3_resume() in
sound/pci/maestro3.c are really called?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: [Alsa-devel] Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

Takashi Iwai wrote:
> At Mon, 14 Jul 2003 19:17:22 +0300,
>
> P. Christeas <p_christ@hol.gr> wrote:
> > 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 .
>
> could you check whether m3_suspend() and m3_resume() in
> sound/pci/maestro3.c are really called?
>
>
> Takashi

OK, I did that.  I put two messages in both functions of the maestro3 driver. 
I suspended/resumed the machine. Both functions had been called.

This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened was 
that the module was properly restored and I could load (and use) artsd even 
after the resume.
That brings me to the first assumption/question I have made: is there 
something wrong if we suspend two parts (one module and a userspace process), 
while they inter-communicate through the /dev/* interface?



static void m3_suspend(m3_t *chip)
{
	snd_card_t *card = chip->card;
	int i, index;

	snd_printk("m3 suspend");
	if (chip->suspend_mem == NULL)
		return;
	if (card->power_state == SNDRV_CTL_POWER_D3hot)
		return;
	...

static void m3_resume(m3_t *chip)
{
	snd_card_t *card = chip->card;
	int i, index;

	snd_printk("m3 resume");

	if (chip->suspend_mem == NULL)
		return;
	...

Re: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

Takashi Iwai wrote:
> At Mon, 14 Jul 2003 19:17:22 +0300,
>
> P. Christeas <p_christ@hol.gr> wrote:
> > 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 .
>
> could you check whether m3_suspend() and m3_resume() in
> sound/pci/maestro3.c are really called?
>
>
> Takashi

OK, I did that.  I put two messages in both functions of the maestro3 driver. 
I suspended/resumed the machine. Both functions had been called.

This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened was 
that the module was properly restored and I could load (and use) artsd even 
after the resume.
That brings me to the first assumption/question I have made: is there 
something wrong if we suspend two parts (one module and a userspace process), 
while they inter-communicate through the /dev/* interface?



static void m3_suspend(m3_t *chip)
{
	snd_card_t *card = chip->card;
	int i, index;

	snd_printk("m3 suspend");
	if (chip->suspend_mem == NULL)
		return;
	if (card->power_state == SNDRV_CTL_POWER_D3hot)
		return;
	...

static void m3_resume(m3_t *chip)
{
	snd_card_t *card = chip->card;
	int i, index;

	snd_printk("m3 resume");

	if (chip->suspend_mem == NULL)
		return;
	...


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: [Alsa-devel] Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

> Takashi Iwai wrote:
> > At Mon, 14 Jul 2003 19:17:22 +0300,
> >
> > P. Christeas <p_christ@hol.gr> wrote:
> > > 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 .
> >
> > could you check whether m3_suspend() and m3_resume() in
> > sound/pci/maestro3.c are really called?
> >
> >
> > Takashi
>
> OK, I did that.  I put two messages in both functions of the maestro3
> driver. I suspended/resumed the machine. Both functions had been called.
>
> This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened
> was that the module was properly restored and I could load (and use) artsd
> even after the resume.
> That brings me to the first assumption/question I have made: is there
> something wrong if we suspend two parts (one module and a userspace
> process), while they inter-communicate through the /dev/* interface?
>
>
In a second test, I have also added messages at the end of these functions. 
They surely don't exit early indeed.

Has anybody else managed to reproduce the bug?
Does it happen with other drivers (say, PCI cards w. pcm interface)?

procedure:
	(read the last step first; it is a warning)
	1. load the sound module, like 'modprobe snd-maestro3'
	2. load the client ("artsd" should be the one, others may eventually release 
the descriptor. If you want, you could give them a try as well.) 
	3. Suspend, S1, NOT with an all-capable script. The script you use must not 
try to bring down ALSA.
	4. Resume.
	5. Check the state of the "artsd" (or equivalent) process.

	W. Note that if the process is waiting for I/O, you can do nothing but 
reboot.

Re: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

> Takashi Iwai wrote:
> > At Mon, 14 Jul 2003 19:17:22 +0300,
> >
> > P. Christeas <p_christ@hol.gr> wrote:
> > > 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 .
> >
> > could you check whether m3_suspend() and m3_resume() in
> > sound/pci/maestro3.c are really called?
> >
> >
> > Takashi
>
> OK, I did that.  I put two messages in both functions of the maestro3
> driver. I suspended/resumed the machine. Both functions had been called.
>
> This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened
> was that the module was properly restored and I could load (and use) artsd
> even after the resume.
> That brings me to the first assumption/question I have made: is there
> something wrong if we suspend two parts (one module and a userspace
> process), while they inter-communicate through the /dev/* interface?
>
>
In a second test, I have also added messages at the end of these functions. 
They surely don't exit early indeed.

Has anybody else managed to reproduce the bug?
Does it happen with other drivers (say, PCI cards w. pcm interface)?

procedure:
	(read the last step first; it is a warning)
	1. load the sound module, like 'modprobe snd-maestro3'
	2. load the client ("artsd" should be the one, others may eventually release 
the descriptor. If you want, you could give them a try as well.) 
	3. Suspend, S1, NOT with an all-capable script. The script you use must not 
try to bring down ALSA.
	4. Resume.
	5. Check the state of the "artsd" (or equivalent) process.

	W. Note that if the process is waiting for I/O, you can do nothing but 
reboot.




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[James Courtier-Dutton]

P. Christeas wrote:
>>Takashi Iwai wrote:
>>
>>>At Mon, 14 Jul 2003 19:17:22 +0300,
>>>
>>>P. Christeas <p_christ@hol.gr> wrote:
>>>
>>>>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 .
>>>
>>>could you check whether m3_suspend() and m3_resume() in
>>>sound/pci/maestro3.c are really called?
>>>
>>>
>>>Takashi
>>
>>OK, I did that.  I put two messages in both functions of the maestro3
>>driver. I suspended/resumed the machine. Both functions had been called.
>>
>>This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened
>>was that the module was properly restored and I could load (and use) artsd
>>even after the resume.
>>That brings me to the first assumption/question I have made: is there
>>something wrong if we suspend two parts (one module and a userspace
>>process), while they inter-communicate through the /dev/* interface?
>>
>>
> 
> In a second test, I have also added messages at the end of these functions. 
> They surely don't exit early indeed.
> 
> Has anybody else managed to reproduce the bug?
> Does it happen with other drivers (say, PCI cards w. pcm interface)?
> 
> procedure:
> 	(read the last step first; it is a warning)
> 	1. load the sound module, like 'modprobe snd-maestro3'
> 	2. load the client ("artsd" should be the one, others may eventually release 
> the descriptor. If you want, you could give them a try as well.) 
> 	3. Suspend, S1, NOT with an all-capable script. The script you use must not 
> try to bring down ALSA.
> 	4. Resume.
> 	5. Check the state of the "artsd" (or equivalent) process.
> 
> 	W. Note that if the process is waiting for I/O, you can do nothing but 
> reboot.
> 
> 
> 
I get a similar sort of problem, but that is with an USB sound card, and 
one unplugs the usb cable.
The process (in my case a media appication) is waiting for a return from 
a call to alsa-lib, but the return from the call never happens.
Maybe suspending a PCI sound card is similar to unplugging a USB sound 
card. In both cases, the device does not respond anymore, but alsa-lib 
fails to return an error to the application, but instead never returns.

Cheers
James






-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0

Re: Reproducible deadlock w. alsa/maestro3 when sleeping (ACPI,) 2.6.0-test1

[P. Christeas]

> >>This time, I did NOT have 'artsd' (i.e. the client) loaded. What happened
> >>was that the module was properly restored and I could load (and use)
> >> artsd even after the resume.
> >>That brings me to the first assumption/question I have made: is there
> >>something wrong if we suspend two parts (one module and a userspace
> >>process), while they inter-communicate through the /dev/* interface?
> >
> > In a second test, I have also added messages at the end of these
> > functions. They surely don't exit early indeed.
> >
> > Has anybody else managed to reproduce the bug?
> > Does it happen with other drivers (say, PCI cards w. pcm interface)?
> >
> > procedure:
> > 	(read the last step first; it is a warning)
> > 	1. load the sound module, like 'modprobe snd-maestro3'
> > 	2. load the client ("artsd" should be the one, others may eventually
> > release the descriptor. If you want, you could give them a try as well.)
> > 3. Suspend, S1, NOT with an all-capable script. The script you use must
> > not try to bring down ALSA.
> > 	4. Resume.
> > 	5. Check the state of the "artsd" (or equivalent) process.
> >
> > 	W. Note that if the process is waiting for I/O, you can do nothing but
> > reboot.
>
> I get a similar sort of problem, but that is with an USB sound card, and
> one unplugs the usb cable.
> The process (in my case a media appication) is waiting for a return from
> a call to alsa-lib, but the return from the call never happens.
> Maybe suspending a PCI sound card is similar to unplugging a USB sound
> card. In both cases, the device does not respond anymore, but alsa-lib
> fails to return an error to the application, but instead never returns.
>
> Cheers
> James

If you verify that you are unable to 'kill -9' the client application, then 
the problem becomes just little more serious. IMHO no such actions should 
cause the kernel to have 'blocked' resources.

One important observation I have is that 'esd' doesn't produce the bug. Esd 
uses '/dev/sound/dsp' rather than '/dev/snd/pcmXXX' (oss-emu. rather than 
ALSA). I don't even know what level of 'feedback' (in terms of function 
returns) OSS provides, in comparison to the ALSA system.





-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0