khj@uncecs.edu (Kenneth H. Jacker) (10/26/90)
We are having problems downloading a 630MTG application from a 3B2/500. Everything worked fine on earlier versions of the application. But after adding more code, re-compiling, etc. the next download just "hung." I'll try and describe the symptoms a bit better ... After issuing the "dmdld" command under "layers", the 630 clears the window preparing itself for the download. About half the time we've tried it, the inverse "filling" during the download starts. But after a short while: HANG! No error messages are displayed. The download stops no matter how few (or many) windows are on the screen. We've had some success when downloading without "layers", but we really need "layers" for multiple windows and especially debugging. The 630 executable file (a.out) is about 119K. The application shows about 27K text, 2K data and 23K bss for a total of about 52K. I hope I've said enough to adequately describe the problem. Any help and/or suggestions of what to try are most appreciated! -- Kenneth H. Jacker Domain: khj@ms.appstate.edu Dept of Math Sciences khj@ecsvax.uncecs.edu Appalachian State Univ Boone, NC 28608 BITNET: khj@appstate
woods@eci386.uucp (Greg A. Woods) (10/27/90)
[ I've appended comp.terminals.tty5620 to the newsgroups line, which BTW, was "inadvertently" set to poster (though I didn't remove comp.graphics. The download-hang problem, in my experience, is common to other "blit" (or DMD) terminals. ] In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes: > We are having problems downloading a 630MTG application from a 3B2/500. > > Everything worked fine on earlier versions of the application. But > after adding more code, re-compiling, etc. the next download just > "hung." I'll try and describe the symptoms a bit better ... Your descriptions follow exactly with my experience with a tty5620 DMD terminal. The downloads, particularly of large programmes, periodically hang. On the 5620 the hung layer must be deleted, thereby killing the 32ld on the host. My most recent experience was with xproof, with which I would have to try three or four times consecutively before it succeeded. This seems to be a problem in either the download protocol, or in the xt(7) driver itself. This is the first time I've heard of this problem occuring on the 630's. On my 3b2/400, any burst of (integral) disk activity sharply increased the chances of failure. Even the disk activity associated with loading the 32ld programme, and the binary to be downloaded, was often enough to trigger a hang. Rumors have it that a re-implementation of 32ld done locally for 386 based machines doesn't experience these lock-ups quite so often. A significant number of people in the Toronto area will be running 5620's on a variety of systems in the near future. I'm sure we will be investigating this problem further. One task I've set for myself is to port dmdld to support the 5620 (i.e. to replace 32ld), and be portable across several host architectures. Since dmdld is in the 630-pkg stuff from the Toolchest, it will allow non-3b2 users (such as myself when I'm at the office :-) to benefit from the 5620 (and the [67]30-MTG's) (given they/I port the host-side software, and have a 5620/630 development package handy). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
wsinpdb@wsinfo13.info.win.tue.nl (Paul de Bra) (10/29/90)
In article <1990Oct26.201542.775@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes: >> We are having problems downloading a 630MTG application from a 3B2/500. >> >> Everything worked fine on earlier versions of the application. But >> after adding more code, re-compiling, etc. the next download just >> "hung." I'll try and describe the symptoms a bit better ... >... >This seems to be a problem in either the download protocol, or in the >xt(7) driver itself. This is the first time I've heard of this >problem occuring on the 630's. I know this won't help, but I spent a fair amount of my time drinking coffee while downloading large programs into a 630 during the past 2 years. I have used this 630 either connected to a Vax through a datakit node or a modem, and also connected to a 386 at 19200 baud through a straight cable. The Vax was running the Ninth (later Tenth) edition Unix, and the 386 was running AT&T sVr3.2u. All downloads were while in layers or 630mux. I have never ever had a hang, not even when downloading over a noisy phone line. This suggests that the problem may have been in the 3b2. (I have rarely used the 630 with a 3b2) Paul. (debra@research.att.com)
woody@praxis.co.uk (Paul Woodman) (10/30/90)
>>In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes: > We are having problems downloading a 630MTG application from a 3B2/500. >> >> Everything worked fine on earlier versions of the application. But >> after adding more code, re-compiling, etc. the next download just >> "hung." I'll try and describe the symptoms a bit better ... >... >This seems to be a problem in either the download protocol, or in the >xt(7) driver itself. This is the first time I've heard of this >problem occuring on the 630's. > I dont know if this will solve your problem but I used to experience the very same symptoms when I had to work with these horrid terminals back at AT&T. It happended to me with both 5620 and 630 terminals and the secret was to set encoding to "on" in the setup menu. Failing that, use a sledgehammer or drop it out of the window, you will feel much better for it. Paul Woodman Praxis plc, Software Engineers, \ / | 20 Manvers Street, Bath, BA1 1PX, UK. \ / ___ ___ _| Tel +44 225 444700 xt228 \ /\ / / / / / / | \ / Fax +44 225 465205, Telex 445848 \/ \/ /__/ /__/ /__| \/ woody@praxis.co.uk _________________________/