In my ongoing struggle to get DittoMax/parallel working with my Siig
parallel card, I've added some instrumentation to the driver code,
and I'm seeing something truly weird: sometimes the fdc_isr interrupt
service procedure is being called when it should, and sometimes it is not.
Here's what I've added to the driver code:
In bpck-fdc.c(bpck_fdc_interrupt()), I print out the address of the handler
just before calling it:
>TRACE(ft_t_noise, "BPCK_FDC_INTERRUPT: handler = 0x%lx", (long)handler);
> handler(fdc); /* this should be fdc_isr() in
> * most cases
> * grab_grab_handler() at
> * probe time
> */
In the fdc-isr.c(fdc_isr()) handler code, I have some instrumentation
at the beginning:
>void fdc_isr(fdc_info_t *fdc)
>{
> int count = 0;
> TRACE_FUN(ft_t_any);
>
>TRACE(ft_t_noise, "FDC_ISR: isr_active = %d", fdc->isr_active);
>TRACE(ft_t_noise, "FDC_ISR: mode = %d", fdc->mode);
>TRACE(ft_t_noise, "FDC_ISR: resetting = %d", fdc->resetting);
>TRACE(ft_t_noise, "FDC_ISR: interrupt_seen = %d", fdc->interrupt_seen);
So... here's an excerpt from the logfile that looks pretty good:
>Feb 7 10:12:38 morse kernel: [146] bpck-fdc.c (bpck_fdc_interrupt) -
>BPCK_FDC_INTERRUPT: handler = 0xca8463a4.
>Feb 7 10:12:38 morse kernel: [147] 0 fdc-isr.c (fdc_isr) - FDC_ISR:
>isr_active = 0.
>Feb 7 10:12:38 morse kernel: [148] 0 fdc-isr.c (fdc_isr) - FDC_ISR: mode = 0.
>Feb 7 10:12:38 morse kernel: [149] 0 fdc-isr.c (fdc_isr) - FDC_ISR:
>resetting = 1.
>Feb 7 10:12:38 morse kernel: [150] 0 fdc-isr.c (fdc_isr) - FDC_ISR:
>interrupt_seen = 0.
We see that we are about to call a handler at address 0xca8463a4, followed
by the instrumentation in the fdc_isr() handler itself. So far so good.
Now here's another excerpt:
>Feb 7 10:12:37 morse kernel: [132] bpck-fdc.c (bpck_fdc_interrupt) -
>BPCK_FDC_INTERRUPT: handler = 0xca8463a4.
This is followed by log messages that will not be hit until *after* the
handler(fdc) call. It appears, to casual observance, that the call to the
handler simply didn't happen. My one other observation is that the only
calls to handler(fdc) that appear to be happening are those in which the
fdc->resetting bit happens to be set.
Any idea what's going on... anyone?
Nathan Meyers
[EMAIL PROTECTED]
