tas@mcnc.UUCP (Tim Seaver) (09/07/86)
4.3 BSD has taken a step in the right dirction by using a global cbase array rather than having each tty device driver use its own static cbase array, but in doing so they seem to have broken the UBA reset recovery code for all tty drivers. The first DMA tty driver opened on a unibus now sets the global cbase value for that UBA, saving UBA map registers that were previously allocated to the second and subsequent tty device types on the unibus. Everything works fine until a UBA reset occurs (a daily event here at mcnc). Under 4.3, only the tty driver which initially allocated the UBA map will re-allocate it during a reset, meaning other tty device types on the same unibus which happen to come before that type in the cdevsw array will try to restart with no UBA map allocated. Also, every device of the original cbase "owner" type will re-allocate the UBA map, so if you have more that one of a given tty device type on a unibus, the second and subsequent device resets will over-write the cbase value for the UBA, wasting map registers and possibly screwing up previous tty device operations. We're short on UBA map registers, so the idea of a global cbase array is welcome, but given that, I don't see an easy way to handle UBA resets except by building knowledge of the cbase array into the generic UBA code - by having the top-level ubareset routine clear the cbase value so that the first active tty driver reset can re-allocate the map, and no others. Anyone have a better idea, or a better analysis of the situation? Waiting with dead tty ports, Tim Seaver Microelectronics Center of North Carolina mcnc!tas tas@mcnc.org