peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
OK, I'm having a problem implementing callback on an iNTeL 520 (multibus-2 based 386/486 multi-CPU box) with System V/386. 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). I beleive that it should raise DTR again (after all, why allow the B0 hack otherwise? If you want to drop DTR altogether and never talk to the device again why not just close the port?). 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. 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? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
les@chinet.chi.il.us (Leslie Mikesell) (04/25/91)
In article <D_XA6J2@xds13.ferranti.com> 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
peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
I said: > >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? In article <1991Apr24.213344.21645@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > 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? Well, I'll give you a hypothetical example, and then the real reason. Either should be enough. They both come down to "close/open doesn't make it work". Hypothetical case: you have another application running that you don't have the source for and for some reason you can't terminate it and start over. This is a problem with terminal programs under AmigaDOS, where they need to keep the port open in a shared mode for things like serial networking. It is a potential problem under UNIX, which is why B0 is there. The real reason: it doens't work. There is a bug somewhere else in the driver that leaves us with no control terminal after we open the port. intel acknowledges that this is incorrect, but has not been able to reproduce it (they have a significantly different system configuration, too). We are using the same program, with the same options, and the same setup. Intel is willing to debug and fix this, at considerable cost to themselves, but is unwilling to make a 2-line change unless they can be sure it retains the correct semantics. Something about staying in sync with AT&T. That's why I'm asking this question on the net: to demonstrate that the behaviour we desire is the right thing to do. While it's frustrating in this case, this conservative approach *does* seem to be better than ISC's and SCO's habit of arbitrarily breaking stuff. > How about open/close on another fd following the ioctl restoring the > speed to non-zero while your current fd remains open? Doesn't work: DTR is only raised on first open and dropped on last close. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
rbj@uunet.UU.NET (Root Boy Jim) (04/27/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >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 they are truly as frustrated, they will do it under the table for you. Clearly, it is so obvious that SVID forgot to mention it. >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? You mean short of walking into the next board of directors meeting with an AK-47? The right thing to do is complain about everything else they do that isn't in the SVID. They should do anything you ask if you pay them. -- [rbj@uunet 1] stty sane unknown mode: sane