peter stokes

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.

william l hartzell

Sir:

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!

mike luther

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

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

peter stokes

controller, the


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.

william l hartzell

Sir:

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


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

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

--
Bill
Thanks a Million!

veit kannegieser

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

veit kannegieser

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

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

william l hartzell

Sir:


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!