Inspecting the PRM no more than 0x3F data segments, DS, of size 16 bytes is
allowed.
Worst case scenario summary of DS usage:
Header is fixed: 2 DS
Maximum inlining: 98 => (98 - 2) / 16 = 6 DS
Remainder: 0x3F - 2 - 6 = 55 DS (mbuf frags)
Previously a value of 56 DS was used and this would work in the
normal case because not all inline data area was used up.
MFC after: 3 days
Approved by: re (marius)
Sponsored by: Mellanox Technologies
r337289 has a side effect of reducing usb frame 0 buffer size down to
touch report size. That broke some devices e.g. "Raydium Touch System"
which are capable of generating non-touch frames of bigger length.
Fix it with enlarging frame 0 buffer up to internal wmt(4) buffer size.
Reported by: Roberto Fernandez Cueto <roberfern@gmail.com>
Tested by: Roberto Fernandez Cueto <roberfern@gmail.com>
Approved by: re (gjb)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16772
This appeared to be required to have EFI RT support and EFI RTC
enabled by default, because there are too many reports of faulting
calls on many different machines. The knob is added to leave the
exceptions unhandled to allow to debug the actual bugs.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: re (rgrimes)
Differential revision: https://reviews.freebsd.org/D16972
Print error message in verbose mode when CLOCK_SETTIME() clock_if.m
method failed. For EFIRT RTC clock, add error code for the failure of
CLOCK_GETTIME() report.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: re (rgrimes)
Differential revision: https://reviews.freebsd.org/D16972
play the MIDI files through /dev/sequencer device with tools like
playmidi. The audio output will go through the external MIDI device
such like wavetable synthesis card.
Reviewed by: matk (a long time ago), kib
Approved by: re (kib)
Tested with: Terratec SiXPack 5.1+ + Yamaha DB50XG
MFC after: 4 weeks
The PCIOCLISTVPD ioctl on /dev/pci is used to fetch a list of VPD
key-value pairs for a specific PCI function. It is used by
'pciconf -l -V'. The list is stored in a userland-supplied buffer as
an array of variable-length structures where the key and data length
are stored in a fixed-size header followed by the variable-length
value as a byte array. To facilitate walking this array in userland,
<sys/pciio.h> provides a PVE_NEXT() helper macro to return a pointer
to the next array element by reading the the length out of the current
header and using it to compute the address of the next header.
To simplify the implementation, the ioctl handler was also using
PVE_NEXT() when on the user address of the user buffer to compute the
user address of the next array element. However, the PVE_NEXT() macro
when used with a user address was reading the value's length by
indirecting the user pointer. The value was ready after the current
record had been copied out to the user buffer, so it appeared to work
on architectures where user addresses are directly dereferencable from
the kernel (all but powerpc and i386 after the 4:4 split). The recent
enablement of SMAP on amd64 caught this violation however. To fix,
add a variant of PVE_NEXT() for use in the ioctl handler that takes an
explicit value length.
Reported by: Jeffrey Pieper @ Intel
Reviewed by: kib
Approved by: re (gjb)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16800
Fix the build of the GENERIC-MMCCAM kernel config after the sdhci_xenon
driver was commited.
While here correct sdhci_fdt and tegra_sdhci, even with MMCCAM they do
need to depend on sdhci(4)
Reported by: Reshetnikov Dmitriy <genserg@hotmail.com>
Approved by: re (kib)
Sponsored by: Rubicon Communications, LLC ("NetGate")
properly in a couple of places in the driver.
Submitted by: Krishnamraju Eraparaju @ Chelsio
Approved by: re@ (rgrimes@)
Sponsored by: Chelsio Communications
The ip/ipv6 header files are included only if the appropriate definition
exists, but the driver was missing similar checks when using the
ip and ip6_hdr structures.
If the kernel was not built with the INET or INET6 option, the driver
was preventing kernel from being built.
To fix that, the missing ifdef checks were added to the driver.
PR: Bug 230886
Submitted by: Michal Krawczyk <mk@semihalf.com>
Reported by: O. Hartmann
Approved by: re (gjb)
Obtained from: Semihalf
MFC after: 1 week
Sponsored by: Amazon, Inc.
This code works for some people, but hasn't been updated in a long
time. Still allow people to use this code for the moment, but put a
big, nasty obsolete message to inform and encourage people to move to
the port.
Approved by: re@ (gjb)
Differential Review: https://reviews.freebsd.org/D16894
given in random(4).
This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.
Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.
PR: 230870
Reviewed by: cem
Approved by: so(delphij,gtetlow)
Approved by: re(marius)
Differential Revision: https://reviews.freebsd.org/D16898
error in the function hypercall_memfree(), where the wrong arena was being
passed to kmem_free().
Introduce a per-page flag, VPO_KMEM_EXEC, to mark physical pages that are
mapped in kmem with execute permissions. Use this flag to determine which
arena the kmem virtual addresses are returned to.
Eliminate UMA_SLAB_KRWX. The introduction of VPO_KMEM_EXEC makes it
redundant.
Update the nearby comment for UMA_SLAB_KERNEL.
Reviewed by: kib, markj
Discussed with: jeff
Approved by: re (marius)
Differential Revision: https://reviews.freebsd.org/D16845
the foreground and background colours. In bitblt_text functions, compare
values to this cache and don't re-draw the characters if they haven't changed.
When invalidating the display, clear this cache in order to force characters
to be redrawn; also force full redraws between suspend/resume pairs since odd
artifacts can otherwise result.
When scrolling the display (which is where most time is spent within the vt
driver) this yields a significant performance improvement if most lines are
less than the width of the terminal, since this avoids re-drawing blanks on
top of blanks.
(Note that "re-drawing" here includes writing to the VGA text mode buffer; on
virtualized systems this can be extremely slow since it triggers a glyph
being rendered onto a 640x480 screen).
On a c5.4xlarge EC2 instance (with emulated text mode VGA) this cuts the time
spent in vt(4) during the kernel boot from 1200 ms to 700ms; on my laptop
(with a 3200x1800 display) the corresponding time is reduced from 970 ms down
to 155 ms.
Reviewed by: imp, cem
Approved by: re (gjb)
Relnotes: Significant speedup in vt(4) and the system boot generally.
Differential Revision: https://reviews.freebsd.org/D16723
they don't check the result of BUS_READ_IVAR(9) and silently return stack
garbage on failure in case a bus doesn't implement a particular instance
variable for example. With MMC bridges not providing MMCBR_IVAR_RETUNE_REQ,
yet, this in turn can cause mmc(4) to get into a state in which re-tuning
seems to be necessary but is inappropriate, causing mmc_wait_for_request()
to fail. Thus, don't use __BUS_ACCESSOR() for mmcbr_get_retune_req() and
instead provide a version of the latter which returns retune_req_none if
reading MMCBR_IVAR_RETUNE_REQ fails.
One more straight-forward solution would have been to change mmc(4) to not
call mmcbr_get_retune_req() if the current transfer mode doesn't require
re-tuning to begin with. However, for modes such as SDR50, it depends on
the controller whether periodic re-tuning is need. Therefore, knowledge of
whether a particular transfer mode does require re-tuning should be kept
to the bridge drivers.
This change is the generic version of r338271, as intended not requiring
bridge drivers to be touched (unless transfer modes beyond high speed are
to be supported that is).
Approved by: re (gjb)
for security, and the excess just slows things down badly.
PR: 230808
Submitted by: rwmaillists@googlemail.com, but tweeked by me
Reported by: Danilo Egea Gondolfo <danilo@FreeBSD.org>
Reviewed by: cem,delphij
Approved by: re(rgrimes)
Approved by: so(delphij)
MFC after: 1 Month
Differential Revision: https://reviews.freebsd.org/D16873
Revert r338177, r338176, r338175, r338174, r338172
After long consultations with re@, core members and mmacy, revert
these changes. Followup changes will be made to mark them as
deprecated and prent a message about where to find the up-to-date
driver. Followup commits will be made to make this clear in the
installer. Followup commits to reduce POLA in ways we're still
exploring.
It's anticipated that after the freeze, this will be removed in
13-current (with the residual of the drm2 code copied to
sys/arm/dev/drm2 for the TEGRA port's use w/o the intel or
radeon drivers).
Due to the impending freeze, there was no formal core vote for
this. I've been talking to different core members all day, as well as
Matt Macey and Glen Barber. Nobody is completely happy, all are
grudgingly going along with this. Work is in progress to mitigate
the negative effects as much as possible.
Requested by: re@ (gjb, rgrimes)
SDHCI_TRNS_ACMD12 is to be set only for multiple-block read/write
commands without data length information, so don't unconditionally
set this bit. The result matches what e. g. Linux does.
- Section 2.2.19 of the SDHCI specification version 4.20 states that
SDHCI_ACMD12_ERR should be only valid if SDHCI_INT_ACMD12ERR is set
and hardware may clear SDHCI_ACMD12_ERR when SDHCI_INT_ACMD12ERR is
cleared (differing silicon behavior is specifically allowed, though).
Thus, read SDHCI_ACMD12_ERR before clearing SDHCI_INT_ACMD12ERR.
While at it, use the 16-bit accessor rather than the 32-bit one for
reading the 16-bit SDHCI_ACMD12_ERR.
- SDHCI_INT_TUNEERR isn't one of the ROC bits in SDHCI_INT_STATUS so
clear it explicitly.
- Add missing prototypes and sort them.
netfront_backend_changed() is called from the xenwatch_thread(), which means
that the curvnet is not set. We have to set it before we can call things like
arp_ifinit().
PR: 230845
Due to hardware limitation AMD I2C controller can't trigger pending
interrupt if interrupt status has been changed after clearing
interrupt status bits. So, I2C will lose the interrupt and IO will be
timed out. Implements a workaround to disable I2C controller interrupt
and re-enable I2C interrupt before existing interrupt handler.
Submitted by: rajfbsd@gmail.com
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16720
The original NVMe API used bit-fields to represent fields in data
structures defined by the specification (e.g. the op-code in the command
data structure). The implementation targeted x86_64 processors and
defined the bit fields for little endian dwords (i.e. 32 bits).
This approach does not work as-is for big endian architectures and was
changed to use a combination of bit shifts and masks to support PowerPC.
Unfortunately, this changed the NVMe API and forces #ifdef's based on
the OS revision level in user space code.
This change reverts to something that looks like the original API, but
it uses bytes instead of bit-fields inside the packed command structure.
As a bonus, this works as-is for both big and little endian CPU
architectures.
Bump __FreeBSD_version to 1200081 due to API change
Reviewed by: imp, kbowling, smh, mav
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D16404
As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.
Users on powerpc, 32-bit hardware, or with GPUs predating Radeon
and i915 will need to install the graphics/drm-legacy-kmod. All
other users should be able to use one of the LinuxKPI-based ports:
graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod.
MFC: never
Approved by: core@
became unused in FreeBSD 12.x as a side-effect of the NUMA-related
changes.)
Reviewed by: kib, markj
Discussed with: jeff, re@
Differential Revision: https://reviews.freebsd.org/D16825
This is an amalgam of a patch by Doug Ambrisko to
generalize uart_acpi_find_device, imp moving the
ACPI table to uart_dev_ns8250.c and advice by jhb
to work around a bug in the EPYC 3151 BIOS
(the BIOS incorrectly marks the serial ports as
disabled)
Reviewed by: imp
MFC after: 8 weeks
Differential Revision: https://reviews.freebsd.org/D16432
Without this patch, some CS4614 cards will need users to reload the driver manually or
the hardware won't be initialised properly. Something like:
# kldload snd_csa
# kldunload snd_csa
# kldload snd_csa
Tested with: Terratec SiXPack 5.1+
I was not aware Warner was making or planning to make forward progress in
this area and have since been informed of that.
It's easy to apply/reapply when churn dies down.
Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.
Mostly done with the coccinelle 'spatch' tool:
$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);
@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);
$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci
(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)
Tinderbox'd (-DMAKE_JUST_KERNELS).
