On Wed, 19 Mar 2003, Martin Langer wrote:
> On Wed, Mar 19, 2003 at 01:10:02PM -0500, Paul Davis wrote:
> > there still appears to be a bug in the trident driver. i have been
> > running jack with a period size of 1024, and it works fine. when i
> > change that to 4096 frames, the kernel does a ha
On Wed, Mar 19, 2003 at 01:10:02PM -0500, Paul Davis wrote:
> there still appears to be a bug in the trident driver. i have been
> running jack with a period size of 1024, and it works fine. when i
> change that to 4096 frames, the kernel does a hard oops, with the oops
> occuring in enable_hlt().
On Wed, 19 Mar 2003, Paul Davis wrote:
> there still appears to be a bug in the trident driver. i have been
> running jack with a period size of 1024, and it works fine. when i
> change that to 4096 frames, the kernel does a hard oops, with the oops
> occuring in enable_hlt(). the rest of the trac
there still appears to be a bug in the trident driver. i have been
running jack with a period size of 1024, and it works fine. when i
change that to 4096 frames, the kernel does a hard oops, with the oops
occuring in enable_hlt(). the rest of the trace doesn't make much
sense, and i cannot feed it
>It's really discarded as spurious? All voices has separate spurious
>interrupt checking based on the global frame counter (stimer). Please, can
>you verify it? I still think, that it would be better to call
>snd_trident_capture_pointer() and see the actual ptr. My patch should
>fix the problem, i
On Thu, 29 Nov 2001, Paul Davis wrote:
> It looks like that the capture direction receives an interrupt before the
> >capture pointer has reached the period size boundary. You can increase the
> >insterrupt delay, something like this:
>
> i'll check on that, but i don't think thats what happened
It looks like that the capture direction receives an interrupt before the
>capture pointer has reached the period size boundary. You can increase the
>insterrupt delay, something like this:
i'll check on that, but i don't think thats what happened above. this
should make it clearer (i processed t
On Thu, 29 Nov 2001, Paul Davis wrote:
> the problem with the trident driver is definitely the spurious
> irqs. the driver doesn't print all such spurious interrupts, which is
> why they don't show up in my logs. when i changed my trace code, its
> became clear that they definitely occur quite of
the problem with the trident driver is definitely the spurious
irqs. the driver doesn't print all such spurious interrupts, which is
why they don't show up in my logs. when i changed my trace code, its
became clear that they definitely occur quite often.
the problem with dropping "spurious" irqs
