PCI serial adapters - OS2

This is a discussion on PCI serial adapters - OS2 ; Has anyone successfully installed a ***PCI*** Serial adapter with COM.SYS? I have a SIIG CyberSerial PCI single port card that is not quite working for me. The adapter works fine in a completely different machine under W2K with SIIG's drivers. ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: PCI serial adapters

  1. PCI serial adapters

    Has anyone successfully installed a ***PCI*** Serial adapter with
    COM.SYS? I have a SIIG CyberSerial PCI single port card that is not
    quite working for me.

    The adapter works fine in a completely different machine under W2K with
    SIIG's drivers.

    The target machine is a Dell XPS T450 (P3 450MHz) running Warp 4 FP15
    (only) with one onboard serial port as COM1. I paid for my Warp back in
    the day but am not entitled to any non-free drivers/support/fixpaks any
    more.

    I tweaked SIO2k (2.03) to find the card by adding 00=1415 02=950A
    uart@10 to PCI.INC (PCI config header data is over my head but this card
    appears to have vendor=1415 dev=950a/9510 "wrappers" on the vendor=131f
    dev=2000 devices that many drivers, including sio2k, look for), and I
    get a COM2 that works, but with various freezes when opening and closing
    the port, and assorted SYS3176s, mouse freezes and system hangs when
    trying to do anything with serial ports in Win/OS2. I am not a fan of
    SIO and I'd really prefer not to use it. If someone knows how to stop
    all that other bleeding it causes, it does give slightly more reliable
    transmission even with the built-in port than COM.SYS, but I'm not
    holding my breath.

    Using IBM's PCI-aware COM.SYS (Aug 2 2002 bldlevel rev 10.78) with or
    without the /F switch, COM2-COM5 are recognized as 16950 UARTs.
    COM3-COM5 are bogus ports that might be in the adapter chip but aren't
    wired on my board. However, data transferred on COM2: is all crap.
    With a null modem cable to another computer I see that the computer
    receives either nothing or garbage characters with some pattern but no
    particular association to the intended data, and reliably sends the same
    kind of garbage.

    I moved my board around the PCI slots to switch up the IRQ that the BIOS
    gives it, same result.

    Whenever I forced ports (e.g. (1,3f8,4) (2,1040,10)) the driver
    misrecognized the UARTS as FIFOless 16450 or 16350.

    Has anyone had one of these boards working with this driver?

    A side note that I don't think has anything to do with why the PCI port
    doesn't work and the regular port does: serial transmission on this
    computer has always been unreliable under OS/2. Move the mouse or
    switch windows and you get errors all over the place. It's sort of like
    a CPU time issue except this computer is much much faster than my old
    ThinkPad P100 760ELD which is almost bombproof at 115.2kbps running the
    exact same OS. There is something else about this system that
    interferes with serial but I've never figured it out (and I've tried,
    that's a story for another day).

    Thanks, Peter.


  2. Re: PCI serial adapters

    Sir:

    Peter Stokes wrote:
    > Has anyone successfully installed a ***PCI*** Serial adapter with
    > COM.SYS? I have a SIIG CyberSerial PCI single port card that is not
    > quite working for me.
    >
    > The adapter works fine in a completely different machine under W2K with
    > SIIG's drivers.
    >
    > The target machine is a Dell XPS T450 (P3 450MHz) running Warp 4 FP15
    > (only) with one onboard serial port as COM1. I paid for my Warp back in
    > the day but am not entitled to any non-free drivers/support/fixpaks any
    > more.
    >
    > I tweaked SIO2k (2.03) to find the card by adding 00=1415 02=950A
    > uart@10 to PCI.INC (PCI config header data is over my head but this card
    > appears to have vendor=1415 dev=950a/9510 "wrappers" on the vendor=131f
    > dev=2000 devices that many drivers, including sio2k, look for), and I
    > get a COM2 that works, but with various freezes when opening and closing
    > the port, and assorted SYS3176s, mouse freezes and system hangs when
    > trying to do anything with serial ports in Win/OS2. I am not a fan of
    > SIO and I'd really prefer not to use it. If someone knows how to stop
    > all that other bleeding it causes, it does give slightly more reliable
    > transmission even with the built-in port than COM.SYS, but I'm not
    > holding my breath.
    >
    > Using IBM's PCI-aware COM.SYS (Aug 2 2002 bldlevel rev 10.78) with or
    > without the /F switch, COM2-COM5 are recognized as 16950 UARTs.
    > COM3-COM5 are bogus ports that might be in the adapter chip but aren't
    > wired on my board. However, data transferred on COM2: is all crap. With
    > a null modem cable to another computer I see that the computer receives
    > either nothing or garbage characters with some pattern but no particular
    > association to the intended data, and reliably sends the same kind of
    > garbage.
    >
    > I moved my board around the PCI slots to switch up the IRQ that the BIOS
    > gives it, same result.
    >
    > Whenever I forced ports (e.g. (1,3f8,4) (2,1040,10)) the driver
    > misrecognized the UARTS as FIFOless 16450 or 16350.
    >
    > Has anyone had one of these boards working with this driver?
    >
    > A side note that I don't think has anything to do with why the PCI port
    > doesn't work and the regular port does: serial transmission on this
    > computer has always been unreliable under OS/2. Move the mouse or
    > switch windows and you get errors all over the place. It's sort of like
    > a CPU time issue except this computer is much much faster than my old
    > ThinkPad P100 760ELD which is almost bombproof at 115.2kbps running the
    > exact same OS. There is something else about this system that
    > interferes with serial but I've never figured it out (and I've tried,
    > that's a story for another day).
    >
    > Thanks, Peter.
    >

    Since comm 1 & 2 are preassigned by OS/2 and unless these are disabled
    in BIOS, the first free comm port is comm 3. Run PCI.exe, a DOS program
    that works in a DOS window. Redirect the output to a file like this
    c:>pci > e.txt. Then use an editor to view the file. It will list the
    address of the port(s) and the IRQ it is using. Plug these values into
    the com.sys line in config.sys like the cmd references shows. Note it
    is possible that more than one port will be listed. Try them in order
    to find the one that is 'live'. I believe Stan Goodman has such a card
    and got it to working. He may have used SIO.
    --
    Bill
    Thanks a Million!

  3. Re: PCI serial adapters

    Peter .. no .. not with COM.SYS, but

    Peter Stokes wrote:

    > Has anyone successfully installed a ***PCI*** Serial adapter with
    > COM.SYS? I have a SIIG CyberSerial PCI single port card that is not
    > quite working for me.
    >
    >


    Yes, with SIO and in this case, I've not tried it with SIO2K in that the
    unit is needed for another 'strange' purpose with SIO and not SIO2K.
    Turns out that HyperAccess Pro doesn't work well for remote desktop
    viewing of HHost sites with SIO2K, although the HHost seems to work fine
    under it. Anyway ..


    The Intel 915GAV motherboards only come with one serial port. I looked
    carefully at the claims for compatibility in PCI serial cards. For my
    research I chose the VScom PCI Dual Serial Card P/N PCI-200L. On th
    ebox it claims compatibility with XP,2000,ME,98.NT4,0,DOS & Linux.


    I'm also a fan of PCI.EXE as Will noted to you in his post. In my case,
    the card shows up with more than two 'ports' active, even though only
    two actual serial hardware connections are on this card. BTW, VScom has
    four port cards and so on as well.


    As 'usual' in PCI operations with OS/2 and comm port issues here, COM1
    is active with the standard OS/2 only since the Intel 915GAV board has
    only one comm port. You can re-direct that port in the Intel BIOS to
    other than the normal port and IRQ, however, to avoid more possible
    mess, I've not done that. In this case, for KVM switch compatibility
    purposes in this relay rack box unit, I'm using that CON1 for mouse
    purposes.


    Will is correct, as far as I have found, that you'll have to experiment
    with PCI.EXE's report on which of the listed ports will work under
    whatever driver you use. In my case, becasue I need VMODEM and TelNet
    and soforth, I can't use COM.SYS. That though many of the system
    conflict and mangling issues you report with the mouse and so on Warp4
    and FP15 have been addressed here, by IBM, with the march toward FP16
    and FP17, coordinated fix work between DOSCALL1.DLL, the HPFS file
    system and what appears to have been write cache issues where heavy
    DOS-VDM and multiple comm program serial port use is involved ... and
    simultaneous TCP/IP traffic as well.


    WIth PCI, it's always, before, a 'problem' here, it seems, to make sure
    that the actual PCI slot and IRQ in use for whatever, including the comm
    port stuff, isn't being shared with other IRQ's. However, as I think
    I've learned, sharing IRQ's with PCI slot operations, is really a
    function of whether or not the applicble drivers are written to share
    them.


    I shuffle my PCI slot cards, in this case Adaptec SCSI controller, the
    VScom card, so that the principal IRQ reported by PCI.EXE doesn't
    conflict with the SCSI controller, nor COM1. However various USB
    controller IRQ issues are still reporting sharing here. They doo not
    report sharing the desired COM2 standard IRQ3 however. Then my SIO line
    simply lists the upper port in the loader section of the line for COM2:


    (COM2,B400,3)


    It's been working fine for modem connection with HyperAccess Pro on that
    comm port to HHost remote locations ever since.


    But in this case, and it *IS* signficant, the box described is on MCP2,
    XRC-05, the latest HPFS file system public release special fix from IBM,
    and the Device Driver fixpack 3 from IBM. The HHost site is FP17 with
    the entire later TCP/IP and all this stuff, which has been absolutely
    necessary in my case to stop exactly the kind of unstable operations
    with, in some cases, all four serial ports in use, TCP/IP at the same
    time. That especial if you are using a serial port for the mouse as well.


    I cannot, yet, however, vouch for whether this PCI card enablement of
    comm ports, works with all the serial port hardware controller line and
    line state issues for real hardware control via serial ports. Which I
    also do via assembler operations at some sites. That's for later
    research as I don't have time to fool with it now..


    Hope this helps.

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  4. Re: PCI serial adapters

    > ... I shuffle my PCI slot cards, in this case Adaptec SCSI
    controller, the
    > VScom card, so that the principal IRQ reported by PCI.EXE doesn't
    > conflict with the SCSI controller, nor COM1. However various USB
    > controller IRQ issues are still reporting sharing here. They doo not
    > report sharing the desired COM2 standard IRQ3 however. Then my SIO line
    > simply lists the upper port in the loader section of the line for COM2:
    >
    >
    > (COM2,B400,3)
    >
    >
    > It's been working fine for modem connection with HyperAccess Pro on that
    > comm port to HHost remote locations ever since...



    I have used a couple of PCI scanners to snoop at the cards, and what I
    have found agrees well with what the COM.SYS driver says it finds. In
    this case, with everything plugged in where I want it, the real port is
    at I/O 1040 (maybe 1041, must try this) and IRQ 10. (The other three
    fake ports also show up at a shared IRQ 10.) Even though the symptoms
    look like an IRQ conflict, there shouldn't be one, what with trying it
    both at IRQ 5 and 10. All the hardware in the system's accounted for
    IRQ-wise. I haven't yet tried paring hardware from the system to see if
    I can find a conflict that way.

    I too have only one onboard serial port so there is no conflict in
    making the new one COM2. You seem to indicate that on yours, you just
    declared the port to be IRQ 3 regardless of what the BIOS picked, just
    because it was available (and it is also available on my system). I
    don't know if I can force this card somehow to be set by the BIOS PnP to
    IRQ 3 on this computer.

    Maybe I should try SIO v1.6 instead of SIO2k, see if there's less backdraft.

    So there are a few more things to try. Really I blame Dell for cheating
    me out of the time-honored second COM port.

    Thanks, Peter.


  5. Re: PCI serial adapters

    Sir:

    Peter Stokes wrote:


    > I too have only one onboard serial port so there is no conflict in
    > making the new one COM2. You seem to indicate that on yours, you just
    > declared the port to be IRQ 3 regardless of what the BIOS picked, just
    > because it was available (and it is also available on my system). I
    > don't know if I can force this card somehow to be set by the BIOS PnP to
    > IRQ 3 on this computer.

    You can use SPCIIRQ to change the irq used by the PCI bus to anything
    (any four) that are free. Look on Hobbes.

    > Maybe I should try SIO v1.6 instead of SIO2k, see if there's less
    > backdraft.

    SIO is recommended as Stan reported that SIO2K failed for him.

    > So there are a few more things to try. Really I blame Dell for cheating
    > me out of the time-honored second COM port.
    >

    Is there a IR port on the machine? That usually uses COMM 2.

    --
    Bill
    Thanks a Million!

  6. Re: PCI serial adapters

    William L. Hartzell wrote:

    > You can use SPCIIRQ to change the irq used by the PCI bus to anything
    > (any four) that are free. Look on Hobbes.


    That would change the IRQ for all serial ports on the adapter,
    since they are alle on one singe function device.
    Special exception for having more than one IRQ per function
    are IDE controllers in legacy mode, but in that cases spciirq
    will not apply.
    --
    Veit Kannegieser

  7. Re: PCI serial adapters

    Peter Stokes wrote:

    > I have used a couple of PCI scanners to snoop at the cards, and what I
    > have found agrees well with what the COM.SYS driver says it finds. In
    > this case, with everything plugged in where I want it, the real port is
    > at I/O 1040 (maybe 1041, must try this


    1041=1040+1 where the 1 indicates that it is an I/O address at 1040.

    >) and IRQ 10. (The other three
    > fake ports also show up at a shared IRQ 10.


    If you do not like them you have to add an correct entry
    into \OS2\BOOT\pcidev.tbl for the card, instead of the /f switch.

    --
    Veit Kannegieser

  8. Re: PCI serial adapters

    Sir:

    Veit Kannegieser wrote:
    > William L. Hartzell wrote:
    >
    >
    >>You can use SPCIIRQ to change the irq used by the PCI bus to anything
    >>(any four) that are free. Look on Hobbes.

    >
    >
    > That would change the IRQ for all serial ports on the adapter,
    > since they are alle on one singe function device.
    > Special exception for having more than one IRQ per function
    > are IDE controllers in legacy mode, but in that cases spciirq
    > will not apply.

    Indubitably, it would change the irq of the card. He wants to use irq
    3, since it is free. The SIIG card has only one port on it, so it does
    not matter that changing that card's irq would affect other devices upon
    it, as there are none other than the phantom serial ports, the ones not
    connected to anything. He will find that changing the irq assigned to
    that card also has effects upon other PCI devices' irq assignment. Then
    there is the problem that USB cards/chips are wired to multiple irq at
    once, in many case to all four irq. So he will have to consider what it
    is that he wishes when he is faced with one or more device drivers that
    are miswritten to not share irq as are some SCSI adapters and some NIC
    cards.

    Anyone know the progress of the ACPI.PSD project and the ability to
    write device drivers that use software interrupts?
    --
    Bill
    Thanks a Million!

+ Reply to Thread