Searched hist:1.308 (Results 1 - 25 of 109) sorted by relevance

12345

/src/sys/arch/sparc64/sparc64/
H A Dpmap.c1.308 Sat Jan 27 23:07:36 GMT 2018 chs branches: 1.308.2; 1.308.4;
apply the change from arch/x86/x86/pmap.c rev. 1.266 commitid vZRjvmxG7YTHLOfA:

In pmap_enter_ma(), only try to allocate pves if we might need them,
and even if that fails, only fail the operation if we later discover
that we really do need them. If we are replacing an existing mapping,
reuse the pv structure where possible.

This implements the requirement that pmap_enter(PMAP_CANFAIL) must not fail
when replacing an existing mapping with the first mapping of a new page,
which is an unintended consequence of the changes from the rmind-uvmplock
branch in 2011.

The problem arises when pmap_enter(PMAP_CANFAIL) is used to replace an existing
pmap mapping with a mapping of a different page (eg. to resolve a copy-on-write).
If that fails and leaves the old pmap entry in place, then UVM won't hold
the right locks when it eventually retries. This entanglement of the UVM and
pmap locking was done in rmind-uvmplock in order to improve performance,
but it also means that the UVM state and pmap state need to be kept in sync
more than they did before. It would be possible to handle this in the UVM code
instead of in the pmap code, but these pmap changes improve the handling of
low memory situations in general, and handling this in UVM would be clunky,
so this seemed like the better way to go.

This somewhat indirectly fixes PR 52706 on the remaining platforms where
this problem existed.

1.308 Sat Jan 27 23:07:36 GMT 2018 chs branches: 1.308.2; 1.308.4;
apply the change from arch/x86/x86/pmap.c rev. 1.266 commitid vZRjvmxG7YTHLOfA:

In pmap_enter_ma(), only try to allocate pves if we might need them,
and even if that fails, only fail the operation if we later discover
that we really do need them. If we are replacing an existing mapping,
reuse the pv structure where possible.

This implements the requirement that pmap_enter(PMAP_CANFAIL) must not fail
when replacing an existing mapping with the first mapping of a new page,
which is an unintended consequence of the changes from the rmind-uvmplock
branch in 2011.

The problem arises when pmap_enter(PMAP_CANFAIL) is used to replace an existing
pmap mapping with a mapping of a different page (eg. to resolve a copy-on-write).
If that fails and leaves the old pmap entry in place, then UVM won't hold
the right locks when it eventually retries. This entanglement of the UVM and
pmap locking was done in rmind-uvmplock in order to improve performance,
but it also means that the UVM state and pmap state need to be kept in sync
more than they did before. It would be possible to handle this in the UVM code
instead of in the pmap code, but these pmap changes improve the handling of
low memory situations in general, and handling this in UVM would be clunky,
so this seemed like the better way to go.

This somewhat indirectly fixes PR 52706 on the remaining platforms where
this problem existed.

1.308 Sat Jan 27 23:07:36 GMT 2018 chs branches: 1.308.2; 1.308.4;
apply the change from arch/x86/x86/pmap.c rev. 1.266 commitid vZRjvmxG7YTHLOfA:

In pmap_enter_ma(), only try to allocate pves if we might need them,
and even if that fails, only fail the operation if we later discover
that we really do need them. If we are replacing an existing mapping,
reuse the pv structure where possible.

This implements the requirement that pmap_enter(PMAP_CANFAIL) must not fail
when replacing an existing mapping with the first mapping of a new page,
which is an unintended consequence of the changes from the rmind-uvmplock
branch in 2011.

The problem arises when pmap_enter(PMAP_CANFAIL) is used to replace an existing
pmap mapping with a mapping of a different page (eg. to resolve a copy-on-write).
If that fails and leaves the old pmap entry in place, then UVM won't hold
the right locks when it eventually retries. This entanglement of the UVM and
pmap locking was done in rmind-uvmplock in order to improve performance,
but it also means that the UVM state and pmap state need to be kept in sync
more than they did before. It would be possible to handle this in the UVM code
instead of in the pmap code, but these pmap changes improve the handling of
low memory situations in general, and handling this in UVM would be clunky,
so this seemed like the better way to go.

This somewhat indirectly fixes PR 52706 on the remaining platforms where
this problem existed.

H A Dmachdep.c1.308 Tue Mar 05 14:15:35 GMT 2024 thorpej Move the at-shutdown call to resettodr() from cpu_reboot() to kern_reboot().

It's a small step, but it's a step.
/src/sys/sys/
H A Dsyscall.h1.308 Sun Sep 22 23:03:21 GMT 2019 christos branches: 1.308.2;
regen
1.308 Sun Sep 22 23:03:21 GMT 2019 christos branches: 1.308.2;
regen
H A Dsyscallargs.h1.308 Sun May 19 22:27:15 GMT 2024 christos regen

/src/sys/kern/
H A Dkern_synch.c1.308 Fri Feb 28 10:16:51 GMT 2014 skrll branches: 1.308.4; 1.308.6; 1.308.8;
G/C sys/simplelock.h includes

