Turns out genfb_softc must be at the start of its own device_private,
so we can't have it in the middle of a structure, and certainly can't
have potentially multiple genfbs per graphics device. Failing to do
this is why entering ddb didn't work with an i915drmkms console.
Instead of putting a genfb_softc into each drm_fb_helper, put a
device_t into each drm_fb_helper and create a new intelfb(4) device
for each Intel framebuffer. This will be more flexible, too, in case
we want accelerated framebuffers later on. (XXX Need to adapt the
radeon code, which I'm disabling until that happens to avoid breaking
the build.)
While here, defer disabling VGA, vga_cndetach, and genfb_attach until
we're actually ready to do them all together along with the mode
switch. This should reduce the amount of time during which the
screen is blanked, in case it hangs.
Screen blanks on boot on the Ivy Bridge system with
DRM error in cpt_serr_int_handler: PCH transcoder A FIFO underrun
But after that everything is OK. Appears to be an upstream problem.
To investigate...
I think there's a cache flushing issue somewhere -- there are little
display artefacts on my T60.
their content into "itp". There's no need for re-reading the whole binary and
trying to find this section again. Just use "itp".
DEBUG_FREEBSD_ELF is now unused, so remove its references in amd64/conf/ALL
and i386/conf/ALL.
- Add 4G freelist to i386 -- there may be higher addresses if PAE.
- Add 64G and 1T freelists to amd64.
- Simplify freelist setup code and condense it into a table.
- Add x86_select_freelist to get a freelist guaranteed to yield
addresses no greater than a prescribed maximum address.
x86_select_freelist takes a uint64_t, not a paddr_t or bus_addr_t, so
that you can pass in, e.g., a 36-bit maximum address without needing
to write conditionals for i386/PAE.
No objections on port-x86:
https://mail-index.netbsd.org/port-i386/2014/05/21/msg003277.htmlhttps://mail-index.netbsd.org/port-amd64/2014/05/21/msg002062.html
trace_enter()/trace_exit() calls.
This fix some cases where tracing show unexpected SYSRET number value
because some syscalls, such as setcontext(2), modified the trapframe
register values.
- Remove PCU_KERNEL (hi matt!) and significantly simplify the code.
This experimental feature was tried on ARM did not meet the expectations.
It may be revived one day, but it should be done in a much simpler way.
- Add a message structure for xcall function, pass the LWP ower and thus
optimise a race condition: if LWP is discarding its state on a remote CPU,
but another LWP already did it - do not cause an unecessary re-faulting.
- Reduce the variety of flags for PCU operations (only PCU_VALID and
PCU_REENABLE are used now), pass them only to the pcu_state_load().
- Rename pcu_used_p() to pcu_valid_p(); hopefully it is less confusing.
- pcu_save_all_on_cpu: SPL ought to be used here.
- Update and improve the pcu(9) man page; it needs wizd(8) though.
space for struct sigframe_siginfo (+ alignment) is allocated just below.
Confirmed by the following tests:
tests/lib/libc/gen/t_siginfo
tests/lib/libc/sys/t_sigtimedwait
tests/lib/libc/sys/t_sigaction
tests/lib/libc/sys/t_sigqueue
The result is only written to sysctl nodes at the moment.
I see:
machdep.fpu_save = 3 (implies xsaveopt)
machdep.xsave_size = 832
machdep.xsave_features = 7
Completely common up the i386 and amd64 machdep sysctl creation.
kernel stack to the top.
Change the pcb layouts so that fpu save area is at the end and is
64byte aligned ready for xsave (saving the ymm registers).
Welcome to 6.99.32
