From: sje@xylos.ma30.bull.com (Steven J. Edwards)
Subject: Re: Coherent 4.0.1; some bad things
Reply-To: sje@xylos.ma30.bull.com
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA
Date: 13 Aug 92 15:32:17
	<9208130820.AA01965@dalek.mwc.com>

In article <9208130820.AA01965@dalek.mwc.com> bob@dalek.mwc.com (Bob Hemedinger) writes:
#> In article <9208120959.AA01930@dalek.mwc.com> bob@dalek.mwc.com (Bob
#  Hemedinger)
#>  writes:
# Give this a try... when you are given the opportunity to press <space> to
# abort the boot, do so and type 'info <return>'. Then type in the kernel
# name to boot (autoboot). If the prepare_gift message disappears, then
# we know what the cause is. Let me know...

I've done a little bit of reverse engineering on /tboot; why is all
the stuff about the mini-monitor not documented?

Also, I've decoded a bit more about the /tboot -> /dev/boot_gift ->
/etc/brc.build -> /etc/boot_cmd conspiracy.  The current hypothesis is
that the 512 byte device is (apparently) not getting properly
initialized by prepare_gift in tboot; hence the warning about only 496
bytes being passed.  The brc.build script complains because it is
getting something other than "begin" or "update" (an empty string?)
from boot_gift via boot_cmd.  I assume that the undocumented boot_gift
device (charater special (0, 3), [RAM driver]) is some secret, kludgey
chunk of memory used as a message buffer by tboot.  So secret in fact,
that it is unknown by the ETEQ folks who've made a multitude of
motherboards.  It could be the Symphony chipset, perhaps.  Or the AMI
BIOS, another favorite whipping boy who just may deserve the blame in
this instance.

#> # 4.0 has 2 curses libraries. libcurses.a is terminfo curses, libtermcap.a
#> # is termcap based curses. Try to compile this with -ltermcap.
#>
#> Will do tonight.  A lot of makefiles will need changing.  I also tried
#> recompiling Udo Munk's rogue port both with its internal curses and
#> with the 4.0 curses library; they linked but crashed under 4.0.1,
#> perhaps the termcap library will help here also.  The old 3.2 binary
#> works fine.

The fix worked for the chess program.  It did not work for Herr Munks
rogue port.  Nothing I tried works for that.  I'll let Udo worry about
it.

The suggestion about LDHEAD and the "-q" option in the release notes
is a good one and helps with terminal control library usage.

#> # The terminfo entries were built from the termcap entries in /etc/termcap.
#> # You can decode a terminfo file with infocmp and, of course, rebuild
#> # one with tic.
#>
#> Will do tonight.  Somehow I missed seeing a reference to "infocmp" in
#> the manual.

None of tic, terminfo, or termcap manual pages had any reference to
infocmp.  Actually, I think that the only reference is in the index.
The program works fine and my termcap and terminfo are back in sync.

# Actually, we are in the process of updating for the ninth revision of
# the manual now... any suggestions you have will most likely hit the
# tenth revision, which will be several months away. I stress for other
# reading this that I am refering to MANUAL revisions, not actual OS
# revisions.

Hmmm.  If you're that far ahead, maybe I'll just stick to software
issues and leave the grammar to others.

#> 17) E-mail though uucp remote sites seems to work okay, but there is a
#> problem with uucp file transfer.  Received files (requested by uucp
#> commands generated by the mwcbbs front end) came in as owned by uucp
#> (okay, maybe?) with weird permision bits like "rw-r-sr-s" (can't
#> remember exactly, but both set-id bits were on).
#
# Interesting... which files came back with the weird permissions?

All files sent from mwcbbs as a result of uucp commands issued by the
mwcbbs front end running on my system.  The mail was unaffected (I
think, it was created/sent and received/deleted okay.)

#> 18) the uucheck program is acting a bit paranoid and is complaining
#> about the absence of about six or so files that have my serial number
#> as the last segment of the pathname.  Most of these were supposed to
#> be in the /usr/spool/uucp directory tree.  I am afraid to try the -f
#> option as I don't think any of these should exist.
#
# Are you using any line continuation charatcers in your L.sys file?

Obviously, I should have checked this first.  Other than
/etc/serialnum, where else would uucheck get the number?  Maybe I
shouldn't watch so many Rescue Ranger episodes while I'm debugging.
There was also at least one filename that uucheck complained about; I
can't remember it at the moment.  More work for tonight.

 [The above opinions expressed are my own; not necessarily held by others.]
      == Steven J. Edwards           Bull HN Information Systems Inc. ==
      == (508) 294-3484              300 Concord Road         MS 820A ==
      == sje@xylos.ma30.bull.com     Billerica, MA 01821          USA ==
"That Government which Governs the Least, Governs Best." -- Thomas Jefferson