On Thu, Feb 10, 2000 at 10:25:11AM +0100, Jochen Hoenicke wrote:
> 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.
Thanks, I'll look into this.
Whatever is going on is too strange to be exclusively explained by
such logic, however. After discovering the ft_tracings[] oddness, I
inserted a lot of printk() calls around the suspected trouble spot in
bpck_fdc_read_reg_value(), eliminating dependence on the ft_tracings[]
array.
Whenever an event occurs that changes the value of ft_tracings[0], my
printk() logging output is disrupted - a big gap appears where logging
output from one call to bpck_fdc_read_reg_value() is suddenly cut off
in the middle of a line, and continues in the middle of a logging line
from some later call to bpck_fdc_read_reg_value(). So the mysterious
activity is, among other things, interfering with buffers used for
printk(). Whatever's happening is very messy.
Nathan
> 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
>
