cassidy@attctc.Dallas.TX.US (Cassidy Lynar) (12/26/89)
Hi, I am having problems *still* trying to bring up a third serial port on my system. I have spoke with Hollis, and with the Santa Monica office as well, but nobody can figure out what the problem is. A bit of history: I am running ISC 2.0.2 with the X5 update installed. I have 2 internal modems setup using the standard irq and addresses for com1 and com2. My third serial card is setup to use irq5, and the address is set to that of a com3 port. I have included my /etc/conf/sdevice.d/asy entry: asy Y 1 7 1 4 3f8 3ff 0 0 asy Y 1 7 1 3 2f8 2ff 0 0 asy Y 1 7 1 5 3e8 3ef 0 0 asy N 1 7 1 7 2e8 2ef 0 0 Now as for the third I/O board, (I forget the make) it has jumpers that allow to PHYSICALLY change the addresses from 3f8 to 3e8 and the irq from 4 to 5. I also tried to as ISC put it, "fake the kconfig" and modified the /etc/conf/pack.d/space.c and changed the entry to: ASY_3_SIOA+6, /* foo..... */ ASY_5_VECT, /* more foo */ and rebuilt the kernel (this is the second time, the first attempt was not using a modifed space.c. Ok, here is the actual problem, the kernel builds fine, getty spawns fine, but the probs are 1) the getty process becomes a non-killable process 2) when I cat foo >> /dev/tty02, the terminal on the other end, receives the data at a smoking 1 cps or less. I know that the terminal is fine, as I used it at work before bringing it home, and I also know that the card and modems do not conflict, as I have no troubles at all when I boot a DOS communications package, and use a modem on the third port. It seems all too clear that there is an unresolved bug still at large in the asy driver supplied with the X5 update. Upon further communications with ISC i am told that any new bug fixes will be released in the next version only, so it seems that the owners of 2.0.2 are screwed, unless they fork up more money to buy the upgrade when its released. To me, and these are my personal feelings only, I have no reasons to trust that the next version will be any better. The track record of these (2.0.2) release are horrible. If ISC wants to continue the relationship with my company, as a reseller of their product, then they had best make some "special packages" available to those of us who have had to suffer with their product and the bugs that live in it. Cassidy Lynar Vice President, Zen Computer CEO, Computer Research, Inc Dallas, Texas ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UUCP: root@walstib.lonestar.org INET: texbell!walstib!root@cs.utexas.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
johnk@opel.uu.net (John Kennedy) (12/27/89)
In article <10740@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes: > (serial device woes deleted) Two problems come to mind: 1) Is another device (typically the first parallel port) using int 5. This conflict would not manifest itself under dos, with its way of doing one thing at a time. 2) Microport had a patchable bit mask that was used to write to the 8259 interrupt controller. If int 5 was not allocated as the OS was delivered, maybe something has to happen to enable it. The fact that you're getting a character occasionally suggests to me that a TxRDY interrupt is being looked for, but after a timeout the next character is sent. I can't image a serial driver that continues to send under those conditions, but it may be some kind of a failsafe to avoid an infinite wait in the driver. My guess would be the first, a conflict with another device. Or, it could be a bug in the driver :-). John -- John Kennedy johnk@opel.uu.uunet Second Source, Inc. Annapolis, MD
mjs@cbnews.ATT.COM (martin.j.shannon) (12/29/89)
In article <10740@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes: >Hi, I am having problems *still* trying to bring up a third serial port >on my system. [What looks like a good set of sdevice entries] >Now as for the third I/O board, (I forget the make) it has jumpers that >allow to PHYSICALLY change the addresses from 3f8 to 3e8 and the irq from >4 to 5. Sounds like the right thing to do. >I also tried to as ISC put it, "fake the kconfig" and modified the >/etc/conf/pack.d/space.c and changed the entry to: > ASY_3_SIOA+6, /* foo..... */ > ASY_5_VECT, /* more foo */ >and rebuilt the kernel (this is the second time, the first attempt was >not using a modifed space.c. Yeah, that oughtta work, too, I think. >Ok, here is the actual problem, the kernel builds fine, getty spawns >fine, but the probs are 1) the getty process becomes a non-killable process > 2) when I cat foo >> /dev/tty02, the terminal on the >other end, receives the data at a smoking 1 cps or less. That's a symptom I recognize: the ASY driver is not getting interrupts from that card. The only reason you get any output at all is the 1-second sanity timer used to deal with missed interrupts on heavily loaded machines. >I know that the >terminal is fine, as I used it at work before bringing it home, and I also >know that the card and modems do not conflict, as I have no troubles at all >when I boot a DOS communications package, and use a modem on the third port. Yeah, well, DOS doesn't use interrupts for the COM devices, so the fact that a serial port runs under DOS *DOES* *NOT* mean you have it configured properly for UNIX (ISC or any other brand of System V Release 3+ on the '386). [Some pissing & moaning (not entirely unwarranted) deleted.] > Cassidy Lynar Bottom line: your jumpers on the ASY port 2 don't match what the driver thinks is the correct interrupt. You may have a conflict with another interrupt device, or either the ASY's space.c or your jumper may be wrong. The bugs (that *I* have heard of) in ISC's ASY driver don't involve any missed interrupts (except at very high speeds on loaded machines). -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
tneff@bfmny0.UU.NET (Tom Neff) (12/29/89)
In article <12653@cbnews.ATT.COM> mjs@cbnews.ATT.COM (martin.j.shannon,59112,lc,4nr10,201 580 5757) writes: >Yeah, well, DOS doesn't use interrupts for the COM devices, so the fact that >a serial port runs under DOS *DOES* *NOT* mean you have it configured properly >for UNIX (ISC or any other brand of System V Release 3+ on the '386). The above quoted poster may be confusing the fact that the standard IBM PC compatible BIOS serial port service (interrupt 0x14) is polled rather than interrupt driven, so if you use the BIOS (or the default DOS named COMn: devices, whose drivers use the BIOS) for your async I/O, you will not be using interrupts. But the majority of commercial, public domain and shareware DOS hosted communications packages DO NOT use the polled BIOS async service; instead, they substitute their own buffered, interrupt-driven handlers for the sake of improved performance. (The necessity of reinventing this particular wheel in every package ranks as one of the major PC development headaches, but as Ted Kennedy said, that's all water under the bridge.) Therefore it's very possible to test a board's interrupt strapping etc. from DOS. That's not saying that the UNIX V/386 drivers mightn't be pickier than a given DOS comm package. -- "UNIX should be used :: Tom Neff <tneff@bfmny0.UU.NET> or as an adjective." -- AT&T :: ...uunet!bfmny0!tneff (UUCP only)
news@brian386.uucp (News Administrator) (12/30/89)
mjs@cbnews.ATT.COM (martin.j.shannon) writes: >In article <10740@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes: >>Hi, I am having problems *still* trying to bring up a third serial port >>on my system. [ deleted ] >>Ok, here is the actual problem, the kernel builds fine, getty spawns >>fine, but the probs are 1) the getty process becomes a non-killable process >> 2) when I cat foo >> /dev/tty02, the terminal on the >>other end, receives the data at a smoking 1 cps or less. >That's a symptom I recognize: the ASY driver is not getting interrupts >from that card. The only reason you get any output at all is the 1-second >sanity timer used to deal with missed interrupts on heavily loaded machines. [ deleted ] I am having the same problem. Except I am using a non-intelligent digiboard for my system. I tried configuring all the ports on the same interrupt, and had identical results. So then I tried only two of the ports, on two different interrupts. Still the same problem, what do you think could be wrong with mine ;-) Interractive said their driver might not be fast enough to handle 4 ports on the same interrupt, since it checks all ports each time an interrupt is received. But this doesn't explain why the second configuration had the problem. brian -- Wm. Brian McCane | Life is full of doors that won't open | when you knock, equally spaced amid Disclaimer: I don't think they even | those that open when you don't want admit I work here. | them to. - Roger Zelazny "Blood of Amber"
tron1@tronsbox.UUCP (HIM) (01/01/90)
>Item: 553 by *Masked* at attctc.Dallas.TX.US >Author: [Cassidy Lynar] > Subj: YASPP (Yet another serial port problem) > Keyw: > Date: Sun Dec 31 1989 09:17 EST >asy Y 1 7 1 4 3f8 3ff 0 0 >asy Y 1 7 1 3 2f8 2ff 0 0 >asy Y 1 7 1 5 3e8 3ef 0 0 >allow to PHYSICALLY change the addresses from 3f8 to 3e8 and the irq from >4 to 5. I also tried to as ISC put it, "fake the kconfig" and modified the >.... >fine, but the probs are 1) the getty process becomes a non-killable process Oh , but this happens to some us us ANYWAY !!!! (grin) there are some things to try , like (for one) doing a (as root) >/dev/foo where foo is the DIAL OUT device name of that port. > 2) when I cat foo >> /dev/tty02, the terminal on the >other end, receives the data at a smoking 1 cps or less. I know that the SOunds like an interrupt conflict with another driver/device. Try running it on a shared interrup with another port , this should not be a problem. I say this because many dumb cards have one interrupt for 4-5 ports. Alternate driver is being emailed anyway. **************************************************************************** "Perfume and leather baby , you and me together baby, what good is living in paradise, if you don't let yourself once or twice." -Tiffany Kenneth J. Jamieson ---- THE BOSS at Xanadu Enterprises Inc. UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
thomax@utopia.uucp (Thomas Kaulmann) (01/05/90)
news@brian386.uucp (News Administrator) writes: >think could be wrong with mine ;-) Interractive said their driver >might not be fast enough to handle 4 ports on the same interrupt, since >it checks all ports each time an interrupt is received. But this hello, to fix that problem, you must get the X6 - update from ISC. this fix should be able (not testet) to support modemcontrol (hardware- handshaking). X6 includes a new asy-driver, but what i use is an heroic public-domain replacement, wich support the FIFO on an NS16550 and works quit nice include all the other "new" features of ISC's asy-driver... thomax -- . |SE| thomas kaulmann 1000berlin61 alexandrinenstr.42 / //_ __ _ _ __ |OR| Bang: ..!unido!tmpmbx!einoed!utopia!thomax /_//_ /_//_///_/_ R.C.|FA| Domain: thomax@utopia phone# +49 30 614 6641 ________/_____________|TW| Fax# +49 30 392 92 52 phone# +49 30 390 80288
fischer@utower.gopas.sub.org (Axel Fischer) (01/06/90)
thomax@utopia.uucp (Thomas Kaulmann) writes: >news@brian386.uucp (News Administrator) writes: >>think could be wrong with mine ;-) Interractive said their driver >>might not be fast enough to handle 4 ports on the same interrupt, since >>it checks all ports each time an interrupt is received. But this >hello, >to fix that problem, you must get the X6 - update from ISC. >this fix should be able (not testet) to support modemcontrol (hardware- >handshaking). Forget the X6 UpDate - doesn't work as expected. >X6 includes a new asy-driver, but what i use is an heroic public-domain >replacement, wich support the FIFO on an NS16550 and works quit nice >include all the other "new" features of ISC's asy-driver... The PD Driver is superb. It does not support vpix or other stuff, it's just a driver for modems/terminals. Runs with hardwarehandshake and HST MNP 5 and Trailblazern superb. -Axel -- fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP Bang-Europe : ...!{doitcr,gopnbg,tmpmbx}!utower!fischer Bang-USA : ...!uunet!unido!gopnbg!utower!fischer Too low for zero ...