1.308 Fri Feb 28 10:16:51 GMT 2014 skrll branches: 1.308.4; 1.308.6; 1.308.8;
G/C sys/simplelock.h includes

1.308 Fri Feb 28 10:16:51 GMT 2014 skrll branches: 1.308.4; 1.308.6; 1.308.8;
G/C sys/simplelock.h includes

1.308 Fri Feb 28 10:16:51 GMT 2014 skrll branches: 1.308.4; 1.308.6; 1.308.8;
G/C sys/simplelock.h includes

H A Dvfs_subr.c1.308 Sat Dec 01 10:36:47 GMT 2007 yamt branches: 1.308.2; 1.308.6;
getnewvnode: remove a homegrown decl. of uvm_vnodeops.

1.308 Sat Dec 01 10:36:47 GMT 2007 yamt branches: 1.308.2; 1.308.6;
getnewvnode: remove a homegrown decl. of uvm_vnodeops.

1.308 Sat Dec 01 10:36:47 GMT 2007 yamt branches: 1.308.2; 1.308.6;
getnewvnode: remove a homegrown decl. of uvm_vnodeops.

H A Dinit_sysent.c1.308 Sun Apr 03 01:01:46 GMT 2016 christos regen

H A Dsyscalls.c1.308 Tue Dec 19 18:34:47 GMT 2017 kamil Drop SYS_sbrk

sbrk - change data segment size

This syscall is dummy since the inception of the project.

Sponsored by <The NetBSD Foundation>

H A Dsyscalls.master1.308 Sun Sep 19 15:51:27 GMT 2021 thorpej Add native implementations of eventfd(2) and timerfd(2), compatible with
the Linux interfaces of the same name.

H A Dtty.c1.308 Fri Feb 17 23:13:01 GMT 2023 riastradh ttycheckoutq(9): wait is always 0. Assert it; prune dead branches.

There appear to have been no callers with wait=1 since NetBSD 1.0
from a cursory search. Let's nix the parameter altogether on the
next kernel revbump. This logic is probably broken anyway in the
presence of ttycancel, which is necessary for, e.g., yanking USB
serial adapters.

/src/
H A Dbuild.sh1.308 Sat Jun 27 06:00:28 GMT 2015 matt Make evbarm64 (little endian) the default for aarch64.

/src/sys/dev/scsipi/
H A Dsd.c1.308 Sun Aug 10 16:44:36 GMT 2014 tls branches: 1.308.2;
Merge tls-earlyentropy branch into HEAD.

1.308 Sun Aug 10 16:44:36 GMT 2014 tls branches: 1.308.2;
Merge tls-earlyentropy branch into HEAD.

/src/share/misc/
H A Dacronyms1.308 Mon Oct 05 14:54:50 GMT 2020 nia NGPC

/src/sys/dev/pci/
H A Dfiles.pci1.308 Thu Oct 30 00:02:14 GMT 2008 darran branches: 1.308.2; 1.308.8;
NetOctave NSP2000 driver, ported from FreeBSD and integrated with
opencrypto by CoyotePoint Systems. The FreeBSD driver source was recently
made available by NBMK Encryption Technologies.

The port includes some currently unused code which implements kernel and
user space interfaces for the driver in FreeBSD. These are left in at this
time to facilitate the port of these interface to NetBSD if they are of
interest.

1.308 Thu Oct 30 00:02:14 GMT 2008 darran branches: 1.308.2; 1.308.8;
NetOctave NSP2000 driver, ported from FreeBSD and integrated with
opencrypto by CoyotePoint Systems. The FreeBSD driver source was recently
made available by NBMK Encryption Technologies.

The port includes some currently unused code which implements kernel and
user space interfaces for the driver in FreeBSD. These are left in at this
time to facilitate the port of these interface to NetBSD if they are of
interest.

1.308 Thu Oct 30 00:02:14 GMT 2008 darran branches: 1.308.2; 1.308.8;
NetOctave NSP2000 driver, ported from FreeBSD and integrated with
opencrypto by CoyotePoint Systems. The FreeBSD driver source was recently
made available by NBMK Encryption Technologies.

The port includes some currently unused code which implements kernel and
user space interfaces for the driver in FreeBSD. These are left in at this
time to facilitate the port of these interface to NetBSD if they are of
interest.

/src/sys/arch/mac68k/mac68k/
H A Dmachdep.c1.308 Sat Dec 24 20:07:15 GMT 2005 perry branches: 1.308.20; 1.308.22;
Remove leading __ from __(const|inline|signed|volatile) -- it is obsolete.

1.308 Sat Dec 24 20:07:15 GMT 2005 perry branches: 1.308.20; 1.308.22;
Remove leading __ from __(const|inline|signed|volatile) -- it is obsolete.

1.308 Sat Dec 24 20:07:15 GMT 2005 perry branches: 1.308.20; 1.308.22;
Remove leading __ from __(const|inline|signed|volatile) -- it is obsolete.

/src/doc/
H A DBRANCHES1.308 Thu Jun 02 22:15:22 GMT 2011 cherry Add note about cherry-xenmp branch

