ghg@EE.PURDUE.EDU (George Goble) (11/22/85)
It all boils down to the 8-line asynchs crap out when they are hit with excessive framing errors.. We have had 16 experimental rom sets (in the 8las's) now for almost 2 months... which fixes that bug.. and 99.9% of our 8-line problems went away..!! The acid test is to take a 19.2K port and stuff it into a 9600 baud port, turn them both on and stuff chars at each side.. which makes zillions of forced framing errors.. The old firmware will crap out in 1/4 sec or so.. We have run the new stuff in the same conditions for around 1/2 hour with no problems. For further details see your Gould C.E. If he hasn't heard of this, have him ask Ernie McMullen or Walt Pasko at Central Support (305) 797-5831. This may not be an offical ECO yet.. --ghg
ron@BRL.ARPA (Ron Natalie) (11/23/85)
There seems to be some definite problem with the tt code on the Gould. Periodically, select will hang and never return although if you interrupt the selected process, you can get the port to come back to life. In addition, when the talk daemon writes on the terminal, no output appears on the user's screen until he types some character. I can't think of any correct operation of the TTY driver that can explain this. -Ron
moss@BRL.ARPA ("Gary S. Moss ", AMXBR-VLD-V) (11/25/85)
This reminds me of a problem I am having with the Raster Tech. driver supplied by Gould in binary form. At random times while doing a READW() command, the driver hangs indefinitely, but killing the process usually straightens things out. Does anyone have a fix for this and is Gould aware of this problem? Thanks, moss