Date: Wed, 29 Nov 1995 04:10:10 +1100 From: Bruce Evans <bde@zeta.org.au> To: jgreco@brasil.moneng.mei.com, msmith@atrad.adelaide.edu.au Cc: freebsd-hackers@freefall.freebsd.org, hsu@clinet.fi, rich@spirit.com.au Subject: Re: 16 ports Boca - anyone using it? Message-ID: <199511281710.EAA05675@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> and fortunately somebody was at the office to observe the logic probe.
>> The interrupt line is being held ACTIVE....???!!! (solid red on the probe,
>> normally green).
>Yecch.
>> Do any sio-shared-interrupt-geniuses have any ideas? I can picture all
>> sorts of plausible race conditions and I have no idea what the code is
>> doing.
The outer loop in siointr() is mainly for handling this problem. It is
supposed to do enough to handle all relevant races.
>ISA interrupts are edge-triggered, so something happened to lose you one.
The edge of one.
>You could possibly add some code to siopoll() to check the interrupt status
>of open ports, and spew a console printf if it found a port with pending
>interrupt status. Something like :
> if (incc <= 0 || !(tp->t_state & TS_ISOPEN))
> continue;
>+ disable_intr();
>+ iir = inb(com->int_id_port) & 0x07;
>+ enable_intr();
>+ if (iir)
>+ printf("sio%d: interrupt pending (%d) in poll\n",
>+ com->unit,iir);
> /*
> * Avoid the grotesquely inefficient lineswitch routine
> * (ttyinput) in "raw" mode. It usually takes about 450
>(Bruce is probably laughing himself silly over some obvious mistake I'm
> making here, but that's what I'd start with).
Heh heh :-). The test should be `if ((iir & 1) == 0)' and it might be
better not to disable interrupts - you will see too many normal interrupts
as it is. I would arrange to run the test when the device has wedged.
It would be interesting to know which ports hang.
>If this "works" (it may fill your log partition pretty quickly 8), then
>we could find a way to call siointr to handle the missed interrupt.
Just calling siointr() might work. It loops sufficiently. Writing to
all affected devices has a small chance of working. sio's "smart"
handling of this problem results in in only calling siointr1() for each
device and separate calls to siointr1() probably wouldn't be atomic
enough to clear the interrupt (modulo races, new output interrupts might
keep the interrupt on).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511281710.EAA05675>