Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!math.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.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: <1993Jun1.224734.10343@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <1u81il$o45@wzv.win.tue.nl> <1993May30.065415.28948@fcom.cc.utah.edu> <C7wwwJ.4Ku@flatlin.ka.sub.org> Date: Tue, 1 Jun 93 22:47:34 GMT Lines: 110 In article <C7wwwJ.4Ku@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >In <1993May30.065415.28948@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >>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. > >Yeah right. If that were the case then FAS wouldn't be able to >sustain 115kbps on dumb boards with 16550s with precisely this >technique. Nonsense! I've been able to do the same thing in commercial DOS, UNIX, and MS-Windows serial drivers I've written; the point is to do serial I/O at the expense of everything else. You take one interrupt, and then instead of waiting for the next interrupt, you mask them and poll like hell keeping a contiguous missed character count, on the theory that serial communications are "bursty". When your count hits a threshold, you reenable the interrupts and return. This depends on setting the threshold based on instruction timing and the data rate at which you run. Any idiot can do 115k. This is complicated under DOS by stupid keyboard interrupt handlers (like Zenith's KEYBUK.COM for the United Kingdom) that process the translation of scan codes *during* rather than *after* the service routine -- giving a long latency of disabled interrupts during which serial traffic can be lost. The same problem (disabled interrupts) occurs in some video BIOS when INT-10 is used (like Paradise and Hercules adapters) since they mask interrupts rather than looking for the vertical retrace to guard against "sparklies". The problem in checking "data available" on each serial device is that this takes as much time as reading multiple characters, and thus isn't a friendly thing to do if the "data available" indicators are spread over several chips. This isn't the case for the 16550, which also has the advantage of an on-board queue to deal with latency in responding to the interrupts in the first place. As has been pointed out here time and again, the main limitations are the serial hardwares TTL connection to the bus (whether a non-asserted IRQ line is held low or just floats) and the ability to handle interrupts in a slightly different way (which means all hardware has to support it, since the masking methodology changes for ALL interrupts in this scenerio). Multiport boards get around this by keeping the data available seperately for each UART and handling the IRQ signalling using a common mechanism; this is what Digiboard and Control Systems Hostess boards do. The "smart" boards for Control Systems, Digiboard, Arnet, Computone, etc., etc. basically download a portion of the tty struct (generally, the queue and flow control mechanisms, and, in some cases, cannonical processing) to on-board "intelligence" (basically an I/O coprocesser). The entire mechanism for tty handling changes. This can be particularly bad if the flow control mechanisms and cooker mechanisms aren't programmed correctly; Computone, for instance, defaults to stipping the 8th bit in it's SCO drivers, and this is *BAD* for serial transfer protocols, SLIP, and internationalization (8 bit clean internationalization, anyway). Generally, you will *Never* get interrupt sharing to work happily on serial ports on seperate boards without some changes, although I think this is much less drastic than what some people have claimed in terms of "cooked boards" as a result of one board pulling high while another pulls low. I find real damage in this situation highly unlikely, and even if it were to occur, it would be a resistor rather than the output driver on some chip that would cook (unless you changed the interrupt strategy as above, in that interrupts would be asserted for extended periods of time -- during their service). On the UARTs on Tandy and Zenith machines I've worked with, the fact remains that there is no register available to determine if a specific card caused the interrupts, and these are nominally considered PC hardware. I can't remember if the DEC Rainbow had this problem as well; I seem to remember that the "Rev A" boards did, but the "Rev B" did not. The applicability of the problem, however is to the 386/486 Tandy and Zenith machines (and since DEC now OEMs Tandy machines, DEC is still involved). In conclusion: Given very particular hardware requirements (of which you would have to be well aware in order to write the driver), a software driver soloution *could* be implemented. Outside of these bounds, a combined software and hardware soloution is required. If the issue is simply the card gating the IRQ low rather than it floating low, a soldering iron, exacto knofe, and in914 diode is all that's needed to put you back on the track of a software soloution... you put a diode inline to the IRQ line from the card to the bus. This is a low hardware requirement (or near-software) soloution. If, on the other hand, your hardware doesn't support the idea of flagging that it caused the interrupt (as Zenith, Tandy, and some Rockwell Chipset modems do not support flagging), then there is no way short of replacing the offending hardware. A software or near-software soloution does not exist. There *are* cases where a software-only soloution is possible (my original premise; I did not mean for people to take it as an overall soloution for all cases), and there *are* cases where a soloution is clearly impossible (bad electronics on a serial port on the motherboard). The original poster will have to know a *hell* of a lot more about *exacly* how his serial hardware is put together to find a soloution, *but* that does not mean that there is *not* a soloution in his particular case, as everyone seems to be claiming. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.