frankb@usource.UUCP (Frank Bicknell) (09/08/89)
Hi all. I've recently installed a Computone ATvantage 8$ board on a client's machine. They were also upgraded to 2.3.1, as I was hoping to be able to use HDB uucp and the "working" bi-directional getty. I've used the Xenix 2.3.1 with COM[12] ports and it works like a charm: no questions there. Normally, when there is a process (such as getty) "live" on the port, the DTR signal is asserted to the modem. When that process dies (like when a user logs off or the port is disabled), the DTR drops. This behavior is very nice in that it automatically shuts off the auto answer mode of the modem, forces a hangup, and also resets the modem (like ATZ would) next time DTR comes up. However, when I tried it with the Computone board, I experience the following "funny stuff." Assuming a disabled port, when the machine is booted, DTR remains off (so far so good). Now, I enable the port, and DTR comes on (great so far). However, when I disable the port or kill getty (same thing, sorta), DTR remains on! I check 'ps' and the getty is indeed dead; no other processes have that tty ensnared. Well, I called Computone, and they said, "Oh, you need the new firmware and drivers," which they promptly sent free of charge (thank you, Computone). However, the thing behaves in exactly the same way. Now their tech support says, "gee everyone else's works right... let's see if we can reproduce it here." Well, that's been about a week and nothing so far. Meantime the modem sits there. So, I ask you collectively: am I doing something wrong or is this a little-publicised problem with the 8$ board? -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.SARASOTA.FL.US
root@nstar.UUCP (Larry Snyder) (09/09/89)
In article <234@usource.UUCP>, frankb@usource.UUCP (Frank Bicknell) writes: > Assuming a disabled port, when the machine is booted, DTR > remains off (so far so good). Now, I enable the port, and DTR > comes on (great so far). However, when I disable the port or > kill getty (same thing, sorta), DTR remains on! I check 'ps' > and the getty is indeed dead; no other processes have that tty > ensnared. > > Well, I called Computone, and they said, "Oh, you need the new > firmware and drivers," which they promptly sent free of charge > (thank you, Computone). However, the thing behaves in exactly > the same way. Now their tech support says, "gee everyone else's > works right... let's see if we can reproduce it here." Well, > that's been about a week and nothing so far. Meantime the modem > sits there. I am using the Intelliport AT8 and had the same problems until installing the new drivers and firmware. Have you checked your cable wiring? Are 8 & 20 crossed, 2 & 3 crossed and 1, 4, 5, and 7 straight through to the modem? Make sure you are using the ports for dialout (/usr/lib/uucp/Devices) as ttyi00 - since inbound calls will be using the port at ttym00 (if you have it set up for modem support which waits until CD goes high before sending data out the port). Did you change anything in your /etc/ic_control file? I ended up changing the buffers to 50% on the modem ports. Also, check your modem to make sure you are not enabling the modem to provide DTR. If you disconnect the serial line will DTR drop? If you run /etc/ic_init will DTR drop (it does for me for a second or two than comes back up). -- Larry Snyder SCO Xenix 2.3.2 '386 uucp: iuvax!ndcheg!ndmath!nstar!larry Computone Intelliport AT8 The Northern Star Usenet Distribution Site HST / PEP / V.22 Notre Dame, Indiana USA Home of the fighting Irish!
bblue@crash.cts.com (Bill Blue) (09/09/89)
In article <234@usource.UUCP> frankb@usource.UUCP (Frank Bicknell) writes: >Assuming a disabled port, when the machine is booted, DTR >remains off (so far so good). Now, I enable the port, and DTR >comes on (great so far). However, when I disable the port or >kill getty (same thing, sorta), DTR remains on! I check 'ps' >and the getty is indeed dead; no other processes have that tty >ensnared. > >Well, I called Computone, and they said, "Oh, you need the new >firmware and drivers," which they promptly sent free of charge >(thank you, Computone). However, the thing behaves in exactly >the same way. Now their tech support says, "gee everyone else's >works right... let's see if we can reproduce it here." Well, >that's been about a week and nothing so far. Meantime the modem >sits there. I haven't seen this exact problem with dtr not going low on a disable, but there are still a lot of bugs in the Computone drivers. I have been going round and round with Computone for months now trying to get them all fixed. To their credit, they have gotten some of the uglier ones fixed: 1. upward dcd transitions would be ignored. Not too useful on a modem control line. Fixed. 2. uucp simply couldn't talk if the device used was a major computone port (m0 as opposed to i0). This was really difficult to track down, and once I did it took forever getting them to believe it. The problem was that they weren't initializing the ioctl structure to a known state (all zero's, basically). So when it was passed to an application which &= and |= to set states, it would fail. If all parms were set absolute, it would work. Fixed. Grudgingly. 3. flushing problems. Partly fixed. The above problems are fixed in the drivers I'm using, which are '4.37 beta'. However, there are still other problems with the drivers, which so far, I have not gotten them to fix. "Gee, no one ELSE is having that problem." They are: 1. A Computone port which is used for dial in and dial out will not restart the dial in getty once it has been used for dial out. uucp terminates and the port just sits there with dtr low. Real useful. Of course, things work perfectly with a com port. 2. A user connected to the system via a Computone port at a slower speed ( <4800bps ) will get about a full screen page of text after using the interrupt key. This should (and does on a comm port) immediately abort output and flush buffers, but doesn't on a Computone port. 3. When a Computone port is used on a dial in line, that may experience much traffic, noisy lines, modems that won't 'sync' up, etc., it is likely that such a port will eventually die (can't kill it, can't disable it) or end up with several getty's sitting on it, any one of which can't be killed unless (sometimes) you start with the newest one first and work your way backwards. In either scenario, issuing an '/etc/ic_init -please' which reinits the ports at the Computone driver level, will then allow you to kill the processes that wouldn't kill before. This one is particularly aggravating, because the ic_init will change some stty settings on ports that are working correctly, upsetting what other users may have going on. I'm hoping there are fixes to these in progress, but I'm not holding my breath. I'd like to hear from anyone else who might be experiencing these problems or variations of them. --Bill
root@nstar.UUCP (Larry Snyder) (09/10/89)
I bought the board and also have been having problems. Friday I received a new set of firmware and 4.40 drivers which seem to have corrected most of the problems - except from time to time after using a port for an outbound call, the port will no longer accept incoming calls. I just got done adding: diasable ttym01 sleep 2 enable ttym01 in my calling scripts after the poll is completed and hopefully this will solve my problems > 1. A Computone port which is used for dial in and dial out > will not restart the dial in getty once it has been used for dial > out. uucp terminates and the port just sits there with dtr low. > Real useful. Of course, things work perfectly with a com port. Same problem (see above). > 2. A user connected to the system via a Computone port at a > slower speed ( <4800bps ) will get about a full screen page of text > after using the interrupt key. This should (and does on a comm port) > immediately abort output and flush buffers, but doesn't on a Computone > port. > > 3. When a Computone port is used on a dial in line, that may > experience much traffic, noisy lines, modems that won't 'sync' up, > etc., it is likely that such a port will eventually die (can't kill > it, can't disable it) or end up with several getty's sitting on it, > any one of which can't be killed unless (sometimes) you start with the > newest one first and work your way backwards. In either scenario, > issuing an '/etc/ic_init -please' which reinits the ports at the > Computone driver level, will then allow you to kill the processes that > wouldn't kill before. This one is particularly aggravating, because > the ic_init will change some stty settings on ports that are working > correctly, upsetting what other users may have going on. The other problems haven't developed as of yet - but then I have only been running 2.3.2 and 4.40 drivers since Friday. I have an RMA to return the board and replace it with a Digiboard (for an additional $100) but I am hoping I can get these problems fixed. -- Larry Snyder SCO Xenix 2.3.2 '386 uucp: iuvax!ndcheg!ndmath!nstar!larry Computone Intelliport AT8 The Northern Star Usenet Distribution Site HST / PEP / V.22 Notre Dame, Indiana USA Home of the fighting Irish!
bill@bilver.UUCP (Bill Vermillion) (09/11/89)
In article <337@crash.cts.com> bblue@crash.cts.com (Bill Blue) writes: (many lines describing several different Computone probs deleted - wjv ) > 2. uucp simply couldn't talk if the device used was >a major computone port (m0 as opposed to i0). This was really >difficult to track down, and once I did it took forever getting >them to believe it. The problem was that they weren't initializing >the ioctl structure to a known state (all zero's, basically). >So when it was passed to an application which &= and |= to set >states, it would fail. If all parms were set absolute, it would >work. Fixed. Grudgingly. Re: not initializing the ioctl to a know state. I had an experience that I shall pass on that may help others. The system was an AT but it was using IBM's Xenix 2.0 (I couldn't change that - they were commited to that OS). Working on some output to rf modems I discovered that in that version of Xenix you could not use the &= or |=. This was a system bug. You had to set absolute parameters, and restore the old one upon exit. On the other hand their creat call was "anded" with the system values, and would not use the explicit values unless you cleared umask ahead of time. Gawd! What a broken system that was. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!tarpit!bilver!bill : bill@bilver.UUCP
bill@bilver.UUCP (Bill Vermillion) (09/11/89)
In article <120@nstar.UUCP> root@nstar.UUCP (Larry Snyder) writes: > >I bought the board and also have been having problems. Friday >I received a new set of firmware and 4.40 drivers which seem to have >corrected most of the problems - except from time to time after >using a port for an outbound call, the port will no longer accept >incoming calls. I just got done adding: > diasable ttym01 > sleep 2 > enable ttym01 >in my calling scripts after the poll is completed and hopefully this >will solve my problems I remember having this problem on one site with the Computone boards and the only thing that would cure it was to poweroff. Now - here is the question. I was told that the 8250s can get into a state and that the reset command issued to them won't work, and the only way to cure that is to remove power. Is this true, or is it hogwash. I do know that when I did have the problem, a reboot without turning the power off did NOT cure it. We were running with older firmware, and have not purchased any Computone boards in the past 18 months. Do the new boards/firmware solve this problem? -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!tarpit!bilver!bill : bill@bilver.UUCP
usenet@carssdf.UUCP (UseNet Id.) (09/11/89)
In article <337@crash.cts.com>, bblue@crash.cts.com (Bill Blue) writes: > > .... The problem was that they weren't initializing > the ioctl structure to a known state (all zero's, basically). > So when it was passed to an application which &= and |= to set > states, it would fail. If all parms were set absolute, it would > work. Fixed. Grudgingly. > I just fixed a problem on a C-16 cluster box. Exactly like that. It worked before on an ATX, but under the C-16, default ioctl had all the ECHO* bits set on. My CPU-CPU program failed. Computone told me that they only support users of "Packages" and that if I am actually writing programs I have to apply for a DEVELOPERS KIT. They sent me a form, not too bad, non-disclosure etc..., looks like the process will take a couple of months. Maby that will shed some light on all of this. I haven't told them about the "fix" because I don't have a line of communications with them yet. Mayb they should be listening! John Watson ...!rutgers!carssdf!usenet
frankb@usource.UUCP (Frank Bicknell) (09/14/89)
In article <337@crash.cts.com> bblue@crash.cts.com (Bill Blue) writes: [ we were talking about Computone boards here, especially one with some dead or stuck process on it ] > ...it is likely that such a port will eventually die (can't kill >it, can't disable it) ... > ... In either scenario, >issuing an '/etc/ic_init -please' which reinits the ports at the >Computone driver level, will then allow you to kill the processes that >wouldn't kill before. ... A _thousand_ thank-yous! I've always wondered how in the world one could kill one of those processes which was hung up in the kernel (driver). One time I killed every process but init and that one just for fun. Gee. The only solution I knew before was to reboot. -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.SARASOTA.FL.US
frankb@usource.SARASOTA.FL.US (Frank Bicknell) (09/14/89)
In article <111@nstar.UUCP> root@nstar.UUCP (Larry Snyder) writes: >In article <234@usource.UUCP>, frankb@usource.UUCP (Frank Bicknell) writes: >> Assuming a disabled port, when the machine is booted, DTR >> remains off (so far so good). Now, I enable the port, and DTR >> comes on (great so far). However, when I disable the port or >> kill getty (same thing, sorta), DTR remains on! I check 'ps' >> and the getty is indeed dead; no other processes have that tty >> ensnared. > >I am using the Intelliport AT8 and had the same problems until >installing the new drivers and firmware. ... Ah, but you are using Intelliport. I am using ATvantage. Therein could lie the difference. Others have responded indicating they had the same problem. Does _anyone_ have an ATvantage 8-port working properly with a modem out there? I'll take my results to Computone for their "perusal". In the meantime, I'm taking a COM1 down there to set up these folks' modem: I'm sure glad they aren't depending on it for anything important. -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.SARASOTA.FL.US
bblue@crash.cts.com (Bill Blue) (09/17/89)
In article <237@usource.UUCP> frankb@usource.SARASOTA.FL.US (Frank Bicknell) writes: >In article <111@nstar.UUCP> root@nstar.UUCP (Larry Snyder) writes: >>I am using the Intelliport AT8 and had the same problems until >>installing the new drivers and firmware. ... > >Ah, but you are using Intelliport. I am using ATvantage. >Therein could lie the difference. > >Others have responded indicating they had the same problem. >Does _anyone_ have an ATvantage 8-port working properly with a >modem out there? I'll take my results to Computone for their >"perusal". In the meantime, I'm taking a COM1 down there to set >up these folks' modem: I'm sure glad they aren't depending on it >for anything important. I am using both the Advantage and Intelliport on two different systems. As long as I use the same drivers, the bugs seem to be the same. Btw, I've started up communications with Computone again, and detailed the behaviors of the last three bugs I reported in a previous message. They seem to be sincere in wanting to sqaush them... Stay tuned. --Bill
larry@nstar.UUCP (Larry Snyder) (09/17/89)
> I am using both the Advantage and Intelliport on two different > systems. As long as I use the same drivers, the bugs seem to > be the same. > > Btw, I've started up communications with Computone again, and > detailed the behaviors of the last three bugs I reported in a > previous message. They seem to be sincere in wanting to sqaush > them... Stay tuned. In my dealings with them I talked with Ken in Tech Support. He mailed me the latest drivers and firmware (4.40) and the problem with bi-directional communications was still there. I ended up calling Tech Data and getting an RMA for the Intelleport. Now I am back at looking for multiport boards - and Digiboard looks like another good choice (comments anyone?). -- Larry Snyder SCO Xenix 2.3.2 '386 uucp: iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site HST / PEP / V.22 Notre Dame, Indiana USA Home of the fighting Irish!
mark@promark.UUCP (Mark J. DeFilippis) (09/19/89)
In article <387@crash.cts.com>, bblue@crash.cts.com (Bill Blue) writes: > In article <237@usource.UUCP> frankb@usource.SARASOTA.FL.US (Frank Bicknell) writes: > >In article <111@nstar.UUCP> root@nstar.UUCP (Larry Snyder) writes: > >>I am using the Intelliport AT8 and had the same problems until > >>installing the new drivers and firmware. ... > > > >Ah, but you are using Intelliport. I am using ATvantage. > >Therein could lie the difference. > > > >Others have responded indicating they had the same problem. > >Does _anyone_ have an ATvantage 8-port working properly with a > >modem out there? Yea, we do. Well, err.. sort of... Would you believe we used to... You see, it goes like this... Once upon a time when we had ATvantage-X boards with 2.45 proms, and device drivers 3.02 we could use a modem as a dial in and dial out device. But then we upgraded to the better 3.0 proms, and better 4.04 drivers, and we no longer have that capability. I believe this was a new feature. :-) Even worse, We have a 4 port board (Atvantage or dollar, who can keep track). Its the board with the DB45's on it, 3.0 proms and whatever the newest drivers are. That board has a hardware problem which manifests itself in that when you hit interrupt, the board continues to flush its output buffers. We purchased several for a few clients, and Computone is aware of the problem. They are not going to fix it. After several months of support calls, you eventually get the hint. By the way, we use the new IP boards also, and we have the same problem with the modems using that product. Is there much difference between the ATvantage-X and the IP, besides the neat racing lights on the IP? When we purchased out first IP board, we were told it supported 8 virtual terminals. After we received it, they denied they said that. The IP board only supports 2 virtual terminals. And if you want to retain the screen between both screens the terminal must have 2+ pages of display ram, and be able to remember its cursor location. (Some terminals have multiple pages of ram, but don't remember their cursor locations from page to page. eg. tvi925's). I will say, we continue to use their boards. Aside from these problems, the boards are reletively reliable and they install with relative ease compared to other vendoes we have tried. -- Adelphi University, Garden City, NY 11530 (516) 663-1170 Department of Mathematics and Computer Science markd@adelphi.UUCP or mark@promark.UUCP UUCP: ...philabs!sbcs!bnlux0!adelphi!markd