| created | 2019-03-30T17:07:28Z |
|---|---|
| begin | 2019-03-25T00:00:00Z |
| end | 2019-03-26T00:00:00Z |
| path | src/sys |
| commits | 6 |
| date | 2019-03-25T02:28:20Z | |||
|---|---|---|---|---|
| author | kevlo | |||
| files | src/sys/dev/pci/if_alc.c | log | diff | annotate |
| message |
- Formatting fixes and in some cases bringing things a bit closer to the original code - Remove unusedd function decarations From Brad |
|||
| date | 2019-03-25T14:17:58Z | |||
|---|---|---|---|---|
| author | fcambus | |||
| files | src/sys/arch/amd64/amd64/efifb.c | log | diff | annotate |
| message |
Revert back to using previous values for EFIFB_WIDTH and EFIFB_HEIGHT, as raising them expose an issue which breaks inteldrm on large screen resolutions. Reported by chris@, and by Lucas Raab on bugs@. Thanks! |
|||
| date | 2019-03-25T18:45:27Z | |||
|---|---|---|---|---|
| author | guenther | |||
| files | src/sys/arch/amd64/amd64/intr.c | log | diff | annotate |
| src/sys/arch/amd64/include/intrdefs.h | log | diff | annotate | |
| message |
X86_IPI_NAMES's only use was #if 0'ed out; delete both ok kettenis@ deraadt@ |
|||
| date | 2019-03-25T18:48:12Z | |||
|---|---|---|---|---|
| author | guenther | |||
| files | src/sys/arch/amd64/amd64/cpu.c | log | diff | annotate |
| src/sys/arch/amd64/amd64/ipifuncs.c | log | diff | annotate | |
| src/sys/arch/amd64/amd64/pctr.c | log | diff | annotate | |
| src/sys/arch/amd64/include/intrdefs.h | log | diff | annotate | |
| src/sys/arch/amd64/include/pctr.h | log | diff | annotate | |
| message |
Fix pctr(4) issues with MP and suspend: - use an IPI to notify other CPUs toi update CR4 and the MSRs - use the cpu(4) resume callback to restore the pctr(4) settings after suspend/hibernate ok kettenis@ deraadt@ |
|||
| date | 2019-03-25T20:29:25Z | |||
|---|---|---|---|---|
| author | guenther | |||
| files | src/sys/arch/amd64/amd64/cpu.c | log | diff | annotate |
| src/sys/arch/amd64/amd64/pmap.c | log | diff | annotate | |
| message |
panic() adds a newline, so don't include one in the format string ok krw@ millert@ |
|||
| date | 2019-03-25T23:32:00Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_tc.c | log | diff | annotate |
| src/sys/kern/kern_time.c | log | diff | annotate | |
| src/sys/sys/timetc.h | log | diff | annotate | |
| message |
MP-safe timecounting: new rwlock: tc_lock tc_lock allows adjfreq(2) and the kern.timecounter.hardware sysctl(2) to read/write the active timecounter pointer and the .tc_adj_freq member of the active timecounter safely. This eliminates any possibility of a torn read/write for the .tc_adj_freq member when we drop the KERNEL_LOCK from the timecounting layer. It also ensures the active timecounter does not change in the midst of an adjfreq(2) call. Because these are not high-traffic paths, we can get away with using tc_lock in write-mode to ensure combination read/write adjtime(2) calls are relatively atomic (a) to other writer adjtime(2) calls, and (b) to settimeofday(2)/clock_settime(2) calls, which cancel ongoing adjtime(2) adjustment. When the KERNEL_LOCK is dropped, an unprivileged user will be able to create some tc_lock contention via adjfreq(2); it is very unlikely to ever be a problem. If it ever is actually a problem a lockless read could be added to address it. While here, reorganize sys_adjfreq()/sys_adjtime() to minimize code under the lock. Also while here, make tc_adjfreq() void, as it cannot fail under any circumstance. Also also while here, annotate various globals/struct members with lock ordering details. With lots of input from mpi@ and visa@. ok visa@ |
|||