Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!uwm.edu!wupost!bigboy.sbc.com!news.mtholyoke.edu!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Modem setup on 386BSD [and a further QUESTION] Message-ID: <1993May30.065415.28948@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <CJB.93May28115334@thrip.cs.uq.oz.au> <1993May28.195017.23712@fcom.cc.utah.edu> <1u81il$o45@wzv.win.tue.nl> Date: Sun, 30 May 93 06:54:15 GMT Lines: 34 In article <1u81il$o45@wzv.win.tue.nl> guido@gvr.win.tue.nl (Guido van Rooij) writes: >terry@cs.weber.edu (A Wizard of Earth C) writes: >>Interrrupt sharing depnds on being able to ask all devices using the >>interrupt if they were the one that caused the interrupt -- basically, >>the interrupt is a "data available" flag. Most serial hardware doesn't >>support a flag to indicate data available since last read. Multiport > >Not true. The 8250, 16440, 16450 and friends all have a bit telling if >this UART triggered the interrupt. (bit 0 in the IIR register). Hmmm. I guess I just had a weird UART at the time I arrived at this, and never bothered to reresearch it. It was an Intel 320 multiport board (I-428 board? Can't remember). >The reason you can't share interrupts between cards in different slots >in an isabus system is the fact that you can break your hardware: if >one card generates an interrupt it wants to hold up, say, the isa bus's >irq 3 line. But the other card is holding the same line down. Unless you >designed your system such that this is allowed, normally you have problems. Of course, the two cards I've checked so far *don't* sink the current low when the interrupt is not being asserted, so this isn't true either; I'll try some more cards after I wake up. Even if this isn't a problem, polling all the cards and reading one byte from one or more of them is going to limit the overall throughput something fierce. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.