| Age | Commit message (Collapse) | Author |
|---|
|
Now that asmc(4) attaches through acpi(4), other than with isa(4), acpi(4)
could attach multiple SMC chips in theory, even though in practice there
will be only one SMC chip per machine.
Suggested and ok kettenis@
|
|
This e.g. makes the driver also work on iMac11,2.
ok kettenis@, jung@
|
|
The header is being pulled via db_machdep.h -> uvm_extern.h -> uvm_map.h
|
|
from jordan@
|
|
Unfortunately, machines tend to come with underpopulated device trees,
and consequently this change is not very useful as is. The lack of good
data is troublesome especially with things like I2C bus switches.
|
|
This generally is an exercise in futility because the phandle of the
controller node tends to be missing.
|
|
|
|
|
|
This makes certain machines' management network port usable.
|
|
|
|
In preparation for running the lapic timer in oneshot mode on amd64 we
need a replacement for lapic_delay().
Using the lapic timer itself to implement delay(9) when the timer is
not running in periodic mode is complicated if not outright impossible.
Meanwhile, the i8254 provides our only other amd64 delay(9) implementation
and it is an extremely slow clock. On my 2GHz machine, gettick() takes
~20 microseconds to complete *without* mutex contention. On a VM it is
even slower, as you must exit the VM for each inb() and outb().
So, add tsc_delay() and use it when we have a constant/invariant TSC.
The TSC is a 64-bit "up-counter" so the implementation is simple.
Given how slow the i8254 is on modern machines, we may want to add an
HPET delay(9) implementation as a fallback for machines where the TSC
drifts. The HPET itself is pretty slow, but not as slow as the i8254.
Discussed with kettenis@, Mike Larkin, and naddy@.
Tweaked by kettenis@.
ok kettenis@
|
|
This makes it possible to use more SLB entries for the kernel than the
hardware supports. The design is such that a subset of the hardware SLB
entries can be replaced when needed. This makes sure the entries
mapping kernel code and data and the page tables ar always present.
Traps for missing SLB entries are handled in real-mode and on a special
stack such that it doesn't have to rely on SLB entires mapping kernel
stacks.
With this in place we can increase KVA to 32GB. Hopefully that's enough
to support large memory configurations.
|
|
|
|
from Matt Baulch
discussed with kettenis and drahn
|
|
|
|
responses. This is what the SCSI specifications say is the correct value and
already used in several cases.
|
|
than 8 SLB entries.
|
|
|
|
than 8 SLB entries.
|
|
This makes various receive and transmit event counters readable. This
additionally replaces the old, and somewhat unusual, way of updating
error counters in ifp.
Most of the hardware counters are 32 bits wide. Hence the code polls
them periodically and adds the values to 64-bit software counters.
The hardware counters are cleared when read.
|
|
We reprogram the lapic timer by hand in three separate places.
This is error-prone and difficult to read.
To clean things up, introduce routines for reprogramming the lapic
timer in a given mode. lapic_timer_oneshot() starts a oneshot
countdown. lapic_timer_periodic() starts a repeating countdown.
Both of these routines call lapic_timer_start(), wherein we actually
write the lapic registers.
With input from dlg@.
Earlier version eyeballed by mlarkin@.
Suspend/resume tested by gnezdo@.
|
|
|
|
|
|
initialize the 'version' field. Not numbers.
|
|
ok kettenis visa
|
|
Copy signotify() from amd64, so that if proc *p is on another cpu, then
signotify(p) notifies the correct cpu.
ok kettenis@
|
|
|
|
|
|
bus_space_mmap(9) implementation to make sure we enter mappings with
the right memory attributes.
|
|
at the beginning of the loop. We need to use cr3 at the start of each
iteration for the top level page directory.
From and ok sf@
|
|
struct scsi_rw_10.
ok gnezdo@ jmatthew@ (who also did sparc64 compile test)
|
|
deraadt@: looks fine
|
|
|
|
handle the priority levels better and guarantee ordering of restoring the
priority level after running an interrupt handler and checking for a new
interrupt.
|
|
entered by pmap_enter(9). Otherwise kernel stack pages get evicted and
that doesn't end well.
We probably only need to lock in wired pages and I will probably revisit
this at some later stage.
tested by deraadt@
|
|
the boot kernel didn't hand us a valid bootduid.
ok visa@
|
|
get picked up by ddb. This makes the "pp" and "show struct" commands that
depends on CTF work.
ok gkoehler@
|
|
|
|
on the HP EliteBook 830 G6 we added a workaround which tries to re-map
the pages where we want to place to kernel read-write. On some machines
though this workaround causes a regression. Fix those by changing a few
things: Only set the writeable bit if it isn't set yet. Un-protect
write-protected page directories. Skip lower levels if large-page is
set, since the next level is already a page. Don't do anything at all
if paging is disabled.
From Christian Ehrhardt
ok bluhm@ tobhe@
|
|
matches the bootduid of the boot kernel.
ok visa@
|
|
OK deraadt@, mpi@
|
|
|
|
|
|
|
|
|
|
Regarding RDTSC, the Intel ISA reference says (Vol 2B. 4-545):
> The RDTSC instruction is not a serializing instruction.
>
> It does not necessarily wait until all previous instructions
> have been executed before reading the counter.
>
> Similarly, subsequent instructions may begin execution before the
> read operation is performed.
>
> If software requires RDTSC to be executed only after all previous
> instructions have completed locally, it can either use RDTSCP (if
> the processor supports that instruction) or execute the sequence
> LFENCE;RDTSC.
To mitigate this problem, Linux and DragonFly use LFENCE. FreeBSD and
NetBSD take a more complex route: they selectively use MFENCE, LFENCE,
or CPUID depending on whether the CPU is AMD, Intel, VIA or something
else.
Let's start with just LFENCE. We only use the TSC as a timecounter on
SSE2 systems so there is no need to conditionally compile the LFENCE.
We can explore conditionally using MFENCE later.
Microbenchmarking on my machine (Core i7-8650) suggests a penalty of
about 7-10% over a "naked" RDTSC. This is acceptable. It's a bit of
a moot point though: the alternative is a considerably weaker
monotonicity guarantee when comparing timestamps between threads,
which is not acceptable.
It's worth noting that kernel timecounting is not *exactly* like
userspace timecounting. However, they are similar enough that we can
use userspace benchmarks to make conjectures about possible impacts on
kernel performance.
Concerns about kernel performance, in particular the network stack,
were the blocking issue for this patch. Regarding networking
performance, claudio@ says a 10% slower nanotime(9) or nanouptime(9)
is acceptable and that shaving off "tens of cycles" is a
micro-optimization. There are bigger optimizations to chase down
before such a difference would matter.
There is additional work to be done here. We could experiment with
conditionally using MFENCE. Also, the userspace TSC timecounter
doesn't have access to the adjustment skews available to the kernel
timecounter. pirofti@ has suggested a scheme involving RDTSCP and an
array of skews mapped into user memory. deraadt@ has suggested a
scheme where the skew would be kept in the TCB. However it is done,
access to the skews will improve monotonicity, which remains a problem
with the TSC.
First proposed by kettenis@ and pirofti@. With input from pirofti@,
deraadt@, guenther@, naddy@, kettenis@, and claudio@. Based on
similar changes in Linux, FreeBSD, NetBSD, and DragonFlyBSD.
ok deraadt@ pirofti@ kettenis@ naddy@ claudio@
|
|
on POWER8 CPUs.
|
|
and earlier CPUs.
|
|
|
|
|
