dwex@wuccrc (David Wexelblat) (02/26/88)
We recently upgraded our 3B2/400 computers to System V, Release 3.1. We
had previously been running (successfully) gnu 18.46. We recently obtained
18.49, so naturally I wanted to install it. After building the program,
it starts up OK, but does not run correctly (e.g. the first ^X-^F yields
a message about 'not listp, t', but second and subsequent executions work;
random reports of 'byte-compile stack overflow' when compile is not running).
The old 18.46 executable works fine, but a recompiled 18.46 from the same
sources does not work.
I am using the 'm-att3b.h' file and have tried both 's-usg5-2.h' and
's-usg5-2-2.h'. We are using the C programming utils, issue 4 compiler.
Any suggestions would be appreciated (is there an s-usg5-3.h anywhere?).
Also, when logged in remotely over StarLan, emacs does not work at all.
It starts up, but does not draw the initial screen or the modeline. It
writes '(mark set)' where the minibuffer should be. If any keys are pressed,
the terminal (a Unix-PC) starts beeping like mad. If I am lucky, it will
respond to ^X-^C and go away.
Any help anyone can give me with these problems would be greatly appreciated.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat Washington University in St. Louis (314) 889-4794
UUCP: dwex@wuccrc.UUCP or ..!{ihnp4,uunet}!wucs1!wuccrc!dwex
ARPANET: wucs1!wuccrc!dwex@uunet.uu.net
CSNET: wucs1!wuccrc!dwex%uunet.uu.net@csnet-relay or
wucs1!wuccrc!dwex.uucp%bbncv.ARPA@csnet-relay
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat Washington University in St. Louis (314) 889-4794
UUCP: dwex@wuccrc.UUCP or ..!{ihnp4,uunet}!wucs1!wuccrc!dwex
ARPANET: wucs1!wuccrc!dwex@uunet.uu.net
CSNET: wucs1!wuccrc!dwex%uunet.uu.net@csnet-relay or
wucs1!wuccrc!dwex.uucp%bbncv.ARPA@csnet-relaykarl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (02/26/88)
You should check to see that your system's MAXMEM is sufficiently large to handle Emacs, and also that the recompiled binary didn't cut short due to ulimit braindamage; these 2 things have weird effects on the building of Emacs, and either could be your trouble. We built 18.49 on 3B2/400s with V.3.0 and have had no trouble. (We told it to believe in 16Mb programs, and 128Mb file ulimit, just because I hate arbitrary limits.) Karl
les@chinet.UUCP (Leslie Mikesell) (02/29/88)
In article <789@wucs2.UUCP> dwex@wuccrc.UUCP (David Wexelblat) writes: >Also, when logged in remotely over StarLan, emacs does not work at all. >It starts up, but does not draw the initial screen or the modeline. It >writes '(mark set)' where the minibuffer should be. If any keys are pressed, >the terminal (a Unix-PC) starts beeping like mad. If I am lucky, it will >respond to ^X-^C and go away. Starlan is a "streams" device which returns -1 to a read() when O_NDELAY is set and no data is present (even though a tty emulation module is pushed??). GNU expects (perhaps rightly) that a read() with no data will return 0 and always uses the value as the count of characters. Adding a check for negative values from read() in keyboard.c will fix it. ...ihnp4!chinet!les
dwex@wuccrc (David Wexelblat) (02/29/88)
In article <7284@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >You should check to see that your system's MAXMEM is sufficiently >large to handle Emacs, and also that the recompiled binary didn't cut >short due to ulimit braindamage; these 2 things have weird effects on >the building of Emacs, and either could be your trouble. We built >18.49 on 3B2/400s with V.3.0 and have had no trouble. (We told it to >believe in 16Mb programs, and 128Mb file ulimit, just because I hate >arbitrary limits.) > >Karl I should have stated this beforehand. Emacs dumps OK in both cases (18.46 and 18.49). I didn't like the ulimit hack, so I modified ymakefile to use C_OPTIMIZE_SWITCH (which is the empty string for the 3B2) instead of C_DEBUG_SWITCH. This results in a dumped file <1Mb. There is NO MAXMEM parameter in /etc/master.d/kernel in V.3.1. If someone knows what has become of this parameter, I would appreciate being informed. ULIMIT is now a configurable parameter in 3.1 (I just noticed), so the ulimit hack isn't needed. Also, temacs displays the same problems as the dumped emacs, so the problem is not caused by unexec. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Wexelblat Washington University in St. Louis (314) 889-4794 UUCP: dwex@wuccrc.UUCP or ..!{ihnp4,uunet}!wucs1!wuccrc!dwex ARPANET: wucs1!wuccrc!dwex@uunet.uu.net CSNET: wucs1!wuccrc!dwex%uunet.uu.net@csnet-relay or wucs1!wuccrc!dwex.uucp%bbncv.ARPA@csnet-relay
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (03/01/88)
dwex@wuccrc writes:
There is NO
MAXMEM parameter in /etc/master.d/kernel in V.3.1. If someone knows what
has become of this parameter, I would appreciate being informed.
Hm, I'd kind of forgotten, but it seems that the MAXMEM constant has
changed name in V.3 to MAXUMEM (User MEMory, there's also a MAXPMEM
which would seem to have some relation to paging reclamation). I just
dropped a note to bug-gnu-emacs to this effect. Grep your
/etc/master.d/kernel for MEM and you'll find it.
ULIMIT is now a configurable parameter in 3.1 (I just noticed), so the
ulimit hack isn't needed.
I also mentioned in my note to bug-gnu-emacs that the comments about
ulimit.hack need to mention that it's for V.3.0 and previous.
Also, temacs displays the same problems as the dumped emacs, so the problem
is not caused by unexec.
Now I'm left wondering what's wrong, since you seem to have eliminated
the problems I've seen. Unfortunately, I haven't got V.3.1, but
rather just V.3.0.
Karlstorm@ambush.UUCP (Kim F. Storm) (03/01/88)
In article <789@wucs2.UUCP> dwex@wuccrc (David Wexelblat) writes: >Also, when logged in remotely over StarLan, emacs does not work at all. >It starts up, but does not draw the initial screen or the modeline. It >writes '(mark set)' where the minibuffer should be. If any keys are pressed, >the terminal (a Unix-PC) starts beeping like mad. If I am lucky, it will >respond to ^X-^C and go away. We have exactly the same problem using emacs via cu on StarLan. I have not tracked the problem down, but it seems that reading from a 'starlan tty' behaves differently from a normal tty. The mark set command is bound to the NUL key, so obviously emacs is constantly reading NUL-characters from the starlan tty when no other input is available. If you are quick, you may be lucky to enter ^X ^C between two reads and get out. Could somebody please enlighten us concerning the differences between a normal tty and a starlan (pseudo) tty ? -- Kim F. Storm UUCP: storm@ambush.dk (or ..!mcvax!diku!ambush!storm) AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte, Denmark. tel: +45 2424 111 No news is good news, but nn is better!
denny@mcmi.UUCP (Dennis Page) (03/06/88)
In article <791@wucs2.UUCP> dwex@wuccrc (David Wexelblat) writes: >There is NO >MAXMEM parameter in /etc/master.d/kernel in V.3.1. If someone knows what >has become of this parameter, I would appreciate being informed. In article <7478@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >Hm, I'd kind of forgotten, but it seems that the MAXMEM constant has >changed name in V.3 to MAXUMEM (User MEMory, there's also a MAXPMEM >which would seem to have some relation to paging reclamation). While maxmem has disappeared from the /etc/master.d/kernel file, it still exists in the kernel's symbol table. From /etc/sysdef: 8192 maximum size of user's virtual address space in pages (MAXUMEM) 8192 for package compatibility equal to MAXUMEM (MAXMEM) MAXPMEM is used to limit the amount of physical memory that the kernel will use. Why they put this in, I don't know. Testing smaller memory preformence perhaps? I have run 18.49 under both 3.1 and 3.1.1 using m-att3b.h and s-usg5-2-2.h without problem (I cannot attest for 3.0 :-). -- Denny Page Martha, the Clones are loose again! Don't just stand there... get a net!