This is a slightly reformatted copy of some mail messages I sent to the BSDI beta mailing list in March 1992.
|Thursday, 19 March 1992||Schellnhausen|
|Top of page|
Beta test report, BSDI/386, 19 March 1992
|Topic: technology||Link here|
|LEMIS, Lehey Microcomputer Systems|
I have only just got on this list, so a certain amount of this information may be redundant; please bear with me. In addition, I have a System V background (specifically, in this context, ISC), and this is my first exposure to BSD, so some of the things I write may sound naive.
The machine configuration is:
Copying disks with DOS DISKCOPY is possible. It can be a problem if DOS hasn't seen a DOS disk on that drive first. The fix is to do a `dir' on a floppy in that drive first. If all is well, the DISKCOPY program should claim
Copy 80 tracks, 2 sides, 18 sectors per track.
The docs suggest that you use -f /dev/rst0 for SCSI devices - is this a typo? In any case, I would expect it to work the same way by setting the TAPE variable to /dev/nrst0, and it does.
Ported GNU bash 1.12 to BSDI with almost no problems—needed to modify machine.h to explain the combination of BSD and 386 when __bsdi__ was set, but that was all. In particular, I had had a panic with ISC UNIX/386 2.2 which appeared to be due to bash calling stat with an invalid buffer address (haven't had time to work out the linkage back to the user process in ISC - if anybody knows how to do this, I'd be grateful for the info).
NFS didn't complain, but also didn't come up correctly. I hadn't created an /etc/exports file, and as a result a number of processes didn't bother doing anything. Probably worth documenting.
Need mountd -n for Sun PC-NFS. It's there in the documentation somewhere, just need to look for it. If you don't do it, the mounts from the PC to the BSD machine fail.
It would have been nice if the Ethernet driver would report missing interrupts: my WD8003 reconfigured itself with an incorrect interrupt, but I spent most of the time looking at the software configuration.
I compiled and ran one of my CPU benchmark programs (a non-Erastosthenes prime number program), and it ran at approximately 10% of the speed it ran under Interactive on the same machine. I suspect that this is related to the coprocessor handling. When I have time, I'll check on it. Apart from that, the system seems very fast, but of course I don't have X installed yet...
Found the halt command by trial and error. I suppose it will be in the final documentation.
SCSI drive config is a bit strange, and I got a number of invalid config messages. However, fsck seemed to be happy enough on rsd0a and rsd0h.
Trying to read in the tape (SCSI tape) I had a minor problem with an invalid status:
This seems to happen when the tape is still moving or after inserting it, and will work correctly the next time.
During installation, trying to mount /dev/rsd0h I got the message Device not configured. Tried a newfs /dev/rsd0h again and got the message "Warning: calculated sectors per cylinder (540) disagrees with disk label (535).". This didn't go away when I rebooted and redid the newfs. It still claims a divergent number of sectors per cylinder. Since I don't have the correct info handy, I'm leaving it at 535 sectors per cylinder. Did another newfs on /dev/sd0h and got the same message again, but it went and did the job anyway. fsck again seemed to be happy.
Still during installation, after reading in the root file system, the mount worked, but tar -xvp read nothing. The last file restored from that archive was root/.login - this agrees with a tar -t I did afterwards. A second tar -xvp worked fine.
Even in multi-user mode, ctrl-alt-DEL will reboot the system. The current implementation seems to be broken: first it asks if you want a dump, and whether you ask for one or not will try to dump and fail about half the time. This is unfortunate, because then it doesn't re-sync the file systems. It would also be nice to be able to escape at this point (i.e. undo the ctrl-alt-DEL).
Problems writing to SCSI tape: there seems to be no way to specify the density to write with. The Tandberg will handle up to 525 MB per disk, but I was not able to use this density. It looks as if it defaults to QIC-150.
To get over the previous problem, I wrote
which worked as expected until the end of tape, when it claimed incorrect block sizes and aborted.
make does strange and somewhat dangerous things. Trying to make emacs (the version supplied on the tape), I hit the intr key while it was making etc, and it removed etc - not, apparently, as a directory, but as a file. On re-booting, fsck tripped over a couple of unlinked etc directories. Is this kosher in BSD?
During installation I tried to start vi with the root file system protected. This didn't work very well, of course - couldn't open the swap file - but when I remounted the file system and tried again, the system paniced (and didn't take a dump, but did reboot before I could get any details).
Tried porting my sources of Emacs and had fun with the xmakefile - there was a ^L at one point, and make didn't understand it. it seems to be a problem with make rather than with emacs, and so I decided to port make first.
A couple of problems with porting make: a recursive definition between job.c and sys/param.h and something that looks like a compiler error:
fails with conflicting definitions, complete with line numbers and so on. When I get EMACS done, I'll do gcc 1.40, and hopefully that will get rid of the problem.
vi dies under certain circumstances (I entered an EMACS ^A) with a segmentation fault and leaves the file open. (Sorry, something ate the core dump, but I'll keep it if it happens again and if anybody is interested).
Problems - would be nice to solve before final release
I tried to configure an NE2000 clone as described, and found no mention of buffer address. Since the requirement was stated in brackets, I assumed that it's always D0000. However, on POST, the Adaptec BIOS (located at DC000 as default) did not come up. This is obviously not directly a problem with BSDI.
telnet doesn't seem to work. Can't find a telnetd, which is probably the missing link.
Serious problems - would like to solve immediately
Can't get any kind of display from X. After working out that it would only support certain chips, got the Orchid card, which only has 512K of memory. It's a pity that the driver insists on supplying 256 colours - I have been using it as a 1024x768 display on Interactive, and here I'm limited to 800x600, assuming I can get it up at all.
Starting xinit from the console blanks everything out, and otherwise nothing of interest happens. I need to reboot to get a display again - does anybody have a program to reset the VGA? After a bit of experimenting, I found that the server would produce some messages if I started it from another terminal. The message I am getting now, after lowering the resolution to 800x600, is "Can't resolve 800x600", which doesn't make much sense to me.
|Friday, 20 March 1992||Schellnhausen|
|Top of page|
Beta test report, BSDI/386, 20 March 1992
|Topic: technology||Link here|
X is working! It took quite a while, but now I think I've worked everything (well, something) out.
In addition to the installation instructions, which tell you a fair amount about how to set up screen geometries, you desperately need to read /usr/X11/man/mann/X386.n, which is Thomas Röll's description of how his server works. In particular, it tells you what choices you have in setting up /usr/X11/lib/X11/Xconfig, which is the main task you need to perform X installation. Here a couple of gotchas, some of which X386.n won't help you with:
the file and path names are different. They look as if they have been set up for Interactive (System V) X. In particular, if you have stuck to the path names suggested in the Beta installation instructions, you will need to change the following:
references to /usr/X386 to /usr/X11
the mouse device from /dev/tty00 to /dev/com0 or /dev/com1
If you don't have a Logitech mouse, you still seem to need to tell the system the bit rate of the mouse - at least, unless you do the results are very erratic.
I finally succeeded installing an Orchid ProDesigner VGA, which has a Tseng 3000 chip set and 512 of memory. The server correctly found the memory, but couldn't work out the bit clocks. The error message in this case is `Mode couldn't be resolved: 800x600', meaning basically that it couldn't find a bit clock to match the specs in Xconfig. It's relatively easy to guess the bit clocks on the ProDesigner, because it's an old board with 5 crystal oscillators on it. However, just specifying `clocks 25 28 35 45 65' won't work, because it seems that this line is used as a reverse indexed array, and in this case (e.g.) 45 MHz would give the value 3 to some register, which would not necessarily set 45 MHz (it doesn't, as it turns out). I think I remember seeing something about this while grepping through the X11 files, but I've forgotten where. In any case, I proceeded by trial and error: I connected a scope up to the horizontal sync and set up the Xconfig as follows:
and then started the display (with xinit). The result was display spaghetti, but I was able to establish that the sync pulses on the scope were 40 microseconds apart. Noting that I have exactly 1000 dots per line, this implies a dot spacing of 40 nanoseconds, or 25 MHz. So I put a 25 in front of the 65 and tried again with 65. This time I got a frequency of 28 MHz, and so I put that in and carried on until I got bored. The final result looks like:
There are a couple of things to note here: first, the values repeat themselves, and secondly there's a 0 in there. With the 0, it didn't sync at all - I just got garbage on the scope. The same happened with 65, but I couldn't imagine that there would be more than 4 bits for selecting the clock speed. I suspect that there is some internal dependency for 65 MHz on the ProDesigner, and that bot 0 and 65 MHz will select 65 MHz, but only under certain conditions. This seems particularly so since the scope showed 65 kHz after I stopped the server (more on that below). I'm currently writing this in an xterm running 800x655 at 45 MHz, and it seems reasonable. Since I can't use this board at 1024x768 with 256 colours, I'll get a new board and use this on the Interactive machine.
Note the resolution I'm using: this makes the most of the memory I have available. Neither the name of the display mode (800x600) nor the frequency spec of the dot clock seem to make any difference to the config routines: they just use the values as IDs to find the resource required. 800x655 uses a total of 524000 bytes of refresh memory, which leaves 288 bytes unused. The monitor will do 1280x1024, so I don't need to limit the on-screen display.
What didn't work
The big problem I had, apart from getting the system to run at all, was that stopping the server, either by stopping the last window or ctrl-alt-bs, would leave the screen in an indeterminate state. I still don't know a way around that.
Another thing that didn't work was the resolution scrolling advertised with ctrl-alt-grey +. Nothing at all happened. If I specified more than one possible display format, it always took the last one.
I included xhosts + in my startup .xinitrc, and the server registered the fact and stated that all hosts had access, but I couldn't start a window from an ISC machine. There may be other reasons behind this, of course, and I intend to investigate them.
I got hold of a 1MB ET 4000-based VGA and put it in the machine, but had the same effect that the Adaptec 1542B no longer ran the BIOS, so I couldn't boot. Has anybody else seen this? The board I had was an Iris VGA ET4000.
Keymaps still don't seem to be right. I'll investigate later, but xev shows that XLookupString will return the same values for an alphabetic key with or without the Alt key.
The server seems slow. I haven't had time to do any real tests - I'm happy enough that the ^&*(&* is running - but possibly the fact that the server is handling 8-bit pixels has a bearing here.
Still can't get telnet to work. Last time I tried, I couldn't get a telnetd started. Turned out inetd didn't have a path to it, so I linked it into /usr/sbin, and it started telnetd - and did nothing. If anybody has any comments on this, I'd be interested to hear them.
|Saturday, 21 March 1992||Schellnhausen|
|Top of page|
LEMIS Beta report, 21 March 1992
|Topic: technology||Link here|
Comparatively little to report today. A couple of minor problems turned up, a couple of problems solved themselves or at least mainfested themselves more clearly.
Permissions problem starting windows: only local root can open a window. This doesn't seem to be a net problem: turned out that remote root could also open the windows after X had been started under root. Starting under my own userid allowed normal access to all users.
The telnet problem, if not completely solved, turned out to be an incompatibility between Sun PC-NFS and BSDI. It works well from ISC to BSDI (except that ISC has a tendency for telnet to die with a ridiculous error message (no more processes) after some indeterminate time).
This is probably related to 2: I can mount UNIX file systems on a PC with PC-NFS, but I can't access directories. A cd to a directory will either do nothing or bring an error message saying "invalid directory".
On one occasion, the system just rebooted without any apparent warning or reason (I was doing something routine in the editor). This could be hardware, but the interesting thing was that, on reboot, fsck did not see any problems.
At the moment I'm doing some thinking about European keyboard mapping. Does anybody out there have any thoughts on how to do it?
|Top of page||Greg's home page||Today's diary entry||Greg's photos||Copyright information|