Xref: utzoo comp.unix.sysv386:7279 comp.unix.wizards:25117 comp.unix.internals:2623 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!tellab5!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.unix.sysv386,comp.unix.wizards,comp.unix.internals Subject: Re: System V, B0, and DTR. Keywords: iNTeL SVID callback etc... Message-ID: <1991Apr24.213344.21645@chinet.chi.il.us> Date: 24 Apr 91 21:33:44 GMT Article-I.D.: chinet.1991Apr24.213344.21645 References: Organization: Chinet - Chicago Public Access UNIX Lines: 24 In article peter@ficc.ferranti.com (Peter da Silva) writes: >It seems that the SVID >does not define what happens when you set speed to B0 (to drop DTR) and >then back to another baud rate (B2400, say). >iNTeL says that even though it's a 2-line fix they >can't do it because it's not in the SVID... even to do a workaround for >us. The iNTeL technical people are quite helpful, and seem as frustrated >as us. If it's not defined, how does that prevent them from doing it right??? I'm pretty sure AT&T's 3b2/386 releases will bring DTR back up. >Any suggestions? (no, closing and opening the port doesn't appear to be >an option in this case) What do you people think the Right Thing to do is? I don't quite understand that attitude either - if you've got the source and a close/open makes it work why is there any question about doing it? How about open/close on another fd following the ioctl restoring the speed to non-zero while your current fd remains open? I would expect that to fix things without the change of close/open returning a different fd. Les Mikesell les@chinet.chi.il.us