Xref: utzoo comp.unix.xenix:4064 comp.unix.wizards:13117 Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!tut.cis.ohio-state.edu!ukma!gatech!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.unix.xenix,comp.unix.wizards Subject: Re: wakeup() race condition. (theory) Summary: SCO's driver ALSO has problems (RTS & no interlock) Keywords: wakeup sleep spl Message-ID: <2306@ddsw1.MCS.COM> Date: 2 Dec 88 22:36:35 GMT References: <455@mrecvax.UUCP> <602@sysco> Reply-To: karl@ddsw1.MCS.COM(Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 51 In article <602@sysco> chapman@sco.COM (Brian Chapman) writes: > >BTW just in case anyone is wondering, SCO's serial driver >does *NOT* call wakeup from it's level 7 interrupt routine. BTW: Just in case anyone cares, the reason people are investigating alternate drivers for SCO Xenix and non-intelligent boards is that the "stock" driver provided, while quite adaptable (and possessed with good overall performance): 1) Has never managed to get bi-directional ports w/internal locking working (ala: open "non modem" port, modem port is blocked, etc. It's been described here and is done by many other firms; email me for full details). Thus we have to use brain-dead schemes which work (some of the time) like ungetty, and I have to deal with customers (and our gear) that has deadlocked lines once in a while. 2) Has a broken RTS flow control capability. (No flames for the "non-standard" in RS232. Broken in the above means the Telebit won't talk to it when RTSFLOW is selected; you get low RTS and that's all folks!) This (and the inclusion of '286-compiled utilities!) is really the only "nasty" complaint I have had with your software in the year or so I've been running it. Other minor complaints include locking discrepancies with the SVID, but we've worked around those (and they're addressed in 2.3, from what I hear). If SCO would fix the serial driver problems, and offer a reasonably- inexpensive (ie: not a $600 update-the-entire-system fix) way to get the fix (aka: the "fix disks" you guys do now) then the stock driver would be completely adaquate. If you additionally enabled FIFOs if present on the UARTs you'd have a bombshell. At present, the 2.2.x /386 serial support out of the box is only passable without external augmentation (ie: smart board w/driver). It appears that some internal design decisions in the kernel make it more difficult to get reasonable operation from drivers that must operate at high priority as well; note though that I'm only a decent driver-hacker (as opposed to a guru). We have had some interesting problems playing with replacements for the stock stuff - _nothing_ is reliable enough for me to release yet (it's not our code; but we're hacking on it). We've not seen 2.3 yet; the last time I checked an update from 2.2.x was not available, nor was cost of same, although I could obtain a "new" 2.3 (at full cost, of course). -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"