access it via pointers (still to only 1 instance, now with a less
generic name).
Restructure the "and" and "or" masks as border and interior masks
(where the "and" mask was for the union of the border and the interior).
"and" and "or" were only a detail in a not very good implementation,
and after fixing that the union was only used to calculate the border
at runtime.
Use the metric data in more places to clip to active pixels earlier.
available starting with T6. The values in the timer holdoff registers
are multiplied by the scaling factor before use.
dev.<nexus>.<n>.holdoff_timers shows the final values of the
timers in microseconds.
MFC after: 1 week
Sponsored by: Chelsio Communications
mode.
Direct mode always supported widths up to 32, except for its hard-coded
16s matching the pixmap size. Text mode is still limited to 9 its 2x2
character cell method and missing adjustments for the gap between
characters, if any.
Cursor heights can be almost anything in graphics modes.
much as possible, by avoiding null ANDs and ORs to the frame buffer.
Mouse cursors are fairly sparse, especially for their frame. Pixels
are written in groups of 8 in planar mode and the per-group sparseness
is not as large, but it still averages about 40% with the current
9x13 mouse cursor. The average drawing time is reduced by about this
amount (from 22 usec constant to 12.5 usec average on Haswell).
This optimization is relatively larger with larger cursors. Width 10
requires 6 frame buffer accesses per line instead of 4 if not done
sparsely, but rarely more than 4 if done sparsely.
mode.
Don't manually unroll the 2 inner loops. On Haswell, doing so gave a
speedup of about 0.5% (about 4 cycles per iteration out of 1400), but
hard-coded a limit of width 9 and made better better optimizations
harder to see. gcc-4.2.1 -O does the unrolling anyway, unless tricked
with a volatile hack. gcc's unrolling is not very good and gives a
a speedup of about half as much (about 2 cycles per iteration). (All
timing on i386.)
Manual unrolling was only feasible because the inner loop only iterates
once or twice. Usually twice, but a dynamic check is needed to decide,
and was not moved from the second-innermost loop manually or by gcc.
This commit basically adds another dynamic check in the inner loop.
Cursor widths of 10-17 require 3 iterations in the inner loop and this
is not so easy to unroll -- even gcc stops at 2.
TXP_CMD_WAIT argument allocates a response buffer. If the allocation
fails, txp_ext_command() returns an error and it's handed in caller.
Found by: PVS-Studio
the method a lot.
Reduce the AND mask to the complement of the cursor's frame, so that area
inside the frame is not drawn first in black and then in lightwhite. The
AND-OR method is only directly suitable for the text mouse image, since
it doesn't go to the hardware there. Planar mode Mouse cursor drawing
takes 10-20 usec on my Haswell system (approx. 100 graphics accesses
at 130 nsec each), so the transient was not visible.
The method used the fancy read mode 1 and its color compare and color
don't care registers with value 0 in them so that all colors matched.
All that this did was make byte reads of frame buffer memory return 0xff,
so that the x86 case could obfuscate read+write as "and". The read must
be done for its side effect on the graphics controller but is not used,
except it must return 0xff to avoid affecting the write when the write
is obfuscated as a read-modify-write "and". Perhaps that was a good
optimization for 8088 CPUs where each extra instruction byte took as
long as a byte memory access.
Just use read+write after removing the fancy read mode. Remove x86
ifdefs that did the "and". After removing the "and" in the non-x86
part of the ifdefs, fix 4 of 6 cases where the shift was wrong.
in unusual cases. Optimize and significantly clean up removal in this
renderer. Optimize removal in the vga direct renderer.
Removal only needs to be done in the border (the part with pixels) in
both cases. The planar renderer used the condition scp->xoff > 0 to
test whether a right border exists. This actually tests for a left
border, and when the total horizontal border is 8 pixels, rounding gives
only a right border. This was the unusual broken case. An example
is easy to configure using something like "vidcontrol -f 8x16 iso-8x16
-g 79x25 MODE_27".
Optimize the planar case a little by only removing 9x13 active pixels
out of 16x16. Optimize it a lot by not doing anything if there is no
overlap with the border. Don't unroll the main loop or hard-code so
many assumptions about font sizes in it. On my Haswell system, graphics
memory and i/o accesses takes about 520 cycles each so optimizations from
unrolling are in the noise.
Optimize the direct case to not do anything if there is no overlap with
the border. Do a sanity check on the saveunder's coordinates. This
requires a previous change to pass non-rounded coordinates.
The previous commit also fixed the coordinates passed to the mouse
removal renderer. The coordinates were rounded down to a character
boundary, and thus essentially unusable. The renderer had to keep
track of the previous position, or clear a larger area. The latter
is only safe in the border, which is all that needs special handling
anyway.
I think no renderer depends on the bug. They have the following
handling:
- gfb sparc64: this seems to assume non-rounded coordinates
- gfb other: does nothing (seems to be missing border handling)
- vga text: does nothing (doesn't need border handling)
- vga planar: clears extras in the border, with some bugs. The fixes
will use the precise coordinates to optimize.
- vga direct: clears at the previous position with no check that it
is active, and clears everything. Checking finds this bug.
- others: are there any?
reduce hard-coded assumptions on font sizes so that the cursor size
can be more independent of the font size. Moving the mouse in the
buggy mode left trails of garbage.
The mouse cursor currently has size 9x13 in all modes. This can occupy
2x3 character cells with 8x8 fonts, but the algorithm was hard-coded
for only 2x2 character cells. Rearrange to hard-code only a maximum
cursor size (now 10x16) and to not hard-code in the logic. The number
of cells needed is now over-estimated in some cases.
2x3 character cells should also be used in text mode with 8x8 fonts
(except with large pixels, the cursor size should be reduced), but
hard-coding for 2x2 in the implementation makes it not very easy to
expand, and it practice it shifts out bits to reduce to 2x2.
In graphics modes, expansion is easier and there is no shifting out
for 9x13 cursors (but 9 is a limit for hard-coding for 2 8-bit VGA
cells wide). A previous commit removed the same buggy hard-coding for
removal at a lower level in planar mode. Another previous commit fixed
the much larger code for lower-level removal in direct mode; this is
independent of the font size so worked for 8x8 fonts. Text mode always
depended on the higher-level removal here, and always worked since
everything was hard-coded consistently for 2x2 character cells.
scteken_init(). Move the internals of scteken_sync() into a local
function to help do this.
scteken_init() reset or adjusted the default attribute and screen
position at least 3 and 5 times, respectively. Warm init shouldn't
do any more than reset the "input" state.
(scterm-sc.c (which still works after minor editing), only resets
the escape state and the saved cursor position, and then does a
nearly-null sync of the current color.)
This mainly broke mode changes, and was most noticeable when the
background color is not teken's default (usually black). Then the
screen gets cleared in the wrong color. vidcontrol restores the
default normal attribute and tries to restore the default reverse
attribute. vidcontrol doesn't clear the screen again after restoring
the attribute(s), and it is too late to do it there without flicker.
Now the default normal attribute is restored before the change affects
the rendering.
When the foreground color is not teken's default, clearing with the
wrong attributes gave strange cursor colors for some cursor types.
The default reverse attribute is not restored since it is unsupported.
2/3 of the clobbering was from 2 resetting window resizing calls. The
second one is needed to restore the size, but must not reset. Window
resizing also sanitizes the cursor position, and after the main reset
resets the window size, the cursor row would often be adjusted from
24 to 23 if it were not already reset to 0. scteken_sync() is good
for restoring the window size and the cursor position in the correct
order, but was unusable at init time since scp->ts is not always
initialized then. Adjust to use its internals.
I didn't notice any problems from the cursor reset. The cursor should
be reset, and a previous fix was to reset it consistently a little
later.
Doing nothing for warm init works almost as well, if not better. It
is not very useful to reset the escape state for mode changes, since
the reset is especially likely to be null then. The escape state is
most likely to be non-initial and corrupted by its most normal uses
-- sloppy non-atomic output where a context switch or just mixing
stdout with stderr splits up escape sequences.
Omit unused rates while initializing / dumping Tx power values.
They were not accessed anywhere (except for debugging), so this is
(mostly) no-op.
Tested with
* RTL8188EU, STA mode.
* RTL8812AU, STA mode.
Found by: PVS-Studio
1. Deadcode in ecore_init_cache_line_size(), qlnx_ioctl() and
qlnx_clean_filters()
2. ARRAY_VS_SINGLETON issue in qlnx_remove_all_mcast_mac() and
qlnx_update_rx_prod()
MFC after:5 days
like I hoped, since they are needed for removing parts over the border.
Continue fixing bugs in them.
In the vga planar mode renderer, remove removal of the part of the
image over the text window. This was hard-coded for nearly 8x16 fonts
and in practice didn't remove enough for 8x8 fonts. This used the
wrong attribute over cutmarked regions. The caller refreshes with the
correct attribute later, so the attribute bug only caused flicker.
The caller uses the same hard-coding, so the refreshes fix up all the
spots with the wrong attribute, but keep missing the missed spots.
This still gives trails of bits of cursors for cursor motions in the
affected configurations (mainly depth 4 modes with 8x8) fonts. 8x14
fonts barely escape the problem since although the cursor is drawn
as 16x16, its active part is only 9x13 and the active part fits in
the hard-coded 2x2 character cell window for 8x14 fonts. 8x8 fonts
need a 2x3 window.
In the fb non-sparc64 renderer, the buggy image removal was buggier
and was already avoided by returning before it. Remove it completely
and fix nearby style bugs. It was essentially the same as for the vga
planar mode renderer (obfuscated by swapping x and y). This was buggier
since fb should handle more types of hardware so the hard-coding is
wronger.
The remaining fb image removal is also buggier. It never supported
software cursors drawn into the border, and the hardware cursor is
probably broken by other bugs to be fixed soon.
The MFC will include a compat definition of smp_no_rendevous_barrier()
that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10313
(that is, in all supported 8, 15, 16 and 24-color modes). Moving the
mouse cursor while holding down a button (giving cut marking) left a
trail of garbage from misremoved mouse cursors (usually colored
rectangles and not cursor shapes). Cases with a button not held down
worked better and may even have worked.
No renderer support for removing (software) mouse cursors is needed
(and many renderers don't have any), since sc_remove_mouse_image()
marks for update the region containing the image and usually much
more. The mouse cursor can be (partially) over as many as 4 character
cells, and removing it in only the 1-4 cells occupied by it would be
best for efficiency and for avoiding flicker. However,
sc_remove_mouse_image() can only mark a single linear region and
usually marks a full row of cells and 1 more to be sure to cover the
4 cells. It always does this, so using the special rendering method
just wastes even more time and gives even more flicker. The special
methods will be removed soon.
The general method always works. vga_pxlmouse_direct() appeared to
defer to it by returning immediately if !on. However,
vga_pxlmouse_direct() actually did foot-shooting using a disguised
saveunder method. Normal order near a mouse move is:
(1) remove the mouse cursor in the renderer (optional)
(2) remove the mouse cursor again and refresh the screen over the
mouse cursor and much more from the vtb. When the mouse has
actually moved and a button is down, many attributes in this
region are changed to be up to date with the new cut marking
(3) draw the keyboard cursor again if it was clobbered by the update
(4) draw the mouse cursor image in its new position.
The bug was to remove the mouse cursor again in step (4), before the
drawing it again in (4), using a saveunder that was valid in step (1)
at best. The quick fix is to use the saveunder in step (1) and not
in step (4). Using it in step (4) also used it before it was
initialized, initially and after mode and screen switches.
in the vga renderer. Removal used stale attributes and didn't try to
merge with the current attribute for cut marking, so special rendering
of cut marking was lost in many cases. The gfb renderer is too broken
to support special rendering of cut marking at all, so this change is
supposed to be just a style fix for it. Remove all traces of the
saveunder method which was used to implement this bug.
Fix drawing of the cursor image in text mode, only in the vga
renderer. This used a stale attribute from the frame buffer instead
of from the saveunder, but did merge with the current attribute for
cut marking so it caused less obvious bugs (subtle misrendering for
the character under the cursor).
The saveunder method may be good in simpler drivers, but in syscons
the 'under' is already saved in a better way in the vtb. Just redraw
it from there, with visible complications for cut marking and
invisible complications for mouse cursors. Almost all drawing
requests are passed a flag 'flip' which currently means to flip to
reverse video for characters in the cut marking region, but should
mean that the the characters are in the cut marking regions so should
be rendered specially, preferably using something better than reverse
video. The gfb renderer always ignores this flag. The vga renderer
ignored it for removal of the text cursor -- the saveunder gave the
stale rendering at the time the cursor was drawn. Mouse cursors need
even more complicated methods. They are handled by drawing them last
and removing them first. Removing them usually redraws many other
characters with the correct cut marking (but transiently loses the
keyboard cursor, which is redrawn soon). This tended to hide the
saveunder bug for forward motions of the keyboard cursor. But slow
backward motions of the keyboard cursor always lost the cut marking,
and fast backwards motions lost in for about 4 in every 5 characters,
depending on races with the scrn_update() timeout handler. This is
because the forward motions are usually into the region redrawn for
the mouse cursor, while backwards motions rarely are.
Text cursor drawing in the vga renderer used also used a
possibly-stale copy of the character and its attribute. The vga
render has the "optimization" of sometimes reading characters from the
screen instead of from the vtb (this was not so good even in 1990 when
main memory was only a few times faster than video RAM). Due to care
in update orders, the character is never stale, but its attribute
might be (just the cut marking part, again due to care in order).
gfb doesn't have the scp->scr pointer used for the "optimization", and
vga only uses this pointer for text mode. So most cases have to
refresh from the vtb, and we can be sure that the ordering of vtb
updates and drawing is as required for this to work.
so that we can use it in iflib to detect pause frames.
The igb(4) driver definitely used to use this in its old timer function and
I see no reason to restrict it to that driver only.
Sponsored by: Limelight Networks
(and accurate).
T4 and later have an extra bit for page shift so the maximum page size
is 8TB (shift of 12 + 31) instead of 128MB (12 + 15). This saves space
in the chip's PBL (physical buffer list) when registering very large
memory regions.
MFC after: 3 days
Sponsored by: Chelsio Communications
- Move all bitmap related functions from bitops.h to bitmap.h, similar
to what Linux does.
- Apply some minor code cleanup and simplifications to optimize the
generated code when using static inline functions.
- Implement the following list of bitmap functions which are needed by
drm-next and ibcore:
- bitmap_find_next_zero_area_off()
- bitmap_find_next_zero_area()
- bitmap_or()
- bitmap_and()
- bitmap_xor()
- Add missing include directives to the qlnxe driver
(davidcs@ has been notified)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Under certain conditions on certain versions of Hyper-V, the RNDIS
rxfilter is _not_ zero on the hypervisor side after the successful
RNDIS initialization, which breaks the assumption of any following
code (well, it breaks the RNDIS API contract actually). Clear the
RNDIS rxfilter explicitly, drain packets sneaking through, and drain
the interrupt taskqueues scheduled due to the stealth packets.
Reported by: dexuan@
MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D10230
Synthetic keyboard is the only supported keyboard on GEN2 Hyper-V.
Submitted by: Hongjiang Zhang <honzhan microsoft com>
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D10196
The tsec_error_intr_locked() is called with the global lock owned (e.g.
the transmit and the receive lock are both owned). We must not call
tsec_receive_intr_locked() while owning the transmit lock. The normal
receive interrupt takes care that frames are received, this is none of
the business of the error interrupt.
Submitted by: Sebastian Huber <sebastian.huber_AT_embedded-brains.de>
Use a method similar to the if_dwc driver. Use a wmb() before the flags of the
first transmit buffer of a frame are written.
Group transmit/receive structure members for better cache efficiency.
Tested on P1020RDB. TCP transmit throughput increases from 60MiB/s to
90MiB/s.
Submitted by: Sebastian Huber <sebastian.huber_AT_embedded-brains.de>
Timeout is now effectively a boolean rather than a time-remaining. This was
missed in r316478, but included in the original patch (mis-merged with a manual
merge).
The status indicators are not set immediatly after a command. Discard
the first value.
Unlock the PHY mutex after a timeout in tsec_init_locked().
Tested on the P1020RDB.
Submitted by: Sebastian Huber <sebastian_DOT_huber_AT_embedded-brains_DOT_de>
mode. This works around bugs in at least 2 Intel BIOSes for our
subsequent setting of the DAC back to 8-bit mode. The bug caused dark
(mostly 1/4-intensity) colors for all except the first setting to a
VESA graphics mode (including for settings to the current mode).
Remove restoration (with less bits) of the palette in vesa_unload()
after resetting the DAC to 6-bit mode. Depend on the BIOS to keep
the palette consistent with the DAC for the simpler reset case like
we do everywhere else in places that are actually important.
Setting the video mode should reset everything to defaults, although
we usually don't want that. Even the buggy BIOSes set the DAC to the
default 6-bit mode, and set the palette to a default that matches the
DAC. We don't undo the reset for most things, but we do undo it for
the DAC (more precisely, we change to an 8-bit DAC if possible, and
this is the only way that we set to an 8-bit DAC; it is accidental
that if the DAC was in 8-bit mode from a previous mode switch then
setting it to 8-bit mode is an undo). The buggy BIOSes are confused
by our setting of the DAC to 8-bit mode in the "undo" case. They
should multiply palette entries by 4 to match, but they actually leave
all palette entries except #2 (green) and #248-255 (unused) untouched.
Green is mysteriously scaled from 0x2a to 0x6a, and #248-255 are scaled
correctly.
Our support for the 8-bit DAC had almost no effect except to enable
bugs. Syscons barely supports 16 colors, so it doesn't benefit much
from having a palette with 16 million colors instead of only 256K.
Applications can manage the palette using FBIO_{GET,SET}PALETTE, but
the palette managed by this is only used in the less interesting modes
(text and non-truecolor graphics modes up to 8 bits wide), and the
kernel loses the changes on any mode switch (including to another vt
in a different mode).
Improve existing BGX detection and adjust it to support both
new and older ThunderX firmwares. Match BGX FDT nodes by name
and reg. Match PHY instances by qlm-mode and name.
Tested on Firmware Version: 2016-09-30 09:12:11
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D9863
position. Especially the screen size, and potentially everything except
the input state and attributes. Do this by changing the cursor position
setting method to a general syncing method.
Use proper constructors instead of copying to create kernel terminal
contexts. We really want clones and not new instances, but there is
no method for cloning and there is nothing in the active instance that
needs to be cloned exactly.
Add proper destructors for kernel terminal contexts. I doubt that the
destructor code has every been reached, but if it was then it leaked the
memory of the clones.
Remove freeing of statically allocated memory for the non-kernel terminal
context for the same terminal as the kernel. This is in the nearly
unreachable code. This used to not happen because delicate context
swapping made the user context use the dynamic memory and kernel
context the static memory. I didn't restore this swapping since it
would have been unnatural to have all kernel contexts except 1 dynamic.
The constructor for terminal context has bad layering for reasons
related to the bug. It has to return static memory early before
malloc() works. Callers also can't allocate memory until after the
first constructor selects an emulator and tells upper layers the size
of its context. After that, the cloning hack required the cloning
code to allocate the memory, but for all other constructors it would
be better for the terminal layer to allocate and deallocate the
memory in all cases.
Zero the memory when allocating terminal contexts dynamically.
the thread that deals with socket state changes. This eliminates
various bad races with the ithread.
Submitted by: KrishnamRaju ErapaRaju @ Chelsio (original version)
MFC after: 3 days
Sponsored by: Chelsio Communications
This patch brings 802.1q support for Marvell 88E606x ethernet switches.
Test is done on 88E6065 chip (Aterm WR1200).
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10144
1) They are using wrong tag (Tx) + map (Rx) combination.
2) Rx descriptor is already synchronized in iwn_notif_intr()
3) It's not needed for transmitted data since device does not change
mbuf contents.
Tested with Intel 6205 (amd64), STA mode.
Newer VGAs don't support any mono modes, but bugs in the tables created
2 virtual mono modes (#45 90x43 and #112 80x43) that behaved more
strangely than crashing. 90-column modes are tweaked 80-column ones
and also fail to work on newer VGAs. #45 did crash (hang) on some
hardware.
it to a separate state for each CPU.
Terminal "input" is user or kernel output. Its state includes the current
parser state for escape sequences and multi-byte characters, and some
results of previous parsing (mainly attributes), and in teken the cursor
position, but not completed output. This state must be switched for kernel
output since the kernel can preempt anything, including itself, and this
must not affect the preempted state more than necessary. Since vty0 is
shared, it is necessary to affect the frame buffer and cursor position and
history, but escape sequences must not be affected and attributes for
further output must not be affected.
This used to work. The syscons terminal state contained mainly the parser
state for escape sequences and attributes, but not the cursor position,
and was switched. This was first broken by SMP and/or preemptive kernels.
Then there should really be a separate state for each thread, and one more
for ddb, or locking to prevent preemption. Serialization of printf() helps.
But it is arcane that full syscons escape sequences mostly work in kernel
printf(), and I have never seen them used except by me to test this fix.
They worked perfectly except for the races, since "input" from the kernel
was not special in any way.
This was broken to use teken. The general switch was removed, and the
kernel normal attribute was switched specially. The kernel reverse
attribute (config option SC_CONS_REVERSE_ATTR) became unused, and is
still unusable because teken doesn't support default reverse attributes
(it used to only be used via the ANSI escape sequence to set reverse
video).
The only new difficulty for using teken seems to be that the cursor
position is in the "input" state, so it must be updated in the active
input state for each half of the switch. Do this to complete the
restoration.
The per-CPU state is mainly to make per-CPU coloring work cleanly, at
a cost of some space. Each CPU gets its own full set of attribute
(not just the current attribute) maintained in the usual way. This
also reduces races from unserialized printf()s. However, this gives
races for serialized printf()s that otherwise have none. Nothing
prevents the CPU doing the a printf() changing in the middle of an
escape sequence.
Some code was additionally moved for (future) lock splitting.
Tested with Intel 6205, STA mode.
Differential Revision: https://reviews.freebsd.org/D10106
Do not try to use errno(2) codes here; instead, just return unique
value (1) when radio is disabled via hardware switch and another
one (-1) for any other error in initialization path.
Tested with Intel 6205, STA mode.
This can significantly reduce scan duration thus saving time and power.
EBS failure reported by FW disables EBS for current connection. It is
re-enabled upon new connection attempt on any WLAN interface.
Obtained from: dragonflybsd.git 89f579e9823a5c446ca172cf82bbc210d6a054a4
Add support for early boot access to NVRAM variables, using a new
bhnd_nvram_data_getvar_direct() API to support zero-allocation direct
reading of NVRAM variables from a bhnd_nvram_io instance backed by the
CFE NVRAM device.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D9913
r315083 essentially reverted r263954 which was made for a good reason,
but didn't take into account AACRAID_DEBUG.
Now both types of build should be clean.
MFC after: 5 days
No MFC to: stable/10
* All the supported firmwares have these flags set.
* This removes the following flags:
IWM_UCODE_TLV_FLAGS_PM_CMD_SUPPORT,
IWM_UCODE_TLV_FLAGS_NEWBT_COEX,
IWM_UCODE_TLV_FLAGS_BF_UPDATED,
IWM_UCODE_TLV_FLAGS_D3_CONTINUITY_API,
IWM_UCODE_TLV_FLAGS_STA_KEY_CMD,
IWM_UCODE_TLV_FLAGS_DEVICE_PS_CMD,
IWM_UCODE_TLV_FLAGS_SCHED_SCAN,
IWM_UCODE_TLV_FLAGS_RX_ENERGY_API,
IWM_UCODE_TLV_FLAGS_TIME_EVENT_API_V2
* Also remove definitions and code for dealing with the v1 time-event api.
* Remove unneeded calc_rssi() function.
Obtained from: dragonflybsd.git d078c812418d0e2c3392e99fa25fc776d07bdfad
Let firmware do its best first, and if it can't, try software recovery.
I would remove software timeout handler completely, but found bunch of
complains on command timeout on sparc64 mailing list few years ago, so
better be safe in case of interrupt loss.
MFC after: 2 weeks
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
For 24xx and above use 2 vectors (default and response queue).
For 26xx and above use 3 vectors (default, response and ATIO queues).
Due to global lock interrupt hardlers never run simultaneously now, but
at least this allows to save one regitster read per interrupt.
MFC after: 2 weeks
Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful
in loop mode, which probably doesn't worth having this hack in 2017.
MFC after: 2 weeks
When I initially did this 11n TX work in days of yonder, my 802.11 standards
clue was ... not as finely tuned. One of the things in 802.11-2012 (which
I guess technically was after I did this work, but I'm sure it was like this
in the previous rev?) is that among other traffic classes, three things are
important:
* group addressed frames should be default non-QoS, even if they're QoS frames, and
* group addressed frames should have a seqno out of a different space than the
per-TID QoS one; and because of this
* group addressed frames, being non-QoS, should never be in the Block-ACK window
for TX.
Now, net80211 and now this code cheats by using the non-QOS TID, but ideally
we'd introduce a separate seqno space just for multicast/group traffic for
TX and RX comparison.
Later extensions (eg reliable multicast / multimedia) express what one should do
when doing multicast traffic in a TID. Now, technically we /could/ do group traffic
as QoS traffic and throw it into a per-TID seqno space, but this definitely
introduces ordering issues when you take into account things like CABQ behaviour.
(Ie, if some traffic in the TID goes into the CABQ and some doesn't, because
it's doing a split of multicast and non-multicast traffic, then you have
seqno ordering issues.)
So, until someone implements 802.11vv reliable multicast / multimedia extensions,
group traffic is non-QoS.
Next, software/hardware queue TID mapping. In the past I believed the WME tagging
of frames because well, net80211 had a habit of tagging things like management
traffic with it. But, then we also map QoS traffic categories to TIDs as well.
So, we should obey the TID! But! then it put some management traffic into higher
WME categories too, as those frames don't have QoS TIDs. But! It'd do things like
put things like QoS action frames into higher WME categories, when they should
be kept in-order with the rest of the traffic for that TID. So! Given all of this,
the ath(4) driver does overrides to not trust the WME category.
I .. am undoing some of this. Now, the TID has a 1:1 mapping to the hardware
queue. The TID is the primary source of truth now for all QoS traffic.
The WME is only used for non-QoS traffic. This now means that any TID traffic
queued should be consistently queued regardless of WME, so things like the
"TX finished, do more TX" that is occuring right now for transmit handling
should be "better".
The consistent {TID, WME} -> hardware queue mapping is important for
transmit completion. It's used to schedule more traffic for that
particular TID, because that {many TID}:{1 TXQ} mapping in ath_tx_tid_sched()
is used for driving completion. Ie, when the hardware queue completes,
it'll walk that list of scheduled TIDs attached to that TXQ.
The eventual aim is to get ready for some other features around putting
some data into other hardware queues (eg for better PS-POLL support,
uAPSD, support, correct-er TDMA support, etc) which requires that
I tidy all of this up in preparation for then introducing further
TID scheduling that isn't linked to a hardware TXQ (likely a per-WME, per-TID
driver queue, and a per-node driver queue) to enable that.
Tested:
* AR9380, STA mode
* AR9380, AR9580, AP mode
There were two copies of the code: one in generic code was half-broken, and
another in platform code was never called. Leave only one in generic code
and working.
MFC after: 2 weeks
for vt. Restore syscons' rendering of background (bg) brightness as
foreground (fg) blinking and vice versa, and add rendering of blinking
as background brightness to vt.
Bright/saturated is conflated with light/white in the implementation
and in this description.
Bright colors were broken in all cases, but appeared to work in the
only case shown by "vidcontrol show". A boldness hack was applied
only in 1 layering-violation place (for some syscons sequences) where
it made some cases seem to work but was undone by clearing bold using
ANSI sequences, and more seriously was not undone when setting
ANSI/xterm dark colors so left them bright. Move this hack to drivers.
The boldness hack is only for fg brightness. Restore/add a similar hack
for bg brightness rendered as fg blinking and vice versa. This works
even better for vt, since vt changes the default text mode to give the
more useful bg brightness instead of fg blinking.
The brightness bit in colors was unnecessarily removed by the boldness
hack. In other cases, it was lost later by teken_256to8(). Use
teken_256to16() to not lose it. teken_256to8() was intended to be
used for bg colors to allow finer or bg-specific control for the more
difficult reduction to 8; however, since 16 bg colors actually work
on VGA except in syscons text mode and the conversion isn't subtle
enough to significantly in that mode, teken_256to8() is not used now.
There are still bugs, especially in vidcontrol, if bright/blinking
background colors are set.
Restore XOR logic for bold/bright fg in syscons (don't change OR
logic for vt). Remove broken ifdef on FG_UNDERLINE and its wrong
or missing bit and restore the correct hard-coded bit. FG_UNDERLINE
is only for mono mode which is not really supported.
Restore XOR logic for blinking/bright bg in syscons (in vt, add
OR logic and render as bright bg). Remove related broken ifdef
on BG_BLINKING and its missing bit and restore the correct
hard-coded bit. The same bit means blinking or bright bg depending
on the mode, and we want to ignore the difference everywhere.
Simplify conversions of attributes in syscons. Don't pretend to
support bold fonts. Don't support unusual encodings of brightness.
It is as good as possible to map 16 VGA colors to 16 xterm-16
colors. E.g., VGA brown -> xterm-16 Olive will be converted back
to VGA brown, so we don't need to convert to xterm-256 Brown. Teken
cons25 compatibility code already does the same, and duplicates some
small tables. This is mostly for the sc -> te direction. The other
direction uses teken_256to16() which is too generic.
nodes from the DTB by default. This will allow us to enumerate the CPUs
without hard coding the CPU count into code.
Reviewed by: br
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D9827
registers.
- Add slot type capability bits. These bits should allow recognizing
removable card slots, embedded cards and shared buses (shared bus
supposedly is always comprised of non-removable cards).
- Dump CAPABILITIES2, ADMA_ERR, HOST_CONTROL2 and ADMA_ADDRESS_LO
registers in sdhci_dumpregs().
- The drive type support flags in the CAPABILITIES2 register are for
drive types A,C,D, drive type B is the default setting (value 0) of
the drive strength field in the SDHCI_HOST_CONTROL2 register.
Obtained from: DragonFlyBSD (9e3c8f63, 455bd1b1)
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)
Of these "partitions", only the enhanced user data area one actually
slices the user data area partition and, thus, gets handled with the
help of geom_flashmap(4). The other types of partitions have address
space independent from the default partition and need to be switched
to via CMD6 (SWITCH), i. e. constitute a set of additional "disks".
The second kind of these "partitions" doesn't fit that well into the
design of mmc(4) and mmcsd(4). I've decided to let mmcsd(4) hook all
of these "partitions" up as disk(9)'s (except for the RPMB partition
as it didn't seem to make much sense to be able to put a file-system
there and may require authentication; therefore, RPMB partitions are
solely accessible via the newly added IOCTL interface currently; see
also below). This approach for one resulted in cleaner code. Second,
it retains the notion of mmcsd(4) children corresponding to a single
physical device each. With the addition of some layering violations,
it also would have been possible for mmc(4) to add separate mmcsd(4)
instances with one disk each for all of these "partitions", however.
Still, both mmc(4) and mmcsd(4) share some common code now e. g. for
issuing CMD6, which has been factored out into mmc_subr.c.
Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.
CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.
- Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications. However, quite some work is
left to be done in this regard; all other R1B-type commands done by
the MMC layer also should be followed by a SEND_STATUS (CMD13), the
erase timeout calculations/handling as documented in specifications
are entirely ignored so far, the MMC layer doesn't provide timeouts
applicable up to the bridge drivers and at least sdhci(4) currently
is hardcoding 1 s as timeout for all command types unconditionally.
Let alone already available return codes often not being checked in
the MMC layer ...
- Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter will be added to ports as sysutils/mmc-utils in
a bit. Among others, the `mmc` tool of the GNU mmc-utils allows for
partitioning eMMC devices (tested working).
- For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.
- Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.
- In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.
OKed by: imp
Submitted by: ian (mmc_switch_status() implementation)
Fix this by using more dynamic initialization with simpler ifdefs for
the machine dependencies. Find a frame buffer address in a more
portable way that at least compiles on sparc64.
inpcb. t4_tom detaches the inpcb from the toepcb as soon as the
hardware is done with the connection (in final_cpl_received) but the
socket is around as long as the cm_id and the rest of iWARP state is.
This fixes an intermittent NULL dereference during abort.
Submitted by: KrishnamRaju ErapaRaju @ Chelsio
MFC after: 3 days
Sponsored by: Chelsio Communications
This patch fixes typo which results in extra bits of PMU control register.
PR: 217782
Submitted by: Svyatoslav <razmyslov at viva64.com>
Found by: PVS-Studio
Instead of single isp_intr() function doing all possible magic, introduce
four different functions to handle mailbox operation completions, async
events, response and ATIO queues. The goal is to isolate different code
paths to make code more readable, and to make easier support for multiple
interrupt vectors. Even oldest hardware in many cases can identify what
code path it should run on interrupt. Contemporary hardware can assign
them to different interrupt vectors.
MFC after: 2 weeks
inet_ntoa() and inet_ntoa_r() take the address in network
byte-order. When I removed those calls, I should have
replaced them with ntohl() to make the hex addresses slightly
less unreadable. Here they are.
See r315277 regarding classic blunders.
vangyzen: you're deep in "no good deed" territory, it seems
--badger
Reported by: ian
MFC after: 3 days
MFC when: I finally get it right
Sponsored by: Dell EMC
When I made the changes in r313821, I fell victim to one of the
classic blunders, the most famous of which is: never get involved
in a land war in Asia. But only slightly less well known is this:
Keep your brain turned on and engaged when making a tedious, sweeping,
mechanical change. KTR can correctly log the immediate integral values
passed to it, as well as constant strings, but not non-constant strings,
since they might change by the time ktrdump retrieves them.
Reported by: glebius
MFC after: 3 days
Sponsored by: Dell EMC
It was implemented to reduce context switches when uploading firmware to
card's RAM. But this mechanism is not used last 10 years since all mbox
operations are now polled, and it was never used for cards produced in
last 15 years. Newer cards can use DMA to upload firmware.
MFC after: 2 weeks
This change fixes DMA resource leak on driver unload. Also it removes
DMA resources allocation for hardcoded number of requests before fetching
the real number from firmware. Also it prepares ground for more flexible
IRQs allocation according to firmware capabilities.
MFC after: 2 weeks
- unconditionally enable BUS_DMA on non-x86 architectures
- speed up rxd zeroing via customized function
- support out of order updates to rxd's
- add prefetching to hardware descriptor rings
- only prefetch on 10G or faster hardware
- add seperate tx queue intr function
- preliminary rework of NETMAP interfaces, WIP
Submitted by: Matt Macy <mmacy@nextbsd.org>
Sponsored by: Limelight Networks
Make sure that uinput state field reflects actual state by checking
evdev_register result for errors
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
Differential Revision: https://reviews.freebsd.org/D9320
hardware but lack the larger fifos rev 5 hardware should have.
The linux world (where our FDT data comes from) solved this by adding
a new property to pl011 nodes, "arm,primecell-periphid". When this
property is present, its values override the values in the hardware
periphid registers. For pl011 rev 5 hardware with small fifos, they
override the id so that it appears to be rev 4 hardware.
The driver now uses the new property when present. It also continues
to check the device compat string, to handle older fdt data that may
still be in use on existing systems (on RPi systems it is common to
update system software without updating fdt data which is part of the
boot firmware).
Reviewed by: imp
- XPT_NOTIFY_ACKNOWLEDGE was not handled, causing stuck requests.
- XPT_ABORT was not even trying to abort active ATIOs/INOTs.
- Initiator's tag was not stored and not used where needed.
- List of TM request types needed update.
- mpt_scsi_tgt_status() missed some useful debugging.
After this change global TM requests, such as reset, should work properly.
ABORT TASK (ABTS) requests are still not passes to CTL, that is not good
and should be fixed.
MFC after: 2 weeks
user default normal attribute to the current attribute).
This change only fixes a logic error. scterm_clear() used to be
used for terminal reset, but teken uses a general fill function for
that, leaving scterm_clear() only used for initialization and mode
change, when using the user default attribute is correct. It is not
really a terminal function, but needs to sync its changes with the
terminal layer. Syncing of the attribute is currently broken for
terminal reset, but works for initialization and mode change.
some cases of initialization and resetting of the teken cursor position.
(This bad name is consistent with others, but it is too easy to confuse
with scteken_cursor() which goes in the opposite direction.)
The following cases were broken:
- for booting without a syscons console, the teken and sc positions for
ttyv0 were (0, 0), but are supposed to be somewhere in the middle of
the screen (after carefully preserved BIOS and loader messages) (at
least if there is no mode switch that loses the messages).
- after mode switches, the screen is cleared and the cursor is supposed to
be moved to (0, 0), but it was only moved there for sc.
The following case was hacked to work:
- for booting with a syscons console, it was arranged that scteken_init()
for the console could see a nonzero cursor position and adjust, although
this broke the sc seeing it in the non-console case above.
They cannot be used anymore with the userland bits we provide.
Furthermore, their KMS versions support the same hardware.
Submitted by: dumbbell
Reviewed by: emaste, manu
Sponsored by: AsiaBSDCon
Differential Revision: https://reviews.freebsd.org/D5614
looked like it might handle reverse attributes, but it actually handles
conversion of attributes in the direction indicated by the new name.
Reverse attributes are just broken.
Rename scteken_attr() to scteken_te_to_sc_attr(). scteken_attr() looked
like it might give teken attributes, but it actually gives sc attributes.
Change scteken_te_to_sc_attr() to return int instead of unsigned int.
u_char would be enough, and it promotes to int, and syscons uses int
or u_short for its attributes everywhere else (u_short holds a shifted
form and it promotes to int too).
This change just does cleanups missed in r56043 17 years ago. The
default attributes were still stored in structs for the purpose of
changing them and passing around pointers to the defaults, but r56043
added another layer that made the defaults invariant and only used for
initialization and reset. Just use the defaults directly. This was
already done for the kernel defaults. The defaults for reverse
attributes aren't actually used, but are ignored in layers that no
longer support them.
- Not set BufferLength caused receive of empty ATIOs.
- CDB length guessing was broken at least for RC16.
- mpt_req_untimeout() was called with wrong req parameter.
- Sense data reporting was broken in several ways.
With this change my LSI7204EP-LC can pass at least basic tests as target.
The code is still far from perfect, but finally I found second hw/driver
after isp(4) that really can work in CAM target mode.
MFC after: 2 weeks
is unavailable on sparc64 only. This makes the new ec_putc() a non-op
on sparc64 but still calls it. On other non-x86 arches, it should
compile but might not work.
Reported by: gjb
Starting with rev 5 (which is inexplicably indicated by a version number
of '3' in the Peripheral ID register), the pl011 doubled the size of the
rx and tx fifos, to 32 bytes, so read the ID register and set the size
variables in the softc accordingly.
An interesting wrinkle in this otherwise-simple concept is that the
bcm2835 SoC, used in Raspberry Pi systems among others, has the rev 5
pl011 hardware, but somehow also has the older 16-byte fifos. We check
the FDT data to see if the hardware is part of a bcm283x system and use
the smaller size if so.
Thanks to jchandra@ for pointing out that newer hardware has bigger fifos.
Some drives sometimes have errors for things like setting the number
of queue entries in the submission queue. The error paths taken for
these drives ensure a panic dereferencing uninialized data.
Sponsored by: Netflix
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omission
of these bridge declarations for mmccam(4) in a single place, i. e.
in dev/mmc/bridge.h.
Fix assumptions about name spaces in NVME driver. First, it assumes
cdata.nn is the number of configured devices. However, it is the
number of supported name spaces. Second, it assumes that there will
never be more than 16 name spaces supported, but a certain drive I'm
testing reports 1024. It assumes that name spaces are a tightly packed
namespace, but the standard seems to indicate otherwise. Finally, it
assumes that an error would be generated when quearying an
unconfigured namespace. Instead, it succeeds but the identify data is
all zeros.
Fix these by limiting the number of name spaces we probe to 16. Remove
aborting when we find one in error. When the size of the name space is
zero, ignore it.
This is admittedly a bandaide. The long term fix will be to
participate in the enumeration and name space change protocols
definfed in the NVNe standard.
Sponsored by: Netflix
This change tries to fix the most obvious locking problems.
sbp_cam_scan_lun() is never called with the sbp lock held, so the lock
needs to be acquired internally (if it's needed at all).
Without this change a kernel with INVARIANTS panics when a firewire disk
is connected:
panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff80420bbb = db_trace_self_wrapper+0x2b/frame 0xfffffe0504df0930
kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame 0xfffffe0504df09e0
vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20
panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80
__mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame 0xfffffe0504df0ac0
sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame 0xfffffe0504df0af0
xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame 0xfffffe0504df0b30
xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame 0xfffffe0504df0b80
fork_exit() at 0xffffffff805ff72f = fork_exit+0xdf/frame 0xfffffe0504df0bf0
fork_trampoline() at 0xffffffff8082483e = fork_trampoline+0xe/frame
0xfffffe0504df0bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Also, I tried to reduce the scope of the sbp lock to avoid holding it
while doing bus_dma allocations.
The code badly needs some re-engineering. SBP really should implement
a CAM transport, so that it avoids control flow inversion when re-scanning
the bus. Also, the sbp lock seems to be too coarse.
Additionally, the commit includes some changes not related to locking.
- sbp_cam_scan_lun: restore CAM_DEV_QFREEZE before re-queueing the ccb
because xpt_setup_ccb resets ccb_h.flags
- sbp_post_busreset: call xpt_release_simq only if it's actually frozen
- don't place private SIMQ_FREEZED flag (sic, "freezed") into sim->flags,
use sbp->flags for that
- some style fixes and control flow enhancements
Reviewed by: sbruno
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9898
Currently netfront is setting the flags of inbound packets with the checksum
not present (offloaded) to (CSUM_IP_CHECKED | CSUM_IP_VALID | CSUM_DATA_VALID |
CSUM_PSEUDO_HDR). According to the mbuf(9) man page this is not the correct
combination of flags, it should instead be (CSUM_DATA_VALID |
CSUM_PSEUDO_HDR).
Reviewed by: Wei Liu <wei.liu2@citrix.com>
MFC after: 2 weeks
Sponsored by: Citrix Systems R&D
Differential revision: https://reviews.freebsd.org/D9831
Lock the xenstore request mutex when suspending user-space processes, in order
to prevent any process from holding this lock when going into suspension, or
else the xenstore suspend process is going to deadlock.
Submitted by: Liuyingdong <liuyingdong@huawei.com>
Reviewed by: royger
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9638
When running on Xen, it's possible that a suspend request to the hypervisor
fails (return from HYPERVISOR_suspend different than 0). This means that the
suspend hasn't succeed, and the resume procedure needs to properly handle this
case.
First of all, when such situation happens there's no need to reset the vector
callback, hypercall page, shared info, event channels or grant table, because
it's state is preserved. Also, the PV drivers don't need to be reset to the
initial state, since the connection with the backed has not been interrupted.
Submitted by: Liuyingdong <liuyingdong@huawei.com>
Reviewed by: royger
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9635
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method (I've whipped these out of the tree as part of r227843
once, but they keep coming back ...),
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.
o Trim/adjust includes.
This is mostly a version bump to stay in version number sync with firmware.
The only change there was cosmetic: Display degraded speed message upon
receiving Active Cable Exception Event with DEGRADED reason code.
Discussed with: slm@
MFC after: 1 week
all the clocks that they provide.
Each clocks are exported under the node 'clock.<clkname>' and have the following
children nodes :
- frequency
- parent (The selected parent, if any)
- parents (The list of parents, if any)
- childrens (The list of childrens, if any)
- enable_cnt (The enabled counter)
This give us the possibility to examine clocks at runtime and make graph of
the clock flow.
Reviewed by: mmel
MFC after: 2 month
Differential Revision: https://reviews.freebsd.org/D9833
For 4965 just extract 'is_chan_5ghz' flag from the RXON structure
(like it was done in r281287); for others it was never used.
Tested with Intel 6205, STA mode.
have been in the code all along, but were masked by having a fifo depth of
one byte at the hardware level, so everything kinda worked by accident.
The hardware interrupts when the TX fifo is half empty, so set
sc->sc_txfifosz to 8 bytes (half the hardware fifo size) to match. This
eliminates dropped characters on output.
Restructure the read loop to consume all the bytes in the fifo by using
the "rx fifo empty" bit of the flags register rather than the "rx ready"
bit of the interrupt status register. The rx-ready interrupt is cleared
when the number of bytes in the fifo fall below the interrupt trigger
level, leaving the fifo half full every time receive routine was called.
Now it loops until the fifo is completely empty every time (including
when the function is called due to a receive timeout as well as for
fifo-full).
Modern GCC and Clang simply ignore the qualifier, while the old base GCC
produces a warning (treated as an error in the kernel build).
Approved by: cem
MFC after: 5 days
it in emergency in sc_cnputc().
Locking fixes in sc_cnputc() previously turned off normal output in
near-deadlock conditions and added deferred output which might never
be completed. Emergency output goes to the frame buffer using
sufficiently atomic non-blocking writes if the console is in text
mode (in graphics mode, nothing is done, modulo races setting the
graphics mode bit). Screen updates overwrite the emergency output
if the emergency condition clears enough to reach them.
ec_putc() also works for "early" console output in normal x86 text
mode as soon as this mode is initialized (if ever). This uses a
hard-coded x86 frame buffer address before cninit() and a hopefully
MI address after cninit(). But non-x86 is more likely to not support
text mode, when ec_putc() will be null. ec_putc() has no dependencies
of syscons before cninit(), and only has them later to track syscons'
mode changes. This commit doesn't attach ec_putc() for early use.
To test emergency use, put a breakpoint in central syscons output code
like sc_puts() and do some user output. The system used to race or
deadlock in ddb output soon after entry to ddb. The locking fixes
deferred the output until after leaving ddb, so ddb was unusable and
you had to try typing c[ontinue] blindly until it exited, or better use
a serial console in parallel. Now the output goes to a window in the
middle 2/3 of the screen. Scrolling is circular and there is no cursor,
but otherwise ec_putc() provides full dumb terminal functionality and
very fast output that hides artificates from dumb overwrites.
by the CPU number.
This was originally for debugging near-deadlock conditions where
multiple CPUs either deadlock or scramble each other's output trying
to report the problem, but I found it interesting and sometimes
useful for ordinary kernel messages. Ordinary kernel messages
shouldn't be interleaved, but if they are then the colorization
makes them readable even if the interleaving is for every character
(provided the CPU printing each message doesn't change).
The default colors are 8-15 starting at 15 (bright white on black)
for CPU 0 and repeating every 8 CPUs. This works best with 8 CPUs.
Non-bright colors and nonzero background colors need special
configuration to avoid unreadable and ugly combinations so are not
configured by default. The next bright color after 15 is 8 (bright
black = dark gray) is not very readable but is the only other color
used with 2 CPUs. After that the next bright color is 9 (bright
blue) which is not much brighter than bright black, but is used with
3+ CPUs. Other bright colors are brighter.
Colorization is configured by default so that it gets tested. It can
only be turned off by configuring SC_KERNEL_CONS_ATTR to anything other
than FG_WHITE. After booting, all colors can be changed using the
syscons.kattr sysctl. This is a SYSCTL_OPAQUE, and no utility is
provided to change it (sysctl only displays it).
The default colors work in all VGA modes that I could test. In 2-color
graphics modes, all 8 bright colors are displayed as bright white, so
the colorization has no effect, but anything with a nonzero background
gives white on white unless the foreground is zero. I don't have an
mono or VGA grayscale hardware to test on. Support for mono mode seems
to have never worked right in syscons (I think bright white gives white
underline with either bold or bright), but VGA grayscale should work
better than 2-color graphics.
I imagine that the module would be useful only to a very limited number
of developers, so that's my excuse for not writing any documentation.
On a more serious note, please see DRAM Error Injection section of BKDGs
for families 10h - 16h. E.g. section 2.13.3.1 of BKDG for AMD Family 15h
Models 00h-0Fh Processors.
Many thanks to kib for his suggestions and comments.
Discussed with: kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D9824
ULPs can set a qp's state to ERROR and then post a work request on the
sq and/or rq. When the reply for that work request comes back it is
guaranteed that all previous work requests posted on that queue have
been drained.
Obtained from: Chelsio Communications
MFC after: 3 days
Sponsored by: Chelsio Communications
registered. T4/5/6 have no internal limit on this size. This is
probably a copy paste from the T3 iw_cxgb driver.
MFC after: 3 days
Sponsored by: Chelsio Communications
TW_CL_MAX_NUM_LUNS should not be 16 but I presume 255. I have a 3ware
controller with more than 16 volumes (LUN's) and otherwise all LUN's
above the 16'th are not working.
Submitted by: jcatrysse <j.catrysse@proximedia.be>
Pull Request: https://github.com/freebsd/freebsd/pull/100
left-click event. It can be disabled setting the new
hw.usb.wsp.enable_single_tap_clicks sysctl to 0.
Submitted by: K Staring <qdk@quickdekay.net>
Pull Request: https://github.com/freebsd/freebsd/pull/97
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Sockets representing the TCP endpoints for iWARP connections are
allocated by the ibcore module. Before this revision they were closed
either by the ibcore module or the iw_cxgbe hardware driver depending on
the state transitions during connection teardown. This is error prone
and there were cases where both iw_cxgbe and ibcore closed the socket
leading to double-free panics. The fix is to let ibcore close the
sockets it creates and never do it in the driver.
- Use sodisconnect instead of soclose (preceded by solinger = 0) in the
driver to tear down an RDMA connection abruptly. This does what's
intended without releasing the socket's fd reference.
- Close the socket in ibcore when the iWARP iw_cm_id is destroyed. This
works for all kinds of sockets: clients that initiate connections,
listeners, and sockets accepted off of listeners.
Reviewed by: Steve Wise @ Open Grid Computing, hselasky@
MFC after: 3 days
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D9796
SBP-2 specification defined maximum CDB length as 12 bytes. Newer SBP-3
specification allows CDB of any size, but this driver is too old. Proper
solution would be to look on maximal ORB size supported by the target.
MFC after: 1 week
RSS hash type will be used to identify the CPU on to which, a receive packet
will be queued. This patch extracts the "RSS hash type" from the receive
completion and sends it to the stack.
Submitted by: Venkatkumar Duvvuru <venkatkumar.duvvuru@broadcom.com>
Reviewed by: shurd
Approved by: sbruno
MFC after: 1 week
Sponsored by: Broadcom Limited
Differential Revision: https://reviews.freebsd.org/D9685
2. add sysctl to set pause frame parameters
3. increase max segs for TSO packets to BXE_TSO_MAX_SEGMENTS (32)
4. add debug messages for PHY
5. HW LRO support restricted to FreeBSD versions 8.x and above.
Submitted by:Vaishali.Kulkarni@cavium.com
MFC after:5 days
This is required for FDT's standard "reg-io-width" property
(similar to "reg-shift" property) found in many DTS files.
This fixes operation on Altera Arria 10 SOC Development Kit,
where standard ns8250 uart allows 4-byte access only.
Reviewed by: kan, marcel
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9785
vm_map_lookup_done should only be called when the gntdev has finished poking at
the entry.
Reported by: alc
Reviewed by: alc
MFC after: 1 week
Sponsored by: Citrix Systems R&D
During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.
Reviewed by: avg @
MFC after: 1 week
The pl011 UART has a 16 entry Tx FIFO and a 16 entry Rx FIFO that
have not been used so far. Update the driver to enable the FIFOs
and use them in transmit and receive.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D8819
directly from the node.
- Use ni_txparms directly instead of calculating them manually every time
- Move M_EAPOL flag check upper; otherwise it may be skipped due to
'ucastrate' / 'mcastrate' check
- Use 'mgtrate' for control frames too (see ifconfig(8), mgtrate parameter)
- Add few more M_EAPOL checks where it was missing (zyd(4), ural(4),
urtw(4))
- Few unrelated cleanups
Tested with:
- Intel 6205 (iwn(4)), STA mode;
- WUSB54GC (rum(4)), HOSTAP mode + RTL8188EU (rtwn(4)), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9811
Its more important for SPI HBAs, as they don't support CDBs above 12 bytes.
The new error code makes CAM to fall back to alternative commands.
MFC after: 2 weeks
This allows to properly handle cases when target wants to receive or send
more data then initiator wants to send or receive. Previously in such
cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0.
MFC after: 2 weeks
This change removes limitation of single S/G list entry and limitation on
maximal I/O size, using multiple data transfers per I/O if needed. Also
it removes code duplication between send and receive paths, which are now
completely equal.
Convert PCIe hot plug support over to asking the firmware, if any, for
permission to use the HotPlug hardware. Implement pci_request_feature
for ACPI. All other host pci connections to allowing all valid feature
requests.
Sponsored by: Netflix
pcib_request_feature allows drivers to request the firmware (ACPI)
release certain features it may be using. ACPI normally manages things
like hot plug, advanced error reporting and other features until the
OS requests ACPI to relenquish control since it is taking over.
Sponsored by: Netflix
- Check return code from initialization path; otherwise, vap state
may be wrong after an error.
- Do not try to run iwn_stop() / iwn_init() multiple times.
- Merge iwn_radio_on/off() and move RFKILL bit check into the task.
- Try to handle possible RF switch state change in S3 state (PR 181694).
PR: 181694
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9797
On Core2 and older Intel CPUs, where TSC stops in C2, system does not
allow C2 entrance if timecounter hardware is TSC. This is done by
tc_windup() which tests for TC_FLAGS_C2STOP flag of the new
timecounter and increases cpu_disable_c2_sleep if flag is set. Right
now init_TSC_tc() only sets the flag if cpu_deepest_sleep >= 2, but
TSC is initialized too early for this variable to be set by
acpi_cpu.c.
There is no reason to require that ACPI reported C2 and deeper states
to set TC_FLAGS_C2STOP, so remove cpu_deepest_sleep test from
init_TSC_tc() condition. And since this is the only use of the
variable, remove it at all.
Reported and submitted by: Jia-Shiun Li <jiashiun@gmail.com>
Suggested by: jhb
MFC after: 2 weeks
* Uses the IWM_FW_PAGING_BLOCK_CMD firmware command to tell the firmware
what memory ranges to use for paging.
Obtained from: dragonflybsd.git 8a5b199964f8e7bdb00039f0b48817a01b402f18
VXGE_DEFAULT_TTI_RTIMER_VAL and VXGE_DEFAULT_RTI_RTIMER_VAL have value
zero but nevertheless we should use the right value on each.
Pointed by: jhb
X-MFC with: r314145
One test was inadvertently expecting a bug in the kernel's sscanf
implementation circa 2012. I don't know when that bug got fixed.
Reported by: royger
Reviewed by: royger
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9766
Most of these are null pointer dereferences or missing error checks in the
unit tests. One is a missing error check in xnb_attach_failed. None can
cause real problems in running systems.
Reported by: Coverity
CIDs: 1092469 1092468 1092467 2092466 1092465 1092512 1092511 1092510
CIDs: 1092510 1092509 1092508 1092507
Reviewed by: royger
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9234
The code is not operational right now so just comment away an obviously
useless assignment. Fix some typos while here.
Found with: coccinelle (da.cocci)
The Xen grant table device treats the mmap offset parameter as an unsigned
type, and as so it must use the newly introduced UOFF_TO_IDX.
Sponsored by: Citrix Systems R&D
MFC after: 2 weeks
X-MFC-with: r313690
with geom_flashmap(4) and teach it about MMC for slicing enhanced
user data area partitions. The FDT slicer still is the default for
CFI, NAND and SPI flash on FDT-enabled platforms.
- In addition to a device_t, also pass the name of the GEOM provider
in question to the slicers as a single device may provide more than
provider.
- Build a geom_flashmap.ko.
- Use MODULE_VERSION() so other modules can depend on geom_flashmap(4).
- Remove redundant/superfluous GEOM routines that either do nothing
or provide/just call default GEOM (slice) functionality.
- Trim/adjust includes
Submitted by: jhibbits (RouterBoard bits)
Reviewed by: jhibbits
Note that the timer itself fully supports suspension, but due to the lack of
ordering during the resume process FreeBSD cannot guarantee that the timer is
resumed before any device attempts to use it.
Submitted by: Liuyingdong <liuyingdong@huawei.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D9639
- Move private data about ATIOs/INOTs from per-LUN to per-channel data.
This allows active commands to continue operation after LUN destruction.
This also simplifies lookup of the data by tag in some situations.
- Unify three restart_queue processing implementations.
- Complete all ATIOs from restart_queue on LUN disable.
- Delete ATIO private data when command completed or aborted, not depending
on the ATIO being requeued, that was ugly hack and could never happen. CAM
should always call ether XPT_CONT_TARGET_IO with status or XPT_ABORT.
- Implement XPT_ABORT for queued ATIOs/INOTs to allow CAM do graceful
shutdown, not depending on LUN disable, as it is done in ahd(4)/targ(4).
- Unify isp_endcmd() arguments to make it more usable in generic code.
- Remove never really used LUN state reference counter.
MFC after: 2 weeks
* This is more similar to how code/definitions are distributed in
Linux's iwlwifi.
* This should make recognizing new chipset variants, and adding additional
flags from the Linux iwlwifi code easier, without blowing up if_iwm.c
Obtained from: dragonflybsd.git 27d11320e707d2c41424efc1983762f6799941d6
* Just add the struct iwm_cfg pointers to the iwm_devices array, to get
rid of the large switch clause.
Obtained from: dragonflybsd.git 35f0e6c86c1654323d6b19f7a077f4ab8ac85868
* The sc->sc_uc.uc_error_event_table value is now at sc->error_event_table,
and not sc->umac_error_event_table.
Obtained from: dragonflybsd.git 612855b1a8c321ec9ba34f63edf913e7ecff8363
* Use the notification wait API, like it's done in the Linux iwlwifi code,
to wait for the IWM_MVM_ALIVE notification.
* This also should fix some firmware load interrupt issues, and errors
in the nic lock using.
Tested:
* (adrian) Intel 7260, STA mode
Obtained from: dragonflybsd.git a7697ea01c11fd493aec52260a02f31df680eb91
* While there, rename some functions to match the names and functionality
of the similarly named functions in Linux iwlwifi.
Obtained from: dragonflybsd.git e98ee77a816bfd8b4912047b93dfb2c560788f24
For some reason isp_handle_platform_notify_fc() allocated INOT just
before calling isp_handle_platform_target_tmf(), which also allocates
INOT. It seems to be a braino introduced in r196008.
MFC after: 2 weeks
* Migrate the rx_params stuff out from ieee80211_freebsd.h where it doesn't belong -
this isn't freebsd specific anymore.
* Don't use a hard-coded number of chains in the ioctl header; now we can shuffle
MAX_CHAINS around so it can be used in the right spot.
* Extend the signal/noisefloor levels in the mimo stats struct to userland to include
the signal and noisefloor levels for each 20MHz slice of a 160MHz channel.
* Bump the number of EVM pilots in preparation for 4x4 and 160MHz channels.
Tested:
* ath(4), STA mode
* iwn(4), STA mode
* local ath10k port, STA mode
TODO:
* 11ax chips will come with 5GHz 8x8 hardware for lots of MU-MIMO - I'll re-bump it
at that point.
Note:
* This breaks the driver and ifconfig ABI; please recompile the kernel,
ifconfig and wpa_supplicant/hostapd.
for USB OTG-capable hardware to implement device side of USB
Mass Storage, ie pretend it's a flash drive. It's configured
in the same way as other CTL frontends, using ctladm(8)
or ctld(8). Differently from usfs(4), all the configuration
can be done without rebuilding the kernel.
Testing and review is welcome. Right now I'm still moving,
and I don't have access to my test environment, so I'm somewhat
reluctant to making larger changes to this code; on the other
hand I don't want to let it sit on Phab until my testing setup
is back, because I want to get it into 11.1-RELEASE.
Reviewed by: emaste (cursory), wblock (man page)
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8787
All resources lack of which may put CTIO into the queue are either
per-channel or potentially per-queue, but none of them are per-LUN.
This is a first step to fix live LUN disabling. Before this change
any CTIOs held in a queue in time of disabling were just leaked.
MFC after: 2 weeks
Do no write to PBA register on igb(4) devices unless we need
to make adjustments for the 82575 and jumbo frames.
Remove redundant LPE/~LPE assignments.
Move e1000_lv_jumbo_workaround_ich8lan() invokcation into a block
so that its not executed in the igb case.
Move em(4) class assignments of RCTL values to its own code block.
Adjust a few direct accesses of ifp->mtu to use accessor functions.
PR: 216734
Submitted by: Kaho Toshikazu <kaho@elam.kais.kyoto-u.ac.jp>
This patch will add support for MacBookPro 11.2.
For the macros, the MBP11_* macros (for the existing MacBookPro11.3) did not
match so they have been renamed to MBP113_* and a new MBP112_* has been
added (modified copy of MBP11_*).
Some trailing whitespaces may have been removed automatically.
PR: kern/214836
Obtained from: Johannes Lundberg <johannes@brilliantservice.co.jp
compile options. Remove doxygen pointers to now deleted files. Remove
EISA and VME as examples in bus_space.9.
Retained EISA mode code for IO PIC and MPTABLES because that's not
EISA bus, per se, and some people have abused EISA to mean "EISA-like
behavior as opposed to ISA" rather than using it for EISA add-in
cards.
Relnotes: yes
VesaLocalBus or EISA. Internally, EISA and ISA are handled the same,
with VL being handled slightly differently. To avoid too much code
churn, retain the EISA name, despite it being used only for ISA
bus. When it is on the ISA bus, weird gymnastics are required with
EISA-space address accesses as well. Remove known models from the ahc
man page. Remove ahc_eisa module.
page. Remove comment about EISA dual channel card. Remove trivial
references in advlib to avoid false positives with grep. Remove stray
MCA reference not worth a seperate commit.
still relevant (ISA cards can still be in EISA mode, and we're still
ignoring those in the identify routine). Notes about cards in EISA
mode have been left in the manual since they aren't relevant to EISA
support, but instruct how to properly configure an ISA card in a mode
when it is in a ISA bus slot.
support. Fix a comment block that's shared with both vx and ep. Remove
obsolete refernce to statically compiling a kernel with a fixed number
of vx devices. Have not removed EISA from the title of the document
the register definitions were originally derived from (though no doubt
more recent docments were also consulted).
inet_ntoa() cannot be used safely in a multithreaded environment
because it uses a static local buffer. Instead, use inet_ntoa_r()
with a buffer on the caller's stack.
Suggested by: glebius, emaste
Reviewed by: gnn
MFC after: 2 weeks
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D9625
machines, only a few 486 machines that used it, and those haven't had
enough memory to run FreeBSD for quite some time (often limited to
16MB).
Not to be confused with the Machine Check Architecture, which is still
very much alive and used (and untouched by this commit).
No Objection From: arch@
I found that at least with Chelsio NICs TOE sockets quite often report
negative sbspace() values. Using unsigned variable to store it resulted
in attempts to aggregate too much data in one sosend() call, that caused
errors and following connection termination.
MFC after: 2 weeks
The {powerpc,powerpc64,sparc64} LINT kernel builds fail with this error:
sys/dev/vt/vt_buf.c:198: warning: 'vtbuf_htw' defined but not used
Move vtbuf_htw() inside the '#if SC_NO_CUTPASTE' block where it belongs, and
put it in the proper order.
This fixes the immedate issue w/ vt(4), but all three then fail on different
issues.
Reviewed by: emaste
Current bxe probe function won't attach to devices with the NetXtreme II
BCM57840 2x20GbE chip, enable it by adding it's chip ID to the list of
supported chips.
Tested on: HP ProLiant WS460c Gen9
Reviewed by: gnn
MFC after: 1 week
Sponsored by: Citrix Systems R&D
Differential Revision: https://reviews.freebsd.org/D9609
we will import a newer version of the Linux code so the linuxkpi was not
used.
This is still missing 10G support, and multicast has not been tested.
Reviewed by: gnn
Obtained from: ABT Systems Ltd
Sponsored by: SoftIron Inc
Differential Revision: https://reviews.freebsd.org/D8549
On laptops like the ThinkPad X240, ClickPad buttons are located at the
top. The hw.psm.synaptics.softbuttons_y sysctl was supposed to allow this
by setting the value to a negative one (e.g. -1700). However, the
condition was wrong (double negative), and doing that placed the buttons
in an unreachable area.
PR: 216342
Submitted by: Greg V <greg@unrelenting.technology>
MFC after: 1 week
All this code is based on assumption that data will be stored in one piece,
and since buffer size if known and fixed, it is easier to hardcode it.
MFC after: 2 weeks
In general case m_pullup() does not really guarantee any data alignment.
Instead of depenting on side effects caused by data being always copied
out of mbuf cluster (which is probably a bug by itself), always allocate
aligned BHS buffer and read data there directly from socket.
While there, reuse new icl_conn_receive_buf() function to read digests.
The code could probably be even more optimized to aggregate those reads,
but until that done, this is still easier then the way it was before.
MFC after: 2 weeks
Add ACPI device 80860F14 with _UID 3 to the list of known devices. It
make SD card available on NUCs and Minnowboard. Previously added _UID 1
covered only eMMC devices.
Reported by: kib@
MFC after: 1 week
