Use sbintime_t timeouts with precision control to get very accurate
timing. It costs little to always ask for about 1% accuracy, and the
not so new event timer implementation usual delivers that, and when
it can't it gets much closer than our previous coarse timeouts and
buggy simple countdown.
The 2 fastest atkbd repeat rates have periods 34 and 38 msec, and ukbd
pretended to support rates in between these. This requires
sub-microsecond precision and accuracy even to handle the 4 msec
difference very well, but ukbd asked the timeout subsystem for timeouts
of 25 msec and the buggy simple countdown of this gave a a wide range
of precisions and accuracies depending on HZ and other timer
configuration (sometimes better than 25 msec but usually more like 50
msec). We now ask for and usually get precision and accuracy of about
1% for each repeat and much better on average.
The 1% accuracy is overkill. Rounding of 30 cps to 34 msec instead of
33 already gives an error of +2% instead of -1%, and ut AT keyboards on
PS/2 interfaces have similar errors.
A timeout is now scheduled for every keypress and release. This allows
some simplifications that are not done. It allows removing the timeout
scheduling for exiting polled mode where it was unsafe in ddb mode. This
is done. Exiting polled mode had some problems with extra repeats. Now
exiting polled mode lets an extra timeout fire and the state is fudged
so that the timeout handler does very little.
The sc->time_ms variable is unsigned to avoid overflow. Differences of
it need to be signed. Signed comparisons were emulated by testing an
emulated sign bits. This only works easily for '<' comparisonss, but
we now need a '<=' comparison. Change the difference variable to
signed and use a signed comparison. Using unsigned types here didn't
prevent overflow bugs but just reduced them. Overflow occurs with
n repeats at the silly repeat period of [U]INT_MAX / n. The old countdown
had an off by 1 error, and the simplifications would simply count down
1 to 0 and not need to accumulate possibly-large repeat repeats.
And stringent input IC version negotiate message checks.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7614
RESET is not used by the hn(4) at all, and RESET_CMPLT does not even
have a rid to match with the pending requests. So, let's put it
onto an independent switch branch and log a warning about it.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7602
kbdcontrol -r fast is documented to give a non-emulated atkbd's fastest
rate of 250.34, but is misimplemented to request this as 0.0. ukbd
supports many nonstandard rates, although it is currently too inaccurate
by a factor of several hundred for non-huge nonstandard rates to be
useful. It mapped 0.0 to 200.0. A repeat delay of 0 means a rate of
infinity which is quite fast, but physical constraints limit this to
a few MHz and the inaccuracies made it almost usable.
Convert 0.0 to the documented 250.34.
Also convert negative args and small args to the 250.34 minimal ones,
like atkbd does. This is for KDSETREPEAT -- the 2 versions of the
deprecated KDSETRAD have bounds checking. Keep not doing any bounds
checking or conversions for upper limits since nonstandard large
delays are useful for testing.
The inaccuracies are dependent on HZ and the timeout implementation.
With the old timeout implementation and HZ = 1000, 200.0 probably
worked better to emulate 250.34 than 250.34 itself. HZ = 100 gives
roundoff errors that accidentally reduce the inaaccuracies, and
event timers reduce the inaccuracies even more, so 200.0 was giving
more like itself (perhaps 215.15 on average but sometimes close to
10 msec repeat which is noticebly too fast). This commit makes 0.0
noticeably too slow, like 250.34 always was.
handling. This resulted in the window target being left uninitialized
when an underflow occured.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7617
This code should be able to support later AMD chipsets as well, but that
hasn't been tested.
SB800 supports accessing several different SMBus buses using the same
set of constrol registeirs plus special PMIO registers that control which
bus is selected. This could be exposed to consumers as several smb devices
each talking to its bus. This feature is not implemented yet.
MFC after: 2 weeks
So that Hyper-V can leverage them instead of rolling its own definition.
Discussed with: hps
Reviewed by: hps
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7592
its own job because this breaks the simplified QEMU XHCI TRB parser,
which expects the complete USB control transfer as a series of back to
back TRBs. The old behaviour is kept under #ifdef in case this change
breaks enumeration of any USB devices.
PR: 212021
MFC after: 1 week
The previous fix was tested mainly on 3 AT keyboards with USB adaptors where
it works. 1 USB keyboard doesn't translate Alt-PrintScreen, so the software
has to do it.
Reorganize a little to share some code and to not translate the unusual usb
scan code0x8a unless an Alt modified is set. Remove redundant check of Alt
modifiers. Translation now more clearly filters out Alt-PrintScreen before
the check.
The table of errors fixed in the previous commit had many bugs. Correct
table:
K_RAW Ctl-PrintScreen: E0-2A-E0-37 -> E0-37
K_RAW Alt-PrintScreen (with 4 comb. of Ctl/Shift): 79 -> 54
K_RAW Pause/Break (with 4 comb. of Alt/Shift): E0-46 -> E1-1D-45
K_CODE PrintScreen (with 4 comb. of Ctl/Shift): 54 -> 5c
K_CODE Alt-PrintScreen (with 4 comb. of Ctl/Shift): 7e -> 54
K_CODE Pause/Break (with 8 comb. of Ctl/Alt/Shift): 6c -> 68
That is 25 of 32 shift combinations for 2 keys fixed. All 16 combinations
were broken for K_CODE and thus also for K_XLATE.
is_completion_pending governs whether or not a callout will be scheduled
when new work is queued on the IOAT device. If true, a callout is
already scheduled, so we do not need a new one. If false, we schedule
one and set it true. Because resetting the hardware completed all
outstanding work but failed to clear is_completion_pending, no new
callout could be scheduled after a reset with pending work.
This resulted in a driver hang for polled-only work.
configuring of EP0 and non-EP0 into xhci_cmd_evaluate_ctx() and
xhci_cmd_configure_ep() respectivly. This resolves some errors when
using XHCI under QEMU and gets is more in line with the XHCI
specification.
PR: 212021
MFC after: 1 week
And don't recreate chimney sending buffer for each primary channel
open, it is now created in device_attach DEVMETHOD and destroyed
in device_detach DEVMETHOD.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7574
It seems Killer E2200/E2400 has a BIOS misconfiguration or silicon
bug which triggers DMA write errors when driver uses advertised
maximum payload size. Force the maximum payload size to 128 bytes
in DMA configuration.
This change should fix occasional DMA write errors reported on
Killer E2200.
Tested by: <psy0nic@sys-tek.org>
controllers. For Gigabit Ethernet version of AR816x, AR813x/AR815x
except L1D controller, use vendor recommended ASPM parameters.
While here, increase alc_dma_burst array size. Broken H/W can
return bogus value in theory.
so they are memory independent which allows for handling panics
triggered by the keyboard driver itself, typically via CTRL+ALT+ESC
sequences. Or if the USB keyboard driver was processing a key at the
moment of panic. Allow UKBD to be attached while keyboard polling is active.
Tested by: Bruce Evans <bde@freebsd.org>
MFC after: 1 week
everything was broken. The cases that I noticed were Ctrl-PrintScreen
not being mapped to the virtual scancode 0x5c (debug) and Pause not being
mapped to the physical/virtual scancode 0x46 (slock).
These keys are the most complicated ones due to kludges to give some
compatibility back to before AT keyboards.
Alt-PrintScreen must pretend to be a separate key from PrintScreen
even at the "raw" level. The (unique) usb code for it is 0x8a and we
just have to map this to our unique virtual scancode 0x54, but we
mapped it first to the internal code 0x7e and then to 0x79 which is a
key on the Japanese 106/109 keyboard. This fix is under the
UKBD_EMULATE_ATASCANCODE option which shouldn't be used for non-AT
keyboards. If it is, then the syscons Japanese keymaps have nothing
of importance for code 0x79 and can easily be changed. 0x54 is also
unimportant in Japanese and US keymaps.
NonAlt-PrintScreen and NonCtl-Pause/Break had many much larger bugs with
smaller compatibility problems from fixing them. The details are too
ugly to give here. Summary of the changed (hex) codes:
K_RAW PrintScreen (Ctl, Shift, Ctl-Shift): E0-2A-E0-37 -> E0-37
K_RAW Alt-PrintScreen (all shift states): 79 -> 54
K_RAW Pause/Break (unshifted, Shift, Alt, Alt-Shift)): E0-46 -> E1-1D-45
K_CODE ALT-PrintScreen (all shift states): 79 -> 54
That is 15 of 32 shift combinations for 2 keys fixed, with 8 easy cases
from the 79 -> 54 remapping.
The difference is only large and with no workaround using a keymap for
for K_RAW, but this affects other modes when ukbd is layered under kbmux
because kbmux keeps all subdevices in K_RAW mode and translates. Oops.
I used kbdmux to generate the above table of changes.
This driver only supports 10Mb Ethernet using PIO (the hardware supports
DMA, but the driver only does PIO). There are not any PCCard adapters
supported by this driver, only ISA cards. In addition, it does not use
bus_space but instead uses bcopy with volatile pointers triggering a
host of warnings. (if_ie.c is one of 3 files always built with
-Wno-error)
Relnotes: yes
The wl(4) driver supports pre-802.11 PCCard wireless adapters that
are slower than 802.11b. They do not work with any of the 802.11
framework and the driver hasn't been reported to actually work in a
long time.
Relnotes: yes
The si(4) driver supported multiport serial adapters for ISA, EISA, and
PCI buses. This driver does not use bus_space, instead it depends on
direct use of the pointer returned by rman_get_virtual(). It is also
still locked by Giant and calls for patch testing to convert it to use
bus_space were unanswered.
Relnotes: yes
This permits a single early return for VF devices in the routines that
add sysctl nodes.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7512
Specifically, the FW_PORT_CMD may or may not work for a VF (the PF
driver can choose whether or not to permit access to this command),
so don't attempt to fetch port information on a VF if permission is
denied by the PF.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7511
While here, mark which parameters are PF-specific and which are
VF-specific.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7508
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.
Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493
And don't recreate RXBUF for each primary channel open, it is now
created in device_attach DEVMETHOD and destroyed in device_detach
DEVMETHOD.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7556
On the first switch we previously released the newly allocated keyboard
instead of the old one. Keyboard state was very confused afterwards for
further keyboard switches.
Submitted by: bde
axge_setmulti()/axge_setpromisc() with axge_rxfilter().
Multicast filter programming and promiscuous mode requires
access to a common RX configuration register so there is no need to
use separate functions with added complexity. axge_rxfilter() does
not read back AXGE_RCR register since accessing a register in USB
is too slow and we already have all knowledge of required
configuration. Rebuilding RX filter configuration is simpler and
faster than manipulating every bits after reading back the
register.
Note, axge_rxfilter() does not set RCR_IPE(IP header alignment on
32bit boundary) to disable extra padding bytes insertion. The
extra padding wastes ethernet to USB host bandwidth as well as
complicating RX handling logic. Current USB framework requires
copying RX frames to mbufs so there is no need to worry about
alignment. Previously axge_rx_frame() performed wrong bound check
due to the extra padding and it was broken when RX checksum
offloading is disabled. See added comment in axge_rx_frame () for
actual RX packet layout.
In axge_init(), disable WOL. It's meaningless to enable WOL in
normal operation.
In axge_rxeof(), use properly sized mbuf rather than blindly
allocating a mbuf cluster.
Use RX H/W checksum offloading only when administrator requested RX
checksum offloading. Previously it always used RX H/W checksum
offloading result regardless of RX checksum offloading state.
Separate L4 checksum offloading validation from L3 one and properly
set required offloading bits for each layer. This is to fix setting
L4 checksum offloading bits for L3 packets.
There are still lots of RX errors(probably RX FIFO overflows) under
moderate load. Users are strongly recommended to enable ethernet
flow control.
Reviewed by: kevlo (initial version), hselasky
