Internal serial ports under AT&T 3.2

[Steve Neighorn]

In article <595 at pmafire.UUCP> dave at pmafire.UUCP (Dave Remien) writes:
>Remember all the flaming about internal serial ports (COM1 and COM2)
>being unable to handle significant (i.e., over 2400) baud rates under
>UNIX (Microport took most of the heat), where SCO had no problems? I've
>been working on a 20Mhz AT&T 6386WGE (WGE!?) tower, and under AT&T V/386
>3.2, the internal port can't reliably handle 1200 baud, on an unloaded
>system.  An AT&T IPC-802 intelligent card can handle the serial I/O
>without problems, but plugging an HP Paintjet into one of it's two
>parallel ports causes the Wangtek 125Mb tape drive to fail, and then the
>serial ports act weirdly (sometimes you can talk to 'em, sometimes you
>can't).  Plugging the Paintjet into the internal parallel port,
>everything works fine.  Thought I was going bananas, until I discovered
>that. 

Please no flames if I am entirely off-base, but I have encountered problems
relating to failing devices on machines I was asked to look at because of
conflicting interrupts. For example, the normal LPT1 interrupt is 7, and
the normal LPT2 interrupt is 5. Int 5 is also normally used by the Bell
Tech tape drive interface card, so there goes your 2nd printer port. Also,
I have seen network cards installed on Int 3 (Normally used for COM2) cause
problems with serial communications. In addition, problems can arise from
conflicting base addresses, ie Ethernet card and Tape card both strapped 
for 0x300H base address. You might try checking your interface cards and
of course the appropriate space.c files in your kernel config directory.

I am puzzled by all the serial port problems I read about in this group.
My 80386 Unix machine (catlabs) is connected directly with qiclab. I use
tip between the two machines all the time. qiclab also polls catlabs hourly
for the purpose of archiving certain newsgroups. All this is done at 9600
baud, and often at the same time a mouse is being used on catlabs. I
believe the problems exist, simply by the amount of traffic "serial woes"
seem to generate. I guess the problem is in some part installation 
specific.

If my ideas on conflicting interrupts and/or base addresses is old and
solved news to you, my apologies. I thought I would throw some of my
experiences with mis-behavin' machines into the ring.
-- 
Steven C. Neighorn           !tektronix!{psu-cs,nosun,ogccse}!qiclab!neighorn
Sun Microsystems, Inc.      "Where we DESIGN the Star Fighters that defend the
9900 SW Greenburg Road #240     frontier against Xur and the Ko-dan Armada"
Portland, Oregon 97223          work: (503) 684-9001 / home: (503) 645-7015