| created | 2018-11-29T22:25:53Z |
|---|---|
| begin | 2018-06-20T00:00:00Z |
| end | 2018-06-21T00:00:00Z |
| path | src/sys |
| commits | 7 |
| date | 2018-06-20T05:51:25Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/i915/intel_lvds.c | log | diff | annotate |
| message |
drm/i915: Disable LVDS on Radiant P845 From Ondrej Zary e88640adf6fe0709466f814a26753d78184a598c in linux 4.4.y/4.4.136 b3fb22733ae61050f8d10a1d6a8af176c5c5db1a in mainline linux |
|||
| date | 2018-06-20T09:44:51Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/net/pfkeyv2.c | log | diff | annotate |
| message |
Use the socket lock rather than the KERNEL_LOCK() in pfkey_sendup(). inputs & ok visa@ |
|||
| date | 2018-06-20T10:48:55Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_ktrace.c | log | diff | annotate |
| src/sys/kern/kern_pledge.c | log | diff | annotate | |
| message |
Grab and/or assert for the KERNEL_LOCK() in in ktrace & pledge. This is required to run network syscall mostly without the KERNEL_LOCK(). ok visa@, kettenis@ as part of a larger diff. |
|||
| date | 2018-06-20T10:52:49Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_descrip.c | log | diff | annotate |
| src/sys/kern/kern_sysctl.c | log | diff | annotate | |
| src/sys/kern/syscalls.master | log | diff | annotate | |
| src/sys/kern/uipc_syscalls.c | log | diff | annotate | |
| src/sys/kern/uipc_usrreq.c | log | diff | annotate | |
| src/sys/sys/file.h | log | diff | annotate | |
| message |
Unlock sendmsg(2) and sendto(2). These syscalls can now be executed w/o the KERNEL_LOCK() depending on the kind of socket. The current solution uses a single global mutex to serialize access to, and reference count, 'struct file'. ok visa@, kettenis@ |
|||
| date | 2018-06-20T10:53:30Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/init_sysent.c | log | diff | annotate |
| src/sys/kern/syscalls.c | log | diff | annotate | |
| src/sys/sys/syscall.h | log | diff | annotate | |
| src/sys/sys/syscallargs.h | log | diff | annotate | |
| message | regen | |||
| date | 2018-06-20T10:57:39Z | |||
|---|---|---|---|---|
| author | helg | |||
| files | src/sys/miscfs/fuse/fuse_vnops.c | log | diff | annotate |
| message | Fix formatting. | |||
| date | 2018-06-20T19:30:34Z | |||
|---|---|---|---|---|
| author | sthen | |||
| files | src/sys/arch/amd64/amd64/identcpu.c | log | diff | annotate |
| message |
On newer AMD parts, use CoreId (EBX) and NodeId (ECX) from cpuid 0x8000001e to detect smt cores. As there's no "smt id" on these like there is on Intel parts, check against other already-id'd cpus to detect which are additional smt threads on a core. jmatthew noticed some unusual (non-contiguous) numbering on an single socket EPYC 7551p but there's no indication that the actual ID numbers need to be sequential. "As long as we treat ci_core_id as just a number, that shouldn't be an issue" and OK kettenis@ ref: 54945 rev 1.14 - PPR for AMD Family 17h Models 00h-0Fh |
|||