Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:11314 comp.os.386bsd.bugs:2300
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!babbage.ece.uc.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mozo.cc.purdue.edu!staff.cc.purdue.edu!bj
From: bj@staff.cc.purdue.edu (Ben Jackson)
Subject: Re: Situation update on 1.1.5R [Was Re: FreeBSD 1.15R (Re: Suggestion for addition to FAQs)]
Sender: news@mozo.cc.purdue.edu (USENET News)
Message-ID: <CsCB9q.nt6@mozo.cc.purdue.edu>
Cc: Jordan Hubbard <jkh@whisker.hubbard.ie>
Date: Sun, 3 Jul 1994 01:10:37 GMT
References: <16FE595EDS85.98022249@wsuvm1.csc.wsu.edu> <JKH.94Jul2113656@whisker.hubbard.ie> <CsC2x4.tqn@mozo.cc.purdue.edu> <JKH.94Jul3010108@whisker.hubbard.ie>
Organization: Purdue University
Lines: 71
In article <JKH.94Jul3010108@whisker.hubbard.ie>,
Jordan Hubbard <jkh@whisker.hubbard.ie> wrote:
>In article <CsC2x4.tqn@mozo.cc.purdue.edu> bj@staff.cc.purdue.edu (Ben Jackson) writes:
>
> But it looks like I'm backing out of 1.1.5 anyway. My machine never
> panicked under 1.1R, and it panics every time it touches swap space now
> (`page fault in supervisor mode'). And for some reason getty thinks my
> console is `ansi' (/etc/ttys still says cons25). The `stty -f
> /dev/ttyXX clocal' workaround no longer works, either. Sigh.
>
>All this is very strange, as many folks have been running what is
>effectively 1.1.5 for some time since it was simply a packaging of
>FreeBSD-current.
I'm surprised too! I'm running a fairly standard configuration (486/66,
Aha1542Cf, 2 SCSI drives) with the exception that I don't have any IDE
drives. I may not even have drivers for my 2 IDE controllers configured.
I am using the same configuration file I was under 1.1R.
>I'm not saying it's all in your head, but it would help
>if you could provide a bit more detail
I wish there were more detail to give. The only pattern I can find to
the panic problem is that it never happens if no swap space is
allocated (swapinfo) and running a few programs which use a lot of
memory will eventually lead to a panic. It doesn't always succeed when
it tries to sync the disks, so I get cores less than 25% of the time,
and kgdb doesn't tell me much.
Sometimes I panic on boot (especially if savecore runs). The `curproc'
has been cron, inetd and xntpd. Usually X is running by the time I
panic (since I don't run many things that consume great gobs of memory
from the console, but under X the server, xterm, xli etc eventually
cause something to be swapped out). It's possible that it's happening
when sbrk() is called with a negative size (libgnumalloc).
The other two problems: When I log on to the console (SYSCONS), my
term type is sent to ansi, which causes my prompt to be invisible. This
seems to be a result of a change in tset:
< /*
< * The termcap file generally has a two-character name first in each
< * entry followed by more descriptive names. If we ended up with the
< * first one, we switch to the second one for setting or reporting
< * information.
< */
< p = strpbrk(tcapbuf, "|:");
< if (p != NULL && *p != ':' && !strncmp(ttype, tcapbuf, p - tcapbuf)) {
< t = ++p;
The second "name" for cons25 is `ansi'. So TERM gets set to ansi and
my shell (zsh) looks it up and finds the `sx' termcap entry, which also
has `ansi' as the second name but comes before cons25 in /etc/termcap.
It's possible that the real bug here is that cons25 should have a 2-char
name before its `cons25' name, so tset would use `cons25'.
And finally, the `stty -f /dev/ttyXX clocal' workaround that you're
supposed to use if you have trouble with cu/kermit/etc hanging on tty
open doesn't work anymore. Under 1.1.5, the open still hangs.
>(and try not to be so
>confrontational, this IS free software after all and we're simply
>doing the best we can - we can't do better if people don't give
>us the information we need to fix things [as you did above with the
>EXTRACT problem, which I will now fix!]).
Sorry to snap there -- I was kind of annoyed that the response to "I
have no /usr/src/bin" was "Yes you do." Usually I'm a very reasonable
bug reporter. :-)
--Ben