new i386/amd64 machdep.lidsuspend sysctl which decides whether a lid
close causes a suspend. resumes are not tied to this; they happen
unconditionally. this is a temporary knob for the 4.8 release;

new i386/amd64 machdep.lidsuspend sysctl which decides whether a lid
close causes a suspend. resumes are not tied to this; they happen
unconditionally. this is a temporary knob for the 4.8 release; afterwards
it will move to a more convenient place
much moaning discussing where to put the knob with kettenis
tested by various including phessler

show more ...

in the clock drivers, seperate the soft-state and hard-state which was
all jumbled up in the same functions. the rtc (mc chip) and clock (i8243)
startup was also mixed up. they the soft state and ha

in the clock drivers, seperate the soft-state and hard-state which was
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

show more ...

Don't leak the contents of the FPU and SSE registers between processes.

ok deraadt@

Make our trapframe squeeky clean in setregs(). Avoid leaking registers into
the new process image.

ok deraadt@, guenther@

Typo in comment.

ok oga@

amd64_pa_used is weird.

We check a bunch of things, where most archs are a lot more simple.
Also, we get problems sometimes: My x201 can't map the framebuffer BAR
from the aperture with the chunk th

amd64_pa_used is weird.

We check a bunch of things, where most archs are a lot more simple.
Also, we get problems sometimes: My x201 can't map the framebuffer BAR
from the aperture with the chunk that checks the bios sections, meaning
the bios is claiming something about it.

Kettenis@ and I are pretty sure that the rest of the checks are more than
sufficient, so just nuke that one.

for the record, in the same situation i386 just checks again VGA_START,
BIOS_END and physmem.

ok kettenis@

show more ...

If you include <uvm/uvm.h>, you do not need to include any other <uvm/uvm_foo.h>

uvm constraints. Add two mandatory MD symbols, uvm_md_constraints
which contains the constraints for DMA/memory allocation for each
architecture, and dma_constraints which contains the range of addre

uvm constraints. Add two mandatory MD symbols, uvm_md_constraints
which contains the constraints for DMA/memory allocation for each
architecture, and dma_constraints which contains the range of addresses
that are dma accessable by the system.

This is based on ariane@'s physcontig diff, with lots of bugfixes and
additions the following additions by my self:

Introduce a new function pool_set_constraints() which sets the address
range for which we allocate pages for the pool from, this is now used
for the mbuf/mbuf cluster pools to keep them dma accessible.

The !direct archs no longer stuff pages into the kernel object in
uvm_km_getpage_pla but rather do a pmap_extract() in uvm_km_putpages.

Tested heavily by my self on i386, amd64 and sparc64. Some tests on
alpha and SGI.

"commit it" beck, art, oga, deraadt
"i like the diff" deraadt

show more ...

Declare safepri at the MD level on each platform, so that the kern_synch.c
does not have to deal with it as a common. Some platforms may be missed
by this commit... if you spot one, fix it the same

Declare safepri at the MD level on each platform, so that the kern_synch.c
does not have to deal with it as a common. Some platforms may be missed
by this commit... if you spot one, fix it the same way.
ok miod

show more ...

Pass signal handlers a more clean FPU state (ie. the right modes) and
properly restore it in sigreturn. Lots of deep digging by matthieu,
otto, guenther, kettenis and I.. and I am certain I forgot s

Pass signal handlers a more clean FPU state (ie. the right modes) and
properly restore it in sigreturn. Lots of deep digging by matthieu,
otto, guenther, kettenis and I.. and I am certain I forgot some other
people.
ok kettenis otto matthieu

show more ...

Since we're direct mapped and don't need to worry about kva availability or
reservation, we don't need to stick to transferring single pages during boot
dump anymore.

so bump the limit up to MAXPHYS

Since we're direct mapped and don't need to worry about kva availability or
reservation, we don't need to stick to transferring single pages during boot
dump anymore.

so bump the limit up to MAXPHYS (64k). Dramatically speeding up boot
dump/crash on amd64. (my 4gig machine went from 13.5 minues to just over
1min with this diff)

ok toby, marco. Discussed with miod.

show more ...

tweak dumpsys's countdown to cope with upcoming speedup

tested by ckuethe@, ok oga@

