MFC r270299 (dumbbell): vt_vga: When clearing video memory, don't read from it
The goal is to clear the video memory, in case an application drew to
it. So the content shouldn't be loaded in the latches, it can't be
trusted anyway.
Set fb_pbase properly on PowerPC in the case where we have to guess at
the right register bank for the framebuffer. Disable the assigned-
addresses path on SPARC since it is just a hack for IBM PPC systems
and was neither relevant for nor worked on SPARC anyway.
Should check fb_read method presence instead of double check for fb_write.
r269620 (nwhitehorn):
Retire various intertwined bits of fbd(4) and vt_fb, in particular the
pixel modification indirection. No actual drivers use it and those
that might (e.g. creatorfb) use custom implementations of
vd_bitbltchr().
Make mmap() of the console device when using ofwfb work like other
supported framebuffer drivers. This lets ofwfb work with
xf86-video-scfb and makes the driver much more generic and less
PCI-centric. This changes some user-visible behavior and will require
updates to the xorg-server port on PowerPC when using ATI graphics
cards.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
MFC r268880:
Allow mappings of memory not previously direct-mapped by the kernel when
calling mmap on /dev/mem and add a handler for the possible userland
machine checks that may result. Remove some pointless and wrong copy/paste
that has been in here for a decade as well.
This results in a /dev/mem with identical semantics to the x86 version.
Add a simple unaccelerated vt(4) framebuffer driver for Sun
framebuffers handled by creator(4) (Sun Creator 3D, Elite 3D, etc.).
This provides vt(4) consoles on all devices currently supported by
syscons on sparc64. The driver should also be easily adaptable to
support newer Sun framebuffers such as the XVR-500 and higher.
Many thanks to dumbbell@ (Jean-Sebastien Pedron) for testing this
remotely during development.
r269783 (dumbbell):
vt(4): Colors are indexed against a console palette, not a VGA palette
Move the PS3 framebuffer console to use vt instead of syscons and
adjust GENERIC64 for PowerPC to use vt with it.
Much to my chagrin, PS3 support seems to have bitrotted somewhat since
the last time I tried it. ehci panics on attach and interrupt handling
seems to be faulty. This should be fixed soon...
r269783 (dumbbell):
Fix two files forgotten in r269783 (vt_generate_cons_palette)
r268895 (nwhitehorn):
Enable X11 via xf86-video-scfb on the Playstation 3. This commit made
from an xterm running for the first time on said Playstation.
MFC r270512 r270513 r270754
- add comments which describe exit status codes of /usr/sbin/bhyve
- move bhyvectl --destroy outside of the while loop
- Use "file -s" so that we can run vmrun.sh against special devces such as
/dev/md memory files systems or zvols
In r253839 the default behaviour of ld(1) was changed such that all
libraries that need to be linked into an executable or library have to be
listed on the command line explicitly. This commit fixes a bug in ld(1)
where it would scan dependencies of the libraries on the command line and
link them if needed if they were also found in ld.so.cache.
The important bit of the patch is the initialisation of needed.by such that
libraries found by scanning dependencies are marked as such and not used in
the link.
MFC r270647: Add references to vt(4) and the configuration files in /usr/sha
MFC r270653: Update man-pages to correctly refer to changed pathes and namin
MFC r270657: More man pages that need to know about vt in addition to syscon
MFC r270659: (by pluknet@) Missed comma.
MFC r270660: Back-out the references to vt(4) from this man-page. It appears
MFC r270933: Add references to vt(4) to further man-pages.
MFC r270934: Final patches to the tools used to convert syscons keymaps for
MFC r270935: Add vt(4) support to the console initialisation script, specifi
Second batch of MFCs to add support for Unicode keymaps for use with vt(4).
It contains the following changes:
- Add references to vt(4) to relevant man-pages.
- Update comment in defaults/rc.conf to mention vt
- Update rc.d/syscons to warn about syscons keymaps used under vt.
An attempt is made to identify the vt keymap to load instead.
- Minor changes to the conversion tool based on mail comments on keymaps.
For reasons which are not clear, r254263 broke some PCMCIA and CardBus
bridges in strange ways, either rendering them unable to detect
insertion and removal events, or possibly unable to read from the
device behind the bridge.
This fixes at least one laptop, a Toshiba Tecra M5 with a Texas
Instruments PCxx12 (d=0x8039 v=0c104c) bridge. The very similar
Tecra M9 has the same bridge, but worked fine without this change.
The bridge chip has no I/O port BAR, and there is nothing in the spec
to suggest I/O decoding should be enabled; however enabling it fixes
the issue. Add an XXX comment to this effect.
marius [Wed, 3 Sep 2014 20:07:26 +0000 (20:07 +0000)]
MFC: r270885, r270948
- Nuke unused sdhci_softc.
- Static'ize sdhci_debug local to sdhci.c.
- Const'ify PCI device description strings.
- Nuke redundant resource ID members from sdhci_pci_softc.
- Nuke unused hw.sdhci_pci.debug tunable.
- Add support for using MSI instead of INTx, controllable via the tunable
hw.sdhci.enable_msi (defaulting to on) and tested with a RICOH R5CE823 SD
controller.
- Use NULL instead of 0 for pointers.
MFC r270280 by dumbbell: vt(4): Pause the flush timer while swithing window
This fixes bad looking refresh when switching window: squares instead
of text, flashing screen, and so on. In the worst case, vt_flush() came
at a very inappropriate timing and the screen was not refreshed at all
(leaving squares all over the place).
This doesn't fix the flickering of the screen with vt_vga, because the
sync signal is temporarily stopped and the video memory is cleared.
MFC vt(4) mouse cursor improvements from dumbbell:
r270269:
vt(4): Handle global and per-window mouse cursor toggle in one place
Before the global flag was set/unset using the CONS_MOUSECTL ioctl,
and the per-window flag through the MOUSE_SETLEVEL or MOUSE_SETMODE
ioctls.
Also, if the cursor is already enabled/disabled, return immediatly.
This avoids to reset the cursor's position to the center of the
screen.
This matches syscons' behavior.
While here, remove a trailing space and a redundant variable
declaration.
r270271:
vt(4): Mark cursor old position as dirty before reading the dirty area
Otherwise, the redraw is done during the next vt_flush run.
r270272:
vt(4): If the cursor is globally disabled, don't mark its position as dirty
This avoids unnecessary redraw. In particular, during boot, where the
cursor is disabled and its fake position is [0;0], this triggered a
refresh of the whole screen each time vt_flush() is called.
r270273:
vt(4): If the cursor didn't move, don't mark its position as dirty
Currently, this has no effect, because the cursor is always redrawn
anyway. But this will be useful after improvements to the
vd_bitbltchr_t callback API.
The vt_device structure members used to store the position of the
cursor as of the last redraw are renamed from vd_mdirty{x,y} to
vd_mold{x,y}. The associated comment is fixed too. Also, their value
is now expressed in pixels, not in character columns/row.
r270275:
vt(4): Mark the current cursor position as dirty
Like r270273, this has no effect for now, because the cursor is always
drawn. This is in preparation of future changes to vd_bitbltchr_t API.
r270278:
vt(4): Mark cursor position as dirty when we enable/disable it
MFC r270661:
Remove leading '/' from hardlink name when removing them from the
regular file name. This fixes the problem, when bsdtar can not create
hardlinks to extracted files.
On amd64, this would increase the binary size by 1.1MiB and
make it possible to examine zpool status offline, useful for
recovery and diagnostic purposes.
MFC r270666
Back in the days when the kernel was single threaded, testing
"vm_paging_target() > 0" was a reasonable way of determining if the
inactive queue scan met its target. However, now that other threads
can be allocating pages while the inactive queue scan is running, it's
an unreliable method. The effect of it being unreliable is that we
can start swapping out processes when we didn't intend to.
This issue has existed since the kernel was multithreaded, but the
changes to the inactive queue target in 10.0-RELEASE have made its
effects visible.
This change introduces a more direct method for determining if the
inactive queue scan met its target that is not affected by the actions
of other threads.
The UEFI framebuffer driver vt_efifb requires vt(4), so add a
mechanism for the startup routine to set the preferred console.
This change is ugly because console init happens very early in the
boot, making a cleaner interface difficult. This change is intended
only to facilitate the sc(4) / vt(4) transition, and can be reverted
once vt(4) is the default.
r268160: Fix typos in VTY constant names from r268158
r268982: Don't pass null kmdp to preload_search_info
Allow efifb to be used with xf86-video-scfb. This is important for EFI
systems without either a CSM or real graphics drivers, such as my
Lenovo Haswell laptop.
This provides working X with the small complication of a console
cursor permanently overlaid on the upper-left corner of the screen
that will be dealt with later.
r268771:
Allow console drivers active from early boot to be used with
xf86-video-scfb, rather than only drivers attached later on. This
involves a small amount of code duplication with dev/fb/fbd.c, which
will fixed later on.
Also improve performance of vt_blank() by making it not read from the
framebuffer unnecessarily.
On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs
set to uncacheable. This leads to execrable console performance. Once
PMAP is up, remap the framebuffer as write-combining. This reduces
boot time on my laptop by 60% when booting with EFI.
The SHT range 0x70000000-0x7fffffff is processor-specific. Pass the
ELF machine type header to sh_types so the section header type name can
be reported correctly for the given processor.
For all ranges report the actual value for unknown types.
Add MIPS-specific type SHT_MIPS_OPTIONS.
r269143 (andreast): Further improvements on elfdump, to follow up r269092:
- Add ARM specific section header types.
- Add SHT_GNU_HASH section header type.
- Improve reporting of undefined tags in d_tags.
- Add DT_GNU_HASH tag.
Reviewed by: emaste
r269337: add EM_AARCH64 64-bit ARM machine architecture
r269338: use existing ELF constants where available
r270303: Rename DT_FEATURE_1 to DT_FEATURE
This provides a minor cleanup in elfdump; there are otherwise no
consumers in the tree. Old SUN documentation can be found for either
variant, but GNU binutils switched to DT_FEATURE around 2000.
r270304: Remove extraneous _SUNW_ in reported DT_ names
MFC r257985:
Fix panic with RADIX_MPATH, when RTFREE_LOCKED() called for already
unlocked route. Use in6_rtalloc() instead of in6_rtalloc1. This helps
simplify the code and remove several now unused variables.
Fix a leak of the wired pages when unwiring of the PROT_NONE-mapped
wired region. Rework the handling of unwire to do the it in batch,
both at pmap and object level.
All commits below are by alc.
MFC r268327:
Introduce pmap_unwire().
MFC r268591:
Implement pmap_unwire() for powerpc.
MFC r268776:
Implement pmap_unwire() for arm.
MFC r268806:
pmap_unwire(9) man page.
MFC r269134:
When unwiring a region of an address space, do not assume that the
underlying physical pages are mapped by the pmap. This fixes a leak
of the wired pages on the unwiring of the region mapped with no access
allowed.
MFC r269339:
In the implementation of the new function pmap_unwire(), the call to
MOEA64_PVO_TO_PTE() must be performed before any changes are made to the
PVO. Otherwise, MOEA64_PVO_TO_PTE() will panic.
MFC r269365:
Correct a long-standing problem in moea{,64}_pvo_enter() that was revealed
by the combination of r268591 and r269134: When we attempt to add the
wired attribute to an existing mapping, moea{,64}_pvo_enter() do nothing.
(They only set the wired attribute on newly created mappings.)
MFC r269433:
Handle wiring failures in vm_map_wire() with the new functions
pmap_unwire() and vm_object_unwire().
Retire vm_fault_{un,}wire(), since they are no longer used.
MFC r269438:
Rewrite a loop in vm_map_wire() so that gcc doesn't think that the variable
"rv" is uninitialized.
ngie [Sun, 31 Aug 2014 23:09:23 +0000 (23:09 +0000)]
MFC r266650, r267172 (both by jmmv):
r266650:
Change libatf-c and libatf-c++ to be private libraries.
We should not be leaking these interfaces to the outside world given
that it's much easier for third-party components to use the devel/atf
package from ports.
As a side-effect, we can also drop the ATF pkgconfig and aclocal files
from the base system. Nothing in the base system needs these, and it
was quite ugly to have to get them installed only so that a few ports
could build. The offending ports have been fixed to depend on
devel/atf explicitly.
Reviewed by: bapt
r267172:
Homogenize libatf-* version numbers with upstream.
The libatf-* major version numbers in FreeBSD were one version ahead of
upstream because, when atf was first imported into FreeBSD, the upstream
numbers were not respected. This is just confusing and bound to cause
problems down the road.
Fix this by taking advantage of the fact that libatf-* are now private
and that atf is not yet built by default. However, and unfortunately, a
clean build is needed for tests to continue working once "make
delete-old-libs" has been run; hence the note in UPDATING.
trasz [Sun, 31 Aug 2014 21:52:26 +0000 (21:52 +0000)]
MFC r270402:
Autofs softc needs to be global anyway, so don't pass it as a local
variable, and don't store in autofs_mount. Also rename it from 'sc'
to 'autofs_softc', since it's global and extern.
trasz [Sun, 31 Aug 2014 21:18:23 +0000 (21:18 +0000)]
MFC r270096:
Bring in the new automounter, similar to what's provided in most other
UNIX systems, eg. MacOS X and Solaris. It uses Sun-compatible map format,
has proper kernel support, and LDAP integration.
There are still a few outstanding problems; they will be fixed shortly.
Reviewed by: allanjude@, emaste@, kib@, wblock@ (earlier versions)
Phabric: D523
Relnotes: yes
Sponsored by: The FreeBSD Foundation
jilles [Sun, 31 Aug 2014 20:34:06 +0000 (20:34 +0000)]
MFC r256800: pathchk: Ensure bytes >= 128 are considered non-portable
characters.
This was not broken on architectures such as ARM where char is unsigned.
Also, remove the first non-portable character from the output. POSIX does
not require this, and printing the first byte may yield an invalid byte
sequence with UTF-8.
PR: 165988
Reported by: Nicolas Rachinsky
Relnotes: yes
projects / FreeBSD / stable / 10.git / log