copywin() couldn't seem to decide whether it should work in window or
screen coordinates - and managed to do neither.
Change copywin() to use window relative coords (as ncurses and solaris do),
and change overwrite() and overlay() to use the modified interface.
It is now possible to use overwrite() to save part of curscr while a
temporary window is drawn.
Fixes PR/26506
this uses a different name for the parallel ports than the openbsd
port otherwise they conflict with the magma parallel ports and you
would be unable to have both a spif and magma installed at the
same time.
connect madvise(2) and mincore(2) - apparently the newer Linux libs
don't stub it anymore, so allow the application to take advantage
of them
the Linux calls appear to be compatible in the flag values and semantics,
so a wrapper is not necessary
don't stub it anymore, so allow the application to take advantage
of them
the Linux calls appear to be compatible in the flag values and semantics,
so a wrapper is not necessary
than two days backward (same as old behaviour) or more than two years
forward. I have lots of test machines I don't power on every two days.
XXX - this should be handled more consistent across the different
ports. While here, move the default time -- in the unlikely event that
we have neither rtc nor file system time -- to this millenium.
Use this to reset the channel before doing a dump, instead of the hack in
wdc_exec_xfer() based on C_POLL. This hack was causing problems on
controllers with a shared queue, because we now can have C_POLL set during
concurent channels probes (problem found and analysed on sparc64 by
Martin Husemann).
This should even make core dumps marginally more reliable on ATA drives.
freebsd drivers for the same. if found and supported, export a
"machdep.speedstep_state" sysctl that can be set to "0" (low) or "1"
(high).
tested on a dell inspiron 8500 (supported, working) and a dual P4
system (supports ichlpcib not speedstep, comes up properly disabled.)
this prevents sysctl from coredumping if the second call fails while the
first succeeds. This isn't supposed to happen, but there is another bug
in the i386 kernel implementation of sysctl machdep.diskinfo that excites this
the background. The problem was exposed when setting a non-black color
as the background, as the shift did not produce the expected fill value
(for black it worked because 0 is black).
scottr