Unix-Wizards-Request@BRL.ARPA (01/25/86)
UNIX-WIZARDS Digest Sat, 25 Jan 1986 V2#055 Today's Topics: flock-fsync problems Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd Non-Internet domain sockets re: Process control query (4.2 BSD) Need Driver for HP Laserjet DEC DMF32 sync port driver wanted pdp C compiler needed under 4.2 need acutab for scholar modem Re: Database software for UNIX systems Increasing 4.2BSD Data Segment Size More RFS bugs ----------------------------------------------------------------- From: Robin Cutshaw <robin%itcatl.uucp@BRL.ARPA> Subject: flock-fsync problems Date: 23 Jan 86 16:42:53 GMT To: unix-wizards@BRL-SEM.ARPA The problem: open-file loop flock file exclusive write special value to location unique to this process only fsync flock file unlock delay flock file exclusive read value from unique location flock file unlock endloop given several processes running the above algorithm and that no process writes over the unique location allocated to any other process, the value read is not always the value previously written (when it is wrong it is the value written on the pass previous to this one). The question: Does the flock-fsync mechanism work for multiple processes accessing the same file? Is their a better/easier/more reliable mechanism to do this? -robin (uucp: ..!gatech!itcatl!robin) ----------------------------- From: Andrew Findlay <andyf%brueer.uucp@BRL.ARPA> Subject: Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd Date: 23 Jan 86 11:02:46 GMT Keywords: VAX 750 disk Eagle Fujitsu 2361 Emulex SC7002 To: unix-wizards@BRL-SEM.ARPA Adding an Eagle-2 (Fujitsu 2361) to a 4.2Bsd system =================================================== I have just put an Eagle-2 onto a VAX 750 under 4.2Bsd. This article describes how it was done so you need not repeat my mistakes. The software preparation and debugging took about 40 man-hours, but with the information presented here it should be possible in less than 8. The initial configuration was: 2MB, TU80, RA80 on UDA50, DMF-32 The expanded configuration is: 5MB, TU80, RA80 on UDA50, 2*DMF-32 Eagle-2 on SC7002 The Fujitsu 2361 Eagle-2 is an expanded version of the well known 2351A Eagle. It has an unformatted capacity of 689MB against the Eagle's 474MB. The first thing to note is that the disk transfer rate has gone up from 1.859 MB/s to 2.458 MB/s. This means that the Emulex SC7000 is not fast enough to handle the new drive. You will need an SC7002, which is just a faster version of the SC7000. Another hardware point is that the Eagle-2 is in a bigger box than the Eagle - 770mm long rather than 700mm. In our case this means that it sticks out at the front of the cabinet. Since the Eagle-2 was designed after the 4.2Bsd release, it does not appear in /etc/disktab or in the hp.c drivers. You will need to put it in. A quick-and-dirty workaround is to set up the SC7002 to treat the disk as an old-style Eagle - you lose storage capacity, but get up and running very easily. I have not tried this. Setting up the SC7002 ===================== Set up for an 'expanded RM02' emulation with 64 sectors/track. This is code 30 on SW1-4. The hp.c drivers use 'RM02' as a flag indicating that the disk type should be determined by asking for the number of tracks, cylinders, and sectors. You need at least revision F of PROM 994. Preparing the drivers ===================== (1) Use diskpart(8) to generate entries for /etc/disktab and for the hp.c drivers. Put the result in files for use later. Call the disk 'eagle2'. The parameters are as follows: Type: winchester Sector size: 512 # Sectors/track: 64 # Tracks/cylinder: 20 # Cylinders: 842 Revs per minute: 3600 You should end up with a 'c' partition of 1077760 blocks. (2) Install the 'eagle2' entry in /etc/disktab (3) Put entries into your configuration file in /sys/conf, something like this: controller mba0 at nexus ? disk hp0 at mba0 drive 0 This assumes the SC7002 will be the only massbus device - if you already have massbus devices, the 0's above will change. The SC7002 actually emulates a massbus controller AND up to eight massbus disks on one board. (It can split a physical drive into two logical devices) (4) Before modifying the system source code, generate a system from the new config file to check all is ok. If the controller is installed at this stage, the system should note the existence of an 'RM02 with 64 sectors/track?' but should not try to use the device. (5) Go into /sys/vaxmba to modify the main hp driver. First take a copy of hp.c for safety, then make changes to hp.c as follows: Add the eagle2_sizes entry generated in stage (1) - put it after eagle_sizes. It should look like this: }, eagle2_sizes[8] = { 15884, 0, /* A=cyl 0 thru 12 */ 66880, 13, /* B=cyl 13 thru 65 */ 1077760, 0, /* C=cyl 0 thru 841 */ 15884, 294, /* D=cyl 294 thru 306 */ 307200, 307, /* E=cyl 307 thru 546 */ 377408, 547, /* F=cyl 547 thru 841 */ 701248, 294, /* G=cyl 294 thru 841 */ 291346, 66, /* H=cyl 66 thru 293 */ Add two lines to hptypes[], just before the final 0: #define HPDT_EAGLE2 15 -1, These go just after the line that says 'beware, actually capricorn or eagle' Add TWO lines to the hpst[] array, as follows: { 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* DUMMY (place holder) */ { 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* EAGLE-2 */ The dummy line is needed because hptypes[] has a dummy element 14, representing the RM02, whereas hpst[] does not. This one held me up for a couple of days - the system panics when trying to reference the disk if you miss the dummy entry. In the section headed 'EMULEX SC750 or SC780', add code to recognise the disk at boot time. Put it after the bit that recognises an eagle: if (ntracks == 20 && nsectors == 64) { type = HPDT_EAGLE2; printf("hp%d: eagle-II\n", mi->mi_unit); goto done; } (6) Re-generate the system with the modified driver. (7) Use /dev/MAKEDEV to make device entries for hp0 (8) Go into /sys/stand to modify the stand-alone hp driver. In hp.c add a line to the end of hptypes[], so it looks like this: . . . MBDT_RM02, /* actually something else */ -1, /* 9300 */ -1, /* Eagle-II */ 0 }; In hpmaptype.c add a line to describe the eagle2 and its disk partitions. Be particularly careful if you did not use diskpart in stage (1). short eagle_off[8] = { 0, 17, 0, 391, 408, 728, 391, 87 }; short eagle2_off[8] = { 0, 13, 0, 294, 307, 547, 294, 66 }; Now add two lines in hpst[] so it looks like this: . . . #define HPDT_9300 13 32, 19, 32*19, 815, rm05_off, /* Ampex 9300 */ #define HPDT_EAGLE2 14 64, 20, 64*20, 842, eagle2_off, /* Fuji Eagle-II */ }; Now add the code to recognise the eagle2: if (ntracks == 48) { newtype = HPDT_EAGLE; /* 48 sector Eagle */ goto done; } if (ntracks == 64) { newtype = HPDT_EAGLE2; /* 64 sector Eagle */ goto done; } printf("RM02 with %d sectors/track?\n", ntracks); done: (9) Reconstruct the standalone utilities with make, and copy what you need into the root filesystem. This will probably be: format copy boot drtest On a 780, these should go onto the console floppy (?) (10) Dump the ENTIRE system onto tape and then get the hardware installed! (11) The Emulex formatter does not seem to get the bad block info in the right place for the hp driver, so use the newly generated version of format(8) to sort that out (in standalone mode of course). It is then worth using drtest(8) to check that all the bad blocks have been found. (12) When you boot up the new system, the lines: mba0 at tr4 hp0 at mba0 drive 0 hp0: Eagle-II (or something very similar) should appear on the console. (13) You should now have a working 540MB disk. Create filesystems with newfs(8) and put it to work. To get the best possible performance out of the filesystems, the rotational delay parameter needs to be set appropriately with tunefs. I used Don Speck's test program and found 8ms to be good, so the command is: tunefs -d 8 /dev/hp0h Remember to do this for each filesystem after creating it. Perhaps surprisingly, I can find no significant difference in performance between a filesystem on an RA80 and one on an Eagle-2. These tests were done with a load factor of about 1.4 - one active user with a cpu-bound process: % time dd if=<big file on RA80> of=/dev/null bs=1024 count=1024 1024+0 records in 1024+0 records out 0.4u 4.8s 0:09 57% 13+9k 129+2io 2pf+0w % time dd if=<big file on Eagle-II> of=/dev/null bs=1024 count=1024 1024+0 records in 1024+0 records out 0.3u 5.0s 0:09 59% 13+9k 263+2io 2pf+0w Good luck, and please let me know if I have missed out anything vital.... Andrew Findlay ... ukc!reading!brueer!andyf ... andyf@uk.ac.bru.ee -- ------------------------------------------------------------ UUCP: ...ukc!reading!brueer!andyf JANET: andyf%brueer@uk.ac.reading ARPANET, CSNET: andyf%brueer@ucl-cs.arpa ------------------------------------------------------------ ----------------------------- From: Nathaniel Mishkin <mishkin%apollo.uucp@BRL.ARPA> Subject: Non-Internet domain sockets Date: 23 Jan 86 19:53:05 GMT To: unix-wizards@BRL-SEM.ARPA I've been attempting to understand how the Berkeley socket mechanism is intended to be used with non-Internet domain sockets, but it seems like the naming issue has not been addressed generally. The framework (e.g. the "sockaddr" struct type) is obviously designed to be domain-independent, but in practice it seems hard to write domain-independent programs. For example, the various network programs (like "telnet") seem to be mightily tied to Internet-style addressing. My understanding is that 4.3BSD supports XNS -- does this mean that some of the Internet dependencies have somehow been excised? If so, how? -- Nat Mishkin Apollo Computer Inc. {uw-beaver, wangins, yale}!apollo!mishkin ----------------------------- From: Brett Galloway <brett%wjvax.uucp@BRL.ARPA> Subject: re: Process control query (4.2 BSD) Date: 24 Jan 86 00:15:38 GMT Keywords: 4.2, BSD, process control To: unix-wizards@BRL-SEM.ARPA Last week I posted a query to the net about communicating the success or failure of an execve() from inside a fork() to the parent process. I got several responses (thank you). I finally decided to create a pipe between the child and the parent. If the child's execve() fails, it writes write(fd,&errno,sizeof(errno)) down the pipe and _exit()'s. If the child's execve() succeeds, the pipe gets closed automatically, because I explicitly mark the close on exec flag for the pipe in the parent). Meanwhile, the parent sits on the other end of the pipe. If it sees EOF (read(fd,&errno_save,sizeof(int) == 0)), it knows the execve() succeeded. Otherwise, it gets the error code returned by exeve(). Apparently, the only way for the parent to detect the difference between the child's execve() failing or succeeding and exiting very quickly is by using a scheme as above, which explicitly communicates the success/failure of the execve() from the child to the parent. ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett ----------------------------- From: "Edward M. Rynes Esq." <rynes%cwruecmp.uucp@BRL.ARPA> Subject: Need Driver for HP Laserjet Date: 23 Jan 86 18:20:11 GMT To: unix-wizards@BRL-SEM.ARPA We will be receiving an HP Laserjet (Plus??) for a free two week trial run to see if we actualy want to spend money to keep it. However, as far as I know, we are not getting any software to drive it. I therefor need a driver that can handle CAT (troff), dvi (prefered), and/or ditroff output. I also need a ditroff to dvi filter so I can use ditroff with our Imagen. Many thanks to everyone who read this far, and endless blessings on all who reply. As Usual, Ed Rynes -- ______________________________________________________________________________ Ed Rynes | "Fixed on the front of her Facilities Manager | Fassbinder face was the kind of a Dept. of Computer Eng. and Science | smile that only a rather dull child Case Western Reserve University | could have drawn while attempting ...!decvax!cwruecmp!rynes | a graveyard at night!" rynes@case.csnet | Roger Waters ______________________________________________________________________________ ----------------------------- From: "George R. Boyce" <george%cornell.uucp@BRL.ARPA> Subject: DEC DMF32 sync port driver wanted Date: 23 Jan 86 19:40:57 GMT To: unix-wizards@BRL-SEM.ARPA I'ld like to have a DMF32 driver which has support for the synchronous port which is on that board. If anyone has something close which needs to be finished or modified, I'ld be glad to take a stab at it. Thanks. George Boyce, Cornell Computer Services, george@cornell ----------------------------- From: Art Hays <hays@BRL-TGR.ARPA> Subject: pdp C compiler needed under 4.2 Date: 25 Jan 86 00:20:20 GMT To: unix-wizards@BRL-SEM.ARPA I would like to be able to generate binaries for a pdp11 V7 system from 4.2 on a VAX. Has anyone put up a pdp11 C compiler (with as, ld, etc) on 4.2 using 'compat' or whatever? Art Hays, Nat Inst of Health (301) 496-7143 hays@brl decvax!brl-bmd!hays ----------------------------- From: Martin Nicholson <marty%decuac.uucp@BRL.ARPA> Subject: need acutab for scholar modem Date: 24 Jan 86 21:23:49 GMT Keywords: acutab To: unix-wizards@BRL-SEM.ARPA I am looking for an acutab for a "scholar modem" (2400 baud). This is to get it useful for tip. Please answer me by email directly. Any info/pointers would be greatly appreciated. thanks, Marty Nicholson UUCP: decvax!decuac!marty VOICE: (301) 731-4100 USMAIL: Digital Equipment Corporation 8301 Professional Place Landover, MD 20785 ----------------------------- From: mo%wgivax.uucp@BRL.ARPA Subject: Re: Database software for UNIX systems Date: 23 Jan 86 13:11:40 GMT To: unix-wizards@BRL-SEM.ARPA Look into ORACLE and SIR. Both have problems (ORACLE did not support 4.2 as of July, 1985 and SIR did not support multiple users except if everyone is interfacing through screens -- no simultaneous batch or ad hoc queries -- as of August, 1985). Informix and Unify just won't cut it for large applications, and Ingres (commercial or not) has a lot of bugs in their UNIX version (the current UNIX 4.2 port was not even able to complete the turorial outlined in the manuals without severely crashing). Ingres also requires mods to the kernel, which some (including myself) feel is a bad way to implement locking. These comments stem from an in depth evaluation of these software systems in July, 1985, including on-hands with SIR, INGRES, and INFORMIX. ORACLE did not have a version available for 4.2 at the time, and UNIFY was just too limiting. Our final decision was to keep what we had -- a Britton Lee Database Machine, the only valid solution to large database applications (500+ Mb) in the UNIX environment today (-: in my opinion, of course :-). We have since bought a second IDM. BTW: Britton Lee just announced a new "deskside" database machine for around $40,000 with disk, making it competitive with software systems. Some addresses you might find useful: Britton Lee, Inc SIR, Inc ORACLE 14600 Winchester Blvd 5215 Old Orchard Rd Los Gatos, CA 95030 Skokie, IL 60077 Menlo Park, CA (408) 378-7000 (312) 470-9770 (415) 854-7350 ----------------------------- From: Ed Mehlschau <em%dscvax2.uucp@BRL.ARPA> Subject: Increasing 4.2BSD Data Segment Size Date: 22 Jan 86 03:18:44 GMT To: unix-wizards@BRL-SEM.ARPA Anyone ever bump MAXDSIZ in the 4.2BSD kernel? What is the relationship between MAXDSIZ and NDMAP & DMMAX? More specifically, how much should NDMAP and DMMAX be increased for a given increase in MAXDSIZ? Many thanks, Ed Mehlschau ucbvax!ucsbcsl!dscvax2!em ----------------------------- From: Todd Brunhoff <toddb%tekcrl.uucp@BRL.ARPA> Subject: More RFS bugs Date: 23 Jan 86 22:36:10 GMT To: unix-wizards@BRL-SEM.ARPA Wayne Power writes: >1. RFS doesn't seem to care about x bits or file type. > > % /remote_host/etc/passwd > > ...tries to run the password file as a shell script, even though its mode > 644. Even more off the wall... > > % /remote_host/etc > > ...does the same thing. > Yep. A bug. Basically, the shell is starting up the interpreter, but that is probably because it thinks it is the right mode. The bug is probably in the server in s_access() in serversyscall.c. >2. Intentional circumfornication like... > > % cd /host1/host2 > > ...hangs the server on 'host1'. > RFS is designed not to allow hopping hosts like this example. It should just fail, but instead causes the server on 'host1' to hang. I think it is because the server is hung in syscall() in /usr/sys/machine/trap.c doing the system call over and over. I think the fix for this is in remote/rmt_general.c around line 147: /* * finally, if the user has turned off remote access for himself, * then just return. */ p = u.u_procp; if (p->p_flag & SNOREMOTE) return(FALSE); <<<< this should be TRUE? u.u_error = 0; >3. If a remote host goes down, it seems that every process that chdir'ed to > or opened a file on that machine's file system must die before it can be > unmounted. This gets in the way of a machine crashing and coming back > without disrupting the rest of the participating machines. This was listed in the bugs at the end of the installation doc. Whenever a connection goes down, there may be processes still up ``using'' that connection. However, if there are no open files or remote chdir(2)'s, the kernel could just as well restart the connection without waiting for those processes to die. The fix would probably go in the kernel routine rmt_getconnection(). If there are indeed no open files or chdir's, then before returning the open socket, just test for so->so_state & SS_CANTSENDMORE If set, then clean up the connection and start a new one. If there are open files or current directories, then things get more complicated. You could traverse the file table, finding any descriptors pointing to the dead host and assign them to some "invalid" entry in remote_info[]. This way, the file descriptors will fail gracefully. Another possibility is just to ignore the old remote file descriptors and fix the server to handle it. The directories are not quite so bad... the user would just suddenly find himself in ``/'' when the connection is restarted. ---------- Another problem related to #1 above is that sometimes real live binary files on a remote host fail in the kernel execve(), and so the shell starts to interpret the file, and you get many occurences of: gobbledygook: not found Well, the interpretation of the file is the same problem as above, but the real binary file failing on the execve() is another. The way it works is that the client kernel sends a request to the server; the server opens the binary, reads the a.out header, and sends it back to the client, and then waits for one of two things: 1) a request for the entire binary to be sent or 2) a "forget it" message saying that the client doesn't want the binary. For whatever reason, the server is not getting the "forget it" message, and hence all the file descriptors get used up, and then NOTHING will exec (and then the shell starts interpreting binaries). This problem has only shown up with ATT's ksh (korn shell). Thank you all for the great feedback, and special thanks to Terry Laskodi (here at TEKLABS) for many great ideas for the design of RFS. Many hours he listened to me babble on about the design making great suggestions. Again, I cannot spend any time on RFS, but I will repost bug reports sent to me with comments attached about suggested fixes. Naturally, I would also like to see the fixes if any of you have the time. Todd Brunhoff {decvax,ucbvax}!tektronix!crl!toddb toddb%crl@tektronix.csnet ----------------------------- End of UNIX-WIZARDS Digest **************************