Jacob Keller [Fri, 2 Dec 2016 20:32:59 +0000 (12:32 -0800)]
i40e: allow i40e_update_filter_state to skip broadcast filters
Fix a bug where we modified the mac_filter_hash while outside a lock,
when handling addition of broadcast filters.
Normally, we add filters to firmware by batching the additions into
lists and issuing 1 update for every few filters. Broadcast filters are
handled differently, by instead setting the broadcast promiscuous mode
flags. In order to make sure the 1<->1 mapping of filters in our
addition array lined up with filters in the hlist tmp_add_list, we had
to remove the filter and move it back to the main hash. However, we
didn't do this under lock, which could cause consistency problems for
the list.
Fix this by updating i40e_update_filter_state logic so that it knows to
avoid broadcast filters. This ensures that we don't have to remove the
filter separately, and can put it back using the normal flow.
Change-ID: Id288fade80b3e3a9a54b68cc249188cb95147518 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d88d40b01c5c0dad6a1dca3b18267849eef4a2a9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:32:58 +0000 (12:32 -0800)]
i40e: don't warn every time we clear an Rx timestamp register
The intent of this message was to indicate to a user that we might have
missed a timestamp event for a valid packet. The original method of
detecting the missed events relied on waiting until all 4 registers were
filled.
A recent commit d55458c0cd7a5 ("i40e: replace PTP Rx timestamp hang
logic") replaced this logic with much better detection
scheme that could detect a stalled Rx timestamp register even when other
registers were still functional.
The new logic means that a message will be displayed almost as soon as
a timestamp for a dropped frame occurs. This new logic highlights that
the hardware will attempt timestamp for frames which it later decides to
drop. The most prominent example is when a multicast PTP frame is
received on a multicast address that we are not subscribed to.
Because the hardware initiates the Rx timestamp as soon as possible, it
will latch an RXTIME register, but then drop the packet.
This results in users being confused by the message as they are not
expecting to see dropped timestamp messages unless their application
also indicates that timestamps were missing.
Resolve this by reducing the severity and frequency of the displayed
message. We now only print the message if 3 or 4 of the RXTIME registers
are stalled and get cleared within the same watchdog event. This ensures
that the common case does not constantly display the message.
Additionally, since the message is likely not as meaningful to most
users, reduce the message to a dev_dbg instead of a dev_warn.
Users can still get a count of the number of timestamps dropped by
reading the ethtool statistics value, if necessary.
Change-ID: I35494442226a444c418dfb4f91a3070d06c8435c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e6e3fc2bd3ee03117e1ce388c897fc3b2da97d65) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Henry Tieman [Fri, 2 Dec 2016 20:32:57 +0000 (12:32 -0800)]
i40e: Save link FEC info from link up event
Store the FEC status bits from the link up event into the
hw_link_info structure.
Change-ID: I9a7b256f6dfb0dce89c2f503075d0d383526832e Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3e03d7ccf4418c87a134bbfa79c05090296767f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sudheer Mogilappagari [Fri, 10 Feb 2017 07:58:22 +0000 (23:58 -0800)]
i40e: Add bus number info to i40e_bus_info struct
Currently i40e_bus_info has PCI device and function info only and log
messages print device number as bus number. Added field to provide bus
number info and modified log statements to print bus, device and
function information.
Change-ID: I811617cee2714cc0d6bade8d369f57040990756f Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b3f028fc8abdf72c6ed1103e60e89dd60538f126) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:46:50 +0000 (23:46 -0800)]
i40e: Clean up dead code
The function i40e_client_prepare() can never return an error. So make it
void and quit checking its return value.
Change-ID: I9ff311e2324dde329eb68648efb2c94aaff856db Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3bb83baf9ac9c73f4da051cae17042f264832e61) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 29 Nov 2016 00:06:11 +0000 (16:06 -0800)]
i40e/i40evf : Changed version from 1.6.25 to 1.6.27
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit cfffef76e7fa5b9ac3ec8298336d0265bc86af3c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Feb 2017 07:44:27 +0000 (23:44 -0800)]
i40e: update comment explaining where FDIR buffers are freed
The original comment implies that the only location where the raw_packet
buffer will be freed is in i40e_clean_tx_ring() which is incorrect. In
fact this isn't even the normal case. Update the comment explaining
where the memory is freed.
Change-ID: Ie0defc35ed1c3af183f81fdc60b6d783707a5595 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a158aeaf5bb5b014240b360693751476aca7440b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:43:30 +0000 (23:43 -0800)]
i40e/i40evf: eliminate i40e_pull_tail()
Reorganize the i40e_pull_tail() logic, doing it in i40e_add_rx_frag()
where it's cheaper. The igb driver does this the same way.
Also renames i40e_page_is_reserved() to reflect what it actually
tests.
Change-ID: Icd9cc507aae1fcdc02308b3a09034111b4c24071 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9b37c937313bf6769d0b018ca35180b379d40862) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:40:25 +0000 (23:40 -0800)]
i40e/i40evf: Moves skb from i40e_rx_buffer to i40e_ring
This patch reduces the size of struct i40e_rx_buffer by one pointer,
and makes the i40e driver a little more consistent with the igb driver
in terms of packets that span buffers.
We do this by moving the skb field from struct i40e_rx_buffer to
struct i40e_ring. We pass the skb we already have (or NULL if we
don't) to i40e_fetch_rx_buffer(), which skips the skb allocation if we
already have one for this packet.
Change-ID: I4ad48a531844494ba0c5d8e1a62209a057f661b0 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e72e56597ba15ce70f4fc1eb2ceeaa8da0d4ab5e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:37:28 +0000 (23:37 -0800)]
i40e/i40evf: Limit DMA sync of RX buffers to actual packet size
On packet RX, we perform a DMA sync for CPU before passing the
packet up. Here we limit that sync to the actual length of the
incoming packet, rather than always syncing the entire buffer.
Change-ID: I626aaf6c37275a8ce9e81efcaa773f327b331487 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7987dcd7b95111a5acbf5abdbf155eedacd3546b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:35:18 +0000 (23:35 -0800)]
i40evf: track outstanding client request
The iWarp client cannot continue until this operation has been completed
by the PF driver. Sleep (with timeout) until the reply from the PF
driver has been received.
Change-ID: I5dc41b857bba32d0218b7ce167b5da122dadf349 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e5f77f4a2ff2d6ce2d973ebc62084d92f203c9f6) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Feb 2017 07:29:13 +0000 (23:29 -0800)]
i40e: don't check params until after checking for client instance
We can avoid the minor bit of work by calling check params after we
check for the client instance, since we're about to return early in
cases where we do not have a client.
Change-ID: I56f8ea2ba48d4f571fa331c9ace50819a022fa1c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d7ce6422d6e64502d9f6acff9a4466e2ddb64721) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Tue, 29 Nov 2016 00:06:03 +0000 (16:06 -0800)]
i40e: add interrupt rate limit verbosity
Due to the resolution of the register controlling interrupt rate
limiting, setting certain values for the interrupt rate limit make it
appear as though the limiting is not completely accurate. The problem
is that the interrupt rate limit is getting rounded down to the nearest
multiple of 4. This patch fixes the problem by adding some feedback to
the user as to the actual interrupt rate limit being used when it
differs from the requested limit. Without this patch setting interrupt
rate limits may appear to behave inaccurately.
Change-ID: I3093cf3f2d437d35a4c4f4bb5af5ce1b85ab21b7 Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 33084060fb6d51ff566439a387f69ed90301280c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Tue, 29 Nov 2016 00:06:02 +0000 (16:06 -0800)]
i40e: refactor macro INTRL_USEC_TO_REG
This patch refactors the macro INTRL_USEC_TO_REG into a static inline
function and fixes a couple subtle bugs caused by the macro.
This patch fixes a bug which was caused by passing a bad register value
to the firmware. If enabling interrupt rate limiting, a non-zero value
for the rate limit must be used. Otherwise the firmware sets the
interrupt rate limit to the maximum value. Due to the limited
resolution of the register, attempting to set a value of 1, 2, or 3
would be rounded down to 0 and limiting was left enabled, causing
unexpected behavior.
This patch also fixes a possible bug in which using the macro itself can
introduce unintended side-affects because the macro argument is used
more than once in the macro definition (e.g. a variable post-increment
argument would perform a double increment on the variable).
Without this patch, attempting to set interrupt rate limits of 1, 2, or
3 results in unexpected behavior and future use of this macro could
cause subtle bugs.
Change-Id: I83ac842de0ca9c86761923d6e3a4d7b1b95f2b3f Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1c0e6a3613d3f0bb088a3160095c8da4c1214d02) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Tue, 29 Nov 2016 00:06:01 +0000 (16:06 -0800)]
i40e: remove unused function
After refactoring the client open and close code, this is no longer
needed. Remove it.
Change-ID: If8e6e32baa354d857c2fd8b2f19404f1786011c4 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 04766b22cf805011620f546384b271586548e8a7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jayaprakash Shanmugam [Tue, 29 Nov 2016 00:06:00 +0000 (16:06 -0800)]
i40e: Remove FPK HyperV VF device ID
Requirement for VFs to use the VMBus has been removed that's why
removing Hyper-V VF device ID.
Change-ID: I84f0964f443ee0db3e5e444b5ace996eb71b8280 Signed-off-by: Jayaprakash Shanmugam <jayaprakash.shanmugam@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 11131e2b8e9454f79ebfc71e45fe246948ce4997) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Tue, 29 Nov 2016 00:05:59 +0000 (16:05 -0800)]
i40e: Quick refactor to start moving data off stack and into Tx buffer info
This patch does some quick work to pull some of the data off of the stack
and hopefully start storing it in the Tx buffer info section of the Tx
ring. Ideally we should be moving away from having to store much of
anything on the stack and can just maintain it all in the descriptor rings.
Change-ID: I4b4715ea1920e122502482b3f9e56a9a6cb1e9fe Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 52ea3e802047552a8c1ec8c42cad361ffd4ca09c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Tushar Dave [Sat, 19 Nov 2016 21:53:58 +0000 (13:53 -0800)]
i40e: remove unnecessary __packed
'struct i40e_dma_mem' defined with 'packed' directive causing kernel
unaligned errors on sparc.
e.g.
i40e: Intel(R) Ethernet Connection XL710 Network Driver - version
1.6.16-k
i40e: Copyright (c) 2013 - 2014 Intel Corporation.
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
i40e 0000:03:00.0: fw 5.1.40981 api 1.5 nvm 5.04 0x80002548 0.0.0
This can be fixed with get_unaligned/put_unaligned(). However no
reference in driver shows that 'struct i40e_dma_mem' directly shoved
into NIC hardware. But instead fields of the struct are being read and
used for hardware. Therefore, __packed is unnecessary for 'struct
i40e_dma_mem'.
In addition, although 'struct i40e_virt_mem' doesn't cause any
unaligned access, keeping it packed is unnecessary as well because
of aforementioned reason.
This change make 'struct i40e_dma_mem' and 'struct i40e_virt_mem'
unpacked.
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9588397d24eecb7298bce9307b589a5bc0ccafdd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 11 Nov 2016 20:39:39 +0000 (12:39 -0800)]
i40evf: remove unused device ID
This device ID was intended for use when running Linux VF drivers under
Hyper-V, but we have determined that it is not necessary. Since it is
unused, and will never be used, remove it.
Change-ID: I74998ab4237db043cd400547bb54a0a5e2a37ea5 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 17901e1bde9b959b535d075f137d5a86ca64f1c9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Fri, 11 Nov 2016 20:39:38 +0000 (12:39 -0800)]
i40e: Deprecating unused macro
I40E_MAC_X710 was supposed to be for 10G and I40E_MAC_XL710
was supposed to be for 40G. But function i40e_is_mac_710
sets I40E_MAC_XL710 for all device IDS, I40E_MAC_X710 is not
used at all. As there is nothing to compare there is no need
for this function. Thus deprecating this extra macro and
removing this function entirely and replacing it with a direct
check.
Change-ID: I7d1769954dccd574a290ac04adb836ebd156730e Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 6de432c5ae28e7330e14e85c4c614a67a0a12263) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:37 +0000 (12:39 -0800)]
i40e: when adding or removing MAC filters, correctly handle VLANs
Instead of using i40e_add_filter or i40e_del_filter directly, when
adding a MAC address, we should normally be using i40e_add_mac_filter or
i40e_del_mac_filter. These functions correctly handle the various cases
of VLAN mode or PVID settings. This ensures consistency and avoids the
issues that can occur with the recent addition of a WARN_ON() in
i40e_sync_vsi_filters.
Change-ID: I7fe62db063391fdd1180b2d6a6a3c5ab4307eeee Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9569a9a4547d5636827c3f6b09be73ed924b1d16) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:36 +0000 (12:39 -0800)]
i40e: avoid O(n^2) loop when deleting all filters
Use __i40e_del_filter instead of using i40e_del_filter() which will
avoid doing an additional search to delete a filter we already have the
pointer for.
Change-ID: Iea5a7e3cafbf8c682ed9d3b6c69cf5ff53f44daf Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 148141bb26cf942e6bc7249c55d9958dd62dd4f2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:35 +0000 (12:39 -0800)]
i40e: rename i40e_put_mac_in_vlan and i40e_del_mac_all_vlan
These functions purpose is to add a new MAC filter correctly, whether
we're using VLANs or not. Their goal is to ensure that all active VLANs
get the new MAC filter. Rename them so that their intent is clear. They
function correctly regardless of whether we have any active VLANs or
only have I40E_VLAN_ANY filters. The new names convey how they function
in a more clear manner.
Change-ID: Iec1961f968c0223a7132724a74e26a665750b107 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit feffdbe47d6f4c02b5e2764e14490c5f9d250bdb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:34 +0000 (12:39 -0800)]
i40e: no need to check is_vsi_in_vlan before calling i40e_del_mac_all_vlan
This function won't be appreciably slower when in VLAN mode, so there is
no real reason to not just call it directly. In either case, we still
must search the full table for a MAC/VLAN pair. We do get to stop
searching a tiny bit early in the case of knowing we are not in VLAN
mode, but this is a minor savings and we can avoid the code complexity
by not having to worry about the check.
Change-ID: I533412195b3a42f51cf629e3675dd5145aea8625 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d983001f044cf823490af7dcfcde39cfb42be0db) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:33 +0000 (12:39 -0800)]
i40e: fold the i40e_is_vsi_in_vlan check into i40e_put_mac_in_vlan
Fold the check for determining when to call i40e_put_mac_in_vlan directly
into the function so that we don't need to decide which function to use
ahead of time. This allows us to just call i40e_put_mac_in_vlan directly
without having to check ahead of time.
Change-ID: Ifff526940748ac14b8418be5df5a149502eed137 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7aaf9536c45021772a5bc6cd4b620a11eac750f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Wed, 7 Dec 2016 22:05:34 +0000 (14:05 -0800)]
i40e: don't allow i40e_vsi_(add|kill)_vlan to operate when VID<1
Now that we have the separate i40e_(add|rm)_vlan_all_mac functions, we
should not be using the i40e_vsi_kill_vlan or i40e_vsi_add_vlan
functions when PVID is set or when VID is less than 1. This allows us to
remove some checks in i40e_vsi_add_vlan and ensures that callers which
need to handle VID=0 or VID=-1 don't accidentally invoke the VLAN mode
handling used to convert filters when entering VLAN mode. We also update
the functions to take u16 instead of s16 as well since they no longer
expect to be called with VID=I40E_VLAN_ANY.
Change-ID: Ibddf44a8bb840dde8ceef2a4fdb92fd953b05a57 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit f94484b7584765eebded5d7bfdeb0b2c7b1caf51) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 8 Nov 2016 21:05:19 +0000 (13:05 -0800)]
i40e: Changed version from 1.6.21 to 1.6.25
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 360238693d2bc93fb6ff73146ed358e84fe67961) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sowmini Varadhan [Wed, 7 Jun 2017 21:09:38 +0000 (14:09 -0700)]
rds: tcp: fix memory leak in TIME_WAIT sockets
Due to a toxic cocktail of an endian-ness bug, plus some other changes
in mprds to make sure that the side with the numerically smaller address
must initiate the tcp connection, end result is an infinite connection
attempt and a memory leak in TIME_WAIT sockets.
Sowmini Varadhan [Wed, 31 May 2017 19:11:20 +0000 (12:11 -0700)]
rds: tcp: canonical connection order for all paths with index > 0
The rds_connect_worker() has a bug in the check that enforces the
canonical connection order described in the comments of
rds_tcp_state_change(). The intention is to make sure that all
the multipath connections are always initiated by the smaller IP
address via rds_start_mprds. To achieve this, rds_connection_worker
should check that cp_index > 0.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan [Wed, 31 May 2017 19:08:34 +0000 (12:08 -0700)]
rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN
rds_conn_shutdown() runs in workq context, and marks the rds_connection
as DISCONNECTING before quiescing Tx/Rx paths. However, after all I/O
has quiesced, we may still find the rds_connection state to be
RDS_CONN_ERROR if an intervening FIN was processed in softirq context.
This is not a fatal error: rds_conn_shutdown() should continue the
shutdown, and there is no need to log noisy messages about this event.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wei Lin Guay [Wed, 7 Dec 2016 08:08:09 +0000 (09:08 +0100)]
IB/cm: remove unnecessary ib_query_device in PSIF RNR WA
The query device is performed in CM REQ/REP to retrieve the
vendorID of the sif device. This operation is illegal because
it is calling a sleeping function (ib_query_device) from
a non-sleepable context. Thus, this patch removes this illegal
call and reuses the cached vendorID/DeviceID in the pci_dev
data structure.
James Smart [Fri, 21 Apr 2017 23:05:05 +0000 (16:05 -0700)]
Fix Express lane queue creation.
The older sli4 adapters only supported the 64 byte WQE entry size.
The new adapter (fw) support both 64 and 128 byte WQE entry sizies.
The Express lane WQ was not being created with the 128 byte WQE sizes
when it was supported.
Not having the right WQE size created for the express lane work queue
caused the the firmware to overwrite the lun indentifier in the FCP header.
This patch correctly creates the express lane work queue with the
supported size.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
(cherry picked from commit 7e04e21afa82ef024416f5413b5bdb66e0505bcd)
Hou Tao [Fri, 3 Feb 2017 22:39:07 +0000 (14:39 -0800)]
xfs: reset b_first_retry_time when clear the retry status of xfs_buf_t
After successful IO or permanent error, b_first_retry_time also
needs to be cleared, else the invalid first retry time will be
used by the next retry check.
Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit 4dd2eb633598cb6a5a0be2fd9a2be0819f5eeb5f)
Carlos Maiolino [Wed, 4 Jan 2017 04:34:17 +0000 (20:34 -0800)]
xfs: fix max_retries _show and _store functions
max_retries _show and _store functions should test against cfg->max_retries,
not cfg->retry_timeout
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit ff97f2399edac1e0fb3fa7851d5fbcbdf04717cf)
Eric Sandeen [Tue, 13 Sep 2016 21:51:30 +0000 (07:51 +1000)]
xfs: normalize "infinite" retries in error configs
As it stands today, the "fail immediately" vs. "retry forever"
values for max_retries and retry_timeout_seconds in the xfs metadata
error configurations are not consistent.
A retry_timeout_seconds of 0 means "retry forever," but a
max_retries of 0 means "fail immediately."
retry_timeout_seconds < 0 is disallowed, while max_retries == -1
means "retry forever."
Make this consistent across the error configs, such that a value of
0 means "fail immediately" (i.e. wait 0 seconds, or retry 0 times),
and a value of -1 always means "retry forever."
This makes retry_timeout a signed long to accommodate the -1, even
though it stores jiffies. Given our limit of a 1 day maximum
timeout, this should be sufficient even at much higher HZ values
than we have available today.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 77169812739dd800bc3620d781a77c50c75165cc)
Eric Sandeen [Wed, 20 Jul 2016 00:54:09 +0000 (10:54 +1000)]
xfs: don't reset b_retries to 0 on every failure
With the code as it stands today, b_retries never increments because
it gets reset to 0 in the error callback.
Remove that, and fix a similar problem where the first retry time
was constantly being overwritten, which defeated the timeout tunable
as well. We now only set first retry time if a non-zero timeout is
set, to match the behavior of only incrementing retries if a retry
value is set.
This way max retries & timeouts consistently take effect after a
tunable is set, rather than acting retroactively on a buffer which
has failed at some point in the past and has accumulated state from
those prior failures.
Thanks to dchinner for talking through this with me.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 5539d36752eb789f4067a9f88e72177895d56317)
Eric Sandeen [Wed, 20 Jul 2016 00:48:51 +0000 (10:48 +1000)]
xfs: fix xfs_error_get_cfg for negative errnos
xfs_error_get_cfg() is called with bp->b_error as an arg, which is
negative, so the switch statement won't ever find any matches.
This results in only the default error handler having any effect, as
EIO/ENOSPC/ENODEV get ignored due to the wrong sign.
It seems simplest to always flip the error sign to positive, so that
we can handle either negative errors in bp->b_error, or possibly a
positive errno via something like xfs_error_get_cfg(EIO) - this
future-proofs the function.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e97f6c545f963abd7de56a58a29ba73a9edee015)
Carlos Maiolino [Wed, 18 May 2016 01:11:27 +0000 (11:11 +1000)]
xfs: add "fail at unmount" error handling configuration
If we take "retry forever" literally on metadata IO errors, we can
hang at unmount, once it retries those writes forever. This is the
default behavior, unfortunately.
Add an error configuration option for this behavior and default it
to "fail" so that an unmount will trigger actuall errors, a shutdown
and allow the unmount to succeed. It will be noisy, though, as it
will log the errors and shutdown that occurs.
To fix this, we need to mark the filesystem as being in the process
of unmounting. Do this with a mount flag that is added at the
appropriate time (i.e. before the blocking AIL sync). We also need
to add this flag if mount fails after the initial phase of log
recovery has been run.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e6b3bb78962e65c4ad125598755cfbf2a8779e86)
Carlos Maiolino [Wed, 18 May 2016 01:09:28 +0000 (11:09 +1000)]
xfs: add configuration handlers for specific errors
now most of the infrastructure is in place, we can start adding
support for configuring specific errors such as ENODEV, ENOSPC, EIO,
etc. Add these error configurations and configure them all to have
appropriate behaviours. That is, all will be configured to retry
forever by default, except for ENODEV, which is an unrecoverable
error, so it will be configured to not retry on error
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e0a431b3a3cc3d0a4c38ccfca8c7320fde40efb6)
Carlos Maiolino [Wed, 18 May 2016 01:08:15 +0000 (11:08 +1000)]
xfs: add configuration of error failure speed
On reception of an error, we can fail immediately, perform some
bound amount of retries or retry indefinitely. The current behaviour
we have is to retry forever.
However, we'd like the ability to choose how long the filesystem
should try after an error, it can either fail immediately, retry a
few times, or retry forever. This is implemented by using
max_retries sysfs attribute, to hold the amount of times we allow
the filesystem to retry after an error. Being -1 a special case
where the filesystem will retry indefinitely.
Add both a maximum retry count and a retry timeout so that we can
bound by time and/or physical IO attempts.
Finally, plumb these into xfs_buf_iodone error processing so that
the error behaviour follows the selected configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit a5ea70d25d76950e11690110b526374307d05d81)
Carlos Maiolino [Wed, 18 May 2016 01:06:44 +0000 (11:06 +1000)]
xfs: introduce table-based init for error behaviors
Before we start expanding the number of error classes and errors we
can configure behaviour for, we need a simple and clear way to
define the default behaviour that we initialized each mount with.
Introduce a table based method for keeping the initial configuration
in, and apply that to the existing initialization code.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ef6a50fbb1bba7951aa23adcfb40e99ca72dc51c)
Carlos Maiolino [Wed, 18 May 2016 01:05:33 +0000 (11:05 +1000)]
xfs: add configurable error support to metadata buffers
With the error configuration handle for async metadata write errors
in place, we can now add initial support to the IO error processing
in xfs_buf_iodone_error().
Add an infrastructure function to look up the configuration handle,
and rearrange the error handling to prepare the way for different
error handling conigurations to be used.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit df3093907ccc718459c54c99da29dd774af41186)
Carlos Maiolino [Wed, 18 May 2016 01:01:00 +0000 (11:01 +1000)]
xfs: introduce metadata IO error class
Now we have the basic infrastructure, add the first error class so
we can build up the infrastructure in a meaningful way. Add the
metadata async write IO error class and sysfs entry, and introduce a
default configuration that matches the existing "retry forever"
behavior for async write metadata buffers.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ffd40ef697dfd3e06f44b1bb5fea93079de8c77d)
Carlos Maiolino [Wed, 18 May 2016 00:58:51 +0000 (10:58 +1000)]
xfs: configurable error behavior via sysfs
We need to be able to change the way XFS behaviours in error
conditions depending on the type of underlying storage. This is
necessary for handling non-traditional block devices with extended
error cases, such as thin provisioned devices that can return ENOSPC
as an IO error.
Introduce the basic sysfs infrastructure needed to define and
configure error behaviours. This is done to be generic enough to
extend to configuring behaviour in other error conditions, such as
ENOMEM, which also has different desired behaviours according to
machine configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 192852be8b5fb14268c2133fe9ce5312e4745963)
Mike Kravetz [Fri, 2 Jun 2017 21:51:12 +0000 (14:51 -0700)]
sparc64: mm: fix copy_tsb to correctly copy huge page TSBs
When a TSB grows beyond its current capacity, a new TSB is allocated
and copy_tsb is called to copy entries from the old TSB to the new.
A hash shift based on page size is used to calculate the index of an
entry in the TSB. copy_tsb has hard coded PAGE_SHIFT in these
calculations. However, for huge page TSBs the value REAL_HPAGE_SHIFT
should be used. As a result, when copy_tsb is called for a huge page
TSB the entries are placed at the incorrect index in the newly
allocated TSB. When doing hardware table walk, the MMU does not
match these entries and we end up in the TSB miss handling code.
This code will then create and write an entry to the correct index
in the TSB. We take a performance hit for the table walk miss and
recreation of these entries.
Pass a new parameter to copy_tsb that is the page size shift to be
used when copying the TSB.
Suggested-by: Anthony Yznaga <anthony.yznaga@oracle.com> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from Linus repo on 7 July 2017
commit 654f4807624a657f364417c2a7454f0df9961734) Reviewed-by: Steve Sistare steven.sistare@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
IB/mlx4: Fix incorrect order of formal and actual parameters
The last two actual parameters when calling id_map_find_by_sl_id()
from id_map_get() are swapped. However, the same formal parameters to
id_map_get() have them swapped as well, inverting the effect of the
first error.
This commit improves readability, but makes no functional change to
the code.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by: Knut Omang <knut.omang@oracle.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
(cherry picked from commit b03ee4ca0cec348c84dccf08aaec2454c4d236c2)
Now that we're guaranteed to have a meaningful root dentry, we can just
export seq_dentry() and use it in btrfs_show_options(). The subvolume ID
is easy to get and can also be useful, so put that in there, too.
Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com>
(cherry picked from commit c8d3fe028f64054d75c72566efb9ecf3c75ee161) Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Current sense_len checks for size of cp->sense_buffer which is of type
pointer. Passing truncated sense data(size of pointer) to upper scsi
layers(aula) is causing delay in discovering FC LUN's.
Fixed sense_len assignment to SCSI_SENSE_BUFFERSIZE, this resolved
delay in discovering FC LUN's.
As part of updating NVMe driver (Bug 25130845), the nvme device mapping was done
before getting the nvme device information. This change got introduced while
resolving a merge conflict. This caused the kernel panic during nvme probe.
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Thomas Tai [Fri, 6 Jan 2017 14:18:38 +0000 (06:18 -0800)]
sparc: Fix kernel BUG at arch/sparc/kernel/mdesc.c
When running ldoms reboot test for long hours, ldom guest panic with
kernel BUG at arch/sparc/kernel/mdesc.c:176! It is because the mdesc
size has changed, mdesc_update should retry the operation by decrement
refcnt before mdesc_free.
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-By: Liam Merwick <Liam.Merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shamir Rabinovitch [Tue, 14 Mar 2017 16:35:27 +0000 (09:35 -0700)]
sparc64/mlx4_core: relaxed order for mlx4_core dma mappings
SPARC PCI require relaxed order PCI transactions from the HCA to the
host memory to enable maximum performance. CX3 is not capable of setting
the relaxed order for the PCI transactions. Only mlx4_core driver can set
relaxed order on the right DMA mappings. Fix it!
This is temporary fix only for UEK4. Upstream changed the way the IB
subsystem work with DMA and upstreaming of this fix requires first to
fix net-next tree panic when rdma service is started (Orabug 25760394)
and only then upstreaming the fix for the SPARC/CX3 performance issue.
This cannot be done in short time and require back-port of lots of
upstream code introduced with upstream commit: "Merge tag
'for-next-dma_ops' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma".
The current decision is to limit the change to mlx4 drivers and the ULPs
that use it. This patch only override the mlx4 DMA functions as opposed
for doing this from ib_verbs DMA functions.
This patch is already used in UEK2/SPARC and was proven as working under
all the product testing and so it is ported as-is.
IOCTL for ccb submission failed due to get_user_pages error should
return EFAULT instead of EPERM. This was a regression introduced by a
prior patch that cleaned up a few functions in this code path.
Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com>
Anthony Yznaga [Wed, 31 May 2017 19:34:59 +0000 (12:34 -0700)]
sparc64: fix M8 ADI support
For platforms that support ADI two things must be done during boot.
First, etrap is patched to ensure that execution in the kernel runs with
PSTATE.mcde=1. This ensures that version checking is enabled if the
kernel accesses ADI-enabled user memory through copy_{to/from}_user,
etc..
Second, the initialization of the common flags used in TTEs must be
adjusted to not set TTE.cv (cacheable-in-virtually-indexed-cache) which
has been replaced by TTE.mcd which enables MCD (aka ADI).
These steps are currently done for M7. This patch adds support for M8
and does some minor cleanup to avoid M7-specific naming and reduce the
number of places chip type needs to be checked (and adjusted in the
future).
Orabug: 26096575 Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com> Reviewed-by: Steve Sistare <steven.sistare@oracle.com>
Return value check of atomic_dec_if_positive is required as it returns
old value minus one. Without this fix, driver will send small ios to
firmware path and that will be a performance issue.
Not critical, but good to have r1_ldio_hint as default value in sdev
private.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 49524b3c6e12375627ddd870613fcc6b24909898) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
For RAID1 FastPath writes, driver needs to allocate extra commands
internally to accommodate for the extra peer command being sent.
Currently driver is allocating 2 extra commands for each but only one
extra command is necessary. Set RAID_1_10_RMW_CMDS to 2 and also change
macro name to RAID_1_PEER_CMDS.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a73b0a4b5d17ee39b2cbac7638a97077189b80cc) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Fix indentation issues and smatch warning reported by Dan Carpenter
for previous series as discussed below.
http://www.spinics.net/lists/linux-scsi/msg103635.html
http://www.spinics.net/lists/linux-scsi/msg103603.html
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 41064f1bf8886bc43afbd9aa23a698f97bc65664) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Fix to account for the reply_q_sz not exceeding the maximum commands
that the firmware can support, instance->max_fw_cmds is already
decremented in megasas_fusion_update_can_queue(). Remove the extra
decrement logic in code.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit cf4e55e7be0a4c009908803ff4c3140c9822c033) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Issue is limited for Syncro firmware where pd_after_lb is not set but is
accidentally used. Not a functional issue, but results in low
performance due to improper load balancing between two LUNs.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b41c0a4aa7c0fc1f98648c020358598498d48f06) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Conflicts:
drivers/scsi/megaraid/megaraid_sas_fp.c
Fetch the latest controller OCR capability from FW before sending
MR_DCMD_CTRL_SHUTDOWN When application sends a shutdown DCMD
(MR_DCMD_CTRL_SHUTDOWN), driver will fetch latest controller information
from firmware. This is to ensure that driver always has latest OCR
capability of controller before sending the DCMD.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 95c060869e6872ea03a4a9d15236adcffb1d8b07) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Change MR_TargetIdToLdGet return type from u8 to u16.
ld id range check is added at two places in this patch -
@megasas_build_ldio_fusion and @megasas_build_ld_nonrw_fusion. Previous
driver code used different data type for lds TargetId returned from
MR_TargetIdToLdGet. Prior to this change, above two functions was
safeguarded due to function always return u8 and maximum value of ld id
returned was 255.
In below check, fw_supported_vd_count as of today is 64 or 256 and valid
range to support is either 0-63 or 0-255. Ideally want to filter
accessing raid map for ld ids which are not valid. With the u16 change,
invalid ld id value is 0xFFFF and we will see kernel panic due to random
memory access in MR_LdRaidGet. The changes will ensure we do not call
MR_LdRaidGet if ld id is beyond size of ldSpanMap array.
if (ld < instance->fw_supported_vd_count)
>From firmware perspective,ld id 0xFF is invalid and even though current
driver code forward such command, firmware fails with target not
available.
ld target id issue occurs mainly whenever driver loops to populate raid
map (ea. MR_ValidateMapInfo). These are the only two places where we
may see out of range target ids and wants to protect raid map access
based on range provided by Firmware API.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit d2d0358bcd09139a8e71afbca35bcd6b219dd1bf) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
On a host, if an ld is deleted there is a hole in the ld array returned
by the FW. But in MR_ValidateMapInfo we are not accounting for holes in
the ld array and traverse only upto index num_lds. This patch takes
care of converting the capability field of all the valid lds in the ld
raid map.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a09454ce5dd11184c5040ed536d323e2a302a579) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Currently fusion context has fixed array load_balance_info. Use dynamic
allocation. In few places, driver do not want physically contigious
memory. Attempt to use vmalloc if physical contiguous memory is not
available.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 5fc499b612c5401a7ae0674086befcdf8b148516) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Conflicts:
drivers/scsi/megaraid/megaraid_sas.h
Avoid Host side PCI bandwidth bottleneck and hint FW to do Write
buffering using RaidFlag MR_RAID_FLAGS_IO_SUB_TYPE_LDIO_BW_LIMIT. Once
IO is landed in FW with MR_RAID_FLAGS_IO_SUB_TYPE_LDIO_BW_LIMIT, it will
do single DMA from host and buffer the Write operation. On back end, FW
will DMA same buffer to the Mirror and Data Arm. This will improve
large block IO performance which bottleneck due to Host side PCI
bandwidth limitation.
Consistent ~4000MB T.P for 256K Block size is expected performance
numbers. IOPS for small Block size should be on par with Disk
performance. (E.g 42 SAS Disk in JBOD mode gives 3700MB T.P. Same
Drive used in R1 WT mode, should give ~1800MB T.P)
Using this patch 24 R1 VDs (HDD) gives below performance for Sequential
Write. Without this patch, we cannot reach above 3200MB (Throughput is
in MB.)
With the changes to remove checks for a valid request descriptor,
issue_dcmd will now always return DCMD_SUCCESS. This patch changes
return type of issue_dcmd to void and change all callers appropriately.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit f4fc209326c79b03fecd38a6709cf08da47f15f7) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
No functional change. Code clean up. Removing error code which is not
valid scenario. In megasas_get_request_descriptor we can remove the
error handling which is not required. With fusion controllers, if there
is a valid message frame available, we are guaranteed to get a
corresponding request descriptor.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 52205ac8940b43cca1711abfb43a05e7df08c09e) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
megasas_fire_cmd_fusion can always use 32 bit descriptor write for
ventura. No need to pass extra flag. Only IOC INIT required 64 bit
Descriptor write.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 45b8a35eed7b1d7e51a4dc04b5b694301a383afa) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Remove function megasas_fpio_to_ldio as we never require to convert fpio
to ldio because of frame unavailability. Grab extra frame of raid 1
write fast path before it creates first frame as Fast Path. Removed
is_raid_1_fp_write flag as raid 1 write fast path command is decided
using r1_alt_dev_handle only. Move resetting megasas_cmd_fusion fields
at common function megasas_return_cmd_fusion.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 8bf7c65d379a6d923dfebb50eb04c2407e4762ed) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
This reverts commit "3e5eadb1a881" ("scsi: megaraid_sas: Enable or
Disable Fast path based on the PCI Threshold Bandwidth")
This patch was aimed to increase performance of R1 Write operation for
large IO size. Since this method used timer approach, it turn on/off
fast path did not work as expected. Patch 0013 describes new algorithm
and performance number.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 18bbcabdc6cc6be8c7f6d80c85d314535d76188d) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
projects / users / jedix / linux-maple.git / log