| Age | Commit message (Collapse) | Author |
|---|
|
the case we verify if the CPU supports a specific version of the
architectural performance monitoring feature and read out the current
frequency from the fixed-function performance counter of the unhalted
core.
My initial motivation to implement this was the Soekris net6501-70
which comes with an Intel Atom E6xx 1.60GHz CPU. It has a constant
time stamp counter plus speed step support and boots on the lowest
frequency of 600MHz. This caused hw.cpuspeed and hw.setperf to
reflect the wrong values.
The diff is a cooperation work with jsg@. The fixed-function
performance counter read code comes from a former diff of him.
OK jsg@
|
|
as it causes hangs in some ports, including libsigsegv's configure script
confirmed by krw@, landry@
|
|
hold the kernel lock, but still need call one function that needs it.
Instead of grabbing the lock all over the place, move the locks into
the affected functions: trapsignal, scdebug*, ktrsyscall, ktrsysret,
systrace_redirect and ADDUPROF. In the cases we already hold the biglock
we'll just recurse.
kettenis@, beck@ ok
|
|
KERNEL_PROC_LOCK -> KERNEL_LOCK
KERNEL_PROC_UNLOCK -> KERNEL_UNLOCK
oga@ ok
|
|
i386 disobeys the Nth commandment. Fix this. While here, make i386 and amd64
definitions of iplclock and statclock match.
ok art@, kettenis@
|
|
(interrupt was not for me), 1 (positive interrupt was for me), or -1
(i am not sure...). We have continued with this practice in as many
drivers as possible, throughout the tree.
This makes some of the architectures use that information in their
interrupt handler calling code -- if 1 is returned (and we know
this specific machine does not have edge-shared interrupts), we
finish servicing other possible handlers on the same pin. If the
interrupt pin remains asserted (from a different device), we will
end up back in the interrupt servicing code of course... but this is
cheaper than calling all the chained interrupts on a pin.
This does of course count on shared level interrupts being properly
sorted by IPL.
There have been some concerns about starvation of drivers which
incorrectly return 1. Those drivers should be hunted down so that
they return -1.
ok and help from various people. In snaps for about a week now.
|
|
mask out invalid bits to prevent a protect fault.
Original diff by joshe@; further feedback and ok kettenis@
|
|
ok krw, miod
|
|
for it. This makes the netisr a real C function which will help further
development. No noticable performance change on i386 and amd64.
With input from kettenis@ and miod@ additional OKs mikeb@ and henning@
|
|
|
|
|
|
This prevents a protection fault if a userland signal handler
scribbles all over it's struct sigcontext
Help from and ok guenther@ kettenis@
|
|
hierarchy. Everything attached to a single root node anyway, so at
best we had a bush.
"i think it is good" deraadt@
|
|
Dell Inspirion 4150 to wake up immediately even though RTC_EN isn't set
in the PM1 Enable register.
ok deraadt@, mlarkin@
|
|
|
|
all jumbled up in the same functions. the rtc (mc chip) and clock (i8243)
startup was also mixed up. they the soft state and hardware state can
be started in the right order, and it is easy to restart just the
neccessary parts upon resume. tested in numerous cases:
(apic, pic) * (GENERIC.MP, GENERIC) * (mp, non-mp) * (i386, amd64)
ok kettenis
|
|
is now shared with all processes/threads. As a result, you can now use the
FPU in true process context (instead of just in kernel threads), but you
need to make sure you restore the default FPU state before calling
fpu_kernel_exit() if you change rounding mode, precision or exception masks.
Lots of discussion with thib@ and Mike Belopuhov.
ok thib@, deraadt@
|
|
ok deraadt@
|
|
context of some random process that happened to be switched onto the FPU
after the decision was made to send the IPI.
|
|
the FPU in the kernel.
From Mike Belopuhov; Little bits by myself.
Comments/OK kettenis@
|
|
the weird "pass by reference" that causes problems with gcc4.
ok nicm@, tom@
|
|
1) when you have a wrapper function in a dmatag that just calls the
_bus_dmamem original, you don't need it, just put the original function
in the tag
2) don't trunc_page the avail_end/ISA_BOUNCE_THRESHOLD stuff (see icb
for a discussion of why this is wrong about 00:00 gmt). make i386 and
amd64 both do this the same (the amd64 way is cleaner and makes the
third diff actually possible without a lot of pain). just do
dmamem_alloc_range(0, threshold) and if that fails do a alloc_range(0,
-1) and assume we'll bounce to pick up the pieces. Also using avail_end
for alloc_range is not nice (miod has been trying to avoid these abuses
iirc), so just use (paddr_t)-1, which is equivalent since you want "any"
memory.
3) now this is the funny one. consider point 2. then considering why
using the same bloody function to allocate your bouncebuffer is just
f'ing wrong. instead allocate with alloc_range(0, threshold) to make
sure that our bouncebuffer is actually uner 16megs.
ok deraadt@, kettenis@. Tested by several people.
|
|
|
|
ok deraadt@
|
|
issue reported by Slava Pestov.
ok deraadt@
|
|
Tested by myself, sthen, oga, kettenis, and jasper.
Input from sthen and jasper.
ok kettenis
(Manpage follows shortly.)
|
|
between instances, saving space in the kernel. feedback from many (some
incorporated, some left for future work).
ok deraadt, kettenis, "why not" miod.
|
|
a define needed to get to ``private'' functions that needs to be defined
5 or more times isn't much use and may cause namespace issues anyway.
Other archs will probably follow.
Discussed in portugal. "Hell yes" weingart@, ok kettenis@, no
objections miod@
|
|
interrupt. On some machines the rtc doesn't generate interrupts and we would
end up not running statclock() at all.
ok miod@, art@
|
|
amd64 isa dma code is identical save for some formatting, and a slight
difference in bus_dmamem_alloc.
"Die x86_!" krw@.
|
|
incorrectly.
The spec (manpage) states that using two PRE or two POST ops together is
entirely valid, but mixing pre and post is invalid. The way this was
handled before with a switch statement meant that only individual
commands actually would be recognised, so move to just checking the
commands indidually using "if (op & $command)". Additionally, add a
DIAGNOSTIC check and panic for the mixing of pre and post operations
(this is done on several other architectures already).
tested by several people; thanks!
ok dlg@, kettenis@, "the diff made sense" deraadt.
|
|
Positive test results by a handful of people. Ok kettenis@
|
|
pointless and just makes the code different for no reason. This moves i386 and
amd64 bus_dma to being a lot closer to identical.
suggestion to just remove the prefix instead of merge them from deraadt@.
no objections art@, kettenis@, ok weingart@
|
|
|
|
|
|
Really just the low-hanging fruit of (hopefully) forthcoming timeout
conversions.
ok art@, krw@
|
|
Not sure what's more surprising: how long it took for NetBSD to
catch up to the rest of the BSDs (including UCB), or the amount of
code that NetBSD has claimed for itself without attributing to the
actual authors.
OK deraadt@
|
|
ok dlg@, jsing@, deraadt@
|
|
ok dlg@, tested by dlg@, oga@, jsg@, deraadt@
|
|
ok krw@
|
|
ok weingart@
|
|
ok deraadt@
|
|
i386 pccom into line with com. Problem reported and first diff by Markus
Hennecke, who also tested and corrected subsequent diffs. Boot messages
and console now work with his 57K serial connections.
Suggestions and ok miod@
|
|
the hp300 related ones currently in use. CN_NORMAL becomes CN_LOWPRI,
CN_INTERNAL becomes CN_MIDPRI and CN_REMOTE becomes CN_HIGHPRI.
ok miod@
|
|
|
|
also assume that 386 cpus are really unknown, and promote them to 486
instead of panic.
|
|
|
|
eyeballed and ok dlg@
|
|
timerreg.h
ok miod@
|
|
|
