vance@mtxinu.UUCP (Vance Vaughan) (11/12/84)
4.2 BUGLIST ABSTRACTS from MT XINU, part 10 of 10:
The following is part of the 4.2 buglist abstracts as processed by
Mt Xinu. The initial line of each abstract gives the offending
program or source file and source directory (separated by --),
who submitted the bug, when, and whether or not it contained
a proposed fix. Due to license restrictions, no source is
included in these abstracts.
Important general information and disclaimers about this and
other lists is appended at the end of the list...
vax/machdep.c--sys astrovax!wls (William L. Sebok) 5 Mar 84 +FIX
The computer (a Vax 750) occasionally panics:
machine check 2: cp tbuf par fault
even though BSD 4.2 contains the patch to flush and return on tbuf
parity errors.
The problem is that the test for the condition insists that bit 0 of
the mcesr (prefetch reference bit) be zero, which need not be true.
REPEAT BY:
Eventually the computer will panic as described above.
_______________________________________________________________________________
vax/machdep.c--sys ECN.ghg@Purdue.ARPA (George Goble) 26 Jul 84 +FIX
One can exec an a.out with a large BSS which exceeds the
user settable DATA size limit. The a.out will run fine
(exceeding the DATA size limit) until it does an sbreak
at which time the limit is checked correctly and ENOMEM
is returned.
REPEAT BY:
Run any large a.out which does not do malloc() or sbreak().
_______________________________________________________________________________
vax/machdep.c--sys astrovax!wls (William L. Sebok) 6 Mar 84 +FIX
In memerr() in /sys/vax/machdep.c no test is ever done to check
whether memory errors on a VAX 750 are correctible or not. Thus
strange panics and such may occur with no indication on the console
that there was a hard error.
The fix below fixes the problem for a VAX 750. I suspect that the
same problem is also present in the VAX 780 and 730 support code, as
I have not seen any tests for the uncorrectable memory error condition.
This bug was also present in 4.1.
REPEAT BY:
Get yourself a bad memory board with hard errors. The system may do
all sorts of strange things because of memory errors yet only
"soft ecc" messages will appear on the console.
_______________________________________________________________________________
vax/machdep.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
The dumpsys() routine in machdep.c writes the core image to the
device specified in "dumpdev". If GENERIC UNIX panics before
setconf() configures dumpdev, dumpsys() tries to write the core image
on device (dev_t)0. If your system is MASSBUS-based, this is
usually the root filesystem. Result: root filesystem gets bashed.
It's ironic that there was code in 4.1bsd to defend against this,
but someone ifdef'ed it out in 4.2bsd.
REPEAT BY:
Introduce faulty code into GENERIC UNIX that causes a crash before
setconf() is called. This would probably never be done intentionally,
but it can happen in the course of debugging new versions of UNIX.
FIX:
Remove the #ifdef notdef and the #endif at the beginning of dumpsys()
in machdep.c. This isn't the best fix, but it is better than
no fix at all.
Reported-By:
Rick Ace, New York Institute of Technology, (516) 686-7644
_______________________________________________________________________________
vax/machdep.c--sys lepreau@utah-cs (Jay Lepreau) 21 Sep 84 +FIX
Someone missed putting in the required null stmnt between
an if and an asm() to get around C compiler bug.
Means a prober is never done.
REPEAT BY:
Source and assembly code examination.
FIX:
At beginning of sigcleanup(), add the line
; /* Avoid asm() label botch */
right after the "return;" line.
_______________________________________________________________________________
vax/machdep.c--sys salkind@nyu (Lou Salkind) 1 Dec 83 +FIX
The amount of physical memory the system uses is not computed
correctly. This is because the kernel makes the (incorrect)
assumption that 2*nbuf = bufpages.
By default, nbuf is set to bufpages/2 where bufpages is
a function of the physical memory available. If bufpages is odd,
you lose.
REPEAT BY:
Actually, I noticed this problem when patching in my own
values of bufpages and nbuf.
_______________________________________________________________________________
vax/sys_machdep.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
If a negative number is passed to the resuba syscall by the super-user,
it is handed to ubareset(), with rather unexpected results.
REPEAT BY:
Issue the resuba syscall with a negative argument.
_______________________________________________________________________________
vax/trap.c--sys rws@mit-bold (Robert W. Scheifler) 17 Nov 83 +FIX
When doing a wait3() with WUNTRACED with a SIGCHLD handler,
if the inferior stops due to a SIGTTIN, SIGTTOU, SIGTSTP, or
SIGSTOP after the parent is already sleeping at PWAIT, the
wait3() never returns.
REPEAT BY:
The following C program will demonstrate the bug. Run it,
and type ^Z to the ftp prompt.
#include <sys/signal.h>
#include <sys/wait.h>
#include <sys/ioctl.h>
extern int child();
struct sigvec sv = { child, 0, 0 };
struct sigvec ig = { SIG_IGN, 0, 0 };
main()
{
sigvec(SIGCHLD, &sv, 0);
sigvec(SIGTTOU, &ig, 0);
if (!fork()) {
short pid = getpid();
setpgrp(pid, pid);
ioctl(0, TIOCSPGRP, &pid);
execl("/usr/ucb/ftp", "/usr/ucb/ftp", 0);
}
wait3(0, WUNTRACED, 0);
}
child()
{
short pid = getpid();
ioctl(0, TIOCSPGRP, &pid);
}
_______________________________________________________________________________
vax/trap.c--sys rws@mit-bold (Robert W. Scheifler) 3 Jan 84
sigstack() seems like this wonderful thing, allowing applications
to field signals without modifying the normal stack. This is
useful, for example, when you need to control values on the stack
to avoid garbage collection problems. Unfortunately, to take
advantage of a VAX instruction (REI), the sigcontext structure that is
passed to the signal handler is always pushed onto the CURRENT stack,
not the stack specified with sigstack(). As near as I can tell, this
largely defeats the whole purpose of sigstack(). (Fortunately
for my applications, namely CLU and Argus, I can guarantee that these
5 longs won't look like heap references, so I luck out.)
REPEAT BY:
Use sigstack() and sigvec() to set up a stack and handler, and cause
the appropriate interrupt. Look which stack the sigcontext is on.
FIX:
The sigcontext is only pushed on the current stack so that the
PS+PC part can be used by the REI instruction in the signal
trampoline code. The fix is probably to do the REI "by hand" in
sigcleanup() instead, or perhaps do some correctness checks on the
PS+PC, and then update the PS+PC on the kernel stack for the REI back
from the CHMK 139, thus collapsing what is currently an REI-to-REI
into a single REI.
_______________________________________________________________________________
vax/tu.c--sys guest@ucbarpa (Guest Account) 19 Jun 84
lint complains a lot as it grovels over sys/vax/tu.c
REPEAT BY:
Configure a 4.2bsd kernel for VAX730 and/or VAX750 and then "make lint"
FIX:
Lots of little mods all over tu.c, all of which will be obvious
when you "make lint". Should have been done when the driver was
coded.
Reported-By:
Rick Ace, New York Institute of Technology
_______________________________________________________________________________
vax/tu.c--sys Bill Croft <croft%Safe@SU-Score> 12 Oct 83
In sys/vax/tu.c (the console tu58 driver), the tu_restart
function calls "timeout" with a bad argument. This
can cause the system to crash if a tu_restart ever occurs
(as often happens on a 750).
REPEAT BY:
cp /dev/tu0 /dev/null
will crash a 750; it would probably crash a 730 too
if the tu_restart code ever gets called.
FIX:
The bad line says:
timeout(tustart(), (caddr_t)0, hz * 3);
and should read
timeout(tustart, (caddr_t)0, hz * 3);
Alas however, there still seems to be bugs in the 750 (RSP)
version of the code. I have my config file and makefile
set up properly to include the pseudo-dma code, but
it still doesnt work (manual section tu(4) claims it
should work in single user mode). I get many "overrun
error, transfer restarted" messages. As a long shot
I tryed nooping the call to "tudma" in locore (Xconsdin),
but still no go. I was hoping to use the tu58 to
backup the dist cassette and in getting some initial
conversion sources over until my net interface
is working (with Stanford subnets).
--Bill Croft
Stanford Medical Center (croft@sumex)
_______________________________________________________________________________
vaxif/if_ec.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
If ecprobe() confirms the presence of an operational 3Com Ethernet
controller, it returns the value 1. It should instead return the
size of the controller's UNIBUS registers.
REPEAT BY:
Examine the code in ecprobe() if if_ec.c
FIX:
At the end of ecprobe() in if_ec.c, replace the line
return (1);
with
return sizeof (struct ecdevice);
Submitted-By:
Rick Ace, New York Institute of Technology, (516) 686-7644
_______________________________________________________________________________
vaxif/if_ec.c--sys Jeff Mogul <mogul@coyote> 13 Feb 84 +FIX
3com Unibus ethernet interfaces don't hear themselves, so
if_ec.c has code to fake this by looping packets. The comment
at ecoutput() says "If destination is this address or broadcast,
send packet to loop device ..." but in fact the code only
checks for broadcasts, and then only by checking the IP address.
So, it won't loopback directed packets or non-IPs.
Fixing this for IPs is easy; fixing it for other AFs is hard
because if_loop.c only handles IPs. The fix below works for
IPs; separate code (marked by #if NENETFILTER) works for users
of Stanford's ethernet filter pseudo-device.
Another, somewhat subtler bug, is that in certain cases the
original code could lose mbufs; it didn't free mcopy if it
bailed out for some error conditions.
REPEAT BY:
Can't be repeated on a vanilla 4.2BSD system; if_ether.c does
IP loopbacks before they get to the driver (except for broadcasts,
which the driver already does right) unless Chris Kent's changes
to if_ether.c have been installed.
Otherwise, repeat by trying (somehow) to send a packet to yourself.
_______________________________________________________________________________
vaxif/if_ec.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
Malfunctioning 3Com Ethernet hardware can crash UNIX. The ecread()
routine extracts the receive-buffer number from the Receiver
Control Register in the 3Com controller. If the controller
malfunctions and reports that it has received a packet in
buffer number 0, the driver issues a panic("ecrint").
Halting the operating system because of a faulty Ethernet
controller is too drastic. The operating system should simply
report the problem and recover as gracefully as it can.
REPEAT BY:
You must have a 3Com Ethernet board that malfunctions in the proper way.
_______________________________________________________________________________
vaxif/if_en.c--sys Jeff Mogul <mogul@coyote> 27 Feb 84 +FIX
The enswab() routine included with if_en.c in 4.2 has my name
on it, but it is NOT what I wrote and it does not work.
Presumably, it was more important for it to pass lint than
for it to work. Also, the routine should be careful about
bogus lengths.
REPEAT BY:
Compile your kernel with SWABIPS turned on and try to use the
3mb interface.
Remark:
The right way to handle this interface is to byteswap all packets
on input and output, since the interface itself byteswaps all
packets (thus the two swaps cancel out.) So, SWABIPS should really
be UNSWABEN, or something like that.
_______________________________________________________________________________
vaxif/if_il.c--sys Jay Lepreau <lepreau@utah-cs> 13 May 83 +FIX
After a ubareset, all the packets sent by that host get thrown out
in ilrint() with a bad type field. Turns out that the interlan
goes into "insert source address" mode after the ubareset.
Evidently the CISA cmd in ilinit() does not work if the device
is ONLINE. From inspection of current code on monet this is
still a problem in 4.1c.
REPEAT BY:
Issue a resuba() call. ruptime shows all hosts up execpt for
this one. Etc.
_______________________________________________________________________________
vaxif/if_il.c--sys guest@ucbarpa (Guest Account) 18 Jun 84
malfunctioning Interlan ethernet board can hang Unix
_______________________________________________________________________________
vaxif/if_pcl.c--sys Jeff Schwab <jrs@Purdue.ARPA> 25 May 84 +FIX
The pcl-11 network driver has some timing problems with
re-initialization after error conditions. The driver is not
truely at fault, the device does not reset quickly enough
when an INIT is issued after a device error. The code needs
juggling for error recovery and there is a small typo
in setting up the receive control register.
REPEAT BY:
Have some hardware errors. Eventually the timing problem will
hit and you will continuously receive/send errors.
_______________________________________________________________________________
vaxif/if_uba.c--sys salkind@nyu (Lou Salkind) 13 Mar 84 +FIX
There are two problems in if_uba.c:if_wubaput:
(1) there is a superfluous instruction
(2) the variable x is used for two different purposes in if_wubaput.
This will cause transfers of two full clicks or more to fail.
(Luckily the network interfaces don't do this currently.)
REPEAT BY:
Transfer 2K packets over your network device...
_______________________________________________________________________________
vaxif/if_uba.c--sys Jeff Schwab <jrs@Purdue.ARPA> 8 Aug 84 +FIX
It has been pointed out to me (in a most embarrassing fashion)
that my previous fixes for handling uba allocation when then
local network hlen is 0 where not complete. I ended up treating
the disease rather than the problem. The corrected fix requires
the same changes to if_ubainit() as before, but the change to
if_rubaget() should be replaced by a more proper fix to the
mr assignment in if_ubaalloc().
REPEAT BY:
The pcl-11 is such a device. If you raise the mtu on the
device from the default 1006 to anything greater than
1024, your network will be unusable.
_______________________________________________________________________________
vaxif/if_uba.c--sys Jeff Schwab <jrs@Purdue.ARPA> 25 May 84 +FIX
If a local network interface has an hlen of 0, the routines
in if_ubainit() allocate spurious pages and the if_rubaget()
routine will exchange the wrong page when handling a packet
greater than 1024 bytes long.
REPEAT BY:
The pcl-11 is such a device. If you raise the mtu on the
device from the default 1006 to anything greater than
1024, your network will be unusable.
_______________________________________________________________________________
vaxif/if_vv.c--sys rws@mit-bold (Robert W. Scheifler) 22 Nov 83 +FIX
The V2LNI driver doesn't set up for broadcast correctly, and
doesn't take advantage of the loopback-net.
REPEAT BY:
Try running rwhod (for broacast) and rlogin to self (for loopback).
_______________________________________________________________________________
vaxmba/hp.c--sys Doug Kingston <dpk@brl-vgr> 29 Sep 83
The unix.generic and unix kernels I generated for a 750
with RH750 and two RM05's incorrectly identified the second
RM05 as a CDC 9775. Drive 0 was correctly identified.
REPEAT BY:
Boot 4.1c on a 750 with RH750 and 2 RM05's.
_______________________________________________________________________________
vaxmba/hp.c--sys Mike Muuss <mike@brl-vgr> 23 Aug 83 +FIX
There is a bug in the distributed (4.1c) CDC 9775 partition table.
The original table claims 843 cylinders, numbered 0..842, but
the device actually only possesses 842 cylinders, numbered
0..841.
REPEAT BY:
Try to read the "bad block" table with bad144.
We encountered the problem with FORMAT(8v), with
9775 disks on a up (Emulex SC21) formatter -- it couldn't write
the bad block table.
FIX:
The fix to the sizes[] table is:
1077760, 0, /* C=cyl 0 thru 841 */
377600, 547, /* F=cyl 547 thru 841 */
701440, 294, /* G=cyl 294 thru 841 */
Also, remember to fix the entry in /etc/disktab.
Change the nc#843 to nc#842.
Enjoy!
-Mike
_______________________________________________________________________________
vaxmba/hp.c--sys weltyrp%rpi@CSNet-Relay 5 Dec 83
In some cases DEC rm03 and rm05 drives may be misidentified by
the code in hpattach as a non-DEC drive on a non-DEC
controller. This problem appears in most parts of the system
that have to identify a drive, including the COPY and FORMAT
programs on the distribution floppy.
REPEAT BY:
The problem will occur with any rm03 or rm05 whose serial
number maps to one of the ones that is used to detect Systems
Industries controllers and drives.
FIX:
If there are no systems industries drives on a system, then the
code that identifies such drives can be removed without harm
(which is what we did, as we don't plan to ever use SI
controllers). If there is a mix of drive types, then the fix
will be much more complex.
_______________________________________________________________________________
vaxmba/ht.c--sys dlw@UCBTOPAZ.CC (David L. Wasley) 6 Aug 83 +FIX
There is a bug in the ht driver that causes UNSafe to be set.
This causes a subsequent operation on ANY drive to abort.
REPEAT BY:
Attempt to open a drive not on-line. Attempt to do anything
subsequent to that drive or any other drive.
FIX:
Remove the following lines from ht.c:htcommand().
I show them commented out.
/* This causes UNS to be set if !MOL, and is unnecessary!
* if (bp == &chtbuf[HTUNIT(bp->b_dev)] && bp->b_command == HT_SENSE) {
* htaddr->htcs1 = HT_SENSE|HT_GO;
* mbclrattn(mi);
* }
*/
David Wasley
_______________________________________________________________________________
vaxmba/mt.c--sys mazama!stew (Stewart Levin) 6 Jan 84
These bugs were originally discovered in the 4.1BSD mt.c driver
and are still in the 4.2BSD version:
1) Reverse reads are handled improperly. These are called for
by the TU78 READOPP error retry sequences (i.e. when you
see the tape drive wig/wagging back and forth over a dirty
tape record. What the tape driver is supposed to do in this
case (and I even got a written letter from DEC detailing this!)
is
a) Use record count from mtca (tape control) register to dequeue
any records that were correctly transferred. Load record count
with 0.
b) Byte count from mtbc (byte count) register is TM78's best
guess of actual record length. This value should be taken as
gospel and loaded into the MBA byte count register (two's
complemented). If record does not fit in buffer, compute
number of word for data channel to skip (mtca skip count) or
give up and return I/O error.
c) Load the MBA virtual address register with the map register
pointer and starting memory address (physical byte offset).
If the last operation was a reverse read then the TM78 has
requested us to do a forward read and we load these just as
for a normal forward read command. If the last operation was a
forward read then the TM78 has requested us to read reverse and
the starting address is the read forward normal starting address
PLUS THE NUMBER OF BYTES TO BE READ MINUS ONE.
d) Load the starting (and successive) map register(s) with physical
page address(es).
e) Set MBA control register interrupt enable.
f) Load the mtcs control register with the function code octal
071 (MT_READ|MT_GO) for a forward read or octal 077 for a
read reverse (MT_READREV|GO).
As you may have guessed, the present driver does NOT load
the virtual address register correctly. The result is that
reverse reads store their data IN FRONT OF THE BUFFER FOR WHICH
IT IS INTENDED. This generally continues until offset 0 of
the page mapping the beginning of the buffer is reached.
In the worst case this overwrites critical data areas and crashes
the system. In more benign settings one gets erroneous data
(dd exhibits "stuttering records" where some part of a record
ends up repeated).
The driver also mishandles read opposite requests by squirreling
away the byte count from b) above in the buffer header and never
retrieving it to compute the correct residual byte count to return
to the user when the retry is successful.
2) The driver signals EOT on writes one record too early by returning
EOF upon data transfer interrupt code 04 (Write operation success-
fully completed beyond EOT marker) rather than on initiation of
the next write operation.
REPEAT BY:
I wish I knew! We found it by reading old tapes until the problem
occurred. We finally found one tape that repeated the retry sequence
consistently on a few records.
FIX:
We have kludged around the problem by commenting out the READOPP
dtint() case causing mt.c to fall through to signal the default
hard I/O error instead.
_______________________________________________________________________________
vaxmba/mt.c--sys Jeff Mogul <mogul@Gregorio> 17 Aug 84 +FIX
If a TU78 tape drive on a TM78 formatter is reading a tape and
cannot completely read a record in the forward direction, it
may interrupt the CPU with an interrupt code of "READ OPP". This
means that the drive has been positioned at the end of the record,
the byte count register has been loaded with the length of the
record, and the CPU should initiate a "Read Opposite" transfer
in an attempt to read the record in the reverse direction.
The DEC technical manual for the TM78 is not too clear on the
subject, but a direct communication with DEC reveals that the
proper sequence in this case is:
(1) Load mtca with SER=1 (Suppress Error Repositioning) and the
drive unit number; all other fields should be 0.
(2) Load the MBA byte count register in the usual way
(3) Load the MBA virtual address register with the map register
pointer and physical byte offset for the *last* byte
in the buffer, unlike the usual case.
(4) Load the drive control register with the MT_READREV code
The mt.c driver supplied with 4.[12]BSD has code to try to handle
this, but this code does not do step (1) or (3) properly. It
fails to set the SER bit in mtca (probably a minor bug), but
it gets step (3) wrong because there is no way to do it right.
This is because the MASSBUS driver (mba.c) does not support
"backwards" DMA; i.e, there is an assumption built into the code
of mbasetup() that the buffer address is always the start of the
buffer.
What actually causes a panic, though, is a little subtler. The
drive returns the total length of the tape record, to be used
as the byte count for the Read Opposite. However, if the
buffer supplied by the user is shorter than the tape record,
when the code in mt.c blindly sets the b_bcount field longer
that the size of the buffer it causes a panic (probably
"mba, zero entry" but I forget exactly which one) if the buffer
is near the end of the user's address space. (I suspect there
may be other ways this code could create havoc.)
I'm not sure there is any reasonable way of doing the Read
Opposite, in the general case, since it might require the driver
to reposition the tape within a record if the user's buffer is
not large enough.
REPEAT BY:
This is hard to repeat, since it requires a tape that is bad
in a way that I don't entirely understand. However, I have
found one tape that will reliably crash our 4.1 system. The
tape is written with 8000 byte blocks; reading it with
dd if=/dev/rmt4 of=/dev/null ibs=1600
causes the panic, presumably because the driver tries to
Read Opposite 8000 bytes into a 1600 byte buffer.
Examination of the mt.c code should suffice to convince one
that the bug exists.
_______________________________________________________________________________
vaxmba/mt.c--sys decvax!dartvax!steve (Steve Campbell) 22 Feb 84
If there are two (dual-ported) TM78 tape formatters, each
with one TU78 transport attached, on the MASSBUS, only
the first can be used. Autoconfig seems to find both
formatters and transports, but i/o operations to the second
will fail.
REPEAT BY:
Configure a 750 as above, mount a scratch tape on both
transports, set port select switches appropriately, and try
mt -f /dev/mt? status. For mt0 you get the expected status
message. For mt1 you get "mu0: not online." Routine mtopen
has failed.
_______________________________________________________________________________
vaxmba/mt.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
Redundant code in non-data-transfer interrupt handler is
occupying space and slowing the CPU.
REPEAT BY:
Examine code in mtndtint() in mt.c.
FIX:
Remove the following two lines of code near the beginning of
the mtndtint() routine:
if (bp == 0)
return (MBN_SKIP);
If you read the preceding code in the routine, it will be evident
that the condition of the aforementioned "if" test will always
be false.
Submitted-By:
Rick Ace, New York Institute of Technology, (516) 686-7644
_______________________________________________________________________________
vaxuba/d[hz].c--sys jbc <ut-ngp!jbc> 15 Jun 83 +FIX
The TIOCCDTR ioctl, used to clear the DTR bit, does
not perform suitable permission checking.
For example, if a terminal device can be opened for
writing by a process in a group other than that
of the device, that process can then force DTR low
on that terminal line. While some processes are only
mildly susceptible to having random garbage written
to the terminal, they may be extremely vulnerable to
the logout which results from loss of DTR on a
typical dialup.
TIOCCDTR, and, less importantly, TIOCSDTR, should
return error if the file descriptor passed in the
ioctl does not refer to the controlling terminal
for the process which invokes the ioctl and the
uid is not superuser.
REPEAT BY:
#include <sys/file.h>
#include <sgtty.h> /* or whatever */
#define error( s ) {perror( (s) ); exit( 1 );}
main( argc, argv )
int argc;
char *argv[];
{
register int fd;
if ( (fd = open( *++argv, FWRONLY )) < 0 )
error( *argv );
if ( ioctl( fd, TIOCCDTR, 0 ) < 0 )
error( "TIOCCDTR" );
exit( 0 );
}
Now, suppose that someone is logged in on /dev/ttyxx, where
/dev/ttyxx is a dialup line. Execution of the above program
as in, say,
a.out /dev/ttyxx
will typically result in termination of the user's login process.
_______________________________________________________________________________
vaxuba/dh.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
If dhparam() sets the input speed of a DH11 line to zero, it returns
to its caller at an elevated IPL. This can cause unnecessary
blockage of device interrupts.
REPEAT BY:
Examine code in dh.c.
FIX:
Before the first "return;" statement in dhparam(), add the line
splx(s);
Submitted-By:
Rick Ace, New York Institute of Technology, (516) 686-7644
_______________________________________________________________________________
vaxuba/dh.c--sys salkind@nyu (Lou Salkind) 27 Jan 84 +FIX
If the soft carrier flag for a dh line is set (dhsoftCAR), and a
dm modem interrupt occurs on the line, the TS_CARR_ON flag may be
cleared. This causes future reads/writes to the terminal to return
EIO.
REPEAT BY:
On a line with modem control, bring down DTR to force a modem
interrupt. (This really can happen!)
_______________________________________________________________________________
vaxuba/dh.c--sys astrovax!wls (William L. Sebok) 5 Mar 84 +FIX
If the soft carrier flag for a dh line is set (dhsoftCAR), data terminal
ready (DTR) will never be set on open. Thus, terminals (or modems)
which require DTR will not work.
REPEAT BY:
Connect a terminal or modem which requires DTR to a line with modem
control which has dhsoftCAR set. The device will not operate.
_______________________________________________________________________________
vaxuba/dmf.c--sys lbl-csam!astrovax!matt (Matt Crawford) 2 Feb 84
The dmfprobe() routine doesn't check for existence of the device,
it just returns a "yes" in all cases. This means if you configure
your dmf's as being on "uba?" and they are not actually on uba0,
they will never be found.
REPEAT BY:
Obvious.
FIX:
Unless there's a reliable way to force an interrupt one must always
specify the uba number explicitly, contrary to the dmf entry in
chapter 4 of the manual.
_______________________________________________________________________________
vaxuba/dmf.c--sys Tim Morgan <morgan@uci-750a> 3 Oct 84 +FIX
The dmf driver does not contain code to wake up processes which
are select'ing on output.
REPEAT BY:
Log onto a terminal on a dmf32 or clone. Telnet to any system,
including the local one. Run something on that system which will
produce lots of output (such as cat'ing /etc/termcap). After a
few hundred characters, the output will stop. It will not start
again until you type something. Telnet is waiting until the output
buffer empties to write more, but the dmf driver never does a
selwakeup() call, so the select() call never returns unless something
else occurs, such as a character in the input buffer.
_______________________________________________________________________________
vaxuba/dmf.c--sys lbl-csam!astrovax!matt (Matt Crawford) 17 Jan 84
When dmf.c is compiled with "-DDMFDMA" flag, there are two undefined
variables found in line 550: "car" and "dmf". Line 550, and the
sccs id line appear below:
/* dmf.c 6.1 83/07/29 */
car = UBACVT(tp->t_outq.c_cf, dmfinfo[dmf]->ui_ubanum);
REPEAT BY:
See above.
FIX:
I think the following two lines added after line 547 ("#ifdef DMFDMA")
will fix this problem. Please tell me whether it is correct, as I
have not tried to run a system with this included yet.
u_short car;
int dmf = minor(tp->t_dev) >> 3;
_______________________________________________________________________________
vaxuba/dz.c--sys koda@hobgoblin (Jim Koda) 22 Feb 84 +FIX
the spl5() in dztimer can actually lower the IPL and can cause
random failures. In particular, suppose the hardclock routine
(IPL 18) is called during servicing of a ethernet interrupt on
the 3com board (IPL 16) when the hardclock routine calls dztimer
it promptly does a spl5() lowering IPL to 15. Thus another
ethernet interrupt can occur and its all over.
REPEAT BY:
With sufficient dz and ethernet traffic, random panics in the
dz or 3com drivers will occur.
_______________________________________________________________________________
vaxuba/d{h,mf,z}.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
The TIOCLSET ioctl can affect the LITOUT bit of the t_flags word.
The setting of the LITOUT bit determines whether the DMF/DH/DZ
will operate in 8-bit mode or in 7-bit/parity mode, so it is
therefore appropriate that dmfparam()/dhparam()/dzparam() be
called during the driver's processing of the TIOCLSET call.
The DMF32, DH11, and DZ11 drivers all fail to do this.
REPEAT BY:
Issue a TIOCLSET ioctl to a DMF, DH, or DZ terminal and note that
the hardware does not switch between 8-bit mode and 7-bit/parity mode.
_______________________________________________________________________________
vaxuba/idc.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
On a Vax-11/730, when the R80 disk requires ECC error recovery,
the idcecc() routine is called. This routine makes a
reference to the UBA page map. The type of reference is
apparently unacceptable to the 730, and it lets you know in
no uncertain terms via Machine Check 9 "nonlw ioref" and,
ultimately, a crash.
REPEAT BY:
Not quite sure... must enter the ECC code in the IDC driver.
_______________________________________________________________________________
vaxuba/lp.c--sys Steve Campbell 8 Jun 84
MAKEDEV assigns sequential minor device numbers - 0,1,2,... - to
lp devices lp0, lp1, lp2, etc. The driver, however, determines
the unit address by shifting the minor device number >> 3, using
the 3 low-order bits for software flags. Hence the driver
wants minor device numbers 0,8,16,etc.
REPEAT BY:
Configure two line printers, lp0 and lp1. MAKEDEV will give
them minor device numbers 0 and 1. Lp0 will work ok, but
if you use lp1, the driver still sends the data to lp0. What's
more, the data will be mapped to upper case, since the "1"
bit is treated as a "map-to-upper" flag by the driver.
FIX:
Take your pick: either hack MAKEDEV to generate the right minor
device numbers for lp's, or fix the driver to use regular,
sequential, minor device numbers and do the flags another way.
Steve Campbell
UUCP: {decvax|linus|cornell|astrovax}!dartvax!steve
CSNET: steve@dartmouth ARPA: steve%dartmouth@csnet-relay
_______________________________________________________________________________
vaxuba/lp.c--sys hplabs!tymix!feldman (Steve Feldman) 29 May 84 +FIX
If the timer interrupt goes off and there has been no activity
in the last few seconds, the timer routine will stop sending
if the device has been closed, even if characters still remain
in the output buffer. This can be a problem on slow devices,
such as our laser printer.
REPEAT BY:
Get yourself a slow laser printer, and print a lot of small
things. Sometimes the last page of a job won't appear until
the next one starts up.
_______________________________________________________________________________
vaxuba/rl.c--sys Jeff Mogul <mogul@coyote> 26 Mar 84 +FIX
If your system includes an RL02 drive (not that they are
all that useful) but the drive is not loaded when the system
is booted, the configuration procedure does not recogniz the
drive and it cannot be used until the system is rebooted.
Since the RL02 is a removable pack, and a darn small one at
that, it's unpleasant to have to have a pack loaded whenever
you boot the machine.
The problem is that the distributed RL02 driver checks for
a ready-to-use, loaded pack instead of simply checking that
the drive is there. This is probably being done because
(as a comment in the code notes) the "Get Status" operation
may return invalid data. Presumably, the author felt that if
the status is "all set to use", then it's valid.
REPEAT BY:
(You need a system with an RL02 that is NOT the root drive).
Unload the RL02, reboot your system.
Once it is running, load the RL02. You won't be able to
use it for anything.
_______________________________________________________________________________
vaxuba/rl.c--sys Jeff Mogul <mogul@Gregorio> 14 Jun 84 +FIX
Disk drive partition tables are supposed to have 8 entries.
The table in the RL02 driver has 7; partition E was left out
and so the sizes for F, G, and H are shifted to the previous
partition
REPEAT BY:
Try to write something on the G partition
_______________________________________________________________________________
vaxuba/uba.c--sys Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX
System crashes when UBA reset is attempted (panic: Segmentation
fault). This is because someone put in half a change to the
way the cdevsw table is searched; it used to end with a null open
routine pointer, but got changed to have its number of entries
defined instead (nchrdev). However ubareset() wasn't changed,
so it falls off the end of the table and calls random mung.
REPEAT BY:
Force a UBA reset somehow. Watch system crash.
_______________________________________________________________________________
vaxuba/uda.c--sys lbl-csam!astrovax!matt (Matt Crawford) 1 Dec 83 +FIX
If there is no drive with unit number 0 on a uda controller the
driver never recognizes the response to the "set controller
characteristics" command, because that packet always has
mscp_unit == 0 and the udip[][] entry for the controller and
unit is checked before the type of the packet.
REPEAT BY:
Try configuring the system with no disk at drive 0 on a uda
controller, and setting the unit plugs accordingly. DEC
installed our ra81's with plugs #1 and #2 and wouldn't give us
a spare plug.
FIX:
Here is a `diff uda.c.distributed uda.c.ourversion`:
================================================================
595a596,599
> #ifdef ASTROVAX
> if ((ui = udip[um->um_ctlr][mp->mscp_unit]) == 0 &&
> ((mp->mscp_opcode&0xff) != (M_OP_STCON|M_OP_END)))
> #else
596a601
> #endif ASTROVAX
================================================================
Matt Crawford (lbl-csam!astrovax!matt)
University of Chicago
Astronomy and Astrophysics Center
5640 S. Ellis
Chicago, IL 60637
_______________________________________________________________________________
vaxuba/ut.c--sys ihnp4!dicomed!boylan (Chris Boylan) 4 Jun 84 +FIX
Variable is initialized in wrong spot, causing intermittent
segmentation violations.
REPEAT BY:
Look at any other Unix UNIBUS driver for conformation or
write large amounts of data to the cooked device.
FIX:
/* ut.c 6.1 83/07/29 */
Line 248 is out of place it should be before
the if (...) {, not in it. The line:
um = tjdinfo[tjunit]->ui_mi;
_______________________________________________________________________________
vaxuba/{dn,lp,rl,uu}.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX
Coding oversight in several UNIBUS device drivers. The unifind()
routine in autoconf.c expects to find the standard address list in
each driver terminated by a zero entry. The drivers dn.c, lp.c,
rl.c, and uu.c do not satisfy this requirement.
REPEAT BY:
Examine code in aforementioned drivers.
_______________________________________________________________________________
vgrind/tmac.vgrind--ucb sdcrdcf!glenn (Glenn C. Scott) 28 Sep 84 +FIX
Vgrind (actually /usr/lib/tmac/tmac.vgrind) doesn't understand the
convention to place even numbered page numbers on the left side of
the page and the odd numbers on the right side of the page.
REPEAT BY:
Vgrind a program source that would use more than one page of
output. Look at the page numbers.
FIX:
Change the file tmac.vgrind to print even numbers on the left
and odd numbers on the right.
*** /usr/lib/tmac/tmac.vgrind (old) Tue Aug 21 15:58:29 1984
--- /usr/lib/tmac/tmac.vgrind (new) Fri Sep 28 14:13:57 1984
***************
*** 25,31
'de vF
'ev 2
'sp .35i
! 'tl '\f2\\*(=M''Page % of \\*(=G\fP'
'bp
'ev
'ft 1
--- 25,32 -----
'de vF
'ev 2
'sp .35i
! 'ie o 'tl '\f2\\*(=M''Page % of \\*(=G\fP'
! 'el 'tl '\f2Page % of \\*(=G''\\*(=M\fP'
'bp
'ev
'ft 1
_______________________________________________________________________________
vgrind/vfontedpr.c--ucb wayne@lbl-csam 12 Sep 84 +FIX
When running vgrind with multiple files the last page of the
current file gets the date from the next file.
REPEAT BY:
Run vgrind with two files that have different modify dates.
FIX:
It seems vfontedpr is reseting the date before the last .bp, moving the
.ds past the last .bp seems to fix this. Heres a diff file of the change;
261a262
> printf(".ds =M %s %s\n", cp+4, cp+20);
269,271d269
< }
< if (!filter) {
< printf(".ds =M %s %s\n", cp+4, cp+20);
_______________________________________________________________________________
vgrind/vgrindefs.src--ucb ucsfcgl!arnold (Ken Arnold) 25 Sep 84 +FIX
"void" is a keyword in C, and vgrind doesn't know it.
REPEAT BY:
Find a program which uses the (void) type cast. Vgrind it.
Look at the output. Notice that "void" is not in bold
font. Realize that this is incorrect. :->
FIX:
Add "void" to the list of keywords in ucb/vgrind/vgrindefs.src.
Install /usr/src/ucb/vgrind/fbrindefs.src in /usr/lib/vgrinddefs
by typing "make install".
_______________________________________________________________________________
vi--ucb mls@wisc-crys.arpa (Michael Scott) 7 Sep 84
The :tag (^]) command will turn magic off if the tags file gives it
a pattern to search for and the search fails.
REPEAT BY:
Make an entry in a tags file for 'foo' with a search pattern that
does not exist. Type :set magic. Type :tag foo. Type :set all.
Nomagic will be set.
_______________________________________________________________________________
vmstat.c--ucb mazama!stew (Stewart Levin) 22 Mar 84 +FIX
After we employed the kgclock (adapted to our ancient AR11) driver
to gather I/O and profiling samples, some of the numbers given by
vmstat were off by a factor of 10. As we were running the external
clock at 10HZ and the internal clock runs at 100HZ, it was easy to
find the cause. vmstat (and iostat) were not reading the "phz"
variable from the kernel's namelist and simply assuming it identical
to the kernel's "hz" variable.
REPEAT BY:
Collecting samples using an external clock set to other than 100HZ.
FIX:
Read both "phz" and "hz" from /dev/kmem and use the former sampling
rate if it is nonzero. Be aware, however, that it may not have been
calibrated correctly. kgclock supposedly counts the number of external
clock interupts occurring over a four second interval as measured using
the system clock. However when we looked at phz (using adb) it was 3
not 10! We cured the problem by explicitly initializing all relevant
variables to zero on entry to the startkgclock() routine. I can't
say for sure why it fixed the bug, but either an unitialized variable
was the culprit or the system modifies its idea of the time between the
kgprobe() and startkgclock() calls.
_______________________________________________________________________________
vmstat.c--ucb cbosgd!mark (Mark Horton) 2 Jun 83 +FIX
The number "60" (indicating 60 ticks/second) is hardcoded into
the vmstat program. (I wouldn't be surprised to find it in
iostat and maybe ps, too.) Now that you're running at 100
ticks/second, the numbers based on etime (e.g. number of disk
I/O's per second) are low by a factor of 6/10. It's interesting
to note that, while our disks got about 25 TPS in 4.1, with
4.1c the same disks seem to peak out at 12-13 TPS (vmstat numbers).
This bug accounts for much of this, raising the numbers to about 20.
However, the number is still smaller than the 30 your document claims.
REPEAT BY:
"vmstat 5" will show disk numbers that are too low.
FIX:
In vmstat.c, change
etime /= 60.;
to
etime /= 100.;
or better yet, get the number 100 from some more global place,
like the kernel or an include file.
I found this while developing a CRT oriented program called sysmon
which essentially does a "ps axv" every 30 seconds and a "vmstat 10",
plus displaying lots more info (which the kernel keeps track of but
vmstat doesn't have room in 1 line to print) as well as the load
average and the date. All this and it puts a much lighter load on
the system (4-5% of a 750) - the speed comes from only having to do
the kernel poking (namelist lookup, reading /dev, and other overhead)
once, not every 10 or 30 seconds. I'm still working on sysmon, but
I'll be happy to send it to you if you want to use/include it.
Rather than cutting up vmstat and ps, I put ifdefs into the sources,
so the program can survive future memory management changes.
Mark
_______________________________________________________________________________
vtroff--ucb jimbo@ucbic (Jim Kleckner) 11 Oct 83 +FIX
" cat foo | vtroff -me - " will fail. The "-" will be
read as an option and then troff will read standard input
before the font width tables. Vtroff appends another "-"
since it thinks that the file is missing (and is not).
REPEAT BY:
try the above.
FIX:
add the following case to the switch:
....
case -: # This line matches the stdin arg.
breaksw
case -*:
....
_______________________________________________________________________________
which.csh--ucb !garfield!andrew@BERKELEY (Andrew Draskoy) 17 Jan 84 +FIX
The which csh script won't tell you if a command is an alias,
and will not read the path from the .cshrc as documented. This
is because it is exec'd with "csh -f", which does not read in the
.cshrc file.
REPEAT BY:
Type "which xxx", where xxx is any alias defined in your .cshrc
If the bug is present, "which" will not tell you that it is an
alias.
FIX:
Take the "-f" out of the top line of the script.
_______________________________________________________________________________
whois--man jsq@ut-sally.ARPA (John Quarterman) 12 Jan 84 +FIX
There was no manual entry for the whois command.
REPEAT BY:
man whois
FIX:
Here's a man entry:
.\" @(#) whois.1 1.2 84/01/12
.TH whois 1 84/01/12
.UC 4
.SH NAME
whois \- DARPA Internet user name directory service
.SH SYNOPSIS
.B whois
name
.SH DESCRIPTION
.TP
whois help
Produces a helpful message similar to the following:
.PP
Please enter a name or a handle ("ident"), such as "Smith"
or "SRI-NIC".
Starting with a period forces a name-only search;
starting with exclamation point forces handle-only.
Examples:
.nf
Smith [looks for name or handle SMITH ]
!SRI-NIC [looks for handle SRI-NIC only ]
.Smith, John [looks for name JOHN SMITH only ]
.fi
Adding "..." to the argument will match anything from that point,
e.g. "ZU..." will match ZUL, ZUM, etc.
.PP
To have the ENTIRE membership list of a group or organization,
if you are asking about a group or org, shown with the record, use
an asterisk character "*" directly preceding the given argument.
[CAUTION: If there are a lot of members this will take a long time!]
You may of course use exclamation point and asterisk, or a period
and asterisk together.
.SH FILES
/usr/doc/local/netinfo/rfc812
.SH SEE ALSO
RFC 812: NICNAME/WHOIS
.SH DIAGNOSTICS
.SH BUGS
_______________________________________________________________________________
GENERAL INFORMATION ON THE 4.2 BUGLIST FROM MT XINU
_________________________________________________________________
--IMPORTANT DISCLAIMERS--
Material in this announcement and the accompanying reports
has been edited and organized by MT XINU as a service to the
UNIX community on a non-profit, non-commercial basis. MT
XINU MAKES NO WARRANTY, EXPRESSED OR IMPLIED, ABOUT THE
ACCURACY, COMPLETENESS, OR FITNESS FOR USE FOR ANY PURPOSE
OF ANY MATERIAL INCLUDED IN THESE REPORTS.
MT XINU welcomes comments in writing about the contents of
these reports via uucp or US mail. MT XINU cannot, however,
accept telephone calls or enter into telephone conversations
about this material.
_________________________________________________________________
Legal difficulties which have delayed the distribution of
4.2bsd buglist summaries by MT XINU have been resolved and
three versions of the buglist are now available.
The current buglist has been derived from reports submitted
to 4bsd-bugs@BERKELEY (not from reports submitted only to
net.bugs.4bsd, for example). Reports are integrated into
the buglist as they are received, so that any distributions
are current to within a week or so.
Buglists now being distributed are essentially "raw". No
judgment has been passed as to whether the submitted bug is
real or not or whether it has been fixed. Only minimal edit-
ing has been done to produce a manageable list. Reports
which are complaints (rather than bug reports) have been
eliminated; obscenities and content-free flames have been
eliminated; and duplicates have been combined. The result-
ing collection contains over 500 bugs.
Three versions of the buglist are now ready for distribu-
tion:
2-Liners:
Two lines per bug, including a concise description, the
affected module, the submittor. Approximately 55K
bytes, it is being distributed to net.sources con-
currently with this announcement.
All-but-Source:
All material, except that all but the most inocuous of
source material has been removed to meet AT&T license
restrictions. Nearly a mega-byte, this will be
distributed to net.sources in several 50K byte pieces
later this week.
A paper listing or mag tape is also available, see
below.
Please note that local usenet size restrictions may
prevent large files from being received and/or
retransmitted. MT XINU will not dump this material on
the net a second time; if your site has not received
material of interest to you within a reasonable time,
please send for a paper or tape copy.
All-with-Source (FOR SOURCE LICENSEES ONLY):
4.2 licensees who also have a suitable AT&T source
license can obtain a tape containing all the material,
including proposed source fixes where such were submit-
ted.
Once again, MT XINU has not evaluated, tested or passed
judgment on proposed fixes; all we have done is organ-
ize the collection and eliminate obvious irrelevancies
and duplications.
A free paper copy of the All-but-Source list can be obtained
by sending mail to:
MT XINU
739 Allston Way
Berkeley CA 94710
attn: buglist
or electronic mail to:
ucbvax!mtxinu!buglist
(Be sure to include your US mail address!)
For a tape, send a check for $110 or a purchase order for
$150 to cover MT XINU's costs to the address given above
(California orders add sales tax). For the All-with-Source
list, mail us a request for the details of license verifica-
tion at either of the above addresses.