DigiWARE Release Notes 93000127M for Digi Asynchronous Driver version 2.1.0g. Digi Xi, Xe, Xr, Xem, C/X, COM/Xi Quantum Software Systems QNX version 4.22, 4.23 Software Package P/N 75000127M Diskette (3.5") P/N 40000754M Software Manual P/N 92000127D December 30, 1998 Note : This package includes two separate device drivers named Dq.ser16 (for 16 bit environments) and Dq.ser32 (for 32 bit environments). Please consult the manual for proper installation instructions. 1. Enhancements: v2.1.0g: December 30, '98 ------------------------- - Added fine-grained incoming BREAK timing reporting. Because the UARTs don't give any indication of a break end, the adapter only tells us when a BREAK starts -- no events are generated when it ends. So, on receiving a BREAK we set a "break_on" flag, then clear it on receipt of the next non-BREAK event, e.g: an incoming character. This is just a faked approximation of the real BREAK end time. However, one trick suggested by Gene Olson can allow us to monitor the BREAK time very closely: connnect pin 3 on the Digiboard side of the cable to some unused modem control line, say RI. Then, whenever an incoming BREAK starts or ends, a modem event will be perceived and propagated by the FEP, and we can use that to clear the break flag in the user accessible (via qnx_ioctl()) structure. v2.1.0c: December 14, '98 ------------------------- - Updated the on-board operating system (FEP and BIOS) download files. - Added support for the 2 port PCI XR 920 2. Bug fixes v2.1.0d-f: December 14-30, '98 ------------------------------ - Interim testing versions v2.1.0c: December 14, '98 ------------------------- - User-specified outgoing BREAK sequence timing control. In previous versions we implemented IOCTL_STARTBREAK as a 250ms BREAK and ignored IOCTL_STOPBREAK. With this version these ioctls are both implemented: STARTBREAK initiates an outgoing BREAK sequence; STOPBREAK ends the BREAK sequence by initiating a final 250ms BREAK. (250 ms is chosen because whatever value we select becomes the default for subsequent BREAK sequences.) - Incoming BREAK time reporting. This actually consisted of two parts: 1. Getting bitmap values to qnx_ioctl(). The QNX stock serial driver, Dev.ser, implements a status bitmap that is user-accessible via qnx_ioctl(). This is described in /usr/local/system/qioctl.h. Previously we neither set nor reset the BREAK bit in this bitmap. Now we set this on receipt of an incoming BREAK and reset it on receipt of the next non-BREAK event. Ideally we'd like to reset this bit on the termination of the BREAK sequence, but in practice we have no way to determine this other than by the receipt of another event. 2. Faking the incoming BREAK end time. The driver does not have direct access to the UARTs and so cannot determine precisely when an incoming BREAK sequence ends. It looks like the best we can do is to set the BREAK bit in the qnx_ioctl() bitmap when an incoming BREAK sequence starts, and clear it on receipt of the next non-BREAK event. v2.1.0b: internal, interim version ---------------------------------- v2.1.0a: April 1 '98 -------------------- - Fixed a problem in the initialization routines where memory allocations could fail, in some system configurations, due to the allocation of memory selectors. 3. Limitations: - The number of devices that can be mounted is severely restricted by the resources of the Dev process whose maximum setting of 128 only permits 96 or possibly 112 devices to be mounted. ========================================================================= DigiWARE Release Notes 93000127L for Digi Asynchronous Driver version 2.1.0. Digi Xi, Xe, Xr, Xem, C/X, COM/Xi Quantum Software Systems QNX version 4.22, 4.23 Software Package P/N 75000127L Diskette (3.5") P/N 40000754L Software Manual P/N 92000127D January 12, 1998 Note : This package includes two separate device drivers named Dq.ser16 (for 16 bit environments) and Dq.ser32 (for 32 bit environments). Please consult the manual for proper installation instructions. 1. Enhancements: Version 2.1.0, January 12, 1998 ------------------------------- - Added support for PC (ISA) and PCI Xr+ cards. Previously the PC/Xr was supported by treating it like a PC/Xem. Now the entire Xr/Xr+ series is supported with new on-board OS files (xrbios.bin and xrfep.bin) and so must be distinguished from PC/Xem's on the driver command line. To specify a PC Xr or Xr+ board, use "r" as the "cfg" command line parameter. E.g: Dq.ser32 320,d0000,r indicates either an PC/Xr or Xr-plus. PCI cards (including the PCI versions of the Xr and Xr+) are identified automatically and do not require "port", "mem" or "cfg" flags. Hence, for example: Dq.ser32 -v will find and identify all supported PCI cards, including PCI Xr and PCI Xr+ cards. - Added driver support for high baud rates (460800 and 921600) for the Xr+ cards. Using these baud rates with other cards will have unpredictable effect. - Updated the on-board OS files, including adding two new files: xrbios.bin and xrfep.bin which are now used for the entire PC and PCI Xr/Xr+ card family. 2. Bug fixes Version 2.0.1a, March 25, 1997 ------------------------------ - Fixed a problem with recognizing the microchannel bus on some machines - Fixed several problems associated with messy termination (possibly trapping the kernel) following HUP, KILL or TERM signals under some circumstances. Version 2.0.1b, April 3, 1997 ----------------------------- - Modified SIGNAL handling code to catch and IGNORE user level, EOF and HUP signals to prevent premature driver exits. - Corrected problem that caused the driver to fail to recognize MCA (MicroChannel) architectures with newer versions of QNX. - Corrected a COM/Xi-specific problem that caused data corruption on channel #8. Version 2.0.1c, July 28, 1997 ----------------------------- - Changed stty code to never return an error. Previously, for example, a bad baud rate would cause the stty handler to return an error which caused the driver to terminate. The POSIX standard instructs us to do the best we can and ignore the rest. Of course, we'd like to be able to inform the caller just what we did do, but QNX Tech Support reports that there is apparently no way to do this in QNX. So, let the user beware: Requesting a bad baud rate no longer causes the driver to crash (it now leaves the previous baud rate unchanged), but there is no way for the user to know that the request has failed. Subsequent information requests (e.g. calling stty at the shell, or cfgetispeed() from a C program) are not reliable sources of information: since user programs talk only to Dev, and Dev never asks the driver (Dq.ser) for its opinion, the returned values will simply be copies of what the user most recently asked for, not necessarily the baud rate actually set. Version 2.0.1c-i July 28 - September 2, 1997 -------------------------------------------- - Interim testing versions to track down the cause of occasional SIGSEGV errors Version 2.0.1j September 5, 1997 --------------------------------- - Fixed scheduling problem that caused SIGSEGV errors under certain circumstances (associated with high priority ioctl calls preempting card write operations at sensitive times). Version 2.0.1k September 15, 1997 ---------------------------------- - Add support for special baud rate of 0 which is a POSIX-sanctioned code for disabling the communications port, including dropping DTR on a modem-enabled line. Programs like ckermit() momentarily set the baud rate to 0 to reset lines. Version 2.0.2 October 20, 1997 ------------------------------- - Removed debug code from beta test versions - Changed version number to V2.0.2 Version 2.0.3a December 1997 ----------------------------- - Fixed a problem with memory segmenting that caused driver crashes during channel buffer pointer rollovers. - Previously, channel buffer memory allocations were fixed at 4K, but some cards have much bigger buffers. Now the driver makes memory requests based on the rx_size and tx_size sizes reported by the card. - Found and fixed a problem with supporting multiple cards simultaneously. In the v2.0.2 release, some cards would sometimes become effectively disabled. - During testing of v2.0.3, found a problem: When interrupting a qcp session on one card, and starting a qcp on a second card, the second never starts up properly. The same problem shows at least as far back as version 2.0.1b. This was a problem with card memory being left disabled after an interrupt. This has been fixed. - Found and fixed a problem with reenabling card memory contexts following high priority interrupts from cards using an ioport memory setting different from that used by the interrupted card. - Found and fixed a problem: The internal routine getFP() allocates system memory segment pointers -- a limited QNX system resource. These were not released in dev_exit(), so repeated stopping (e.g. via kill) and restarting of the driver eventually used up all the available segment pointers and caused the next invocation of the driver (or anything else that needs segment pointers) to crash. Previously, the only way to reset this was to reboot. Now, dev_exit() frees up these memory pointers. 3. Limitations: - The number of devices that can be mounted is severely restricted by the resources of the Dev process whose maximum setting of 128 only permits 96 or possibly 112 devices to be mounted.