Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!cs.yale.edu!yarvin-norman From: yarvin-norman@CS.YALE.EDU (norman yarvin) Newsgroups: comp.sys.att Subject: Re: UNIX PC BOF Minutes, and Fixdisk 2.0 Message-ID: <15523@cs.yale.edu> Date: 14 Feb 90 03:09:42 GMT References: <1089@icus.islp.ny.us> Sender: news@cs.yale.edu Lines: 187 In article <1089@icus.islp.ny.us> lenny@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/. 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 /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@cs.yale.edu "The blastoff looked much like the Challenger, except it appeared to take place at night and there was no subsequent explosion"