of the Broadcom BCM5201 PHY on the LinkSys USB100TX adapter so that the
link LED correctly (lights up amber for 10mbps link, green for 100mbps
link).
Note that the sticker on the bottom of the adapter says amber for 10
and green for 100, but the appendix in the manual that comes with
the adapter says green for 10 and amber for 100. Given that there doesn't
seem to be any way to make the hardware produce the latter combination,
I think it's safe to say the sticker is right and the manual is wrong.
I'm just shocked, shocked I tell you.
of 4 longs used as a bitmask. sv4r4_sigfillset has been broken for a
while, probably since rev 1.5.
This patch fixes SVR4_NSIG (i.e.: sets it to the actual number of signals,
instead of the number of bits in the mask) because some SysVR4 clients
honestly seem to care about whether bits in the signal mask are set for
non-existant signals.
Additionally, the svr4_sigfillset macro has been replaced by a
fully fledged function, because the macro didn't actually work
(it returned an all-ones mask, but we don't want that: we want 0's
set where FreeBSD doesn't actually have a signal which is the same
as an SysVR4 signal, for example).
SysVR4 clients can now successfully ignore signals, although catching
them remains problematic (see commit log message for rev1.13 of
sys/i386/svr4/svr4_machdep.c for more info).
eliminate warnings, etc.
Note that svr4_setcontext() and svr4_getcontext() currently don't work
correctly, which makes returning from signal handlers somewhat problematic
(for reference: the SysVR4 setcontext() and getcontext() syscalls behave
like a low-level version of setjmp() and longjmp(), in that they save and
restore process context. SysVR4 uses this to implement its signal handler
trampoline: The context which is saved before a signal handler is called
is restored by an implicit call to the setcontext() syscall when the signal
handler returns. That currently doesn't work right in this emulator,
although it used to).
I'm committing this anyway, with a caveat that it's buggy, so that I can
(a) note the bug for anyone who is wondering about it, and (b) get the
stuff I've done to improve (but not fix) the situation in the tree before
4.0 is released. If I have time to fix it totally RSN I'll talk to Jordan
to see if I can bend him into letting me commit a bugfix :-)
Note that the situation now is somewhat better than it was yesterday
anyway, because I've fixed the handling of svr4_sigsets which previously
was causing signal handlers to not get called at all. Stay tuned for
an upcoming commit to svr4_signal.c...
- Split terminal emulation code from the main part of the driver so
that we can have alternative terminal emulator modules if we like in
the future. (We are not quite there yet, though.)
- Put sysmouse related code in a separate file, thus, simplifying the
main part of the driver.
As some files are added to the source tree, you need to run config(8)
before you compile a new kernel next time.
You shouldn't see any functional change by this commit; this is only
internal code reorganization.
-opt_ipsec.h was missing on some tcp files (sorry for basic mistake)
-made buildable as above fix
-also added some missing IPv4 mapped IPv6 addr consideration into
ipsec4_getpolicybysock
Changes are:
- rpc.umntall is called at the right places now in /etc/rc*
- rpc.umntall timeout has been lowered from two days (too high) to one
- verbose messages in rpc.umntall have been clarified
- kill double entries in /var/db/mounttab when rpc.umntall is invoked
- ${early_nfs_mounts} has been removed from /etc/rc
- patched mount(8) -p to print different pass/dump values for ufs filesystems.
(last patch recieved from dan <bugg@bugg.strangled.net>)
Submitted by: Martin Blapp <mbr@imp.ch>, dan <bugg@bugg.strangled.net>
did test this through a ``make world'', but of course I already
had a working lint binary (one that does not call cpp -undef)
installed.
Reported by: "Pierre Y. Dampure" <Pierre.Dampure@barclayscapital.com>
Pleases let me make sure that no one touch the invalid ro_rt pointer,
after splx(s) and before next ro_rt initialization.
Though usually this seems to be already called at splnet,
I still sometime experience kernel crash at rtfree() in my
INET6 enabled environment where IPv6 connection is frequently used.
(Off-course, it might be just due to another bug.)
This must be one of the reason why connections over IPsec hangs for
bigger packets.(which was reported on freebsd-current@freebsd.org)
But there still seems to be another bug and the problem is not yet fixed.
ifconfig and bogus ethernet address (4b:57:4b:57:4b:57) has been
hacked around. I'll revisit this when I have a clue whats going on.
Reviewed by: obrien
