| Technote PT 18 | August 1990 |
Because the IOP does not return the bits of a character which is received with a parity error, the A/UX driver always returns NUL to an application. Applications which use PARMRK mode to recover a character with a parity error always think the character was a NUL .
Break Always Returns a NUL to an Application
Because the IOP always returns a NUL character when a break occurs, the A/UX driver passes it along to an application. There is no way for the driver to determine that the NUL is superfluous. Other break processing is unaffected. Programs which use IGNBRK mode receive the unexpected NUL in the data stream.
Multiple Errors in a "Chunk" of Characters Are Not Reported
The IOP only reports parity and framing errors on the first such occurrence in its internal buffer. The A/UX driver always reads characters in "chunks" from the IOP; therefore, only the first error is reported and subsequent errors go unnoticed. For example, assume an application sets PARMRK mode, expects to read a 10-byte packet (call it "ABCDEFGHIJ"), and four parity errors occur during transmission of the packet. (The received data is "ABxDExxHxJ," where the x characters are parity errors). The IOP returns six valid data characters, marking only the first bad character ("ABxDEHJ"). The subsequent errors go unreported, simply causing missing characters. The A/UX driver then marks the bad character (marking it as NUL as previously described), and returns "ABmmxDEHJ" (where mm are the 0xff 0x00 marker bytes) to the application.
This situation causes two problems:
* Since only nine bytes, and not 10, are returned to the application, it is possible for the application's read to block permanently. This would occur if the application simply issued a 10-byte read request.
* The application has no way of knowing that several characters were dropped.
Since the timing of the A/UX driver's "chunk reads" and the arrival of data can vary, there is no way to predict or prevent the occurrence of this problem.
The Current "DMA Hang" IOP Code Patch is Incomplete
The existing IOP code has been patched, both under the Macintosh OS and A/UX, to code around a bug in its DMA logic. Should any errant characters be received during servicing of a DMA operation, the IOP silently discards them, never reporting any error. This can cause unreported dropping of characters. Since this situation is timing-dependent, there is no way to predict or prevent the occurrence of this problem.
IIfx Serial Switch cdev
The IIfx Serial Switch cdev does not, itself, work under A/UX. If users need
to enable "Compatibility" mode, they should do so first under the Macintosh OS.
A/UX, upon booting, honors the switch setting in parameter RAM. Refer to
M.HW.MacIIfx for more details on the IIfx Serial Switch cdev.
Further Reference: