UNIX PC BOF Minutes, and Fixdisk 2.0

[norman yarvin]

In article <1089 at icus.islp.ny.us> lenny at icus.islp.ny.us (Lenny Tropiano) writes:
>            Discussions about porting X-windows to the UNIX-pc can be
>       summarized  in  one  sentence, "X windows can be ported to the
>       UNIX-pc, but we need someone to write it."  Nobody at the  BOF
>       volunteered  to  port  X,  but the MGR demonstration did spark
>       some additional enthusiasm about doing it.

On a Sun, the X11R3 server takes 500K for the code segment and over a
megabyte total.  On the Unix PC, less storage would be required for window
data (because of the smaller screen), but the server alone would still take
up a substantial percentage of the memory.  The X clients together generally
take more memory than the server.

X was too big for the Sun-2, another 68010 machine; a friend who tried
running X on a Sun-2 says that the machine was very slow, and would crash
under the high load.

In summary, X is much too big and slow for the Unix PC, even if someone were
to port it.  The Unix PC is a slow machine with a small amount of memory.



Some comments on Fixdisk 2.0:  First, I unpacked it by hand (in case of any
AT&T treachery...).  In the process, I discovered a couple of things in the
Install files that deserve comment.  (Each fix has its own directory and
Install file; a central Install file runs the Install file in all the
directories.)

1) The Install file for the ATE fix creates the file /usr/lib/ua/ate_info
with permissions 666 (as follows, starting from line 20):

|	# Create /usr/lib/ate_info and make 666 for permissions fix
|	> /usr/lib/ua/ate_info
|	chmod 666 /usr/lib/ua/ate_info

I have no idea why a blank file called ate_info should be created, much less
why everyone should be able to bash it.

2) The Install file for the kernel fix contains the following code (starting
from line 26):

|	echo "Unpacking window driver --- please standby ...\c"
|	unpack wind.o 2>/dev/null
|	echo
|	mv /etc/lddrv/wind.o /etc/lddrv/wind.o.OLD
|	mv ./wind.o /etc/lddrv/wind.o
|	chown bin /etc/lddrv/wind.o
|	chgrp bin /etc/lddrv/wind.o
|	chmod 644 /etc/lddrv/wind.o
|	rm -f wind  #  Force a new one to be built

The last line, "rm -f wind", does not work, because the routine has not
changed directory to /etc/lddrv.  Does anyone out there know the difference
between "wind" and "wind.o", and how "wind" would be rebuilt?  I decided not
to remove "wind", seeing as the fix had probably worked fine on lots of
other machines.


The second comment on 3.51m is that a bug which has made me reboot quite a
few times still exists.  It is activated by the following sequence:

(rm /usr/spool/uucp/LCK..ph0)
(kermit; starts up on line /dev/ph0 at 1200 baud)
(phtoggle, from another window)

at which point the Phone Mangler switches its window to display "DATA 1:",
followed by the screen blanking as the machine crashes, followed by a relay
clicking five seconds later.  (no, the relay bit isn't really that
significant.)

Configuration: Kermit (don't know version # off hand), Fixdisk 2.0 phone
manager, Unix 3.51m kernel, phtoggle from Foundation Set 3.51, stock 67MB/2MB
3b1.  Well, not quite stock; I put in a new clock battery.  The problem only
occurs on the first use of the phone after booting the machine.

Workaround: running phtoggle twice before the above sequence.

This sequence is the only way I have found to get kermit to work.  Starting
up kermit with the line already in DATA mode does not work, and not removing
the lock does not work -- kermit detects the lock, and refuses to open the
line.  I don't remember what else doesn't work.  Normally, after the steps
mentioned above, I dial from within kermit.  This produces the message
"Can't release lock file" (or something similar), then "Dialing xxx-yyyy, 
/dev/ph0, 1200 baud" (or something similar).  Sometimes the dialing does not
start until I hit ^\, kermit's interrupt key, after which all is OK.

After the phtoggle, the disk starts a repetitive pattern of accesses, which
continue indefinitely until kermit starts dialing.


My last comment on 3.51m is that loading device drivers seems to take longer.
I have not verified this by a stopwatch (I will soon), but after each driver
is loaded, the system seems to wait for maybe 5 seconds before loading the
next.  I would not notice this, except that I have modified /etc/.drvload to
display to the screen rather than to /tmp/<whatever>.  I load two drivers:
lipc (SYSV IPC) and dup (Ford's /dev/fd/* device driver).  After each there
is the pause.  The modified .drvload follows:  (I do suggest installing it.)

#
#  called from /etc/rc to load drivers at boot time:
#	/etc/.drvload
#   requires:
#	/etc/master	(with entries for loadable devices)
#	/etc/lddrv	(directory)
#	/etc/lddrv/lddrv (setuid root)
#	/etc/lddrv/mkifile
#	/etc/lddrv/drivers
#	.o files for loadable drivers in /etc/lddrv
#
if [ ! -f /etc/lddrv/drivers ]
then
	exit
fi
cd /etc/lddrv
exec < drivers

find . -name unix.sym ! -newer /unix -exec rm {} \; 
if [ ! -r unix.sym ]
then
	echo creating unix.sym 
	./mkifile /unix unix.sym 
fi

# Addition by F. Dewey 5/86 to take care of drivers that cause a panic 
# during binding.  The name of the current driver is kept in /etc/current.driver
# so that if, on the reboot after a panic or hang, the file contains
# the name of a driver, that driver is removed from the /etc/drivers
# file for subsequent bootups.

if [ -s /etc/current.driver ]
then
	read driver </etc/current.driver
	rm -f /etc/current.driver
	echo "Removing problem driver $driver"
	grep -v $driver /etc/lddrv/drivers >/tmp/$$.drv
	mv /tmp/$$.drv /etc/lddrv/drivers
 	exec < drivers
fi

while read driver
do
	echo $driver >/etc/current.driver
	sync;sync;sync
	sleep 1

	if [ -z "$driver" ]
	then
		continue
	fi
	./lddrv -q $driver 
	if [ "$?" != "0" ]
	then
		./lddrv -av $driver 
		retcode="$?"
	else
		retcode="0"
	fi
	if [ \( "$retcode" = "0" \) -a \( -x ./${driver}.rc \) ]
	then
		./${driver}.rc 
		retcode="$?"
		if [ "$retcode" != "0" ]
		then
			./lddrv -dv $driver
		fi
	else
		if [ \( "$retcode" != "0" \) -a \( -x ./${driver}.brc \) ]
		then
			./${driver}.brc 
		fi
	fi
	if [ "$retcode" != "0" ]
	then
		echo "Error loading driver $driver"
	fi

	# if we got this far, the current driver didnt cause a panic or
	# system hang, so it is OK to remove it from the current driver.file.
	rm -f /etc/current.driver
done



exit 0
		Norman Yarvin		yarvin-norman at cs.yale.edu
  "The blastoff looked much like the Challenger, except it appeared to take
  place at night and there was no subsequent explosion"