I think I have two bugs in the 1.5 release kernel.  One is just
really annoying, the other is more serious.

1. I'm still messing about with the Cyclades 8Y serial card, and I have it
working, but I'm pretty convinced that the interrupt machinery in the
kernel has some sort of timing hole.  What happens is that interrupts
get invoked by the hardware that never show up as a call to the interrupt
handler.  I think that what's happening is that the low-level interrupt
handler(s) in macppc are doing something wrong, and masking the interrupts
from the card in some (rare) circumstances.

Der Mouse has been very helpful with this and my soft interrupt problem
(the one that got PPP working).  Can someone point me to the code/flow
so I might be able to dig into this.  The code in macppc/extintr.c
does not look like the right place..... or maybe I'm not following the code...

2. When I use an Asante 10/100 ethernet card (this is the card with the
"real" tulip chip, not the "lite-on" chip.  It loads the "de" driver.)
It's in my 7600/132.  When I have
two serial ports active banging away with ppp moving data, I can easily
crash the kernel (panic: m_copydat()).  All I have to do is use the
ethernet for some slightly intense traffic and boom!
The telltale message in the system log is:

Jan 22 22:24:42 p75 /netbsd: de0: abnormal interrupt: transmit underflow (raisin
g TX threshold to 96|256)
Jan 22 22:24:43 p75 /netbsd: de0: abnormal interrupt: transmit underflow (raisin
g TX threshold to 160|1024)
Jan 22 22:24:43 p75 /netbsd: de0: abnormal interrupt: transmit underflow (switch
ing to store-and-forward mode)
-> panic here

One or more of these messages seems to consistently and immediately
precede the crash.

If it does not crash, it appears to step on the kernel callout table, and
disable my serial ports (which is why I started messing with this)

Ideas?  Is this a known problem?

I tried to get a stack trace, but "trace" command at the prompt after
panic resulted in some pretty useless output that was all ffffff addresses.
Is this the kernel debugger that I hear is busted?   Can anyone tell me
how to get a useful stack trace from this condition?

Thanks,

-dgl-