Added support for the following:
- iSCSI TLV (requires 64 Tx and 32 Rx rings
- 9K receive buffers for jumbo frames (feature may be enabled/disabled)
- builtin firmware, bootloader and minidump template
- quick stats
- async event handling for SFP insertion/removal and DCBX changes
- Configuring DCBX and interrupt coalescing parameters
adds support of 4Kn drives and report LUNs command.
This driver update is intended for 10.2-RELEASE.
Many thanks to HighPoint for providing this driver update.
Submitted by: Steve Chang
MFC after: 3 days
It (mostly) allows to enable/disable initiator mode in run time.
Target mode control is blocked here to force coordination with CTL.
While there, add separate tunables/sysctls for virtual channels.
Previously this was done by the caller of 'svm_launch()' after it returned.
This works fine as long as no code is executed in the interim that depends
on pcpu data.
The dtrace probe 'fbt:vmm:svm_launch:return' broke this assumption because
it calls 'dtrace_probe()' which in turn relies on pcpu data.
Reported by: avg
MFC after: 1 week
Previous implementation was too fragile to initiator parameters changes.
In case of port role change it could not survive different handle assigned
to the same initiator by firmware, even though initiator was logged out.
The new implementation should be more resillient to this kind of problems,
trying to work in any situation and only warn user about suspisious events.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
xbd_initialize to xbd_connect. Both of these initialization steps need
to know what the maximum possible I/O size will be, and when we gain
support for indirect segment I/Os we won't know that value until we
reach xbd_connect. Since none of this data is used before xbd_connect
completes, moving the initialization is harmless.
This commit should not result in any functional changes.
removed bxe_free_mcast_macs_list() and bxe_init_mcast_macs_list()
fixed bug where copy of multicast list mta was deleted prior to passing the list to firmware
MFC after:5 days
- remove last remnants of never implemented multiple targets support;
- implement missing support for LUN mapping in this area.
Due to existing locking constraints LUN mapping code is practically
unlocked at this point. Hopefully it is not racy enough to live until
somebody get idea how to call sleeping fronend methods under lock also
taken by the same frontend in non-sleepable context. :(
adding already exists and if so just return that. The typical use case
is from identify routines, which shouldn't be adding multiple copies
of the same phandle_t to the gpiobus. Only one per phandle_t is needed
(or expected by the current code).
Differential Revision: https://reviews.freebsd.org/D2871
At this point CTL has no known use case for device queue freezes.
Same time existing (considered to be broken) code was found to cause
modify-after-free issues.
Discussed with: ken
MFC after: 1 week
into blkif segments, and moving it into a new function. This will be used
by upcoming support for indirect-segment blkif requests.
This commit should not result in any functional changes.
* nsegs must be at most BLKIF_MAX_SEGMENTS_PER_REQUEST (since we specify
that limit to bus_dma_tag_create), so KASSERT that rather than silently
adjusting the request.
* block_segs is now a synonym for nsegs, so garbage collect that variable.
* nsegs is never read during or after the while loop, so remove the dead
decrement from the loop.
These were all left behind from the pre-r284296 support for a "segment
block" extension.
function, which is expected to set returned env to NULL upon reaching the end
of the environment list but fails to do so in certain cases. The respective
u-boot code looks like the following (HEAD at the time of this commit):
--- api.c ---
496 static int API_env_enum(va_list ap)
...
510 *next = last;
511
512 for (i = 0; env_get_char(i) != '\0'; i = n + 1) {
513 for (n = i; env_get_char(n) != '\0'; ++n) {
514 if (n >= CONFIG_ENV_SIZE) {
515 /* XXX shouldn't we set *next = NULL?? */
516 return 0;
517 }
518 }
-------------
The net result is that any unfortunate user of the loader's ub_env_enum()
function hitting this condition would be trapped in the infinite loop, as
the main use pattern of ub_env_enum() is basically the following:
while ((env = ub_env_enum(env)) != NULL) { DO STUFF }
Which would stuck forever with the last element.
fails to properly consider memory regions when the loader is
located below of those regions or engulfs their lower limit. This
results in "not enough RAM to load kernel" panic, which is totally
bogus. On top of that, there are some variables that can be left
unitialized in those cases, which might cause it fail with memory
access violation instead of panic while trying to load kernel to
a wrong or non-existing address of memory.
Augment the code to properly deal with the loader being below or
at the lower bound of the memory region in question. Also, don't
leave ununitialized variables behind.
Reviewed by: ian
