On Tue, Feb 08, 2000 at 01:19:50PM +0100, Wolfgang Weisselberg wrote:
> Hi, Nathan!
>
> Trying to kill the keyboard, Nathan Meyers
> ([EMAIL PROTECTED]) produced 0,7K in 22 lines:
>
> > Its purpose is to call a function pointed to by the function pointer
> > "handler". As far as I can tell, it behaves the following way when
> > handler points to the function fdc_isr():
>
> > 1) If fdc->fifo_locked is 0, fdc_isr is called.
> > 2) If fdc->fifo_locked is 1, fdc_isr is not called.
>
> > There is no obvious reason for this logic, but that seems to be what's
> > happening and seems to be the cause for my lack of a working tape
> > drive. Any insights into what's going on here would be most welcome.
This problem is a symptom of the memory corruption I described last
night. The memory being corrupted includes the ftape_tracings[] array;
it's not that fdc_isr() is not being called, it's that the logging in
fdc_isr() is not happening because the relevant tracing variable was
set to 0 by the corruption. At some later time, another event of some
sort sets it back to 4 and tracing resumes.
> It might be an attempt to handle stray interrupts. It may be
> that an interrupt would intrduce too much latency ... and the
> Max is very sensitive there. However, people have gotten it
> to work without changing the code.
>
> IMHO, if you can, try to exchange the Ditto for a more ...
> useful and reliable model. Ditto Max (Pro) are not exactly
> known to be easy to use or very robust.
Is there any way the Ditto could be responsible for memory corruption
during driver operation? Seems like a long shot.
Nathan
>
> -Wolfgang
>
