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
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 trace
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(). the
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 hard
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
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 above.
