For the floppy driver, use fdcontrol to manipulate density selection.
For the CD drivers, the 'a' and 'c' suffix is without actual effect and
any applications insisting on it can be satisfied with a symlink:
ln -s /dev/cd0 /dev/cd0a
Ongoing discussion may result in these pieces of code being removed before
the 5-stable branch as opposed to after.
such a card is ejected, we'd panic. Instead, just ignore it.
I should also add a sanity check in the FUNCID code as well, but this
isn't wrong since the check is cheap and happens infrequently.
into targreadfilt(). Unlock around calls to notify_user(). If an application
is sending CCBs while the endpoint is shutting down, this may result in
incomplete disable. A more complete solution will come with a "dying" flag.
Submitted by: simokawa
of do_cmd() broke things, because this function assumes that a socklen_t
is large enough to hold a pointer.
A real solution to this problem would be a rewrite of do_cmd() to
treat the optlen parameter consistently and not use it to carry
a pointer or integer dependent on the context.
a correctable DMA error. Failing to do so can cause the error interrupt
to be triggered over and over again.
- Clean up the comments for UEAFSR_* constants, fix a typo (UEAFSR_BLK is
(1 << 23), not (1 << 22)), and add two more. Also, add similar constants
for the CE AFSR bits.
The immediate purpose for this option is to use it in rc.d so that we
can make savecore behavior conditional.
Tremendous assistance with ideas and sanity checking provided by tjr
and b@etek.chalmers.se.
hose your system. You end up with just about everything statically linked
(except for libpam.so), which then causes all the pam users to fail.
eg: login, sshd, su etc all stop working because dlopen no longer works
because there is no libc.so in memory anymore.
gcc passes -L/usr/lib to ld. The /usr/lib/libxxx.so symlink is *not* a
compatability link. It is actually the primary link. There should be no
symlinks in /lib at all. Only /lib/libXX.so.Y.
peter@daintree[9:27pm]/usr/bin-104> file yppasswd
yppasswd: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.1.1, dynamically linked (uses shared libs), stripped
peter@daintree[9:27pm]/usr/bin-105> ldd yppasswd
yppasswd:
libpam.so.2 => /usr/lib/libpam.so.2 (0x280d1000)
peter@daintree[9:28pm]/usr/bin-106>
Note no libc.so.5. Hence libpam.so.2 has unresolved dependencies.
I believe this is also the cause of the recent buildworld failures when
pam_krb5.so references -lcrypto stuff etc and when librpcsvc.so references
des_setparity() etc.
This change could not possibly have worked, unless there are other missing
changes to the gcc configuration. It won't work with ports versions of
gcc either.
value for getcontext() in a preserved register rather than on the stack.
The second time around, the stack value would likely have changed so we
can't depend on it for the return value.
otherwise the return from the syscall stub for getcontext will pop off
the return value for the caller to the getcontext stub and it will appear
as though the setcontext() syscall returned instead of the getcontext().
The same bug exists on amd64, a fix is coming there too.
The bug can be demonstrated with this test code fragment:
main()
{
ucontext_t top;
if (getcontext(&top) == 0) {
write(2, "PING!\n", 6);
/* Cause a return value of 1 from getcontext this time */
top.uc_mcontext.mc_eax = 1;
setcontext(&top);
err(1, "setcontext() returned");
}
write(2, "PONG!\n", 6);
_exit(0);
}
instead of long types for low-level locks.
Add prototypes for some internal libc functions that are
wrapped by the library as cancellation points.
Add memory barriers to alpha atomic swap functions (submitted
by davidxu).
Requested by: bde
threatened over 2 years ago.
Why? -pthread was a hack to prevent linking to both libc and libc_r
and became unecessary when libc_r became free of libc. Now that we
have multiple thread libraries from which to choose, it is more confusing
because you can't link to more than one threads library at a time.
Things like autoconf and libtool sometimes detect -pthread and
also -lc_r, and in conjunction with ports usage of ${PTHREAD_LIBS},
really wacky things ensue when PTHREAD_LIBS is set to another
threads library. This might not be so bad if the build broke
when this happens, but it doesn't and you don't know it until
funny things happen when you run the application (or use an
affected library).
Reviewed by: obrien
