davek@lakesys.UUCP (Dave Kraft) (08/14/89)
Hi, Where I work, we've got two internal modems (can't remember make offhand), configured as MS-DOS's COM3: and COM4:, but, when Xenix is started up, they aren't listed on the first screen where it lists what you have in your system. I can mkdev serial them allright, but when I try to access them with cu, it comes back with an error messge like "cannot acces", or something... what's wrong here?? Oh, ther version I have is 386 2.3.2. Thanks in advance. Dave -- davek@lakesys.lakesys.com uunet!marque!lakesys!davek ------------------------------------------------------------------------------- "You can't beat a good conspiracy" --'Billionaire Boys Club'
root@.UUCP (Larry Snyder) (08/15/89)
In article <958@lakesys.UUCP>, davek@lakesys.UUCP (Dave Kraft) writes: > configured as MS-DOS's COM3: and COM4:, but, when Xenix is started up, they > aren't listed on the first screen where it lists what you have in your system. I thought that only COM1 and 2 were support by the stock release versions of SCO unless you were using a smart card - or multiport board since SCO expects the first com board on IRQ 4 and the second on IRQ 3. -- Larry Snyder uucp: iuvax!ndcheg!ndmath!nstar!larry The Northern Star XBBS/Usenet Site 219-289-3745 (PEP+) 219-287-9020 (HST) Regional Echomail Distribution SIte Fidonet 1:227/1 219-289-0286 (HST)
jbayer@ispi.UUCP (Jonathan Bayer) (08/15/89)
davek@lakesys.UUCP (Dave Kraft) writes: >Hi, >Where I work, we've got two internal modems (can't remember make offhand), >configured as MS-DOS's COM3: and COM4:, but, when Xenix is started up, they >aren't listed on the first screen where it lists what you have in your system. SCO has a patch for this problem. I don't have the number in front of me now, but call them and speak to the media desk. Ask for the internal modem patch. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 500 Oakwood Ave. ...uunet!ispi!root Roselle Park, NJ 07204 (201) 245-5922 jbayer@ispi.UUCP
timk@xenitec.uucp (Tim Kuehn) (08/15/89)
In article <958@lakesys.UUCP> davek@lakesys.lakesys.com (Dave Kraft) writes: >Hi, >Where I work, we've got two internal modems (can't remember make offhand), >configured as MS-DOS's COM3: and COM4:, but, when Xenix is started up, they >aren't listed on the first screen where it lists what you have in your system. >I can mkdev serial them allright, but when I try to access them with cu, >it comes back with an error messge like "cannot acces", or something... >what's wrong here?? I've got the same problem with a Telebit Trailblazer/+ in a 286 Xenix. It worked fine installed as COM2:, but no response as COM3:. Any suggestions? +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Satisfaction Gauranteed| +-----------------------------------------------------------------------------+
chip@vector.Dallas.TX.US (Chip Rosenthal) (08/16/89)
In article <56@.UUCP> root@.UUCP (Larry Snyder) writes: >I thought that only COM1 and 2 were support by the stock release versions >of SCO unless you were using a smart card - or multiport board since SCO >expects the first com board on IRQ 4 and the second on IRQ 3. XENIX doesn't expect any magic cookie -- it uses whatever you've programmed. If you haven't programmed anything, then it uses whatever default SCO gave you. It turns out that /usr/sys/io/sioconf.c is distributed with two entries for dumb cards which correspond to the usual DOS COM1 and COM2 parameters. The structure of this file allows you to associate any of SCO's serial drivers with any of a number of addresses and interrupts. About your only limit here (other than keeping I/O addresses and interrupt vectors unique) is the fact that /usr/sys/conf/master only allows four interrupt vectors per device driver, hence there is a limit of four devices per driver (unless the driver allows some sort of interrupt sharing, which the dumb COM driver doesn't). There is absolutely no reason why you can't move your dumb COM cards to other addresses or interrupts, or throw in a couple more. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 "I wish you'd put that starvation box down and go to bed" - Albert Collins' Mom
root@nstar.UUCP (Larry Snyder) (08/16/89)
> I've got the same problem with a Telebit Trailblazer/+ in a 286 Xenix. > It worked fine installed as COM2:, but no response as COM3:. Any > suggestions? What kind of serial board are you using to provide support for COM3? Will COM3 work with a terminal? Are you trying to dial in or out using the PEP on COM3? It is my understanding that SCO only supports complete modem control on the first two serial lines. -- Larry Snyder uucp: iuxax!ndcheg!ndmath!nstar!larry The Northern STAR XBBS/Usenet Site 219-287-9020 (VHST) - 219-289-3745 (PEP+) Backbone Echomail Distribution Site Fidonet 227/1 219-289-0286 (VHST 2 lines) We carry all backbone Echomail & Usenet newsgroups!
chip@vector.Dallas.TX.US (Chip Rosenthal) (08/16/89)
In article <66@nstar.UUCP> root@nstar.UUCP (Larry Snyder) writes: >It is my understanding that SCO only supports complete modem control >on the first two serial lines. This is not correct. The dumb comm driver provides two minor numbers per adapter, one with and one without modem control. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 "I wish you'd put that starvation box down and go to bed" - Albert Collins' Mom
rosso@sco.COM (Ross Oliver) (08/17/89)
In article <958@lakesys.UUCP> davek@lakesys.lakesys.com (Dave Kraft) writes: >Hi, >Where I work, we've got two internal modems (can't remember make offhand), >configured as MS-DOS's COM3: and COM4:, but, when Xenix is started up, they >aren't listed on the first screen where it lists what you have in your system. >I can mkdev serial them allright, but when I try to access them with cu, >it comes back with an error messge like "cannot acces", or something... >what's wrong here?? It's been a quite I while since I've seen this one mentioned. The reason you are having problems is that your internal modems cannot be set to use interrupts other than IRQ3 or IRQ4. For a serial device to work under XENIX, it must be configured on its own interrupt vector. IRQ4 is allocated to COM1, and IRQ3 is for COM2. Since MS-DOS does not use interrupts, manufacturers of serial cards have taken the I/O ports used by COM1 and COM2, and simply extended them on up through the I/O space, thus producing COM3, COM4, COM5, etc. (I've seen some cards that claim to go up to COM10). However, since XENIX requires interrupts as well as the I/O ports, most of these modems and serial cards won't work under XENIX above COM2. However, if you can set these boards to use other interrupts, then you can use them alongside existing COM1 and COM2 devices. To do this, you will have to modify the /usr/sys/conf/master file to tell the serial driver to handle the additional interrupts. Modify the "vec3" and "vec4" columns for the "sio" entry, then rebuild your kernel. Ross Oliver Technical Support The Santa Cruz Operation, Inc.
jbayer@ispi.UUCP (Jonathan Bayer) (08/17/89)
In article <5101@viscous.sco.COM> rosso@sco.com (Ross Oliver) writes: }The reason you are having problems is that your internal modems cannot }be set to use interrupts other than IRQ3 or IRQ4. For a serial device }to work under XENIX, it must be configured on its own interrupt vector. }IRQ4 is allocated to COM1, and IRQ3 is for COM2. Since MS-DOS does not }use interrupts, manufacturers of serial cards have taken the I/O ports }used by COM1 and COM2, and simply extended them on up through the I/O }space, thus producing COM3, COM4, COM5, etc. (I've seen some cards that }claim to go up to COM10). However, since XENIX requires interrupts as }well as the I/O ports, most of these modems and serial cards won't work }under XENIX above COM2. } }However, if you can set these boards to use other interrupts, then you }can use them alongside existing COM1 and COM2 devices. To do this, you }will have to modify the /usr/sys/conf/master file to tell the serial }driver to handle the additional interrupts. Modify the "vec3" and "vec4" }columns for the "sio" entry, then rebuild your kernel. OK. Since each device must have it's own interrupt, why not make two serial ports both use the same interrupt, and modify sioconf.c to show that the second serial port is nothing more that a second port on the first serial card? For these serial cards that go to com 10 (or whatever), why not simply set up all the ports on the card to use the same interrupt, and set up sioconf properly (specificaly the port count, the interrupt vector, the base address of the board, the interrupt poll address, and the spacing of the io ports on the board). The only potential problem is the interrupt poll address (as I see it) JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 500 Oakwood Ave. ...uunet!ispi!root Roselle Park, NJ 07204 (201) 245-5922 jbayer@ispi.UUCP
rosso@sco.COM (Ross Oliver) (08/23/89)
In article <1112@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes about how to use more than two serial devices under XENIX: >OK. Since each device must have it's own interrupt, why not make two >serial ports both use the same interrupt, and modify sioconf.c to show >that the second serial port is nothing more that a second port on the >first serial card? For these serial cards that go to com 10 (or >whatever), why not simply set up all the ports on the card to use the >same interrupt, and set up sioconf properly (specificaly the port count, >the interrupt vector, the base address of the board, the interrupt poll >address, and the spacing of the io ports on the board). The only >potential problem is the interrupt poll address (as I see it) This will work, provided one other condition is met: each of the cards that share an interrupt must allow the IRQ line to "float" when the card is not asserting it. If one of the cards clamps the IRQ line high (I believe the interrupt lines are active low), another card might not be able to force it low to signal its interrupt. The result at best would be missed or spurious interrupts, and at worst, damage to the hardware. I'm not trying to scare anyone out of trying this; there is a lot of flexibility in sioconf and the master file, so if you think you can make use of it, by all means do it. However, you should also be aware of the potential pitfalls when using hardware designed primarily for MS-DOS. Ross Oliver Technical Support The Santa Cruz Operation, Inc.