While wrestling with another problem that my custom kernel has that
GENERIC doesn't, I double-checked the Xorg/intel behavior while running
GENERIC. The behavior is the same: the intel driver with "TearFree" on
with or without "AccelMethod" "SNA" is only marginally improved but still
doesn't draw
Updating src tree:
P
src/external/bsd/jemalloc/include/jemalloc/internal/tsd_malloc_thread_cleanup.h
P src/external/bsd/jemalloc/include/jemalloc/internal/tsd_tls.h
U src/lib/libc/arch/riscv/gdtoa/gd_qnan.h
P src/libexec/ld.elf_so/ld.elf_so.1
P src/libexec/ld.elf_so/rtld.c
P
So, the following has been happening (and for go111), but I don't
understand the errors, nor have I any clue as to their cause.
Note that I do have Go 1.11.1 installed and working A-OK on this same
machine, but built against somewhat older OS.
13:31 [510] $ go version
go version
On Sun, 14 Apr 2019, John D. Baker wrote:
> So it appears my kernel paring has elided something that is now
> necessary.
Comparing my custom config for netbsd-8 versus -current, the only
obvious relevant difference is how "options COMPAT_XX" is handled.
I tend to aggressively elide all COMPAT_XX
On Sat, 13 Apr 2019, John D. Baker wrote:
> Again, this works fine on NetBSD-8_STABLE.
As a sanity check, I booted -current GENERIC rather than the machine's
custom kernel and the serial port works fine (although I'm still using
the rewired adapter with RTS/CTS looped). Rebooting with the