chuckr [Mon, 4 Jan 1999 03:14:48 +0000 (03:14 +0000)]
Fix a build problem when upgrading from 9 month old sources. There's
a circular dependency problem, wherein rpcgen depends on the latest
includes, but those same includes depend on rpcgen to build
include/rpcsvc. This was causing the build or librpcsvc to fail
(like I said, only on upgrades of 9 month old sources).
If there's stylistic problems, tell me, I'll learn and fix them.
I did a buildworld with this, it should be safe.
mjacob [Sun, 3 Jan 1999 22:57:54 +0000 (22:57 +0000)]
Temporary workaround (bandaid) for case where you have READ
CAPACITY fail for a non-removable media device. There's a race
condition where the device entry is removed and then
xpt_release_ccb is called which attempts to give back the ccb
to a device that's now gone. In this bandaid release the ccb
early and then remember to not call xpt_release_ccb later.
jkh [Sun, 3 Jan 1999 02:18:58 +0000 (02:18 +0000)]
Clean up some more residual /usr/mdec references. I left all the
extra rbootd/boot rom cruft pointing at /usr/mdec since it either
doesn't exist or doesn't work anyway, so who cares? :)
wpaul [Sun, 3 Jan 1999 02:05:21 +0000 (02:05 +0000)]
Minor bug: in the case where allocating a fresh mbuf for the receive ring
fails, we need to set the descriptor status word so that the 'OWN' bit
is set again so that the chip can reuse it. Previously, this wasn't being
done.
wollman [Sun, 3 Jan 1999 00:35:31 +0000 (00:35 +0000)]
Fix grammar in the description of timegm() by totally rewriting it. Remove
a potentally inflammatory comment from BUGS, and add a more useful comment
about the lack of reentrancy in the timezone-setting interface.
Ensure that deHighClust in direntry always initialized.
Noticed by: Carl Mascott <cmascott@world.std.com>
Don't write access time of a file more than once per day. (Its precision is
1 day anyway). Don't try to write access and creation time in nonwin95 case.
billf [Sat, 2 Jan 1999 04:37:46 +0000 (04:37 +0000)]
Let's make sure we're at the end of the password string before we apply a \0
and terminate it. This patch ensures passwords will be the correct length of 8,
which is what is implied in the source (but not reflected in the man page).
billf [Fri, 1 Jan 1999 17:37:33 +0000 (17:37 +0000)]
Make periodic(8) and the security mailings reflect the full FQDN, as opposed
to a hostname. This will help those who keep a cluster of machines all with
the same hostname but different domain names.
PR: bin/9091
Submitted By: Heikki Suonsivu <hsu@clinet.fi>
No Response From: -current mailing list
bde [Fri, 1 Jan 1999 14:14:44 +0000 (14:14 +0000)]
Ignore the fs_spec entry for "/" in /etc/fstab if the device which
is actually mounted on "/" can be determined using statfs() and is
in /dev. This fixes fsck operating on the wrong device when the
fs_spec entry is only an alias. The aliased case became more
dangerous when the ROOTSLICE_HUNT hack was committed in mount(8).
ROOTSLICE_HUNT may be unnecessary now.
bde [Fri, 1 Jan 1999 13:15:02 +0000 (13:15 +0000)]
Fixed overflow in 1K-blocks to disk-blocks conversions. Use quad
arithmetic instead of the special macros in PR 8163 or the magic
2's in PR 381. (Rev.1.3 unfortunately fixed only half of the
problems reported in PR 381.)
bde [Fri, 1 Jan 1999 12:35:47 +0000 (12:35 +0000)]
The previous commit was bogus. malloc(..., M_WAITOK) should not be
used in device attach routines. At least for attaches at boot time,
actually waiting, or actually failing for malloc(..., M_NOWAIT), are
almost equally unlikely and harmless, but using M_WAITOK interferes
with automatic detection of bogus M_WAITOK's.
bde [Fri, 1 Jan 1999 10:14:37 +0000 (10:14 +0000)]
Made this compile if UMAPFS_DIAGNOSTIC is defined. This has been broken
since before rev.1.1, so UMAPFS_DIAGNOSTIC should not be trusted.
UMAPFS_DIAGNOSTIC is commented out in LINT to hide various bugs.
peter [Fri, 1 Jan 1999 08:18:13 +0000 (08:18 +0000)]
Part 2 of pcvt/voxware revival. I hope I have not clobbered any other
deltas, but it is possible since I had a few merge conflicts over the last
few days while this has been sitting ready to go.
(Part 1 was committed to the config files, but cvs aborted grrr..)
peter [Fri, 1 Jan 1999 08:09:58 +0000 (08:09 +0000)]
Part 1 of pcvt/voxware revival. I hope I have not clobbered any other
deltas, but it is possible since I had a few merge conflicts over the last
few days while this has been sitting ready to go.
dillon [Fri, 1 Jan 1999 04:14:11 +0000 (04:14 +0000)]
The mount_mfs process that stays in a supervisor context handling MFS
I/O requests must be marked P_SYSTEM because if it isn't and the system
decides to swap it or (god forbid) kill it, the system stands a good
chance of locking up.
wpaul [Thu, 31 Dec 1998 17:19:21 +0000 (17:19 +0000)]
This commit adds a software workaround for a hardware bug in certain PNIC
chip revisions. (A buggy taiwanese chip? I'm just shocked; shocked I tell
you.) So far I have only observed the anomalous behavior on board with
PCI revision 33 chips. At the moment, this seems to include only the
Netgear FA310-TX rev D1 boards with chips labeled NGMC169B. (Possibly this
means it's an 82c169B part from Lite-On.)
The bug only manifests itself in promiscuous mode, and usually only at
10Mbps half-duplex. (I have not observed the problem in full-duplex mode,
and I don't think it ever happens at 100Mbps.) The bug appears to be in
the receiver DMA engine. Normally, the chip is programmed with a linked
list of receiver descriptors, each with a receive buffer capable of holding
a complete full-sized ethernet frame. During periods of heavy traffic
(i.e. ping -c 100 -f 8100 <otherhost>), the receiver will sometimes appear
to upload its entire FIFO memory contents instead of just uploading the
desired received frame. The uploaded data will span several receive
buffers, in spite of the fact that the chip has been told to only use
one descriptor per frame, and appears to consist of previously transmitted
frames with the correct received frame appended to the end.
Unfortunately, there is no way to determine exactly how much data is
uploaded when this happens; the chip doesn't tell you anything except the
size of the desired received frame, and the amount of bogus data varies.
Sometimes, the desired frame is also split across multiple buffers.
The workaround is ugly and nasty. The driver assembles all of the data
from the bogus frames into a single buffer. The receive buffers are always
zeroed out, and we program the chip to always include the receive CRC
at the end of each frame. We therefore know that we can start from the
end of the buffer and scan back until we encounter a non-zero data byte,
and say conclusively that this is the end of the desired frame. We can
then subtract the frame length from this address to determine the real
start of the frame, and copy it into an mbuf and pass it on.
This is kludgy and time consuming, but it's better than dropping frames.
It's not too bad since the problem only happens at 10Mbps.
The workaround is only enabled for chips with PCI revision == 33. The
LinkSys LNE100TX and Matrox FastNIC 10/100 cards use a revision 32 chip
and work fine in promiscuous mode. Netgear support has confirmed that
they "have some previous knowledge of problems in promiscuous mode" but
didn't have a workaround. The people at Lite-On who would be able to
suggest a possible fix are on vacation. So, I decided to implement a
workaround of my own until I hear from them. I suppose this problem made
it through Netgear's QA department since Windows doesn't normally use
promiscuous mode, and if Windows doesn't need the feature than it can't
possibly be important, right? Grrr.
abial [Thu, 31 Dec 1998 14:03:28 +0000 (14:03 +0000)]
Add support for some FACILITY words:
key? ( -- flag) \ check to see if there's a key to be read from input
ms ( u -- ) \ wait that many milliseconds
seconds ( -- u ) \ get number of seconds from midnight.
'words' now outputs the list page by page - this probably should go
through libstand's pager, but will have to wait for closer integration of
built-ins with Forth...
Submitted partially by: W Gerald Hicks <wghicks@bellsouth.net>
luigi [Thu, 31 Dec 1998 08:14:27 +0000 (08:14 +0000)]
Add Joachim Kuebart's ES1370 driver. With my Shuttle HOT-255 card,
this has a problem with capture but i am not sure if it is related
to the mixer or what else.
But in the meantime, this is ok to listen to mpegs.
I also have a much simpler version of the driver in the works which
reuses a lot more of the existing "pcm" routines. Next year...
luigi [Thu, 31 Dec 1998 07:43:29 +0000 (07:43 +0000)]
Partial fix for when ipfw is used with bridging. Bridged packets
have all fields in network order, whereas ipfw expects some to be
in host order. This resulted in some incorrect matching, e.g. some
packets being identified as fragments, or bandwidth not being
correctly enforced.
NOTE: this only affects bridge+ipfw, normal ipfw usage was already
correct).
jkh [Thu, 31 Dec 1998 02:35:43 +0000 (02:35 +0000)]
Eliminate all dependence on boot1 and boot2. This is passed in by
Set_Boot_Blocks() anyway and should thus have never been a part of
libdisk, it should have been provided by the client of libdisk since
passing the information in is already part of the API.
hoek [Wed, 30 Dec 1998 17:32:47 +0000 (17:32 +0000)]
-make clear need to use the upgrade kit
-add "depends" to list of recursive targets
-consistent capitilization of FreeBSD.ORG
-remove description of PATCH_DEBUG
-add .Xr to portcheckout(1) and pib(1)
dfr [Wed, 30 Dec 1998 10:38:59 +0000 (10:38 +0000)]
Various changes to support OSF1 emulation:
* Move the user stack from VM_MAXUSER_ADDRESS to a place below the 32bit
boundary (needed to support 32bit OSF programs). This should also save
one pagetable per process.
* Add cvtqlsv to the set of instructions handled by the floating point
software completion code.
* Disable all floating point exceptions by default.
* A minor change to execve to allow the OSF1 image activator to support
dynamic loading.