Bug 20255

Summary:

[PATCH] resume from suspend breaks pcm

Product:

Base System

Reporter:

mike ryan <msr+fbsd>

Component:

kern

Assignee:

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

4.1-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description mike ryan 2000-07-28 16:20:01 UTC

	after resuming from suspend, sound can no longer be played.  any
	attempt to play sound results in "pcm0: play interrupt timeout,
	channel dead" errors.

Fix: this patch works for me:
How-To-Repeat: 
	suspend + resume.

Comment 1 bill fumerola freebsd_committer

2000-07-28 23:15:05 UTC

Responsible Changed
From-To: freebsd-bugs->cg

over to the pcm maintainer.

Comment 2 dej 2000-08-08 02:12:36 UTC

The "channel dead" problem is not limited to suspend and resume.

I can produce it using my VIA82C686 driver by running "xgalaga" from the
ports collection.

From the code, the channel is marked dead if the driver is unable to
make progress writing data for more than one second.  My driver was
using 16K buffers divided into two 8K halves.  At 8 kbps, there could be
a race between the timeout in the write routine and the buffer playing. 
Therefore, I changed my code to use smaller buffers, so now I have four
4K buffers.  However, I still occasionally get this error.

In FreeBSD 4.0, xgalaga's sounds lagged the action often by a second or
more.  I believe that the application may not be writing correctly to
the audio device.  If this is the case, then to mark the channel dead is
not appropriate behavior, since a reboot is required to reset the
system.  One can envision a denial-of-service attack whose effect is to
mute the target computer until it is rebooted.

I will attempt to patch my kernel to reset the "Dead" bit when the
device is closed, to get around the immediate DOS, and to enable further
experimentation.  I may be able to determine the sequence of actions
that provoke the problem.  In any event, to have suspend/resume handlers
in the low-level drivers themselves is not a good solution to a problem
that was introduced at a higher layer.

Comment 3 msr 2000-08-08 04:06:47 UTC

On Mon, Aug 07, 2000 at 09:12:36PM -0400, David Jones wrote:
> The "channel dead" problem is not limited to suspend and resume.
> 
> I can produce it using my VIA82C686 driver by running "xgalaga"
> from the ports collection.

same effect, different cause.

> From the code, the channel is marked dead if the driver is unable
> to make progress writing data for more than one second.

it doesn't matter whether or not audio is playing when the machine
is suspended -- after resume, all audio output will fail unless
certain registers on the device itself are reset.

> In any event, to have suspend/resume handlers in the low-level
> drivers themselves is not a good solution to a problem that was
> introduced at a higher layer.

we're encountering different problems here.  the bios on these
particular laptops just don't do a good job of restoring state after
a resume.  see kern/18261 and kern/18756 for similar problems (and
fixes) with the uhci and fxp devices.

it's possible that a fix for the bug you describe would alleviate
the need for the chn_resetbuf() calls, but the register resets
appear to be mandatory.

Comment 4 greid freebsd_committer

2001-04-08 23:07:20 UTC

State Changed
From-To: open->closed

Patch from misc/20891 committed