/src/sys/dev/raidframe/
H A Drf_netbsdkintf.c1.308 Thu Apr 03 18:55:26 GMT 2014 christos branches: 1.308.2;
Add a "soft" root option, leaving the current default as "force root", so
as not to break existing configurations.

1.308 Thu Apr 03 18:55:26 GMT 2014 christos branches: 1.308.2;
Add a "soft" root option, leaving the current default as "force root", so
as not to break existing configurations.

/src/sys/dev/usb/
H A Dehci.c1.319 Sat Oct 28 21:18:31 GMT 2023 riastradh ehci(4): Fix bug causing missed wakeups since ehci.c 1.308.

For reasons beyond me now, I used cv_signal on the same cv that is
used to wait for the doorbell to be available _and_ to wait for the
host controller to acknowledge the doorbell. Which means when the
host controller acknowledges the doorbell, we might wake some thread
waiting for the doorbell to be available -- and leave the thread
waiting for the doorbell acknowledgment hanging indefinitely.

PR port-i386/57662

XXX pullup-10

1.308 Sun Mar 13 11:29:10 GMT 2022 riastradh ehci(4): Fix doorbell synchronization.

ehci_sync_hc was previously subject to spurious wakeup, in which case
the CPU might proceed from aborting and recycle a DMA buffer before
the hardware was done writing to it. Now the code is not subject to
spurious wakeup -- it waits (up to the 1sec timeout) for the relevant
interrupt to be delivered, not for anything else.

/src/sys/rump/librump/rumpkern/
H A Drump.c1.308 Mon Aug 11 04:27:24 GMT 2014 ozaki-r branches: 1.308.2;
Do cprng_fast_init in rump_init

It fixes rump bootup failure:
panic: kernel diagnostic assertion "off < percpu_nextoff" failed:
file "/usr/src/lib/librump/../../sys/rump/../kern/subr_percpu.c", line 76

1.308 Mon Aug 11 04:27:24 GMT 2014 ozaki-r branches: 1.308.2;
Do cprng_fast_init in rump_init

It fixes rump bootup failure:
panic: kernel diagnostic assertion "off < percpu_nextoff" failed:
file "/usr/src/lib/librump/../../sys/rump/../kern/subr_percpu.c", line 76

/src/sys/dev/
H A DDEVNAMES1.308 Mon Apr 09 19:06:18 GMT 2018 christos rename cobalt panel to ledpanel

/src/sys/arch/sparc/sparc/
H A Dmachdep.c1.308 Mon Apr 18 00:26:11 GMT 2011 rmind Replace malloc with kmem, and remove M_SUBPROC.

/src/sys/arch/mips/mips/
H A Dmips_machdep.c1.308 Thu Apr 24 23:55:18 GMT 2025 riastradh mips: Make sure stack is aligned on exec.

The only caller of setregs, sys/kern/kern_exec.c execve_runproc,
already guarantees STACK_ALIGNBYTES alignment, so let's assert it but
out of paranoia also clear the bits anyway just in case for non-
DIAGNOSTIC builds.

Based on a patch by rin@.

PR kern/59327: user stack pointer is not aligned properly

/src/sys/arch/i386/conf/
H A DINSTALL1.308 Mon May 28 21:54:38 GMT 2007 pavel Move ixpide from INSTALL to INSTALL_LARGE. This controller is apparently
found only in southbridges of relatively recent motherboards.
/src/sys/arch/i386/i386/
H A Dtrap.c1.308 Sat Aug 20 23:48:50 GMT 2022 riastradh x86: Split most of pmap.h into pmap_private.h or vmparam.h.

This way pmap.h only contains the MD definition of the MI pmap(9)
API, which loads of things in the kernel rely on, so changing x86
pmap internals no longer requires recompiling the entire kernel every
time.

Callers needing these internals must now use machine/pmap_private.h.
Note: This is not x86/pmap_private.h because it contains three parts:

1. CPU-specific (different for i386/amd64) definitions used by...

2. common definitions, including Xenisms like xpmap_ptetomach,
further used by...

3. more CPU-specific inlines for pmap_pte_* operations

So {amd64,i386}/pmap_private.h defines 1, includes x86/pmap_private.h
for 2, and then defines 3. Maybe we should split that out into a new
pmap_pte.h to reduce this trouble.

No functional change intended, other than that some .c files must
include machine/pmap_private.h when previously uvm/uvm_pmap.h
polluted the namespace with pmap internals.

Note: This migrates part of i386/pmap.h into i386/vmparam.h --
specifically the parts that are needed for several constants defined
in vmparam.h:

VM_MAXUSER_ADDRESS
VM_MAX_ADDRESS
VM_MAX_KERNEL_ADDRESS
VM_MIN_KERNEL_ADDRESS

Since i386 needs PDP_SIZE in vmparam.h, I added it there on amd64
too, just to keep things parallel.

/src/sys/arch/alpha/conf/
H A DGENERIC1.308 Sat Jan 06 08:49:34 GMT 2007 pavel spaces -> tabs in the new zstty lines.

Completed in 307 milliseconds

12345