boundary when filling rectangles, especially annoying when we draw whitespaces
As a workaround we draw all rectangles less than 50 pixels wide by drawing
a 50 pixel rectangle into off-screen memory to the right of the visible fb and
then copy the portion we want. Keeps track of the colour and size of the
off-screen rectangle so we can avoid redrawing it whenever possible.
Whether or not we have /dev/random and /dev/urandom baked into the
kernel, configuring `octrnm* at ...' in the kernel config requires
octeon_rnm.c.
Related to PR kern/46728.
For now it is wired up only in x86 ALL kernels, and built as a module
for x86 and Arm. Once it gets a little more testing on machines with
APEI, I would like to flip it on by default.
PR kern/58046
KASSERT already references all the variables even in !DIAGNOSTIC
builds (but evaluates nothing at run-time in that case).
That said: Is the curlwp->l_blcnt assertion correct? Can't curlwp be
changed in this interrupt handler by preemption?
mtx_count, biglock_count and blcnt are defined inside DIAGNOSTIC block, thus
KASSERTs using them should be guarded as well.
Seemingly introduced with matt-nb5-mips64 merge in 2011.
r. 1.39 introduced a regression where instead of applying a reasonable
default maximum (as was done prior to that change), incorrect values
were accepted and applied, as failures to retrieve an expected MSR
value weren't accounted for.
Apply different logic for unexpectedly low vs. high maximums, with
distinct warnings for each. Also add another warning about a retrieval
failure right at the outset (which also just uses the default, then).
This change fundamentally doesn't address the fact that
__SHIFTOUT(msr, MSR_TEMP_TARGET_READOUT)
doesn't necessarily return a valid value. It just restores prior
behaviour, which is more reasonable than applying a zero value, which
started happening on some older hardware. (I infer this is most likely
an issue with dated generations of Intel hardware with this feature.)
The challenge is that this evidently isn't all documented properly
anywhere. Various "magic values" in this driver need further
investigation.
While here, also fix output so warnings are cleanly formatted, rather
than the slightly scrambled way they were appearing.
Tested on older Intel hardware I had on hand:
E7500 (now falls back to default 100 rather than 0)
E5540 (successfully retrieves 97, as before)
i5-3340M (successfully retrieves 105, as before)
have an interesting feature: the RTC and console UART are present on each
CPU module, but only those peripherals on the "primary" CPU module matter,
because each CPU's module's periperals are mapped to the same physical
address, but are only accessible by that CPU module. The firmware selects
a primary CPU to boot the system, and that CPU's RTC and UART are the
system RTC and console, respectively.
To handle this, on systems where it's needed, we wrap the RTC gettime/settime
calls and, if not running on the primary CPU already, cross-call to the primary
to perform the RTC access.
- The time between the time the alarm occurred and the time read by
TIME_* register in the next interrupt handler was not accumulated.
- With the one-shot timer method, once the host time prolongs, the
guest time will never be able to catch up with the host time again.
New one does:
- The driver maintains its (guest's) time (as sc_alarm_time) and always
set the next alarm sc_interval_ns after the previous alarm.
- gfrtc_set_alarm() takes an absolute time instead of a relative time
as the argument.
PR kern/57980. Confirmed on QEMU.
and DEC 10000.
This is a work-in-progress, but this should be sufficient for the system
to boot, using the PROM console routines (and then proceed to not find any
devices because we don't yet support the "Laser System Bus").
clockframe layout and remove the CLOCK_FORMAT0 work-around. As a nice
side-effect, this also eliminates the super-sketchy stack unwinding used
by rtclock_intr to get at the interrupt stack frame.
macallan