ccefhh@rivm.UUCP (Frits v de heuvel) (09/22/88)
We've got a problem with PC-Interface in cooperation with some communication programms. The equipment: - Different types of OLIVETTI / AT&T PC. M24, M240, M28, & M280 = 6300 and 6300+ type. - 3Com Etherlink boards type 3C501 connected coaxial to fileservers (RG-58) - Standard COM1 + added COM2 Amptron IOS-r card (Taiwan) used to connect via current loop interfaces with other systems. - 640 KB ram or more The software: - OLIVETTI MS-DOS versions 3.10, 3.27 & 3.30 - PC-Interface versions 2.8.0 & 2.8.6 LOCUS computing corporation (DOS distribution) - PROCOMM version 2.4.2 and the latest version of PCPLUS - KERMIT several types (latest version V2.29) Without activating the PC-Interface software, communication is working well with PROCOMM & KERMIT through either COM1 and COM2. As I activate PC-Interface, (login on a fileserver), and start PROCOMM or KERMIT, terminal emulation seems to be as good as impossable. What happens ? When output on the screen reaches the bottomline and the screen needs to scroll, it seems that FLOW CONTROL doesn't work anymore. Parts of the information are damaged and other parts are placed random on the screenline. BTW. file_transfer still works because of the protocols. Question: Does anybody have a solution for this problem? Or maybe you have a suggestions which points in that direction. Please let me know !!!! Regards, F.H. van den Heuvel. mcvax!rivm!ccefhh rivm!ccefhh@mcvax.uucp
jlfox@cisunx.UUCP (James L Fox) (10/07/88)
In article <1053@rivm05.UUCP>, ccefhh@rivm.UUCP (Frits v de heuvel) writes: > We've got a problem with PC-Interface in cooperation with some > communication programms. > ..... Fritz is using Olivetti's and AT&T PC's with 3COM 3C501's and typical COM1-2 cards running PC-Interface, PROCOMM, and KERMIT. > ..... > When he runs kermit he gets what appear to be flow control problems resulting in a messed up screen display. > ..... > > BTW. file_transfer still works because of the protocols. > ..... > Does anybody have a solution for this problem? > ..... > Thanks for posting this Fritz! I don't have a solution to the problem yet but I thought I'd post to add support to your belief that something is awry. I'm using an IBM-PC/XT with a 3COM 3C501 board running SUN's PC-NFS and kermit v2.30 and I'm experiencing alomost identical symptoms to yours. I'm on a thinwire with a SUN 3 local host. I've been giving our technicians grief getting them to play games with my serial connection which is to a DEC-server. I hope the SUN and 3COM people are "listening!" --Jim Fox
romkey@asylum.UUCP (John Romkey) (10/08/88)
For the people who are having problems with Kermit and 3C501's: make sure that the 3C501 is not using the same interrupt vectors as your COM ports. COM1 uses interrupt 4; COM2 uses interrupt 3. Make sure the 3C501 isn't using 3 or 4 then. Interrupt 5 or 2 is probably safe, depending on what other hardware you've got installed. -- - john romkey UUCP: romkey@asylum.uucp ARPA: romkey@xx.lcs.mit.edu ...!ames!acornrc!asylum!romkey Telephone: (415) 594-9268
donegan@stanton.TCC.COM (Steven P. Donegan) (10/08/88)
> When he runs kermit he gets what appear to be flow control problems > resulting in a messed up screen display. > > > > BTW. file_transfer still works because of the protocols. > > ..... > > Does anybody have a solution for this problem? I have reproduced this type of problem again and again in the lab. What is happening is fairly simple. While running a networking package with file system support and a communications program using the RS-232 ports and interrupt driven I/O data will get lost on the RS-232 link. This is a very simple problem - the PC, under the DOS operating system, is simply not capable of handling both high speed (ethernet or starlan) I/O and interrupt driven serial port I/O at the same time. Too many portions of DOS turn off interrupt processing and lost interrupts during this time show up at any serial rate higher than 1200 on an 8mhz AT, worse with slower systems. Most networking software and the file transfer protocols under terminal emulation programs can recover from the lost data, but in terminal mode you WILL lose data and it will be visually obvious. The answer is - turn of the networking during critical terminal emulation functions or get an operating system for the PC that handles these interrupts more gracefully (like UNIX :-)) ). Sorry, but I think you're stuck with the problem :-( .
klein@lupine.UUCP (Doug Klein ) (10/11/88)
In article <956@asylum.UUCP>, romkey@asylum.UUCP (John Romkey) writes: > > For the people who are having problems with Kermit and 3C501's: make > sure that the 3C501 is not using the same interrupt vectors as your > COM ports. COM1 uses interrupt 4; COM2 uses interrupt 3. Make sure the > 3C501 isn't using 3 or 4 then. Interrupt 5 or 2 is probably safe, > depending on what other hardware you've got installed. To change the int on the 3C501, move the jumper on the the card. (See the manual). But if you do, you have to tell PC-Interface that you did this with a run-string switch, '-x'. For example, changing the int to 5 means you should change the cmd line for PCI to: pciinit -x13 -iAA.BB.CC.DD (13 = 8 + 5). -- Doug Klein Network Computing Devices uunet!lupine!klein