Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!soda.berkeley.edu!wjolitz From: wjolitz@soda.berkeley.edu (William F. Jolitz) Newsgroups: comp.unix.bsd Subject: Re: General problems (serial line, spontaneous reboots) Message-ID: <14id9vINN3k1@agate.berkeley.edu> Date: 22 Jul 92 01:23:11 GMT References: <1992Jul21.025130.15471@ponds.uucp> Organization: U.C. Berkeley, CS Undergraduate Association Lines: 68 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.