From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: Re: General problems (serial line, spontaneous reboots)
Date: 22 Jul 92 01:23:11 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu

In article <1992Jul21.025130.15471@ponds.uucp> rivers@ponds.uucp (Thomas David Rivers) writes:

>I'm *very* pleased to get the newest 386bsd; it looks like some
>really nice work.

Thanks.

>First of all, I'd like to report that the cursor seems to be confused
>for monochrome cards.  The line appears above the space instead of
>below it.  I got around this by using a CGA card displaying on my
>monochrome monitor (a clever little card from an old Tandy 1200H
>machine.)

I think this is due to the block cursor being larger than possible on
a monochrome card, so only the top lines are turned on. Point noted.

>Next, with respect to silo overflows in the serial driver.
>I was *plagued* with them when I was using an MFM disk, replacing
>that with an IDE disk appears to have corrected the problem.  Could
>there be a problem with interrupts being left too high, too long in the
>wd driver?

That should not be a problem, since disk activity blocks interrupts only
to disks, and does not block the terminal. Undoubtably, there is a problem
elsewhere. There are some improvements for better handling of the com
driver that missed the boat for 0.1, esp. for FIFO UARTs.

>Next, I noticed that when running screen (the binary supplied in the
>etc01 distribution) on a serial line, the characters get buffered
>an extra time, some how, some where.  This isn't the case for screen
>running on the console; so there could be a problem in the serial driver
>(i.e. probably not the pty driver.)

We have a suspect at the moment, but I've been too flooded to get to it.
It occasionally causes a single character to be caught until the next one
is typed, then the problem goes away.

>Next, I thought I would try and replace the com driver with the latest
>one I had for 0.0 (in which Chris cgd@agate.berkeley.edu had implement
>bidirectional lines); however, the first compile of the locked up (it was
>over a serial line.)  I could type *nothing* anywhere and get any
>response - even ctrl-alt-delete; so I powered down and rebooted.

Hmm. A lockup at either spltty() or splhigh(). Try pinging next time, then
you can isolate the two.

>After the fsck's; I restarted the compile on the console instead of over
>a serial line.  This time, compiling part of ../../vm, the machine
>spontaneously rebooted.

A shutdown. What's your memory size, has this machine run windows/3 lately,
have you seen a shutdown without the FPU present ?

>So, now, after complaining so much :-), let me offer one trivial
>helpful hint.  To compile trek (in the etc01 distribution) you need
>to remove the -lcompat from the Makefile line (there is no compat library
>for 386bsd), and properly define gtty() in main.c.  I added the following
>two lines just before main():
>
>#define gtty(fd, argp) ioctl(fd, TIOCGETP, argp)
>#define stty(fd, argp) ioctl(fd, TIOCSETP, argp)

This is true of many old berkeley programs left unconverted to the POSIX
world order. Libcompat contained a lot of trivial "old" entry points,
the idea was to locate the entry points an recode them in modern form.


Bill.