On Feb 9, Nathan Meyers wrote:
> 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.
There are some places where ftape does this intentionally. You should
disable the SET_TRACE_LEVEL macro to be sure you get not bitten by
this.
Also note that there are 5 different tracing variables (one for each
slot and one for messages not related to a slot). Maybe the fdc_isr
uses a different variable than the bpck_fdc_interrupt. You can change
the ftape_tracing macro to always use the same ft_tracings entry to be
sure.
Jochen
