Subject: Re: panic: crazy interrupts
To: None <port-sparc@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 11/02/1997 07:07:08
>> I fixed the race condition that was causing this earlier this year
>> in the previous version of the zs driver.
> I looked at that when you posted the message, but I thought the new
> version of the driver was OK. Maybe I was wrong.
It sure doesn't seem OK on my machine. :-)
> It is supposed to work this way: If the kernel calls zscnputc when
> the transmitter had been busy, it will wait for it to be non-busy,
> and then make it busy again. The interrupt-driven output should
> still get a transmit-complete interrupt, after the last character
> written by zscnputc finishes going out.
Perhaps it will. But first, it seems, it takes the
previously-requested interrupt immediately after zs_putc() drops ipl,
at which point the chip has no interrupt pending 'cause it was cleared
by writing the character to be transmitted. From this we can deduce
that the hardware latches interrupt requests, so that when the chip
drops its interrupt request the cpu ends up taking the interrupt
anyway...but broken or not, that is the way it works and NetBSD will
have to deal with it.
> This was how the old com driver did things as well, and the only
> "problem" with the method is that it will cause extra transmit
> complete interrupts (no big deal).
Ah, but those extra interrupts are _exactly_ the problem: when zshard()
finds that the chip doesn't want to interrupt, it concludes
(incorrectly) that it didn't want to interrupt, and returns zero,
causing the interrupt machinery whines about a stray interrupt. The
reason this leads to "panic: crazy interrupts" is that the stray
interrupt whine is output via zscnputc() and therefore provokes the
condition again.
> After looking again, it appears that the new <arch>/dev/zs.c does not
> ignore supurrious interrupts. Should it?
gwr seems to think the SPARC version should. If nothing else uses
interrupt level 12, I'd agree; if so, I might still agree but would
want to take a careful look at how interrupts work first.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B