Synchronise amd64 more with other PMAP_DIRECT architectures. (step 1,
more to come later)

Specfically, there is no reason to reserve a special virtual address just so we
can do boot dump, we have a

Synchronise amd64 more with other PMAP_DIRECT architectures. (step 1,
more to come later)

Specfically, there is no reason to reserve a special virtual address just so we
can do boot dump, we have a direct map of every page anyway.

since pmap_map is deprecated and MD only anyway, this means we can remove that
interface too. If anything this should increase reliability since pmap_enter
won't fail under memory pressure during dump (unlikely but possible). It is also
simpler and smaller ;)

Tested by myself and ckuethe, no regressions.

ok miod@

show more ...

Bring back PHYSLOAD_DEVICE for uvm_page_physload.

ok kettenis@ beck@ (tentatively) and ariane@. deraadt asked for it to be
commited now.

original commit message:

extend uvm_page_physload to have

Bring back PHYSLOAD_DEVICE for uvm_page_physload.

ok kettenis@ beck@ (tentatively) and ariane@. deraadt asked for it to be
commited now.

original commit message:

extend uvm_page_physload to have the ability to add "device" pages to
the system.

This is needed in the case where you need managed pages so you can
handle faulting and pmap_page_protect() on said pages when you manage
memory in such regions (i'm looking at you, graphics cards).

these pages are flagged PG_DEV, and shall never be on the freelists,
assert this. behaviour remains unchanged in the non-device case,
specifically for all archs currently in the tree we panic if called
after bootstrap.

ok art@ kettenis@, beck@

show more ...

fix compiling without ACPI, ok marco@ deraadt@ krw@ mlarkin@

back out strict splassert semantics from 1.103; it breaks some things
like bigmem (disabled by default), sppp (ask wilfried about
"splassert: if_up/down: want 5 have 7")

bring the splassert semantic from sparc64 to amd64. splassert in interrupt
handlers now checks that the spl the isr was established at is the same as
the one passed to splassert. this lets you check

bring the splassert semantic from sparc64 to amd64. splassert in interrupt
handlers now checks that the spl the isr was established at is the same as
the one passed to splassert. this lets you check that isrs dont enter code
that have insufficient protection if entered from process context.

ok kettenis@

show more ...

Remove ACPI_SLEEP_ENABLED checks.

This enables by default the suspend/resume paths in the kernel.

Okay deraadt@.

Do not bother initializing bufpages in the md code if the computation is
exactly the same the mi could will use if bufinit() is invoked with
bufpages == 0.

With the SysV memory allocation changes, allocsys() doesn't do anything
anymore. Get rid of it completely.

Rototill system V message queues.

No longer allocate a static amount of memory for messages in MD
boot path; message queues, message metadata, and message data now
all use dynamic memory, which mean

Rototill system V message queues.

No longer allocate a static amount of memory for messages in MD
boot path; message queues, message metadata, and message data now
all use dynamic memory, which means that runtime sysctls should now
be trivial to implement.

Since I'm going to be around all week to fix any breakage, this should
probably just go in now.

show more ...

Dynamic buffer cache support - a re-commit of what was backed out
after c2k9

allows buffer cache to be extended and grow/shrink dynamically

tested by many, ok oga@, "why not just commit it" deraadt@

via nano cpus are amd64, and so we need machdep.xcrypt

Back out all the buffer cache changes I committed during c2k9. This reverts three
commits:

1) The sysctl allowing bufcachepercent to be changed at boot time.
2) The change moving the buffer cache ha

Back out all the buffer cache changes I committed during c2k9. This reverts three
commits:

1) The sysctl allowing bufcachepercent to be changed at boot time.
2) The change moving the buffer cache hash chains to a red-black tree
3) The dynamic buffer cache (Which depended on the earlier too).

ok on the backout from marco and todd

show more ...

backout:
> extend uvm_page_physload to have the ability to add "device" pages to the
> system.
since it was overlayed over a system that we warned would go "in to be
tested, but may be pulled out".

backout:
> extend uvm_page_physload to have the ability to add "device" pages to the
> system.
since it was overlayed over a system that we warned would go "in to be
tested, but may be pulled out". oga, you just made me spend 20 minutes
of time I should not have had to spend doing this.

show more ...