| Age | Commit message (Collapse) | Author |
|---|
|
on exynos4/5 yet as it isn't at the usual offset from periphbase.
ok bmercer@
|
|
one of the cases was reached. Matches other parts of the mpbios code.
|
|
something based on an address family and later assumes one of the paths
was taken. This was initially just calls to panic until guenther
suggested a function to reduce the amount of strings needed.
This reduces the amount of noise with static analysers and acts
as a sanity check.
ok guenther@ bluhm@
|
|
not all usb controllers.
this lets jsg build ehci on a platform that lacks a pci bus.
ok jsg@
|
|
|
|
truncating trailing zeros.
Testing by many as part of a larger change to use ACPI _CST objects
ok krw@
|
|
annoying trailing, leading and embedded whitespace. No change to
.o files.
ok deraadt@
|
|
the qemu cortex a15 useable without trustzone.
Establish the interrupt for the non-secure physical timer (30), in
addition to the secure physical timer (29).
Stop masking the timer output signal in the interrupt handler.
|
|
|
|
routes.
Since such routes are also flagged with RTF_LLINFO various code path
assume correctly that they contain valid ARP or ND information.
This fixes the "arpresolve: unresolved and rt_expire == 0" issue
reported on tech@ by mxb <mxb AT alumni DOT chalmers DOT se>.
ok claudio@, phessler@
|
|
code to use sotopf() like tcp_usrreq() does. Also following
tcp_usrreq(), put more stuff under splsoftnet. And as a result
in-line code in udp_detach() and nuke udp_detach().
Most ideas from and ok mikeb@
|
|
what register dance copyerr should do.....
|
|
in copyerr itself, like other architectures of this type do.
as a result of chatter between miod and kettenis
|
|
|
|
permit the active copyout/copyin to continue work on subsequent faulting
pages and not misinterpret & fault them as kernel bcopy against userland
addresses. Old bug -- fall of 1996. This should fix getentropy issues
on MP systems which have become more apparent recently, probably due to
some combo of increased ASLR with unlocked getentropy happening very soon
after vfork/fork...
ok miod
|
|
Discussed with kettenis
|
|
bits the first time it is called, so don't do it again.
ok miod
|
|
ok deraadt@
|
|
Reshuffle the code around a bit and greatly improve error handling
fixing a few bugs along the way.
Problem reported by and fix was written with Alexandr Nedvedicky.
OK henning
|
|
|
|
|
|
reused by a CPU while another CPU is manipulating it.
This races occurs because the virtual spill handlers are run without
taking the KERNEL_LOCK for obvious reasons. So use a per-pmap mutex
that CPUs must hold when modifying a pted in order to guarantee the
atomicity of operations *and* the coherence between pmap VPs tree and
what's in the HASH.
Thanks to dlg@ for assisting me debugging this. This change ends your
PowerPC pmap SMP show of the week. GENERIC.MP on macppc should now be
stable enough to build ports without corrupting its own memory.
ok kettenis@, deraadt@, dlg@
|
|
Needed for upcoming locking.
|
|
Since this lock is recursive we can now guarantee the atomicity of
pte_inser{32,64}() when a pted has to be removed first. This fixes
one of the races.
Using a __mp_lock here also allowed dlg@ to provide me useful traces
to fix the next race. Thanks for your help!
ok kettenis@, deraadt@, dlg@
|
|
it. This will reduce the number of places to audit for locking.
Note that for profiling purposes pte_spill_v() is now marked a __noprof
since per-CPU profiling buffers are not guaranteed to be 1:1 mapped and
cannot be accessed from the real mode fault handler.
ok kettenis@, deraadt@, dlg@
|
|
Document every operation, make sure to call "sync" when appropriate so
that other CPUs see the bit changes and finally grab a lock where it was
missing to grantee atomicity.
ok kettenis@, deraadt@, dlg@
|
|
This should not introduce any behavior change but makes the code easier
to read and later easier to protect. This also brings this pmap closer
to what others do.
Thanks to kettenis@ for spotting a bad typo!
ok kettenis@, deraadt@, dlg@
|
|
If you wonder why pte_insert{32,64}() is not using pmap_hash_remove() if
it finds a conflicting PTE in the HASH, it's because in the current state
trying to grab the same lock a second time would lead to a deadlock.
This is much easier to reproduce on G5 (or G4 with BAT disabled).
ok kettenis@, deraadt@, dlg@
|
|
|
|
|
|
if a PTE is present in the HASH.
Note that atomicity is currently not guaranteed between this check and
the following operations.
ok kettenis@, deraadt@, dlg@
|
|
that does not call pmap_vp_lookup().
Carreful readers would have notice the removal of the bits on the virtual
address with a page mask, this change allows me to find the 13 years old
bug fixed in r1.145.
ok kettenis@, deraadt@, dlg@
|
|
This simplify pmap_remove() & friends by re-using an already fetched PTE
descriptor.
There's currently a race on MP system where one CPU can reuse a pted
while another one is still trying to insert it in the HASH. This commit
starts reducing the number of pmap_vp_lookup() calls to help fix this
race.
ok kettenis@, deraadt@, dlg@
|
|
Even if this change is not strickly needed, because the memory will be
returned to the pool it helped me track the use-after-free.
|
|
By instructing spl(9) calls on MP machines I figured out that their high
cost was hiding a race condition involving PTE reuse in our pmap. Thanks
to deraadt@ for finding a way to trigger such panic by adding a couple of
splvm().
This should make the races easier to trigger but will be addressed
shortly.
This commit starts your PowerPC pmap SMP show of the week.
ok kettenis@, deraadt@, dlg@
|
|
won't accept just a number which a comment in the gas code mentions is
for backward compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
This is a PCI card from the same chip family as supported by urtwn(4) on USB.
Development started in 2013 using urtwn(4) as a starting point but was dormant
for much of the time since. I finally unslacked after uwe@ provided help with
lifting this driver on its feet. As usual we got helpful hints from Theo.
Requires firmware which will be available in ports soon.
There are rate adaptation issues that still need to be fixed, cause unknown.
In my testing the hardware rarely transmits more than 1Mbit/s.
Committing over MAC/BB RTL8188CE, RF 6052 1T1R.
|
|
|
|
|
|
based devices. This introduces Realtek PHY into em driver
code and is only a temporary solution to the problem.
OK deraadt@
|
|
timeout. Unfortunately the smu(4) CPU voltage slewing code sleeps, which
causes a kernel panic. Prevent this by delegating the CPU frequency switching
and voltage slewing to a task.
ok mpi@
|
|
|
|
|
|
Report & tests by mxb@alumni.chalmers.se, thanks!
OK deraadt, chris
|
|
|
