| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
Also change default disk name to ada.
MFC after: 3 weeks
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
|
|
|
|
| |
Only Style 9 changes for mrsas driver.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
| |
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
| |
Bring head mrsas same as internal Phase 6.5.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
where as there are limited number(32) of mfi commands in the pool.
The mfi command pool is now restricted to 27 simultaneous accesses by using
a counting semaphore while calling the passthru function.
In the mrsas_cam.c source file there was a same function name mrsas_poll(),
which was same as the mrsas_poll() implemented in the mrsas.c file for the
polling interface.
To clearly distinguish the functionality by usage we have renamed the former
as mrsas_cam_poll().
In the passthru function let's say it has got an mfi command from the pool
but it has failed in one of the DMA function call which will lead to leak
an mfi command because in the ERROR case it directly returns and not freeing up
the occupied mfi command.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
|
|
|
|
|
|
| |
application.
It is meant to notify the applications which will be waiting for some
controller events to be occured.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
|
|
|
|
|
| |
This Driver will create multiple MSI-x vector depending upon what FW expose.
As of now 12 Gbp/s MR controller (Invader and Fury) expose 96 msix vector.
As of now 6 Gbp/s MR controller (Thunderbolt) expose 16 msix vector.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
|
|
|
|
|
| |
snv add, so I have added $FreeBSD$ as comment.
This commit is contininous of last mrsas commit, so that compilation
does not break.
Obtained from: AVAGO Technologies
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
machine, for which 32bit compatibilty code has been added.
As in linux there is only one device entry that is used to fire IOCTL commands,
a new device entry megaraid_sas_ioctl_node is added for solely this
purpose.
From one dev node i.e mrgaraid_sa_ioctl_node we have to find out the
controller instance in case of multicontroller, for which one management info
structure has been added.
Reviewed by: ambrisko
MFC after: 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
| |
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
E.g: If the user wants to create more than 64VD on a controller,
it is not possible on current firmware/driver.
New feature and requirement to support upto 256VD, firmware/driver/apps need changes.
In addition to that, there must be a backward compatibility of the new driver with the
older firmware and vice versa.
RAID map is the interface between Driver and FW to fetch all required
fields(attributes) for each Virtual Drives.
In the earlier design driver was using the FW copy of RAID map where as
in the new design the Driver will keep the RAID map copy of its own; on which
it will operate for any raid map access in fast path.
Local driver raid map copy will provide ease of access through out the code
and provide generic interface for future FW raid map changes.
For the backward compatibility driver will notify FW that it supports 256VD
to the FW in driver capability field.
Based on the controller properly returned by the FW, the Driver will know
whether it supports 256VD or not and will copy the RAID map accordingly.
At any given time, driver will always have old or new Raid map.
Reviewed by : ambrisko
MFC after : 2 weeks
Sponsored by: AVAGO Technologies
|
|
|
|
|
| |
Atomic writes are only supported for ZVOLs in "dev" mode. In other cases
atomicity can not be guarantied and so the command is blocked.
|
|
|
|
|
|
| |
USB HUBs.
MFC after: 2 weeks
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These controllers seem to have the same feature of AR813x/AR815x and
improved RSS support(4 TX queues and 8 RX queues). alc(4) supports
all hardware features except RSS. I didn't implement RX checksum
offloading for AR816x/AR817x just because I couldn't get
confirmation from the Vendor whether AR816x/AR817x corrected its
predecessor's RX checksum offloading bug on fragmented packets.
This change adds supports for the following controllers.
o AR8161 PCIe Gigabit Ethernet controller
o AR8162 PCIe Fast Ethernet controller
o AR8171 PCIe Gigabit Ethernet controller
o AR8172 PCIe Fast Ethernet controller
o Killer E2200 Gigabit Ethernet controller
Tested by: Many
Relnotes: yes
MFC after: 2 weeks
HW donated by: Qualcomm Atheros Communications, Inc.
|
|
|
|
|
|
|
| |
QAC AR816x/E2200 controller has a silicon bug that MSI interrupt
does not assert if PCIM_CMD_INTxDIS bit of command register is set.
Reviewed by: jhb
|
|
|
|
| |
Reviewed by: nwhitehorn
|
|
|
|
|
| |
additional register was erroneously added in the MAC register set
such that 7 TX statistics counters were wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from xnu sources. If we encounter a network where ICMP is blocked
the Needs Frag indicator may not propagate back to us. Attempt to
downshift the mss once to a preconfigured value.
Default this feature to off for now while we do not have a full PLPMTUD
implementation in our stack.
Adds the following new sysctl's for control:
net.inet.tcp.pmtud_blackhole_detection -- turns on/off this feature
net.inet.tcp.pmtud_blackhole_mss -- mss to try for ipv4
net.inet.tcp.v6pmtud_blackhole_mss -- mss to try for ipv6
Adds the following new sysctl's for monitoring:
-- Number of times the code was activated to attempt a mss downshift
net.inet.tcp.pmtud_blackhole_activated
-- Number of times the blackhole mss was used in an attempt to downshift
net.inet.tcp.pmtud_blackhole_min_activated
-- Number of times that we failed to connect after we downshifted the mss
net.inet.tcp.pmtud_blackhole_failed
Phabricator: https://reviews.freebsd.org/D506
Reviewed by: rpaulo bz
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Limelight Networks
|
|
|
|
|
|
|
|
| |
cannot be sent to the chip because a prerequisite L2 resolution
failed.
Submitted by: Hariprasad at chelsio dot com (original version)
MFC after: 2 weeks.
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
tolerant to errors.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
| |
E5372 with different product IDs.
Interestingly, the standard E5372 IDs (12d1:1506) are currently listed in
u3g.c and are the same as the E3131. However, the R215/E5372 is an NCM
device and works well with cdce(4) whereas the E3131 isn't. More work
may be needed to better identify the other device IDs.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
similar as syscons(4) do.
Submitted by: Tiwei Bie <btw@mail.ustc.edu.cn>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
| |
events we have actually counted 'Branch Instruction Retired' when people
asked for 'Unhalted core cycles' using the 'unhalted-core-cycles' event mask
mnemonic.
Reviewed by: jimharris
Discussed with: gnn, rwatson
MFC after: 3 days
Sponsored by: DARPA/AFRL
|
|
|
|
| |
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
| |
This gets rid of the following error message during FreeBSD guest bootup:
"vtbd0: hard error cmd=flush fsbn 0"
Reported by: rodrigc
Reviewed by: grehan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD has ARC_BUFC_NUMMETADATALISTS metadata lists and ARC_BUFC_NUMDATALISTS
data lists (currently both are 16) while illumos has just a single list
of each kind.
headroom determines how much data is scanned on a single list
during each run of the l2arc feed thread.
Because FreeBSD has more lists we proportionally decrease the limit.
Reviewed by: Brendan Gregg (earlier version)
MFC after: 2 weeks
Sponsored by: HybridCluster
|
| |
|
|
|
|
|
|
| |
https://svnweb.freebsd.org/base?view=revision&revision=272347
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD has ARC_BUFC_NUMMETADATALISTS metadata lists and ARC_BUFC_NUMDATALISTS
data lists (currently both are 16) while illumos has just a single list
of each kind.
L2ARC_WRITE_SIZE determines the default value of l2arc_write_max which
defines limits on how much data is scanned and written to a cache device
during each run of the l2arc feed thread. The limits are applied on the
per buffer list basis.
Because FreeBSD has more lists we proportionally reduce the limits.
Reviewed by: Brendan Gregg (earlier version)
MFC after: 2 weeks
Sponsored by: HybridCluster
|
|
|
|
|
|
| |
This should allow zdb -A option to actually make difference.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
Change mbuf's rcvif to enc0 and restore it after pfil processing.
PR: 110959
Sponsored by: Yandex LLC
|
|
|
|
|
| |
MFC after: 3 days
Sponsored by: Mellanox Technologies
|
|
|
|
|
|
|
| |
2) Return error on unsupported format specs.
(both according to POSIX)
PR: 93197
|
|
|
|
|
|
|
| |
POSIX treats negative time_t as undefined (i.e. may be valid too,
depends on system's policy we don't have) and we don't set EOVERFLOW
in mktime/timegm as POSIX requires to surely distinguish -1 return
as valid negative time from -1 as error return.
|
|
|
|
| |
MFC after: 2 weeks
|
| |
|
|
|
|
|
| |
Obtained from: OpenBSD
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
| |
one to, for example, access the "provider" field of a struct g_consumer,
even though "provider" is a D keyword.
PR: 169657
MFC after: 2 months
Discussed with: Bryan Cantrill
Sponsored by: EMC / Isilon Storage Division
|
|
|
|
|
|
|
|
| |
The hypervisor hides the MONITOR/MWAIT capability by unconditionally setting
CPUID.01H:ECX[3] to 0 so the guest should not expect these instructions to
be present anyways.
Discussed with: grehan
|
|
|
|
|
|
|
|
|
|
| |
configuration value is an integer count of seconds, it is not a timeval.
Using memcpy() to copy a timeval from it put garbage into the tv_usec
field.
PR: 194025
Submitted by: David Shane Holden <dpejesh@yahoo.com>
MFC after: 1 week
|
|
|
|
|
| |
PR: 193660
Submitted by: holger@freyther.de
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
run directly on netmap ports using netmap:foo or valeXX:YY device names.
Modifications to existing code are small and trivial, the netmap-specific
code is all in a new file.
Please be aware that in netmap mode the physical interface is disconnected from
the host stack, so libpcap will steal the traffic not just make a copy.
For the full version of the code (including linux and autotools support) see
https://code.google.com/p/netmap-libpcap/
MFC after: 3 days
|
|
|
|
| |
my bug in r271409 that I noticed while reviewing r272492.
|
|\ |
|