[nas] nasd outputs only part of a sample, client stalls -- exceptunder strace

[Erik Auerswald]

Hi,

On Tue, Oct 02, 2007 at 04:41:33PM -0600, Jon Trulson wrote:
> On Mon, 10 Sep 2007, Erik Auerswald wrote:
> >On Mon, Sep 03, 2007 at 01:28:38PM -0600, Jon Trulson wrote:
> >>On Mon, 3 Sep 2007, Erik Auerswald wrote:
> >>>On Sun, Sep 02, 2007 at 08:24:18PM -0600, Jon Trulson wrote:
> >>>>On Sun, 2 Sep 2007, Erik Auerswald wrote:
> >>>>>On Mon, Jul 23, 2007 at 08:54:00AM -0400, mmurray wrote:
> >>>>>>
> >>>>>>To the best of my reasoning, the SIGALRM is being lost in a race
> >>>>>>somewhere.
> >>>>>
> >>>>>This seems to be correct -- sending a SIGALRM to nasd whenever the
> >>>>>playback hangs results in continued playback.
> >>
> >>  I'll have to see about installing one of these kernels and try to
> >>  track the problem further (unless someone beats me to it :).
> >
> >I've written a test program to reproduce the problem. Setting the
> >interval timer to values used by auvoxware (or to values an order of
> >magnitude higher or lower) works on every tested kernel (2.6.11, 2.6.18,
> >2.6.20 and 2.6.22). Ignoring most of the generated SIGALRMs by having a
> >long running signal handler works as well.
> >
> >Using sleep() inside the signal handler for SIGALRM shows similar
> >behaviour to that of auvoxware: After a while the program does not
> >recieve any SIGALRMs, sending a SIGALRM to the process lets it continue.
> >According to the man-page of sleep(), sleep can be implemented using
> >SIGALRM:
> 
>   Erik, I just wanted to let you know I have't forgotten about this
>   issue.  There's just been alot going on around here.

I don´t have much time either, the machine in question has been
downgraded to a 2.6.20 kernel which doesn´t show these problems.

>   I think we only use these when waiting for the device to be
>   available when ReleaseDevice is enabled...

AFAICT you are right.

Erik