1-How can I determine that SIO2K has correctly determined my uart type and the IRQ it is using. In the sio2k distribution zip, there is a program named logger.exe. This program can hook into sio2k.sys and provide an enormous amount of information. However, some information is only available once, when the port (uart) is first touched by an application. For information like uart type, fifo depth, and crystal multiplier, you must have logger running before the port is touched the first time. Here is how. Reboot your computer, go to an OS/2 session and execute (for info on com1) x:\path\LOGGER COM1. Then go to another OS/2 session and execute MODE COM1. You can then examine the information produced by logger. Note that LOGGER.EXE has an optional parameter of a disk file name. If a disk file name is given, the information produced by logger is written to that file, as well as being displayed. 2-DTR/DSR flow control does not work, I am using a 16650. The 16650 and similar devices do flow control on chip (in hardware) Unfortunately DTR/DSR flow control is not supported. One can use a special cable to achieve the desired flow control. Simply move the wires for the DTR and DSR signals to the RTS and CTS signals at the PC end of the cable. Then specify RTS/CTS flow control. 3-Why is the IRQ not show in the Hardware (Resource) Manager screen(s). During boot time, the SIO2K driver set does not always know the IRQ that the serial port is going to use. This is especially true with legacy ISA serial ports. However, the first time the port is accessed by a program, the IRQ is determined and is reported to the Hardware Manager. So, if you are not seeing the IRQ for COM1 when rmview is executed, then do a MODE COM1, and then execute rmview. The IRQ should then show up on the rmview report(s). 4-Why is a message about failing an integrity check being displayed. Assuming the drivers have not been otherwise altered, you are probably running a disk compression utility. In order to use the SIO2K drivers, they must NOT be altered in any way, which includes compression. 5-Why is the FIFO depth shown as 1 for a Hayes ESP when the port is used in compatibility (16550) mode via uart.sys. The 16550 emulation by the Hayes ESP seems to have a few problems. The compatibility mode should be avoided if possible, when ESP.SYS is loaded. One of these problems causes the probed FIFO depth to show up incorrectly. However, once uart.sys has detected a FIFOed device, the FIFO size will only be increased, not decreased. Even though the probed depth is shown as 1, the 16 byte FIFOs (for a 16550) are still used. 6-I am having problems using a Hayes ESP card in compatibility mode. Once ANY ESP port has been used in enhanced mode (touched by ESP.SYS), power much be cycled before ANY ESP port will again work in compatibility mode again. If your are not using ESP.SYS, try forcing a 16450 uart for the port in the uart.sys section of sio2k.cfg. If this still fails, you should use enhanced mode only, via ESP.SYS. 7-One of my applications complains that the buffers are not large enough. Why some people, including some very good programmers, insist on believing in the need for large buffers is beyond this writers comprehension. The buffers in the SIO2K drivers are sufficiently large enough (and then some) for any application to work well (at top speed). 8-I am getting an "In Use" or "Not Ready" error when I try to use one of my serial ports, even though that port is not being used by another program. The serial port may not be in use, but the IRQ the port uses probably is in use. See FAQ number 1 for a description of how to use LOGGER.EXE. Information produced by logger should tell you exactly why you are getting the error. 9-Why do the drivers skip assigning hardware to COM2 (or COM3/COM4), then assigns other hardware to ports after that? You probably have PCMCIA.SYS installed. If the SIO drivers detect that PCMCIA.SYS is installed, then a COMn (COM2 through COM4) opening must be available for a possible PCMCIA modem being inserted. 10-Why am I getting errors when I use higher bit rates? There are several possible reasons: 1 - The most common reason is a flow control problem. You should always try to use RTS/CTS flow control. Xon/Xoff flow control may react too slowly at higher bit rates. Refer to your application manual (or their support) to determine how to set flow control. 2 - The second most common reason is possibly your serial cable. If you are using a serial cable at high speeds, it must be a good quality shielded cable. Also, the cable should be as short as possible. The longer the cable, the less the bit rate it will be able to pass. 3 - Another common reason is that your UARTs supporting hardware, like the RS232 drivers and receivers, cannot support the higher bit rates. That is to say, simply because your UART can generate 921600 bps, other associated hardware in your computer may not be able to work correctly at these rates. 4 - Last, it could be that your computer is simply not fast enough to handle the higher bit rates. 11-Why does my PCMCIA modem not work? Try removing, and reinserting the modem card after your system has booted. The PCMCIA drivers seem to only report the existence of a PC card modem to the serial drivers when it (the modem) is inserted. If the modem is already inserted when the system is booted, the modems existence is not reported to the serial drivers. This may work differently on some systems. 12-Does Sio2k support WinModems? Currently (10-18-00) no. I will look into WinModem support as soon as time permits. Watch the history.txt file for information. 13- Why does my serial ports behave strangely (or not at all) when I switch from sio2k back to com.sys? Sio2k enables advanced features of serial devices. Often com.sys is not aware of the advanced features. On some (poorly designed) system the advanced features are not reset to their default state when you boot by ALT-CTRL-DEL, or by shutdown, unless you also power off. If you have this problem, you should alter your config.sys to use com.sys, shutdown or ALT-CTRL-DEL, then power your system off. The power off, then power on will reset the uarts to a state the com.sys understands. 14- How do I prevent the kernel warning message at boot time? By far, the best solution is for IBM to correct the problem and adhere to their own driver specifications. In the opinion of the author, this anomaly makes the system unstable at boot time. I also believe the bug could be the reason that many other WARP drivers will not work on WSeB. If a corrected kernel is released and installed on your system, the message will go away automatically. Until and/or if a corrected kernel is released, you can eliminate the warning message by adding "WSeB", without the quote marks, to your sio2k.sys command line. 15 - Does the sio2k drivers work on SMP systems? Yes. At least this is so for many SMP systems reported by users and including the authors SMP system. However, the OS/2 SMP systems tested by the author DO NOT follow IBM's published specification for device driver initialization. Specifically, on SMP systems device drivers are initialized on ring 0, while the driver specification (and all other OS/2 implementations) state the driver will be initialized on ring 3. This incorrect initialization sequence no longer causes a problem for the sio2k drivers. However, the author is concerned there may be other undocumented/uncorrected errors in the SMP implementations by IBM et al. 16 - Does the sio2k drivers work on WSeB? I tried them but have problems. Yes, the sio2k drivers have been tested and work well on WSeB with and without SMP. However, there seems to be a problem in the WSeB kernel, or device drivers. Something on WSeB systems interferes with IRQ3, note that com2 usually uses IRQ3. Due to this interference, the sio2k drivers (and com.sys too) will not work well on some WSeB systems when the comm port is using IRQ3. The only solution is to switch the IRQ, if possible, or to switch to a comm port this is not using IRQ3. 17 - Why is the I/O addresses shown in the SIO2K.SYS part of SIO2K.LOG not the same as I specified in the configuration file. If you are speaking of the address following "AutoVirtIo=" then you need not be concerned. At the time that SIO2K.SYS makes the log entries, VSIO2K.SYS has not yet processed the config file. The addresses following "AutoVirtIo=" are the addresses that will be assigned in the Dos/Windows sessions if NO config file specifies otherwise. That is, the configuration file will override the addresses shown after "AutoVirtIo=". 18 - Why does the kernel debugger not work correctly after uart.sys has initialized. Try adding "NoSuperIo", without the quote marks, to the uart.sys command line. This will prevent uart.sys from enabling the enhanced features of SuperIo uarts which may confuse the kernel debugger. 19 - Why is the virtual IRQ for COMn in DOS/Windows sessions wrong. This is a complicated subject, and the virtual IRQ may not be wrong. Lets use com3 as an example. First you can attempt to use the vsio2k.sys command line option "vItqList" to specify the virtual irq that com3 is the use. For example vIrqList(3,5,3=7). This says that vsio2k.sys can use virtual IRQs 3, 5, and 7. The "3=7" fragment says that com3 is to use virtual IRQ 7. However, there is still a potential problem. Virtual IRQ 7 may be in use by another driver. If virtual IRQ 7 is not available, then vsio2k,sys will attempt to use the default IRQ for COM3, which is IRQ 4. This will not work because IRQ 4 is not in the vIrqList of IRQs. Finally, vsio2k.sys will select either IRQ 3 or 5, the other available IRQs in the pool. If the virtual IRQ is assigned other than what you think it should be, it will still work. All you need to do is configure your DOS/Windows app to use the virtual that vsio2k.sys has assigned. The vsio2k.sys log file will show the port/irq combinations. For a given computer system, the virtual IRQs should always be the same. 20 - Where do I find the vsio2k.sys log file. First, you must have "LogFile=x:\path\vsio2k.log", without the quote marks, in your vsio2k.sys command line. Then you must open a Dos or Windows session, then close the session. You can then examine the log file specified in the vsio2k.sys command line. 21 - Why does my modem fail to initialize correctly the first time I use it after booting. The first time a uart (COMn Port) is accessed uart.sys probes the uart for fifo size and maximum bit rates. This test is performed by placing the uart into loop back mode and transmitting a few characters. Even though the uart is on loop back mode, the transmitted characters on some uarts "leak" out, and are actually transmitted to the modem. The modem may see these characters as the beginning of a AT sequence that never completes. Then when your application attempts to initialize the modem, the initialization fails because the modem thinks it is already in the middle of an initialization sequence. The solution should be a simple modification to your modem init string. I believe the addition if a simple CR (Carriage Return), usually shown as ^M in init strings should correct the problem. The ^M should be added at the beginning of the modem initialization string. If this fails, then try expanding your modem init string such that the entire string is sent twice should correct the problem. 22 - Why does FaxWorks (aka PMFAX) not work with sio2k? If you are seeing an error message mentioning FMD1, FMD2 etc, then FaxWorks is NOT using the sio2k drivers. An independent driver named FMD.SYS is supplied with FaxWorks, and by default, FaxWorks will use their driver. The last time I used FaxWorks, it could be configured to use the installed serial driver. Configure FaxWorks to use the installed serial driver and it should work with sio2k. 23 - How do I run DOS doors with my BBS? The following comes from Bob Juge, http://www.juge.com: Here are my lines, see if they help (the vx00.sys line is the one that provides FOSSIL support in DOS sessions, the "Os2Shares" at the end of the sio2k.sys line is needed to allow DOS apps to share the comm port): device=c:\sio2k\uart.sys logfile=c:\sio2k\sio2k.log device=c:\sio2k\vsio2k.sys logfile=c:\sio2k\vsio2k.log vIrqList(3,4) device=c:\sio2k\vmodem.sys logfile=c:\sio2k\sio2k.log nPorts=4 device=c:\sio2k\vx00.sys logfile=c:\sio2k\sio2k.log device=c:\sio2k\sio2k.sys logfile=c:\sio2k\sio2k.log Os2Shares 24 - Why does the install program ----------------- The goal of the install program (script) is to install on as many systems as possible without asking the user any questions. The install program assumes your OS/2 installation is structured much as it was when the OS/2 installation was completed. Those that have problems with the install program have probably modified the standard location of OS/2 components. Fortunately, if you have enough knowledge to do such modifications, you should also know how to manually install the drivers. Additionally, the install program is a REXX script and the source is in the sio2k distribution zip. This enables you to modify the script to your liking. 25 - Why does the throughput for the 16650, 16850 and 16950 seem less than that for a 16550? The 16650, 16850 and 16950 have on chip flow control. This relieves the cpu from the burden of flow control and means your serial ports use less processor time. However, the on chip flow control seems NOT to be very efficient. The on chip flow control seems to assert flow control at times that it is not necessary. I have discovered that the sio2k driver's software implementation of flow control seems much more efficient than the on chip flow control, close to 1000 characters per second at 115200bps. You can add 'Use16550', without the quote marks, to the uart.sys command line (in config.sys) to force the driver to NOT use the slower on chip flow control. Use of this option will slightly increase the overhead on the processor.