Re: sio / puc wedging on both -current and -stable

On Tue, 18 May 2004, Mike Tancsa wrote:

> Thanks for the response! I will work on providing the information below
> today.  One quick note that I am not sure if its a fluke yet or something
> important, the problem *seems* to go away, if on the STABLE box, I remove
> the defs for sio2 and sio3

[Another reply said that this didn't actually help.]

> On a possibly related point, I think I might have locked up my firewall at
> home in a similar manner once.  I tried once to attach to a com port that
> was defined in the kernel, but disabled in the BIOS.  This froze up the
> machine.  I wonder now if it was perhaps the same root cause.

I think it is a different problem.  The disabled-port one is diagnosed in
PR 55930 (nonexistent ports must not have 0x10 set in their flags).

> >Going through intr_mux() means that the interrupt is not fast
> >(options PUC_FASTINTR).  Try that.
>
> OK, but I thought one is not supposed to use that option if the Interrupts
> are shared no ?

Yes, if the interrupts are shared (with a different device).  You could
try it anyway, possibly after arranging that the interrupt isn't shared.

> >It may be significant that the hang seems to occur while openig the console
> >device.  Do you have a serial console on the puc device?  I thought that
> >this doesn't work.
>
> No, I have it on just the built in cuaa0. The hangs will happen with or
> without serial console support. I only moved to the serial debugger as I

Then it is very strange that cnopen appears in the traceback.  cnopen()
is only for opening the console device.  cnopen() is just the function
being interrupted, not the direct cause of the hang.  It looks like
something opens the console device every now and then, and the sio-level
part of this open does something which triggers spurious interrupts on
a different sio port.  I don't know how this can happen.

Bruce