isolated to revision 33 PNIC chips is also present in revision 32 chips.
Cards with rev. 32 chips include the LinkSys LNE100TX and the Matrox
FastNIC 10/100. This accounts for all the cards that I have to test
with.
(I was never able to personally trip the bug on this chip rev, but today
one of the guys in the lab did it with the software they're working on
for their cellular IP project, which uses BPF and promiscuous mode
extensively.)
This commit enables the promiscuous mode software workaround code for
both revison 32 and revision 33 chips. It's possible all of the PNIC
chips suffer from this bug, but these are the only two revs where I
know for a fact it exists.
The char that the random letters and numbers are being pulled from is
ended with a '\0'. Using sizeof() includes this '\0' in the 'pool' of
possible characters. This patch decrements by one the size so we don't
accidently end the new password prematurly.
so it can't be completely fixed here. Putting -I paths to the current
headers in CFLAGS is more likely to break things than fix them, since
there is no reason why current headers should work with old libraries.
Other Makefiles that do this may only work because they are not used early
in the bootstrap. However, the usual problem with errno being defined in
terms of a nonexistent library doesn't seem to occur here, since we don't
reference errno.
probably other versions by spamming ${DESTDIR}/usr/include in much
the same way as `make includes'.
Details for 2.2.7: the bootstrap target has always done a weak spam
of ${DESTDIR}/usr/include; we depend on it not installing any
significant anachronisms (it probably shouldn't touch the headers
at all; however, we may be depending on it for things like the
renaming of ts_nsec to ts_sec in <sys/time.h>). Rev.1.49 strengthens
the spam to everything in src/include. For 2.2.7, this is not
immediately fatal. However, the `make all' step in src/includes
is not followed by a `make clean' step, so new rpc headers are not
generated after we've bootstrapped rpcgen. This causes a fatal
error much later when the old (generated) rpc headers are used with
the current headers (sys/types.h and/or the non-generated rpc
headers).
Details for 2.1.x: the bug is immediately fatal. It gives definition
of errno that is not supported by 2.1.x's libc. The weak spam in the
restored version avoids this problem by not installing errno.h.
(Bootstrapping from 2.1.5 actually breaks much earlier.)
I think the header problems supposedly fixed by rev.1.49 were caused
by using NOCLEAN and having the build fall over when the weakly
spammed headers are active. Minor differences in the layout will
then cause the .depend files to point to nonexistent headers. It
is a feature for symlinks like errno.h -> sys/errno.h to not exist
early.
The other change in rev.1.49 breaks building obj directories if NOCLEAN
is set. It is only safe for _re_building with NOCLEAN set.
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.
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.
- Special registers of IO-DATA device's RSA series are defined in
ic/rsa.h (new file).
Pointed out by: Bruce Evans <bde@zeta.org.au>
Submitted by: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.ac.jp>
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.
Suggested by: bde (long time ago).
