created | 2020-11-01T20:36:53Z |
---|---|
begin | 2020-10-30T00:00:00Z |
end | 2020-10-31T00:00:00Z |
path | src/sys |
commits | 6 |
date | 2020-10-30T13:07:48Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/powerpc64/include/fdt.h | log | diff | annotate |
src/sys/arch/powerpc64/powerpc64/machdep.c | log | diff | annotate | |
message | Add code to determine the console devie node. |
date | 2020-10-30T13:11:11Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/powerpc64/dev/astfb.c | log | diff | annotate |
message |
Allow astfb(4) to become the console. At this point this is a "late" switch and early kernel boot messages will appear on opalcons(4) until astfb(4) attaches. |
date | 2020-10-30T13:26:29Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/powerpc64/dev/opalcons.c | log | diff | annotate |
message |
Add a comment that explains why the major/minor of the device is set unconditionally now that astfb(4) can be used as the console as well. Only print that we're the console if we actually are. |
date | 2020-10-30T13:36:45Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/powerpc64/dev/astfb.c | log | diff | annotate |
message |
No need to print that we're the console device; wsdisplay(4) will do that for us. |
date | 2020-10-30T17:11:20Z | |||
---|---|---|---|---|
author | deraadt | |||
files | src/sys/arch/m88k/m88k/trap.c | log | diff | annotate |
message |
As done on other architectures, narrow the KERNEL_LOCK only around uvm_fault (and some similar "fault emulation" code which scream danger danger) tested by aoyama |
date | 2020-10-30T19:39:00Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/amd64/stand/efiboot/conf.c | log | diff | annotate |
src/sys/arch/amd64/stand/efiboot/efiboot.c | log | diff | annotate | |
message |
Use a 64MB block to load the kernel to deal with kernel growth. Note that the first 16MB of the block are currently unused since we link our kernels at physical address 0x01000000. Therefore 32MB is no longer enough to load a kernel that is now larger than 16MB. Fixes the "entry point at 0x10010000" hang that people have reported on some machines. ok patrick@, naddy@, deraadt@ |