* Re: [PATCH net] bpf: adjust verifier heuristics
From: David Miller @ 2017-05-18 2:56 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <57a6fc1f937d985a5851016221c98a29fb1cc46a.1495068621.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 18 May 2017 03:00:06 +0200
> Current limits with regards to processing program paths do not
> really reflect today's needs anymore due to programs becoming
> more complex and verifier smarter, keeping track of more data
> such as const ALU operations, alignment tracking, spilling of
> PTR_TO_MAP_VALUE_ADJ registers, and other features allowing for
> smarter matching of what LLVM generates.
>
> This also comes with the side-effect that we result in fewer
> opportunities to prune search states and thus often need to do
> more work to prove safety than in the past due to different
> register states and stack layout where we mismatch. Generally,
> it's quite hard to determine what caused a sudden increase in
> complexity, it could be caused by something as trivial as a
> single branch somewhere at the beginning of the program where
> LLVM assigned a stack slot that is marked differently throughout
> other branches and thus causing a mismatch, where verifier
> then needs to prove safety for the whole rest of the program.
> Subsequently, programs with even less than half the insn size
> limit can get rejected. We noticed that while some programs
> load fine under pre 4.11, they get rejected due to hitting
> limits on more recent kernels. We saw that in the vast majority
> of cases (90+%) pruning failed due to register mismatches. In
> case of stack mismatches, majority of cases failed due to
> different stack slot types (invalid, spill, misc) rather than
> differences in spilled registers.
>
> This patch makes pruning more aggressive by also adding markers
> that sit at conditional jumps as well. Currently, we only mark
> jump targets for pruning. For example in direct packet access,
> these are usually error paths where we bail out. We found that
> adding these markers, it can reduce number of processed insns
> by up to 30%. Another option is to ignore reg->id in probing
> PTR_TO_MAP_VALUE_OR_NULL registers, which can help pruning
> slightly as well by up to 7% observed complexity reduction as
> stand-alone. Meaning, if a previous path with register type
> PTR_TO_MAP_VALUE_OR_NULL for map X was found to be safe, then
> in the current state a PTR_TO_MAP_VALUE_OR_NULL register for
> the same map X must be safe as well. Last but not least the
> patch also adds a scheduling point and bumps the current limit
> for instructions to be processed to a more adequate value.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Ok, applied, but we should continue trying to make the pruner
more effective.
^ permalink raw reply
* Re: [net:master 9/12] net/ipv6/ip6_offload.c:120:7-21: WARNING: Unsigned expression compared with zero: unfrag_ip6hlen < 0 (fwd)
From: David Miller @ 2017-05-18 2:58 UTC (permalink / raw)
To: julia.lawall; +Cc: kraig, netdev, kbuild-all
In-Reply-To: <alpine.DEB.2.20.1705181000150.3833@hadrien>
From: Julia Lawall <julia.lawall@lip6.fr>
Date: Thu, 18 May 2017 10:01:07 +0800 (SGT)
> It may be worth checking on these. The code context is shown in the first
> case (line 120). For the others, at least it gives the line numbers.
...
>>> net/ipv6/ip6_offload.c:120:7-21: WARNING: Unsigned expression compared with zero: unfrag_ip6hlen < 0
> --
>>> net/ipv6/ip6_output.c:601:5-9: WARNING: Unsigned expression compared with zero: hlen < 0
> --
>>> net/ipv6/udp_offload.c:94:6-20: WARNING: Unsigned expression compared with zero: unfrag_ip6hlen < 0
Sigh, this is worse than the bug the commit introducing these warnings
was trying to fix.
I've pushed the following:
====================
ipv6: Check ip6_find_1stfragopt() return value properly.
Do not use unsigned variables to see if it returns a negative
error or not.
Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/ip6_offload.c | 9 ++++-----
net/ipv6/ip6_output.c | 7 +++----
net/ipv6/udp_offload.c | 8 +++++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index eab36ab..280268f 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -63,7 +63,6 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
const struct net_offload *ops;
int proto;
struct frag_hdr *fptr;
- unsigned int unfrag_ip6hlen;
unsigned int payload_len;
u8 *prevhdr;
int offset = 0;
@@ -116,10 +115,10 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
skb->network_header = (u8 *)ipv6h - skb->head;
if (udpfrag) {
- unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
- if (unfrag_ip6hlen < 0)
- return ERR_PTR(unfrag_ip6hlen);
- fptr = (struct frag_hdr *)((u8 *)ipv6h + unfrag_ip6hlen);
+ int err = ip6_find_1stfragopt(skb, &prevhdr);
+ if (err < 0)
+ return ERR_PTR(err);
+ fptr = (struct frag_hdr *)((u8 *)ipv6h + err);
fptr->frag_off = htons(offset);
if (skb->next)
fptr->frag_off |= htons(IP6_MF);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 01deecd..d4a31be 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -597,11 +597,10 @@ int ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
int ptr, offset = 0, err = 0;
u8 *prevhdr, nexthdr = 0;
- hlen = ip6_find_1stfragopt(skb, &prevhdr);
- if (hlen < 0) {
- err = hlen;
+ err = ip6_find_1stfragopt(skb, &prevhdr);
+ if (err < 0)
goto fail;
- }
+ hlen = err;
nexthdr = *prevhdr;
mtu = ip6_skb_dst_mtu(skb);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index b348cff..a2267f8 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -29,6 +29,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
u8 frag_hdr_sz = sizeof(struct frag_hdr);
__wsum csum;
int tnl_hlen;
+ int err;
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
@@ -90,9 +91,10 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
/* Find the unfragmentable header and shift it left by frag_hdr_sz
* bytes to insert fragment header.
*/
- unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
- if (unfrag_ip6hlen < 0)
- return ERR_PTR(unfrag_ip6hlen);
+ err = ip6_find_1stfragopt(skb, &prevhdr);
+ if (err < 0)
+ return ERR_PTR(err);
+ unfrag_ip6hlen = err;
nexthdr = *prevhdr;
*prevhdr = NEXTHDR_FRAGMENT;
unfrag_len = (skb_network_header(skb) - skb_mac_header(skb)) +
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] hdlcdrv: fix divide error bug if bitrate is 0
From: Firo Yang @ 2017-05-18 3:29 UTC (permalink / raw)
To: walter harms; +Cc: linux-hams, netdev
In-Reply-To: <591C756B.8060109@bfs.de>
On Wed, May 17, 2017 at 06:08:11PM +0200, walter harms wrote:
>
>
>Am 17.05.2017 15:42, schrieb Firo Yang:
>> On Wed, May 17, 2017 at 02:59:39PM +0200, walter harms wrote:
>>>
>>>
>>> Am 17.05.2017 14:35, schrieb Firo Yang:
>>>> The divisor s->par.bitrate will always be 0 until initialized by
>>>> ndo_open() and hdlcdrv_open().
>>>>
>>>> In order to fix this divide zero error, check whether the netdevice
>>>> was opened by ndo_open() before performing divide.
>>>>
>>>> Reported-by: Dmitry Vyukov <dvyukov@google.com>
>>>> Signed-off-by: Firo Yang <firogm@gmail.com>
>>>> ---
>>>> drivers/net/hamradio/hdlcdrv.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
>>>> index 8c3633c..3c783fd 100644
>>>> --- a/drivers/net/hamradio/hdlcdrv.c
>>>> +++ b/drivers/net/hamradio/hdlcdrv.c
>>>> @@ -574,7 +574,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>>>> break;
>>>>
>>>> case HDLCDRVCTL_CALIBRATE:
>>>> - if(!capable(CAP_SYS_RAWIO))
>>>> + if (!capable(CAP_SYS_RAWIO) || !netif_running(dev))
>>>> return -EPERM;
>>>> if (bi.data.calibrate > INT_MAX / s->par.bitrate)
>>>> return -EINVAL;
>>>
>>> I would still check for s->par.bitrate > 0 later changes may affect the setting of it
>>> and it is much more obvious.
>>
>> I think 0 is not valid value for bitrate, so we should check it in
>> other places, like what ser12_open() did:
>> 429 if (bc->baud < 300 || bc->baud > 4800) {
>> 430 printk(KERN_INFO "baycom_ser_fdx: invalid baudrate "
>> 431 "(300...4800)\n");
>> 432 return -EINVAL;
>> 433 }
>> ...
>> 440 bc->hdrv.par.bitrate = bc->baud;
>
>
>I do not want to say you change is not valid but i have learned that it is better to
>have an obvious check that to rely on hidden knowledge.
I agree with this.
>
>
>>
>>>
>>> Also perhaps !netif_running(dev) should better return ENODEV.
>>
>> However, the 'dev' truly exists in this circumstance.
>>
>
>yes and i do not feel good with that but "no permission" will lead
>any enduser into a search for user rights.
Indeed, ENODEV is more informative to enduser.
I will send a update patch.
Thanks,
Firo
>
>
>
>re,
> wh
>
>
>> Thanks,
>> Firo
>>
>>>
>>>
>>> just my 2 cents,
>>> re,
>>> wh
>>>
^ permalink raw reply
* [[PATCH v1]] hdlcdrv: fix divide error bug if bitrate is 0
From: Firo Yang @ 2017-05-18 4:02 UTC (permalink / raw)
To: t.sailer, wharms
Cc: linux-hams, netdev, dvyukov, syzkaller, davem, gregkh, Firo Yang
The divisor s->par.bitrate will always be 0 until initialized by
ndo_open() and hdlcdrv_open().
In order to fix this divide zero error, check whether the netdevice was
opened by ndo_open() before performing divide.And we also check the the
value of bitrate in case of bad setting of it.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Firo Yang <firogm@gmail.com>
---
v0->v1:
Reviewed by walter harms <wharms@bfs.de>.
Return ENODEV instead of EPERM if !netif_running(dev)
Check if s->par.bitrate > 0.
drivers/net/hamradio/hdlcdrv.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
index 8c3633c..b0f417f 100644
--- a/drivers/net/hamradio/hdlcdrv.c
+++ b/drivers/net/hamradio/hdlcdrv.c
@@ -576,6 +576,10 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
case HDLCDRVCTL_CALIBRATE:
if(!capable(CAP_SYS_RAWIO))
return -EPERM;
+ if (!netif_running(dev))
+ return -ENODEV;
+ if (!(s->par.bitrate > 0))
+ return -EINVAL;
if (bi.data.calibrate > INT_MAX / s->par.bitrate)
return -EINVAL;
s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: Leon Romanovsky @ 2017-05-18 4:22 UTC (permalink / raw)
To: Doug Ledford, Linus Torvalds
Cc: Parav Pandit, David Miller, Bart.VanAssche@sandisk.com,
hch@lst.de, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
stable@vger.kernel.org, ubraun@linux.vnet.ibm.com
In-Reply-To: <4a873ea1-ba83-1506-9172-e955d5f9ae16@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]
On Wed, May 17, 2017 at 08:07:00PM -0400, Doug Ledford wrote:
> On 5/17/2017 6:37 PM, Parav Pandit wrote:
> > Hi Doug,
> >
>
> >> It would have been better with AF_INET/AF_INET6 and an option to enable
> >> SMC than AF_SMC. The first implementation simply assumes AF_INET in
> >> the presence of AF_SMC. When IPv6 support is added, some sort of
> >> guessing logic will have to be put in place to try and determine if an
> >> AF_SMC address is actually AF_INET or AF_INET6 since we won't have a
> >> guaranteed way of telling. Apps can use struct sockaddr_storage as their
> >> normal element to stick the address into, and could rely on the kernel to
> >> interpret it properly based on the AF_INET/AF_INET6 differentiation, and
> >> this breaks that. The RFC gives *some* thought to adding IPv6 in the
> >> future, but not a lot. It may be that the answer is that in the future, IPv6
> >> support is enabled by making the IPv6 API be
> >> AF_INET6 + setsockopt(SMC) or the equivalent. If that's the case, then I
> >> would suggest making the later API specifically call out AF_INET +
> >> setsockopt(SMC) be identical to AF_SMC.
> >>
> >
> > What are the shortcomings in my proposal [1] which I am reiterating below.
> > Bart also suggested to define new stream protocol for SMC similar to SCTP.
> >
> > (a) address family should be either AF_INET or AF_INET6
> > (b) socket() API to introduce new protocol as PROTO_SMC for in socket() system call.
> >
> > With this there is no additional setsockop() needed.
> >
> > With this - user space applications, do getaddrinfo() with hint as
> > hints.ai_family = AF_INET;
> > hints.ai_socktype = SOCK_STREAM;
> >
> > getaddrinfo() returns back both the protocols TCP and SMC.
> > Famous database application such as Redis client iterates over all entries of getaddrinfo() and establishes connection to servers.
> >
> > There are few advantages of this interface.
> > 1. No change in any makefile of applications needed - unless user wants to specify explicitly that it wants to force SMC protocol.
> > 2. No need to do LD_LIBRARY_PRELOAD, (which won't work anyway because bind() connect() of SMC checks for AF_INET).
> > 3. No major changes to glibc to process AF_SMC differently
> > glibc references IPPROTO_TCP at 22 places. (compare to AF_INET at 140+ places).
> > A lot simpler test matrix for glibc for new protocol
> > 5. No need to recompile applications, as long as getaddrinfo returns all streaming protocols (TCP, SMC)
> > 6. for applications to make use of setsockopt() it needs another knob and hint from other places, which can be avoided because SMC TCP option negotiates with remote end
> >
> > And representing new protocol as new protocol for a given address family appears correct, compare to setting socket options.
> >
> > Tools like CRIU or similar tool might find a race conditions - when it queries socket option, SMC was not set, but later on SMC was set, and does incorrect handling.
> > Setting socket() with SMC protocol makes it easier to understand in this area as well.
>
> I have no problem with the proposal in itself, but as IBM released this
> publication and did their own implementation prior to submitting things
> upstream, and as there might exist in the field implementations, it
> depends on whether we wish to call those in the field implementations
> experimental and break them as we go to a final implementation of
> version 1, or if we consider version 1 baked. I'm fine breaking it.
> After all, that's what happened with XRC back in the day and Mellanox
> learned a valuable lesson about upstream first. I have no problem with
> IBM learning that same lesson IMO. So, I find your proposal, including
> breaking the API of the version 1 implementation just taken into the
> kernel before it has had time to fully sit and gel, acceptable.
Doug,
I am amused that after your excellent summary you are not calling to
this v1 of protocol in its real word: BROKEN.
Current implementation and RFC are DOA (dead-on-arrival) and are not
usable for ALL RDMA key players (Mellanox, Intel, Chelsio, ...) and
ALL RDMA major users. It doesn't fit into existing infrastructure
(DB, HPC, glibc, e.t.c.) and doesn't even fulfill the expected from
cover letter (doesn't work with LD_PRELOAD_*).
The fact that IBM implemented it and used it doesn't mean that they
can't continue to leave it with out-of-tree solution for a little
bit more time till usable version will come.
>
> But this is where we kind of need a judgment from on high, and why I
> Cc:ed Linus on this thread. Any input on this issue Linus?
It should be dropped/moved_to_staging as soon as possible, before
UAPI started to spread.
>
> > I have additional proposal for link groups, resource creation area. I will take that up after this discussion.
>
> Look forward to hearing it.
>
> > [1] https://patchwork.kernel.org/patch/9719375/
>
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG Key ID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] drivers: net: xgene: Check all RGMII phy mode variants
From: Quan Nguyen @ 2017-05-18 4:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Iyappan Subramanian, David S. Miller, netdev, Florian Fainelli,
linux-arm-kernel, patches
In-Reply-To: <20170517202633.GA14413@lunn.ch>
On Thu, May 18, 2017 at 3:26 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> +bool is_xgene_enet_phy_mode_rgmii(struct net_device *ndev)
>> +{
>> + struct xgene_enet_pdata *pdata = netdev_priv(ndev);
>> + int phy_mode = pdata->phy_mode;
>> + bool ret;
>> +
>> + ret = phy_mode == PHY_INTERFACE_MODE_RGMII ||
>> + phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
>> + phy_mode == PHY_INTERFACE_MODE_RGMII_RXID ||
>> + phy_mode == PHY_INTERFACE_MODE_RGMII_TXID;
>> +
>> + return ret;
>> +}
>
> include/linux/phy.h:
>
> /**
> * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
> * is RGMII (all variants)
> * @phydev: the phy_device struct
> */
> static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
> {
> return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
> phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
> };
>
Hi Andrew,
Our purpose is to handle our internal pdata->phy_mode, so
phy_interface_is_rgmii(phydev) seems not to fit.
Instead, we're working on the below:
+bool is_xgene_enet_phy_mode_rgmii(struct net_device *ndev)
+{
+ struct xgene_enet_pdata *pdata = netdev_priv(ndev);
+
+ return pdata->phy_mode >= PHY_INTERFACE_MODE_RGMII &&
+ pdata->phy_mode <= PHY_INTERFACE_MODE_RGMII_TXID;
+}
+
^ permalink raw reply
* RE: [PATCH net 5/5] qede: Split PF/VF ndos.
From: Mintz, Yuval @ 2017-05-18 4:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20170517.111007.1089356716021925537.davem@davemloft.net>
> > Looking at my alternatives for solving this, I can't see any 'good'
> > options - it seems mightily unorthodox to modify net_device_ops, I.e.,
> > add/remove an NDO function-pointer based on some device property, and
> > having multiple ops declared for the sake of a single feature seems
> > unscalable.
>
> Multiple ops is the only thing that works right now.
What about something like -
diff --git a/drivers/net/ethernet/qlogic/qede/qede_filter.c b/drivers/net/ethernet/qlogic/qede/qede_filter.c
index 333876c..7450c8b 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_filter.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_filter.c
@@ -1028,6 +1028,13 @@ int qede_xdp(struct net_device *dev, struct netdev_xdp *xdp)
{
struct qede_dev *edev = netdev_priv(dev);
+ /* Not all VFs can support XDP; But we can't fail the query */
+ if ((<Actual condition to determine XDP support>) {
+ if (xdp->command == XDP_QUERY_PROG)
+ return 0;
+ return -EOPNOTSUPP;
+ }
+
switch (xdp->command) {
case XDP_SETUP_PROG:
return qede_xdp_set(edev, xdp->prog);
^ permalink raw reply related
* Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
From: Bjorn Andersson @ 2017-05-18 5:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, k.eugene.e@gmail.com, Andy Gross, David Brown,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-soc@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, wcn36xx@lists.infradead.org,
nicolas.dechesne@linaro.org
In-Reply-To: <1495026867.2442.9.camel@sipsolutions.net>
On Wed 17 May 06:14 PDT 2017, Johannes Berg wrote:
> On Thu, 2017-05-04 at 13:13 +0000, Kalle Valo wrote:
> >
> > > > This code intentionally checked if TX status was requested, and
> > > > if not then it doesn't go to the effort of building it.
> > > >
> > >
> > > What I'm finding puzzling is the fact that the only caller of
> > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like
> > > drivers, such as ath10k, call this for each packet handled - but
> > > I'm likely missing something.
>
> Yes, many drivers do call it for each packet, and as such, this
> deficiency was never noted.
>
> > > > As it is with your patch, it'll go and report the TX status
> > > > without any
> > > > TX status information - which is handled in
> > > > wcn36xx_dxe_tx_ack_ind()
> > > > for those frames needing it.
> > > >
> > >
> > > Right, it doesn't sound desired. However, during normal operation
> > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> > > ieee80211_led_tx() is never called.
> >
> > So what's the conclusion? How do we get leds working?
>
> Well, frankly, I never thought the TX LED was a super good idea - but
> it had been supported by the original code IIRC, so never removed. Some
> people like frantic blinking I guess ;-)
>
It seems very important to a lot of people...
But if ieee80211_free_txskb() is the counterpart of
ieee80211_tx_status() then we should be able to push the
ieee80211_led_tx() call down into ieee80211_report_used_skb() and handle
both cases.
The ieee80211_free_txskb() seems to be used in various cases where we
discard skbs, but perhaps this is not an issue in reality.
> But I think the problem also applies to the throughput trigger thing,
> so perhaps we need to stick some LED feedback calls into other places,
> like _noskb() or provide an extra way to do it?
>
Looking around it seems that we either have a call to free_txskb() or
one of the tx_status(); where the _noskb() would need some special
handling. Are there others or would it be reasonable to add a call in
this one "special" case?
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 0/7] crypto: aesni: provide generic gcm(aes)
From: Herbert Xu @ 2017-05-18 5:28 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: netdev, Hannes Frederic Sowa, David S. Miller, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, linux-crypto, linux-kernel
In-Reply-To: <cover.1493395785.git.sd@queasysnail.net>
On Fri, Apr 28, 2017 at 06:11:55PM +0200, Sabrina Dubroca wrote:
> The current aesni AES-GCM implementation only offers support for
> rfc4106(gcm(aes)). This makes some things a little bit simpler
> (handling of associated data and authentication tag), but it means
> that non-IPsec users of gcm(aes) have to rely on
> gcm_base(ctr-aes-aesni,ghash-clmulni), which is much slower.
>
> This patchset adds handling of all valid authentication tag lengths
> and of any associated data length to the assembly code, and exposes a
> generic gcm(aes) AEAD algorithm to the crypto API.
>
> With these patches, performance of MACsec on a single core increases
> by 40% (from 4.5Gbps to around 6.3Gbps).
All patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [net-intel-i40e] question about assignment overwrite
From: Jeff Kirsher @ 2017-05-18 5:49 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20170517154858.Horde.xMvsIEhHNSGu52mfyp7HA3R@gator4166.hostgator.com>
[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]
On Wed, 2017-05-17 at 15:48 -0500, Gustavo A. R. Silva wrote:
> While looking into Coverity ID 1408956 I ran into the following
> piece
> of code at drivers/net/ethernet/intel/i40e/i40e_main.c:8807:
>
> 8807 if (pf->hw.mac.type == I40E_MAC_X722) {
> 8808 pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE
> 8809 | I40E_FLAG_128_QP_RSS_CAPABLE
> 8810 | I40E_FLAG_HW_ATR_EVICT_CAPABLE
> 8811 | I40E_FLAG_OUTER_UDP_CSUM_CAPABLE
> 8812 | I40E_FLAG_WB_ON_ITR_CAPABLE
> 8813 |
> I40E_FLAG_MULTIPLE_TCP_UDP_RSS_PCTYPE
> 8814 | I40E_FLAG_NO_PCI_LINK_CHECK
> 8815 | I40E_FLAG_USE_SET_LLDP_MIB
> 8816 | I40E_FLAG_GENEVE_OFFLOAD_CAPABLE
> 8817 | I40E_FLAG_PTP_L4_CAPABLE
> 8818 | I40E_FLAG_WOL_MC_MAGIC_PKT_WAKE;
> 8819 } else if ((pf->hw.aq.api_maj_ver > 1) ||
> 8820 ((pf->hw.aq.api_maj_ver == 1) &&
> 8821 (pf->hw.aq.api_min_ver > 4))) {
> 8822 /* Supported in FW API version higher than 1.4 */
> 8823 pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> 8824 pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8825 } else {
> 8826 pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8827 }
>
> The issue here is that the assignment at line 8823 is overwritten
> by
> the code at line 8824.
>
> I'm suspicious that line 8824 should be remove and a patch like the
> following can be applied:
>
> index d5c9c9e..48ffa73 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -8821,7 +8821,6 @@ static int i40e_sw_init(struct i40e_pf *pf)
> (pf->hw.aq.api_min_ver > 4))) {
> /* Supported in FW API version higher than 1.4 */
> pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> - pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> } else {
> pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> }
>
> What do you think?
This issue is already fixed in my dev-queue branch on my next-queue
tree.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* bnx2x - bnx2x_attn_int_deasserted3 - MC assert!
From: Daniel Axtens @ 2017-05-18 6:21 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2; +Cc: netdev
Hi,
I'm looking into a powerpc 64-bit little-endian system with 4
(IBM-branded) Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit
Ethernet adaptors installed. It's running 4.11 and using Open vSwitch
and bonded interfaces. We're seeing regular firmware errors coming out
of the network cards when netperf is started as soon as the interfaces
appear:
[60072.330838] bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert!
[60072.330854] bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
[60072.330860] bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
[60072.330878] bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1
... (dump of values follows) ...
I've included the dmesg output with the dump of both crashing cards
below. The errors do not appear if netperf isn't started until a few
minutes after the interfaces come up. The errors are not new in 4.11 -
they have been reproduced in 4.8 and 4.10.
This all seems to come out of firmware rather than Linux, and I don't
have the datasheets to decode the magic numbers, so I was hoping you'd
be able to shed some light on it?
Thanks in advance!
Regards,
Daniel Axtens
====== dmesg output ======
[60072.330838] bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert!
[60072.330854] bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
[60072.330860] bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
[60072.330878] bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1
[60072.330881] bnx2x: [bnx2x_attn_int_deasserted3:4329(enP24p1s0f0)]driver assert
[60072.330884] bnx2x: [bnx2x_panic_dump:923(enP24p1s0f0)]begin crash dump -----------------
[60072.330888] bnx2x: [bnx2x_panic_dump:933(enP24p1s0f0)]def_idx(0xe51f) def_att_idx(0x4) attn_state(0x1) spq_prod_idx(0x37) next_stats_cnt(0xe517)
[60072.330892] bnx2x: [bnx2x_panic_dump:938(enP24p1s0f0)]DSB: attn bits(0x0) ack(0x1) id(0x0) idx(0x4)
[60072.330894] bnx2x: [bnx2x_panic_dump:939(enP24p1s0f0)] def (0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xe605 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0) igu_sb_id(0x0) igu_seg_id(0x1) pf_id(0x0) vnic_id(0x0) vf_id(0xff) vf_valid (0x0) state(0x1)
[60072.330909] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp0: rx_bd_prod(0x4245) rx_bd_cons(0x7e) rx_comp_prod(0x76e1) rx_comp_cons(0x7515) *rx_cons_sb(0x7515)
[60072.330913] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x287b)
[60072.330916] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp0: tx_pkt_prod(0x211b) tx_pkt_cons(0x211b) tx_bd_prod(0x4278) tx_bd_cons(0x4277) *tx_cons_sb(0x211b)
[60072.330920] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.330924] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.330928] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x287b 0x0)
[60072.330929] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0x7515 0x0 0x0 0x0 0x211b 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.330956] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp1: rx_bd_prod(0x8af8) rx_bd_cons(0x931) rx_comp_prod(0xa811) rx_comp_cons(0xa645) *rx_cons_sb(0xa645)
[60072.330960] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x21d8)
[60072.330964] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp1: tx_pkt_prod(0x1eb8) tx_pkt_cons(0x1eb8) tx_bd_prod(0x3dad) tx_bd_cons(0x3dac) *tx_cons_sb(0x1eb8)
[60072.330968] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.330972] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.330975] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x21d8 0x0)
[60072.330976] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0xa645 0x0 0x0 0x0 0x1eb8 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331003] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp2: rx_bd_prod(0x1cd5) rx_bd_cons(0xb0e) rx_comp_prod(0xdd30) rx_comp_cons(0xdb64) *rx_cons_sb(0xdb64)
[60072.331007] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x97d0)
[60072.331011] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp2: tx_pkt_prod(0x1ed6) tx_pkt_cons(0x1ed6) tx_bd_prod(0x3de9) tx_bd_cons(0x3de8) *tx_cons_sb(0x1ed6)
[60072.331015] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331019] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331022] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x97d0 0x0)
[60072.331023] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0xdb64 0x0 0x0 0x0 0x1ed6 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331050] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp3: rx_bd_prod(0xea0a) rx_bd_cons(0x843) rx_comp_prod(0xc22b) rx_comp_cons(0xc05f) *rx_cons_sb(0xc05f)
[60072.331054] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x8aab)
[60072.331057] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp3: tx_pkt_prod(0x1ff3) tx_pkt_cons(0x1ff3) tx_bd_prod(0x41b2) tx_bd_cons(0x41b1) *tx_cons_sb(0x1ff3)
[60072.331062] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331065] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331069] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x8aab 0x0)
[60072.331070] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0xc05f 0x0 0x0 0x0 0x1ff3 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331096] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp4: rx_bd_prod(0xfc36) rx_bd_cons(0xa6f) rx_comp_prod(0x7309) rx_comp_cons(0x713c) *rx_cons_sb(0x713c)
[60072.331100] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x3ada)
[60072.331104] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp4: tx_pkt_prod(0x1e8a) tx_pkt_cons(0x1e8a) tx_bd_prod(0x3d51) tx_bd_cons(0x3d50) *tx_cons_sb(0x1e8a)
[60072.331108] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331112] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331115] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x3ada 0x0)
[60072.331116] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0x713c 0x0 0x0 0x0 0x1e8a 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331143] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp5: rx_bd_prod(0x4a1c) rx_bd_cons(0x855) rx_comp_prod(0x666e) rx_comp_cons(0x64a2) *rx_cons_sb(0x64a2)
[60072.331147] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0xb0dc)
[60072.331150] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp5: tx_pkt_prod(0x85d3) tx_pkt_cons(0x85d3) tx_bd_prod(0xcb2) tx_bd_cons(0xcb1) *tx_cons_sb(0x85d3)
[60072.331154] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331158] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331162] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0xb0dc 0x0)
[60072.331163] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0x64a2 0x0 0x0 0x0 0x85d3 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331189] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp6: rx_bd_prod(0x7aa9) rx_bd_cons(0x8e2) rx_comp_prod(0x9484) rx_comp_cons(0x92b7) *rx_cons_sb(0x92b7)
[60072.331193] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x27f8)
[60072.331197] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp6: tx_pkt_prod(0x1edb) tx_pkt_cons(0x1edb) tx_bd_prod(0x3df3) tx_bd_cons(0x3df2) *tx_cons_sb(0x1edb)
[60072.331201] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331205] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331208] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x27f8 0x0)
[60072.331209] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0x92b7 0x0 0x0 0x0 0x1edb 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331235] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f0)]fp7: rx_bd_prod(0xd2fe) rx_bd_cons(0x137) rx_comp_prod(0xdb9d) rx_comp_cons(0xd9d1) *rx_cons_sb(0xd9d1)
[60072.331239] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x8f11)
[60072.331243] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp7: tx_pkt_prod(0x25fc) tx_pkt_cons(0x25fb) tx_bd_prod(0x4c46) tx_bd_cons(0x4c42) *tx_cons_sb(0x25fb)
[60072.331247] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331251] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f0)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60072.331254] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f0)] run indexes (0x8f11 0x0)
[60072.331255] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f0)] indexes (0x0 0xd9d1 0x0 0x0 0x0 0x25fb 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60072.331284] bnx2x 0018:01:00.0 enP24p1s0f0: bc 7.10.4
[60072.331290] begin fw dump (mark 0x3c6724)
[60072.331681] end of fw dump
[60072.331684] bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
[60072.331690] bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
[60072.331707] bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1
[60072.331710] bnx2x: [bnx2x_panic_dump:1186(enP24p1s0f0)]end crash dump -----------------
[60075.481819] bnx2x: [bnx2x_stats_update:1232(enP24p1s0f2)]storm stats were not updated for 3 times
[60075.481832] bnx2x: [bnx2x_stats_update:1233(enP24p1s0f2)]driver assert
[60075.481844] bnx2x: [bnx2x_panic_dump:923(enP24p1s0f2)]begin crash dump -----------------
[60075.481849] bnx2x: [bnx2x_panic_dump:933(enP24p1s0f2)]def_idx(0xe520) def_att_idx(0x6) attn_state(0x0) spq_prod_idx(0x39) next_stats_cnt(0xe516)
[60075.481855] bnx2x: [bnx2x_panic_dump:938(enP24p1s0f2)]DSB: attn bits(0x0) ack(0x1) id(0x0) idx(0x6)
[60075.481859] bnx2x: [bnx2x_panic_dump:939(enP24p1s0f2)] def (0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xe606 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0) igu_sb_id(0x44) igu_seg_id(0x1) pf_id(0x1) vnic_id(0x0) vf_id(0xff) vf_valid (0x0) state(0x1)
[60075.481880] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp0: rx_bd_prod(0x2ae5) rx_bd_cons(0xa65) rx_comp_prod(0x2ed5) rx_comp_cons(0x2e53) *rx_cons_sb(0x2e53)
[60075.481886] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x500) last_max_sge(0x112) fp_hc_idx(0xcc21)
[60075.481891] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp0: tx_pkt_prod(0xb195) tx_pkt_cons(0xb195) tx_bd_prod(0x6d6c) tx_bd_cons(0x6d6b) *tx_cons_sb(0xb195)
[60075.481898] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.481903] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.481908] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xcc21 0x0)
[60075.481910] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x2e53 0x0 0x0 0x0 0xb195 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.481949] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp1: rx_bd_prod(0x4963) rx_bd_cons(0x8e3) rx_comp_prod(0x4a98) rx_comp_cons(0x4a16) *rx_cons_sb(0x4a16)
[60075.481954] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x480) last_max_sge(0xb6) fp_hc_idx(0xecc3)
[60075.481960] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp1: tx_pkt_prod(0xb2c6) tx_pkt_cons(0xb2c5) tx_bd_prod(0x6f6d) tx_bd_cons(0x6f6a) *tx_cons_sb(0xb2c5)
[60075.481965] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.481971] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.481975] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xecc3 0x0)
[60075.481977] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x4a16 0x0 0x0 0x0 0xb2c5 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482015] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp2: rx_bd_prod(0xb91a) rx_bd_cons(0x89a) rx_comp_prod(0x44cb) rx_comp_cons(0x4449) *rx_cons_sb(0x4449)
[60075.482021] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x4c0) last_max_sge(0xf3) fp_hc_idx(0xdd6b)
[60075.482026] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp2: tx_pkt_prod(0xb1d9) tx_pkt_cons(0xb1d9) tx_bd_prod(0x6e18) tx_bd_cons(0x6e17) *tx_cons_sb(0xb1d9)
[60075.482031] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482036] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482041] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xdd6b 0x0)
[60075.482043] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x4449 0x0 0x0 0x0 0xb1d9 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482080] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp3: rx_bd_prod(0x998e) rx_bd_cons(0x90e) rx_comp_prod(0xee01) rx_comp_cons(0xed7e) *rx_cons_sb(0xed7e)
[60075.482086] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x4c0) last_max_sge(0xf3) fp_hc_idx(0xb170)
[60075.482091] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp3: tx_pkt_prod(0xc93a) tx_pkt_cons(0xc938) tx_bd_prod(0x9d0f) tx_bd_cons(0x9d0a) *tx_cons_sb(0xc938)
[60075.482097] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482103] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482107] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xb170 0x0)
[60075.482109] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0xed7e 0x0 0x0 0x0 0xc938 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482146] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp4: rx_bd_prod(0xa1e) rx_bd_cons(0x99c) rx_comp_prod(0x691a) rx_comp_cons(0x6898) *rx_cons_sb(0x6898)
[60075.482152] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x500) last_max_sge(0x12d) fp_hc_idx(0x83a5)
[60075.482157] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp4: tx_pkt_prod(0xb30f) tx_pkt_cons(0xb30c) tx_bd_prod(0x6ffb) tx_bd_cons(0x6ff4) *tx_cons_sb(0xb30c)
[60075.482163] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482167] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482173] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0x83a5 0x0)
[60075.482174] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x6898 0x0 0x0 0x0 0xb30c 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482211] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp5: rx_bd_prod(0x43da) rx_bd_cons(0x35a) rx_comp_prod(0x451b) rx_comp_cons(0x4499) *rx_cons_sb(0x4499)
[60075.482216] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x4c0) last_max_sge(0xce) fp_hc_idx(0xe90d)
[60075.482221] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp5: tx_pkt_prod(0xb372) tx_pkt_cons(0xb371) tx_bd_prod(0x708a) tx_bd_cons(0x7087) *tx_cons_sb(0xb371)
[60075.482227] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482232] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482237] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xe90d 0x0)
[60075.482239] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x4499 0x0 0x0 0x0 0xb371 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482276] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp6: rx_bd_prod(0x4064) rx_bd_cons(0xfe2) rx_comp_prod(0x7138) rx_comp_cons(0x70b6) *rx_cons_sb(0x70b6)
[60075.482281] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x74c0) last_max_sge(0x70c2) fp_hc_idx(0x6fee)
[60075.482286] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp6: tx_pkt_prod(0xc033) tx_pkt_cons(0xc032) tx_bd_prod(0x8aaf) tx_bd_cons(0x8aac) *tx_cons_sb(0xc032)
[60075.482292] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482297] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482302] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0x6fee 0x0)
[60075.482303] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x70b6 0x0 0x0 0x0 0xc032 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482342] bnx2x: [bnx2x_panic_dump:990(enP24p1s0f2)]fp7: rx_bd_prod(0x4302) rx_bd_cons(0x282) rx_comp_prod(0x4438) rx_comp_cons(0x43b6) *rx_cons_sb(0x43b6)
[60075.482347] bnx2x: [bnx2x_panic_dump:993(enP24p1s0f2)] rx_sge_prod(0x540) last_max_sge(0x144) fp_hc_idx(0xee03)
[60075.482353] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp7: tx_pkt_prod(0xb8e7) tx_pkt_cons(0xb8e6) tx_bd_prod(0x7be7) tx_bd_cons(0x7be4) *tx_cons_sb(0xb8e6)
[60075.482358] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482363] bnx2x: [bnx2x_panic_dump:1010(enP24p1s0f2)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60075.482368] bnx2x: [bnx2x_panic_dump:1021(enP24p1s0f2)] run indexes (0xee03 0x0)
[60075.482370] bnx2x: [bnx2x_panic_dump:1027(enP24p1s0f2)] indexes (0x0 0x43b6 0x0 0x0 0x0 0xb8e6 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60075.482411] bnx2x 0018:01:00.2 enP24p1s0f2: bc 7.10.4
[60075.482417] begin fw dump (mark 0x3c6724)
[60075.482837] end of fw dump
[60075.482841] bnx2x: [bnx2x_mc_assert:720(enP24p1s0f2)]XSTORM_ASSERT_LIST_INDEX 0x2
[60075.482849] bnx2x: [bnx2x_mc_assert:736(enP24p1s0f2)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
[60075.482868] bnx2x: [bnx2x_mc_assert:750(enP24p1s0f2)]Chip Revision: everest3, FW Version: 7_13_1
[60075.482872] bnx2x: [bnx2x_panic_dump:1186(enP24p1s0f2)]end crash dump -----------------
[60082.679313] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[0]: txdata->tx_pkt_prod(8476) != txdata->tx_pkt_cons(8475)
[60084.691653] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[1]: txdata->tx_pkt_prod(7867) != txdata->tx_pkt_cons(7864)
[60086.703936] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[2]: txdata->tx_pkt_prod(7898) != txdata->tx_pkt_cons(7894)
[60088.714354] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[5]: txdata->tx_pkt_prod(34272) != txdata->tx_pkt_cons(34259)
[60090.726489] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[6]: txdata->tx_pkt_prod(7900) != txdata->tx_pkt_cons(7899)
[60092.737306] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[7]: txdata->tx_pkt_prod(9724) != txdata->tx_pkt_cons(9723)
[60094.748509] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[0]: txdata->tx_pkt_prod(8476) != txdata->tx_pkt_cons(8475)
[60096.757971] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[1]: txdata->tx_pkt_prod(7867) != txdata->tx_pkt_cons(7864)
[60098.768651] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[2]: txdata->tx_pkt_prod(7898) != txdata->tx_pkt_cons(7894)
[60100.780366] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[5]: txdata->tx_pkt_prod(34272) != txdata->tx_pkt_cons(34259)
[60102.792871] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[6]: txdata->tx_pkt_prod(7900) != txdata->tx_pkt_cons(7899)
[60104.806225] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f0)]timeout waiting for queue[7]: txdata->tx_pkt_prod(9724) != txdata->tx_pkt_cons(9723)
[60104.809790] bnx2x: [bnx2x_del_all_macs:8501(enP24p1s0f0)]Failed to delete MACs: -5
[60104.809797] bnx2x: [bnx2x_chip_cleanup:9321(enP24p1s0f0)]Failed to schedule DEL commands for UC MACs list: -5
[60104.833774] bnx2x: [bnx2x_func_stop:9080(enP24p1s0f0)]FUNC_STOP ramrod failed. Running a dry transaction
[60105.011980] bnx2x: [bnx2x_flr_clnup_poll_hw_counter:1296(enP24p1s0f0)]CFC PF usage counter timed out usage count=8
[60105.011998] bnx2x 0018:01:00.0 enP24p1s0f0: bc 7.10.4
[60105.012004] begin fw dump (mark 0x3c6774)
[60105.012404] end of fw dump
[60105.012410] bnx2x: [bnx2x_nic_load:2722(enP24p1s0f0)]HW init failed, aborting
[60105.070295] bnx2x 0018:01:00.0 enP24p1s0f0: speed changed to 0 for port enP24p1s0f0
[60487.475116] ibmveth 30000009 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60489.710502] ibmveth 3000000a (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60502.603300] ibmveth 3000000f (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60505.382114] ibmveth 30000010 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60521.307081] ibmveth 30000015 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60522.468067] Unknown VPD Code: 0xfd
[60531.460692] Unknown VPD Code: 0xfd
[60534.795194] ibmveth 30000019 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60539.462088] Unknown VPD Code: 0xfd
[60546.261969] ibmveth 3000001c (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60548.461773] Unknown VPD Code: 0xfd
[60557.802758] ibmveth 3000001f (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60561.754192] ibmveth 30000020 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60567.462169] Unknown VPD Code: 0xfd
[60575.466460] Unknown VPD Code: 0xfd
[60588.693018] ibmveth 30000026 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60590.484390] Unknown VPD Code: 0xfd
[60598.585058] ibmveth 30000028 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60599.464037] Unknown VPD Code: 0xfd
[60608.109536] ibmveth 3000002a (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60613.182019] ibmveth 3000002b (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60615.465578] Unknown VPD Code: 0xfd
[60633.242435] ibmveth 3000002f (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60640.464170] Unknown VPD Code: 0xfd
[60654.378339] ibmveth 30000033 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60665.461887] Unknown VPD Code: 0xfd
[60665.466307] Unknown VPD Code: 0xfd
[60666.089092] ibmveth 30000035 (unnamed net_device) (uninitialized): unable to change checksum offload settings. 1 rc=0 ret_attr=a101
[60673.459592] Unknown VPD Code: 0xfd
[60682.461031] Unknown VPD Code: 0xfd
[60691.102735] ics_rtas_set_affinity: ibm,set-xive irq=655369 returns -3
[60691.102853] ics_rtas_set_affinity: ibm,set-xive irq=655371 returns -3
[60691.102960] ics_rtas_set_affinity: ibm,set-xive irq=655373 returns -3
[60699.460686] Unknown VPD Code: 0xfd
[60707.460300] Unknown VPD Code: 0xfd
[60711.102986] ics_rtas_set_affinity: ibm,set-xive irq=655367 returns -3
[60711.103053] ics_rtas_set_affinity: ibm,set-xive irq=655368 returns -3
[60711.103108] ics_rtas_set_affinity: ibm,set-xive irq=655369 returns -3
[60711.103167] ics_rtas_set_affinity: ibm,set-xive irq=655370 returns -3
[60711.103221] ics_rtas_set_affinity: ibm,set-xive irq=655371 returns -3
[60711.103325] ics_rtas_set_affinity: ibm,set-xive irq=655373 returns -3
[60760.873753] bnx2x: [bnx2x_attn_int_deasserted3:4323(enP30p128s0f0)]MC assert!
[60760.873775] bnx2x: [bnx2x_mc_assert:720(enP30p128s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
[60760.873784] bnx2x: [bnx2x_mc_assert:736(enP30p128s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43df9 0x00463db3 0x00010052
[60760.873808] bnx2x: [bnx2x_mc_assert:750(enP30p128s0f0)]Chip Revision: everest3, FW Version: 7_13_1
[60760.873812] bnx2x: [bnx2x_attn_int_deasserted3:4329(enP30p128s0f0)]driver assert
[60760.873816] bnx2x: [bnx2x_panic_dump:923(enP30p128s0f0)]begin crash dump -----------------
[60760.873821] bnx2x: [bnx2x_panic_dump:933(enP30p128s0f0)]def_idx(0xe7c0) def_att_idx(0x4) attn_state(0x1) spq_prod_idx(0xd8) next_stats_cnt(0xe7b8)
[60760.873826] bnx2x: [bnx2x_panic_dump:938(enP30p128s0f0)]DSB: attn bits(0x0) ack(0x1) id(0x0) idx(0x4)
[60760.873830] bnx2x: [bnx2x_panic_dump:939(enP30p128s0f0)] def (0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xe8a8 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0) igu_sb_id(0x0) igu_seg_id(0x1) pf_id(0x0) vnic_id(0x0) vf_id(0xff) vf_valid (0x0) state(0x1)
[60760.873850] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp0: rx_bd_prod(0x36d6) rx_bd_cons(0x50f) rx_comp_prod(0x3781) rx_comp_cons(0x35b4) *rx_cons_sb(0x35b4)
[60760.873855] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x2ec8)
[60760.873860] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp0: tx_pkt_prod(0x15d) tx_pkt_cons(0x15c) tx_bd_prod(0x2bd) tx_bd_cons(0x2b9) *tx_cons_sb(0x15c)
[60760.873866] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.873871] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.873876] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x2ec8 0x0)
[60760.873878] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x35b4 0x0 0x0 0x0 0x15c 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.873915] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp1: rx_bd_prod(0x580) rx_bd_cons(0x3b9) rx_comp_prod(0x595) rx_comp_cons(0x3c9) *rx_cons_sb(0x3c9)
[60760.873921] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x391)
[60760.873926] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp1: tx_pkt_prod(0x10a) tx_pkt_cons(0x10a) tx_bd_prod(0x216) tx_bd_cons(0x215) *tx_cons_sb(0x10a)
[60760.873931] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.873937] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.873942] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x391 0x0)
[60760.873943] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x3c9 0x0 0x0 0x0 0x10a 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.873980] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp2: rx_bd_prod(0x9fde) rx_bd_cons(0xe19) rx_comp_prod(0xa4d6) rx_comp_cons(0xa30a) *rx_cons_sb(0xa30a)
[60760.873985] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x3e52)
[60760.873990] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp2: tx_pkt_prod(0x392) tx_pkt_cons(0x392) tx_bd_prod(0x8d3) tx_bd_cons(0x8d2) *tx_cons_sb(0x392)
[60760.873995] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874001] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874005] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x3e52 0x0)
[60760.874007] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0xa30a 0x0 0x0 0x0 0x392 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874043] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp3: rx_bd_prod(0xaf77) rx_bd_cons(0xdb0) rx_comp_prod(0xb192) rx_comp_cons(0xafc6) *rx_cons_sb(0xafc6)
[60760.874049] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x7778)
[60760.874053] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp3: tx_pkt_prod(0x174) tx_pkt_cons(0x174) tx_bd_prod(0x2ea) tx_bd_cons(0x2e9) *tx_cons_sb(0x174)
[60760.874059] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874064] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874069] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x7778 0x0)
[60760.874070] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0xafc6 0x0 0x0 0x0 0x174 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874107] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp4: rx_bd_prod(0x5967) rx_bd_cons(0x7a0) rx_comp_prod(0x5a7b) rx_comp_cons(0x58af) *rx_cons_sb(0x58af)
[60760.874112] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x161d)
[60760.874117] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp4: tx_pkt_prod(0x1a5) tx_pkt_cons(0x1a5) tx_bd_prod(0x34d) tx_bd_cons(0x34c) *tx_cons_sb(0x1a5)
[60760.874123] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874128] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874133] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x161d 0x0)
[60760.874134] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x58af 0x0 0x0 0x0 0x1a5 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874171] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp5: rx_bd_prod(0x5c4) rx_bd_cons(0x3fd) rx_comp_prod(0x5da) rx_comp_cons(0x40e) *rx_cons_sb(0x40e)
[60760.874176] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x651)
[60760.874183] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp5: tx_pkt_prod(0x29f) tx_pkt_cons(0x29f) tx_bd_prod(0x543) tx_bd_cons(0x542) *tx_cons_sb(0x29f)
[60760.874188] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874194] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874199] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x651 0x0)
[60760.874200] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x40e 0x0 0x0 0x0 0x29f 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874238] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp6: rx_bd_prod(0x27ef) rx_bd_cons(0x62a) rx_comp_prod(0x286d) rx_comp_cons(0x26a1) *rx_cons_sb(0x26a1)
[60760.874244] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0x1e2b)
[60760.874249] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp6: tx_pkt_prod(0x117) tx_pkt_cons(0x117) tx_bd_prod(0x230) tx_bd_cons(0x22f) *tx_cons_sb(0x117)
[60760.874254] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874260] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874264] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0x1e2b 0x0)
[60760.874266] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x26a1 0x0 0x0 0x0 0x117 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874302] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f0)]fp7: rx_bd_prod(0x39b) rx_bd_cons(0x1d4) rx_comp_prod(0x3aa) rx_comp_cons(0x1de) *rx_cons_sb(0x1de)
[60760.874308] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f0)] rx_sge_prod(0x0) last_max_sge(0x0) fp_hc_idx(0xaaa)
[60760.874312] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp7: tx_pkt_prod(0x8e9) tx_pkt_cons(0x8e9) tx_bd_prod(0x11e3) tx_bd_cons(0x11e2) *tx_cons_sb(0x8e9)
[60760.874318] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874324] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f0)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60760.874328] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f0)] run indexes (0xaaa 0x0)
[60760.874330] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f0)] indexes (0x0 0x1de 0x0 0x0 0x0 0x8e9 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60760.874370] bnx2x 001e:80:00.0 enP30p128s0f0: bc 7.10.4
[60760.874377] begin fw dump (mark 0x3c6524)
[60760.874905] end of fw dump
[60760.874909] bnx2x: [bnx2x_mc_assert:720(enP30p128s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
[60760.874918] bnx2x: [bnx2x_mc_assert:736(enP30p128s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43df9 0x00463db3 0x00010052
[60760.874941] bnx2x: [bnx2x_mc_assert:750(enP30p128s0f0)]Chip Revision: everest3, FW Version: 7_13_1
[60760.874945] bnx2x: [bnx2x_panic_dump:1186(enP30p128s0f0)]end crash dump -----------------
[60764.439813] bnx2x: [bnx2x_stats_update:1232(enP30p128s0f2)]storm stats were not updated for 3 times
[60764.439828] bnx2x: [bnx2x_stats_update:1233(enP30p128s0f2)]driver assert
[60764.439841] bnx2x: [bnx2x_panic_dump:923(enP30p128s0f2)]begin crash dump -----------------
[60764.439847] bnx2x: [bnx2x_panic_dump:933(enP30p128s0f2)]def_idx(0xe7b6) def_att_idx(0x6) attn_state(0x0) spq_prod_idx(0xcf) next_stats_cnt(0xe7ab)
[60764.439853] bnx2x: [bnx2x_panic_dump:938(enP30p128s0f2)]DSB: attn bits(0x0) ack(0x1) id(0x0) idx(0x6)
[60764.439858] bnx2x: [bnx2x_panic_dump:939(enP30p128s0f2)] def (0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xe89e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0) igu_sb_id(0x44) igu_seg_id(0x1) pf_id(0x1) vnic_id(0x0) vf_id(0xff) vf_valid (0x0) state(0x1)
[60764.439879] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp0: rx_bd_prod(0xb8c9) rx_bd_cons(0x849) rx_comp_prod(0xbb58) rx_comp_cons(0xbad6) *rx_cons_sb(0xbad6)
[60764.439884] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0x90) fp_hc_idx(0xcb1b)
[60764.439891] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp0: tx_pkt_prod(0x16d2) tx_pkt_cons(0x16d2) tx_bd_prod(0x37d4) tx_bd_cons(0x37d3) *tx_cons_sb(0x16d2)
[60764.439897] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.439902] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp0: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.439907] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xcb1b 0x0)
[60764.439909] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xbad6 0x0 0x0 0x0 0x16d2 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.439953] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp1: rx_bd_prod(0xa484) rx_bd_cons(0x404) rx_comp_prod(0xa6d2) rx_comp_cons(0xa650) *rx_cons_sb(0xa650)
[60764.439958] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0x94) fp_hc_idx(0x3f53)
[60764.439963] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp1: tx_pkt_prod(0xc4ca) tx_pkt_cons(0xc4ca) tx_bd_prod(0xda80) tx_bd_cons(0xda7f) *tx_cons_sb(0xc4ca)
[60764.439969] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.439975] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp1: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.439979] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0x3f53 0x0)
[60764.439982] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xa650 0x0 0x0 0x0 0xc4ca 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440025] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp2: rx_bd_prod(0x3288) rx_bd_cons(0x208) rx_comp_prod(0x39ad) rx_comp_cons(0x392b) *rx_cons_sb(0x392b)
[60764.440030] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0x99) fp_hc_idx(0x351e)
[60764.440036] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp2: tx_pkt_prod(0x99d0) tx_pkt_cons(0x99cd) tx_bd_prod(0x9f36) tx_bd_cons(0x9f26) *tx_cons_sb(0x99cd)
[60764.440042] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440047] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp2: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440052] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0x351e 0x0)
[60764.440054] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0x392b 0x0 0x0 0x0 0x99cd 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440094] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp3: rx_bd_prod(0xfdd3) rx_bd_cons(0xd53) rx_comp_prod(0x13c) rx_comp_cons(0xba) *rx_cons_sb(0xba)
[60764.440100] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0xa2) fp_hc_idx(0xe3f0)
[60764.440105] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp3: tx_pkt_prod(0x1aa9) tx_pkt_cons(0x1aa9) tx_bd_prod(0x3fee) tx_bd_cons(0x3fed) *tx_cons_sb(0x1aa9)
[60764.440111] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440117] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp3: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440122] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xe3f0 0x0)
[60764.440123] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xba 0x0 0x0 0x0 0x1aa9 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440165] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp4: rx_bd_prod(0xfc6d) rx_bd_cons(0xbeb) rx_comp_prod(0xe) rx_comp_cons(0xff8c) *rx_cons_sb(0xff8c)
[60764.440170] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x540) last_max_sge(0x14d) fp_hc_idx(0xca9b)
[60764.440175] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp4: tx_pkt_prod(0x1578) tx_pkt_cons(0x1578) tx_bd_prod(0x33ca) tx_bd_cons(0x33c9) *tx_cons_sb(0x1578)
[60764.440181] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440185] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp4: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440191] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xca9b 0x0)
[60764.440192] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xff8c 0x0 0x0 0x0 0x1578 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440235] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp5: rx_bd_prod(0xa37a) rx_bd_cons(0x2fa) rx_comp_prod(0xa5ba) rx_comp_cons(0xa538) *rx_cons_sb(0xa538)
[60764.440240] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0x83) fp_hc_idx(0xb59c)
[60764.440245] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp5: tx_pkt_prod(0x1636) tx_pkt_cons(0x1636) tx_bd_prod(0x35e9) tx_bd_cons(0x35e8) *tx_cons_sb(0x1636)
[60764.440251] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440256] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp5: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440261] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xb59c 0x0)
[60764.440263] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xa538 0x0 0x0 0x0 0x1636 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440303] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp6: rx_bd_prod(0xb1f9) rx_bd_cons(0x179) rx_comp_prod(0xc531) rx_comp_cons(0xc4af) *rx_cons_sb(0xc4af)
[60764.440308] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0xeb80) last_max_sge(0xe77f) fp_hc_idx(0xe607)
[60764.440313] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp6: tx_pkt_prod(0x161e) tx_pkt_cons(0x161e) tx_bd_prod(0x35e7) tx_bd_cons(0x35e6) *tx_cons_sb(0x161e)
[60764.440319] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440324] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440329] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xe607 0x0)
[60764.440330] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xc4af 0x0 0x0 0x0 0x161e 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440372] bnx2x: [bnx2x_panic_dump:990(enP30p128s0f2)]fp7: rx_bd_prod(0xa274) rx_bd_cons(0x1f2) rx_comp_prod(0xa4c7) rx_comp_cons(0xa445) *rx_cons_sb(0xa445)
[60764.440377] bnx2x: [bnx2x_panic_dump:993(enP30p128s0f2)] rx_sge_prod(0x480) last_max_sge(0xae) fp_hc_idx(0xbd4d)
[60764.440382] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp7: tx_pkt_prod(0x1f29) tx_pkt_cons(0x1f29) tx_bd_prod(0x482c) tx_bd_cons(0x482b) *tx_cons_sb(0x1f29)
[60764.440388] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440393] bnx2x: [bnx2x_panic_dump:1010(enP30p128s0f2)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[60764.440397] bnx2x: [bnx2x_panic_dump:1021(enP30p128s0f2)] run indexes (0xbd4d 0x0)
[60764.440399] bnx2x: [bnx2x_panic_dump:1027(enP30p128s0f2)] indexes (0x0 0xa445 0x0 0x0 0x0 0x1f29 0x0 0x0)pf_id(0x1) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[60764.440443] bnx2x 001e:80:00.2 enP30p128s0f2: bc 7.10.4
[60764.440451] begin fw dump (mark 0x3c6524)
[60764.440976] end of fw dump
[60764.440981] bnx2x: [bnx2x_mc_assert:720(enP30p128s0f2)]XSTORM_ASSERT_LIST_INDEX 0x2
[60764.440989] bnx2x: [bnx2x_mc_assert:736(enP30p128s0f2)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43df9 0x00463db3 0x00010052
[60764.441013] bnx2x: [bnx2x_mc_assert:750(enP30p128s0f2)]Chip Revision: everest3, FW Version: 7_13_1
[60764.441017] bnx2x: [bnx2x_panic_dump:1186(enP30p128s0f2)]end crash dump -----------------
[60773.620017] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[0]: txdata->tx_pkt_prod(349) != txdata->tx_pkt_cons(348)
[60775.632359] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[1]: txdata->tx_pkt_prod(276) != txdata->tx_pkt_cons(266)
[60777.640531] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[2]: txdata->tx_pkt_prod(915) != txdata->tx_pkt_cons(914)
[60779.649798] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[3]: txdata->tx_pkt_prod(373) != txdata->tx_pkt_cons(372)
[60781.661792] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[4]: txdata->tx_pkt_prod(422) != txdata->tx_pkt_cons(421)
[60783.674166] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[5]: txdata->tx_pkt_prod(675) != txdata->tx_pkt_cons(671)
[60785.686835] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[6]: txdata->tx_pkt_prod(294) != txdata->tx_pkt_cons(279)
[60787.700171] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[7]: txdata->tx_pkt_prod(2293) != txdata->tx_pkt_cons(2281)
[60789.713792] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[0]: txdata->tx_pkt_prod(349) != txdata->tx_pkt_cons(348)
[60791.730113] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[1]: txdata->tx_pkt_prod(276) != txdata->tx_pkt_cons(266)
[60793.746280] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[2]: txdata->tx_pkt_prod(915) != txdata->tx_pkt_cons(914)
[60795.762117] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[3]: txdata->tx_pkt_prod(373) != txdata->tx_pkt_cons(372)
[60797.778579] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[4]: txdata->tx_pkt_prod(422) != txdata->tx_pkt_cons(421)
[60799.794700] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[5]: txdata->tx_pkt_prod(675) != txdata->tx_pkt_cons(671)
[60801.812897] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[6]: txdata->tx_pkt_prod(294) != txdata->tx_pkt_cons(279)
[60803.830978] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f0)]timeout waiting for queue[7]: txdata->tx_pkt_prod(2293) != txdata->tx_pkt_cons(2281)
[60803.835043] bnx2x: [bnx2x_del_all_macs:8501(enP30p128s0f0)]Failed to delete MACs: -5
[60803.835049] bnx2x: [bnx2x_chip_cleanup:9321(enP30p128s0f0)]Failed to schedule DEL commands for UC MACs list: -5
[60803.855737] bnx2x: [bnx2x_func_stop:9080(enP30p128s0f0)]FUNC_STOP ramrod failed. Running a dry transaction
[60804.033992] bnx2x: [bnx2x_flr_clnup_poll_hw_counter:1296(enP30p128s0f0)]CFC PF usage counter timed out usage count=8
[60804.034012] bnx2x 001e:80:00.0 enP30p128s0f0: bc 7.10.4
[60804.034018] begin fw dump (mark 0x3c6574)
[60804.034536] end of fw dump
[60804.034542] bnx2x: [bnx2x_nic_load:2722(enP30p128s0f0)]HW init failed, aborting
[60804.092357] bnx2x 001e:80:00.0 enP30p128s0f0: speed changed to 0 for port enP30p128s0f0
[60900.119619] INFO: task kworker/24:3:19463 blocked for more than 120 seconds.
[60900.119635] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.119638] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[60900.119747] INFO: task kworker/16:1:11309 blocked for more than 120 seconds.
[60900.119750] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.119752] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[60900.119845] INFO: task kworker/1:2:17629 blocked for more than 120 seconds.
[60900.119848] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.119850] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[60900.119940] INFO: task kworker/8:3:19694 blocked for more than 120 seconds.
[60900.119943] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.119945] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[60900.120032] INFO: task kworker/24:4:22639 blocked for more than 120 seconds.
[60900.120034] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.120037] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[60900.120121] INFO: task kworker/1:6:23846 blocked for more than 120 seconds.
[60900.120124] Tainted: G W OE 4.11.0-041100-generic #201705041534
[60900.120126] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[61020.951258] INFO: task kworker/24:3:19463 blocked for more than 120 seconds.
[61020.951276] Tainted: G W OE 4.11.0-041100-generic #201705041534
[61020.951279] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[61020.951389] INFO: task kworker/16:1:11309 blocked for more than 120 seconds.
[61020.951392] Tainted: G W OE 4.11.0-041100-generic #201705041534
[61020.951394] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[61020.951486] INFO: task kworker/1:2:17629 blocked for more than 120 seconds.
[61020.951489] Tainted: G W OE 4.11.0-041100-generic #201705041534
[61020.951491] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[61020.951581] INFO: task kworker/8:3:19694 blocked for more than 120 seconds.
[61020.951584] Tainted: G W OE 4.11.0-041100-generic #201705041534
[61020.951586] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[61344.754891] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[1]: txdata->tx_pkt_prod(50382) != txdata->tx_pkt_cons(50378)
[61346.770627] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[2]: txdata->tx_pkt_prod(39377) != txdata->tx_pkt_cons(39373)
[61348.784316] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[3]: txdata->tx_pkt_prod(7452) != txdata->tx_pkt_cons(6825)
[61350.802315] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[4]: txdata->tx_pkt_prod(5500) != txdata->tx_pkt_cons(5496)
[61352.822720] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[5]: txdata->tx_pkt_prod(5689) != txdata->tx_pkt_cons(5686)
[61354.836610] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[6]: txdata->tx_pkt_prod(5663) != txdata->tx_pkt_cons(5662)
[61356.856177] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[7]: txdata->tx_pkt_prod(8000) != txdata->tx_pkt_cons(7977)
[61358.868256] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[1]: txdata->tx_pkt_prod(50382) != txdata->tx_pkt_cons(50378)
[61360.888612] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[2]: txdata->tx_pkt_prod(39377) != txdata->tx_pkt_cons(39373)
[61362.907396] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[3]: txdata->tx_pkt_prod(7452) != txdata->tx_pkt_cons(6825)
[61364.923391] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[4]: txdata->tx_pkt_prod(5500) != txdata->tx_pkt_cons(5496)
[61366.936149] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[5]: txdata->tx_pkt_prod(5689) != txdata->tx_pkt_cons(5686)
[61368.957430] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[6]: txdata->tx_pkt_prod(5663) != txdata->tx_pkt_cons(5662)
[61370.970463] bnx2x: [bnx2x_clean_tx_queue:1205(enP30p128s0f2)]timeout waiting for queue[7]: txdata->tx_pkt_prod(8000) != txdata->tx_pkt_cons(7977)
[61370.974118] bnx2x: [bnx2x_del_all_macs:8501(enP30p128s0f2)]Failed to delete MACs: -5
[61370.974128] bnx2x: [bnx2x_chip_cleanup:9321(enP30p128s0f2)]Failed to schedule DEL commands for UC MACs list: -5
[61370.998105] bnx2x: [bnx2x_func_stop:9080(enP30p128s0f2)]FUNC_STOP ramrod failed. Running a dry transaction
[61371.696099] bnx2x: [bnx2x_nic_load:2753(enP30p128s0f2)]Function start failed!
[61371.754320] bnx2x 001e:80:00.2 enP30p128s0f2: speed changed to 0 for port enP30p128s0f2
[61691.632291] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[0]: txdata->tx_pkt_prod(45512) != txdata->tx_pkt_cons(45461)
[61693.653503] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[1]: txdata->tx_pkt_prod(45827) != txdata->tx_pkt_cons(45765)
[61695.671123] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[2]: txdata->tx_pkt_prod(45571) != txdata->tx_pkt_cons(45529)
[61697.687133] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[3]: txdata->tx_pkt_prod(52084) != txdata->tx_pkt_cons(51512)
[61699.697993] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[4]: txdata->tx_pkt_prod(45893) != txdata->tx_pkt_cons(45836)
[61701.716654] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[5]: txdata->tx_pkt_prod(45980) != txdata->tx_pkt_cons(45937)
[61703.733489] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[6]: txdata->tx_pkt_prod(49251) != txdata->tx_pkt_cons(49202)
[61705.747094] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[7]: txdata->tx_pkt_prod(47447) != txdata->tx_pkt_cons(47334)
[61707.767683] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[0]: txdata->tx_pkt_prod(45512) != txdata->tx_pkt_cons(45461)
[61709.779342] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[1]: txdata->tx_pkt_prod(45827) != txdata->tx_pkt_cons(45765)
[61711.797600] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[2]: txdata->tx_pkt_prod(45571) != txdata->tx_pkt_cons(45529)
[61713.817255] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[3]: txdata->tx_pkt_prod(52084) != txdata->tx_pkt_cons(51512)
[61715.838415] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[4]: txdata->tx_pkt_prod(45893) != txdata->tx_pkt_cons(45836)
[61717.858064] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[5]: txdata->tx_pkt_prod(45980) != txdata->tx_pkt_cons(45937)
[61719.879706] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[6]: txdata->tx_pkt_prod(49251) != txdata->tx_pkt_cons(49202)
[61721.890224] bnx2x: [bnx2x_clean_tx_queue:1205(enP24p1s0f2)]timeout waiting for queue[7]: txdata->tx_pkt_prod(47447) != txdata->tx_pkt_cons(47334)
[61721.894311] bnx2x: [bnx2x_del_all_macs:8501(enP24p1s0f2)]Failed to delete MACs: -5
[61721.894318] bnx2x: [bnx2x_chip_cleanup:9321(enP24p1s0f2)]Failed to schedule DEL commands for UC MACs list: -5
[61721.917093] bnx2x: [bnx2x_func_stop:9080(enP24p1s0f2)]FUNC_STOP ramrod failed. Running a dry transaction
[61722.615051] bnx2x: [bnx2x_nic_load:2753(enP24p1s0f2)]Function start failed!
[61722.673242] bnx2x 0018:01:00.2 enP24p1s0f2: speed changed to 0 for port enP24p1s0f2
^ permalink raw reply
* Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
From: Johannes Berg @ 2017-05-18 7:00 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
nicolas.dechesne@linaro.org, David Brown, Kalle Valo,
k.eugene.e@gmail.com, netdev@vger.kernel.org, Andy Gross,
wcn36xx@lists.infradead.org, linux-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170518050538.GL12920@tuxbook>
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote:
>
> It seems very important to a lot of people...
I get blinking, I guess, but I don't get toggling for every packet :)
The throughput thing we did in iwlwifi seems like a so much better
idea. Not that it really matters for this discussion though.
> But if ieee80211_free_txskb() is the counterpart of
> ieee80211_tx_status() then we should be able to push the
> ieee80211_led_tx() call down into ieee80211_report_used_skb() and
> handle both cases.
Yeah, I guess that works.
> The ieee80211_free_txskb() seems to be used in various cases where we
> discard skbs, but perhaps this is not an issue in reality.
Those should be code paths that are really rare, when we fail
allocations in some places, etc. So it shouldn't really lead to any
problems.
> Looking around it seems that we either have a call to free_txskb() or
> one of the tx_status();
Yes, you're right - we always need one of those for each SKB that
passed through mac80211, everything else is already a bug.
> where the _noskb() would need some special
> handling. Are there others or would it be reasonable to add a call in
> this one "special" case?
Now that I think more about it, the _noskb() doesn't actually make
sense - it's for a separate status report, pretty much only for rate
control feedback, but the SKB should be freed separately with
free_txskb().
johannes
^ permalink raw reply
* [patch net 2/2] mlxsw: spectrum_router: Fix rif counter freeing routine
From: Jiri Pirko @ 2017-05-18 7:18 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw
In-Reply-To: <20170518071853.12279-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
During rif counter freeing the counter index can be invalid. Add check
of validity before freeing the counter.
Fixes: e0c0afd8aa4e ("mlxsw: spectrum: Support for counters on router interfaces")
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 33cec1c..9f89c41 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -206,6 +206,9 @@ void mlxsw_sp_rif_counter_free(struct mlxsw_sp *mlxsw_sp,
{
unsigned int *p_counter_index;
+ if (!mlxsw_sp_rif_counter_valid_get(rif, dir))
+ return;
+
p_counter_index = mlxsw_sp_rif_p_counter_get(rif, dir);
if (WARN_ON(!p_counter_index))
return;
--
2.9.3
^ permalink raw reply related
* [patch net 0/2] mlxsw: couple of fixes
From: Jiri Pirko @ 2017-05-18 7:18 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Cuple of fixes from Arkadi
Arkadi Sharshevsky (2):
mlxsw: spectrum_dpipe: Fix incorrect entry index
mlxsw: spectrum_router: Fix rif counter freeing routine
drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c | 3 ++-
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [patch net 1/2] mlxsw: spectrum_dpipe: Fix incorrect entry index
From: Jiri Pirko @ 2017-05-18 7:18 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw
In-Reply-To: <20170518071853.12279-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
In case of disabled counters the entry index will be incorrect. Fix this
by moving the entry index set before the counter status check.
Fixes: 2ba5999f009d ("mlxsw: spectrum: Add Support for erif table entries access")
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
index ea56f6a..5f0a7bc 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
@@ -199,10 +199,11 @@ static int mlxsw_sp_erif_entry_get(struct mlxsw_sp *mlxsw_sp,
entry->counter_valid = false;
entry->counter = 0;
+ entry->index = mlxsw_sp_rif_index(rif);
+
if (!counters_enabled)
return 0;
- entry->index = mlxsw_sp_rif_index(rif);
err = mlxsw_sp_rif_counter_value_get(mlxsw_sp, rif,
MLXSW_SP_RIF_COUNTER_EGRESS,
&cnt);
--
2.9.3
^ permalink raw reply related
* [patch net-next] mlxsw: spectrum_dpipe: Fix sparse warnings
From: Jiri Pirko @ 2017-05-18 7:22 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw
From: Arkadi Sharshevsky <arkadis@mellanox.com>
drivers/net/ethernet/mellanox/mlxsw//spectrum_dpipe.c:221:52: warning:
Using plain integer as NULL pointer
drivers/net/ethernet/mellanox/mlxsw//spectrum_dpipe.c:221:74: warning:
Using plain integer as NULL pointer
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
index ce2534d..096212d 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.c
@@ -217,7 +217,7 @@ static int
mlxsw_sp_table_erif_entries_dump(void *priv, bool counters_enabled,
struct devlink_dpipe_dump_ctx *dump_ctx)
{
- struct devlink_dpipe_value match_value = {{0}}, action_value = {{0}};
+ struct devlink_dpipe_value match_value, action_value;
struct devlink_dpipe_action action = {0};
struct devlink_dpipe_match match = {0};
struct devlink_dpipe_entry entry = {0};
@@ -226,6 +226,9 @@ mlxsw_sp_table_erif_entries_dump(void *priv, bool counters_enabled,
int i, j;
int err;
+ memset(&match_value, 0, sizeof(match_value));
+ memset(&action_value, 0, sizeof(action_value));
+
mlxsw_sp_erif_match_action_prepare(&match, &action);
err = mlxsw_sp_erif_entry_prepare(&entry, &match_value, &match,
&action_value, &action);
--
2.9.3
^ permalink raw reply related
* [PATCH] net: ieee802154: fix net_device reference release too early
From: linzhang @ 2017-05-18 7:50 UTC (permalink / raw)
To: aar, stefan, davem; +Cc: linux-wpan, netdev, linux-kernel, linzhang
This patch fixes the kernel oops when release net_device reference in
advance. In function raw_sendmsg(i think the dgram_sendmsg has the same
problem), there is a race condition between dev_put and dev_queue_xmit
when the device is gong that maybe lead to dev_queue_ximt to see
an illegal net_device pointer.
So i think that dev_put should be behind of the dev_queue_xmit.
Also, explicit set skb->sk is needless, sock_alloc_send_skb is
already set it.
Signed-off-by: linzhang <xiaolou4617@gmail.com>
---
net/ieee802154/socket.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index eedba76..a60658c 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
goto out_skb;
skb->dev = dev;
- skb->sk = sk;
skb->protocol = htons(ETH_P_IEEE802154);
- dev_put(dev);
-
err = dev_queue_xmit(skb);
if (err > 0)
err = net_xmit_errno(err);
+ dev_put(dev);
+
return err ?: size;
out_skb:
@@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
goto out_skb;
skb->dev = dev;
- skb->sk = sk;
skb->protocol = htons(ETH_P_IEEE802154);
- dev_put(dev);
-
err = dev_queue_xmit(skb);
if (err > 0)
err = net_xmit_errno(err);
+ dev_put(dev);
+
return err ?: size;
out_skb:
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets
From: Greg KH @ 2017-05-18 8:11 UTC (permalink / raw)
To: Anoob Soman
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Eric Dumazet,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <371bcd34-10fa-867f-8bfb-7f61caf11cbe-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
On Wed, May 17, 2017 at 10:21:09AM +0100, Anoob Soman wrote:
> On 17/05/17 09:19, Greg KH wrote:
> > Why is this a non-upstream patch? What commit in Linus's tree fixed
> > this? Why not just backport that?
> >
> > thanks,
> >
> > greg k-h
>
> Agreed, I think it is sensible to backport 52bd2d62ce67 "net: better
> skb->sender_cpu and skb->napi_id cohabitation" to 4.4, rather than having a
> different patch.
So backporting that one patch solves the issue here? Can you please
verify it, and let me know before I apply it?
thanks,
greg k-h
^ permalink raw reply
* Re: stable/linux-4.10.y build: 203 builds: 3 failed, 200 passed, 3 errors, 5 warnings (v4.10.16)
From: gregkh @ 2017-05-18 8:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kernelci.org bot, Kernel Build Reports Mailman List, Eric Dumazet,
stable, Networking
In-Reply-To: <CAK8P3a2gFXScsizfvd-2=yEWBvPoE7L-r5CCf63MzPuWejPzAQ@mail.gmail.com>
On Mon, May 15, 2017 at 02:57:08PM +0200, Arnd Bergmann wrote:
> On Sun, May 14, 2017 at 3:48 PM, kernelci.org bot <bot@kernelci.org> wrote:
> >
> > stable/linux-4.10.y build: 203 builds: 3 failed, 200 passed, 3 errors, 5 warnings (v4.10.16)
> > Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.10.y/kernel/v4.10.16/
> > Tree: stable
> > Branch: linux-4.10.y
> > Git Describe: v4.10.16
> > Git Commit: 6e8e9958691907e8d7eb3b2107619dddbdaeb175
> > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > Built: 4 unique architectures
> >
> > Build Failures Detected:
> >
> > arm: gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> > spear3xx_defconfig FAIL
> > spear6xx_defconfig FAIL
> > tct_hammer_defconfig FAIL
> > Errors summary:
> > 3 net/core/skbuff.c:1575:37: error: 'sock_edemux' undeclared (first use in this function)
> > Warnings summary:
>
> This is a regression against v4.10.15, caused by the backport of
> c21b48cc1bbf ("net: adjust skb->truesize in ___pskb_trim()") by Eric
> Dumazet.
>
> Part of another commit that Eric did earlier fixes it:
>
> 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()")
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1534,7 +1534,7 @@ void sock_efree(struct sk_buff *skb);
> #ifdef CONFIG_INET
> void sock_edemux(struct sk_buff *skb);
> #else
> -#define sock_edemux(skb) sock_efree(skb)
> +#define sock_edemux sock_efree
> #endif
>
> int sock_setsockopt(struct socket *sock, int level, int op,
>
> This commit is not marked 'Cc: stable' upstream, but is referenced
> in the one that was backported and looks like it might be appropriate
> for stable as well. Eric, can you clarify?
Ok, if this is true, can someone provide me with a working backport of
this patch? As it is, it does not apply cleanly, and I don't know how
to resolve the merge error.
Or, we can just not worry about it, as I'm only going to do one more
4.10-stable release, this week, before we throw it away and never care
about it again :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] cdc-ether: divorce initialisation with a filter reset and a generic method
From: Oliver Neukum @ 2017-05-18 8:23 UTC (permalink / raw)
To: davem, netdev, bjorn; +Cc: Oliver Neukum
Some devices need their multicast filter reset but others are crashed by that.
So the methods need to be separated.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reported-by: "Ridgway, Keith" <kridgway@harris.com>
---
drivers/net/usb/cdc_ether.c | 34 +++++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index f3ae88fdf332..70d823043803 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -310,6 +310,26 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
return -ENODEV;
}
+ return 0;
+
+bad_desc:
+ dev_info(&dev->udev->dev, "bad CDC descriptors\n");
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(usbnet_generic_cdc_bind);
+
+
+/* like usbnet_generic_cdc_bind() but handles filter initialization
+ * correctly
+ */
+int usbnet_ether_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ int rv;
+
+ rv = usbnet_generic_cdc_bind(dev, intf);
+ if (rv < 0)
+ goto bail_out;
+
/* Some devices don't initialise properly. In particular
* the packet filter is not reset. There are devices that
* don't do reset all the way. So the packet filter should
@@ -317,13 +337,10 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
*/
usbnet_cdc_update_filter(dev);
- return 0;
-
-bad_desc:
- dev_info(&dev->udev->dev, "bad CDC descriptors\n");
- return -ENODEV;
+bail_out:
+ return rv;
}
-EXPORT_SYMBOL_GPL(usbnet_generic_cdc_bind);
+EXPORT_SYMBOL_GPL(usbnet_ether_cdc_bind);
void usbnet_cdc_unbind(struct usbnet *dev, struct usb_interface *intf)
{
@@ -417,7 +434,7 @@ int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data)
< sizeof(struct cdc_state)));
- status = usbnet_generic_cdc_bind(dev, intf);
+ status = usbnet_ether_cdc_bind(dev, intf);
if (status < 0)
return status;
@@ -472,7 +489,6 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
if (urb->actual_length < sizeof(*event))
return;
-
event = urb->transfer_buffer;
if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
@@ -493,7 +509,7 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
.flags = FLAG_ETHER | FLAG_POINTTOPOINT,
- .bind = usbnet_cdc_bind,
+ .bind = usbnet_ether_cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = usbnet_cdc_status,
.set_rx_mode = usbnet_cdc_update_filter,
--
2.12.0
^ permalink raw reply related
* Re: [PATCH] ravb: add wake-on-lan support via magic packet
From: Geert Uytterhoeven @ 2017-05-18 8:52 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Simon Horman, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20170516121604.GF15597@bigcity.dyn.berto.se>
Hi Niklas,
On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 1:01 PM, Simon Horman <horms@verge.net.au> wrote:
>> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
>> > until the clock issues is sorted out? I'm quite happy to enable features
>> > where they work; not so much where they don't.
>>
>> Agreed.
>>
>> One workaround could be to disable/enable the module clock in the WoL
>> resume path, to make sure it is enabled. Once the enable count reaches
>> 0, CCF will know it's disabled, and will really enable next time.
>> You may need a double disable/double enable though, without testing I
>> don't know remember the enable count is 1 or 2 at that point (due to PM
>> runtime).
>
> I thought about this but it feels like such a hack I did not dare
> suggest it :-) But at the same time it would be nice to enable WoL for
> the s2idle use-case where it works. Only resume from PSCI with WoL
> enabled that is broken, and WoL in PSCI suspend will never work :-)
Indeed.
> How about I add another patch in v2 on-top of this that adds the clock
> disable/enable hack? That way it's clear that this is a workaround and
> once we have support for suspend/resume in CPG/MSSR just that patch can
> be reverted? Or is it cleaner to fold it in to this patch with a big
> comment that this is a workaround? Or is it maybe better to hold of on
> this until CPG/MSSR supports suspend/resume?
Personally, I would have no problems of having the workaround integrated (and
documented, of course) in the WoL patch, as it avoids having broken PSCI
suspend in between WoL-without-workaround and a separate workaround.
It's not that dissimilar from the initial R-Car Gen3 support patch limiting
ravb to 100 Mbps.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* pull-request: can-next 2017-05-18
From: Marc Kleine-Budde @ 2017-05-18 8:56 UTC (permalink / raw)
To: netdev; +Cc: David Miller, kernel@pengutronix.de, linux-can@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 1493 bytes --]
Hello David,
this is a pull request of 4 patches for net-next/master.
All 4 patches are by Quentin Schulz, they add deep deep Suspend/Resume
support to the m_can driver.
regards,
Marc
---
The following changes since commit 1fc4d180b3c6bed0e7f5160bcd553aec89594962:
Merge branch 'phy-marvell-cleanups' (2017-05-17 16:27:52 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-4.13-20170518
for you to fetch changes up to d14ccea0e71a55ad02bf4e1cb378bbece282d5cf:
can: m_can: add deep Suspend/Resume support (2017-05-18 10:32:48 +0200)
----------------------------------------------------------------
linux-can-next-for-4.13-20170518
----------------------------------------------------------------
Quentin Schulz (4):
can: m_can: move Message RAM initialization to function
can: m_can: make m_can_start and m_can_stop symmetric
can: m_can: factorize clock gating and ungating
can: m_can: add deep Suspend/Resume support
drivers/net/can/m_can/m_can.c | 87 ++++++++++++++++++++++++++-----------------
1 file changed, 53 insertions(+), 34 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] liquidio: make the spinlock octeon_devices_lock static
From: Colin King @ 2017-05-18 9:14 UTC (permalink / raw)
To: Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
octeon_devices_lock can be made static as it does not need to be
in global scope.
Cleans up sparse warning: "warning: symbol 'octeon_devices_lock'
was not declared. Should it be static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 3cc56675359a..b5be7074f3de 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -547,7 +547,7 @@ static atomic_t adapter_refcounts[MAX_OCTEON_DEVICES];
static u32 octeon_device_count;
/* locks device array (i.e. octeon_device[]) */
-spinlock_t octeon_devices_lock;
+static spinlock_t octeon_devices_lock;
static struct octeon_core_setup core_setup[MAX_OCTEON_DEVICES];
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next v2] net: fix __skb_try_recv_from_queue to return the old behavior
From: Paolo Abeni @ 2017-05-18 9:53 UTC (permalink / raw)
To: Andrei Vagin, David S. Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20170517183905.10971-1-avagin@openvz.org>
On Wed, 2017-05-17 at 11:39 -0700, Andrei Vagin wrote:
> This function has to return NULL on a error case, because there is a
> separate error variable.
>
> The offset has to be changed only if skb is returned
>
> v2: fix udp code to not use an extra variable
>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: David S. Miller <davem@davemloft.net>
> Fixes: 65101aeca522 ("net/sock: factor out dequeue/peek with offset cod")
> Signed-off-by: Andrei Vagin <avagin@openvz.org>
> ---
> net/core/datagram.c | 14 ++++++++------
> net/ipv4/udp.c | 12 +++---------
> 2 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index a4592b4..bc46118 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -170,20 +170,21 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
> struct sk_buff **last)
> {
> struct sk_buff *skb;
> + int _off = *off;
>
> *last = queue->prev;
> skb_queue_walk(queue, skb) {
> if (flags & MSG_PEEK) {
> - if (*off >= skb->len && (skb->len || *off ||
> + if (_off >= skb->len && (skb->len || _off ||
> skb->peeked)) {
> - *off -= skb->len;
> + _off -= skb->len;
> continue;
> }
> if (!skb->len) {
> skb = skb_set_peeked(skb);
> if (unlikely(IS_ERR(skb))) {
> *err = PTR_ERR(skb);
> - return skb;
> + return NULL;
> }
> }
> *peeked = 1;
> @@ -193,6 +194,7 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
> if (destructor)
> destructor(sk, skb);
> }
> + *off = _off;
> return skb;
> }
> return NULL;
> @@ -253,8 +255,6 @@ struct sk_buff *__skb_try_recv_datagram(struct sock *sk, unsigned int flags,
>
> *peeked = 0;
> do {
> - int _off = *off;
> -
> /* Again only user level code calls this function, so nothing
> * interrupt level will suddenly eat the receive_queue.
> *
> @@ -263,8 +263,10 @@ struct sk_buff *__skb_try_recv_datagram(struct sock *sk, unsigned int flags,
> */
> spin_lock_irqsave(&queue->lock, cpu_flags);
> skb = __skb_try_recv_from_queue(sk, queue, flags, destructor,
> - peeked, &_off, err, last);
> + peeked, off, &error, last);
> spin_unlock_irqrestore(&queue->lock, cpu_flags);
> + if (error)
> + goto no_packet;
> if (skb)
> return skb;
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 7bd56c9..278e707 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1465,16 +1465,13 @@ struct sk_buff *__skb_recv_udp(struct sock *sk, unsigned int flags,
> error = -EAGAIN;
> *peeked = 0;
> do {
> - int _off = *off;
> -
> spin_lock_bh(&queue->lock);
> skb = __skb_try_recv_from_queue(sk, queue, flags,
> udp_skb_destructor,
> - peeked, &_off, err,
> + peeked, off, err,
> &last);
> if (skb) {
> spin_unlock_bh(&queue->lock);
> - *off = _off;
> return skb;
> }
>
> @@ -1488,20 +1485,17 @@ struct sk_buff *__skb_recv_udp(struct sock *sk, unsigned int flags,
> * the sk_receive_queue lock if fwd memory scheduling
> * is needed.
> */
> - _off = *off;
> spin_lock(&sk_queue->lock);
> skb_queue_splice_tail_init(sk_queue, queue);
>
> skb = __skb_try_recv_from_queue(sk, queue, flags,
> udp_skb_dtor_locked,
> - peeked, &_off, err,
> + peeked, off, err,
> &last);
> spin_unlock(&sk_queue->lock);
> spin_unlock_bh(&queue->lock);
> - if (skb) {
> - *off = _off;
> + if (skb)
> return skb;
> - }
>
> busy_check:
> if (!sk_can_busy_loop(sk))
LGTM, thanks!
Acked-by: Paolo Abeni <pabeni@redhat.com>
^ permalink raw reply
* Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low
From: Oliver Neukum @ 2017-05-18 10:01 UTC (permalink / raw)
To: David Miller, bjorn; +Cc: jim_baxter, linux-kernel, linux-usb, netdev
In-Reply-To: <20170517.141819.1307166900606639947.davem@davemloft.net>
Am Mittwoch, den 17.05.2017, 14:18 -0400 schrieb David Miller:
> From: Bjørn Mork <bjorn@mork.no>
> Date: Tue, 16 May 2017 20:24:10 +0200
>
> > Jim Baxter <jim_baxter@mentor.com> writes:
> >
> >> The CDC-NCM driver can require large amounts of memory to create
> >> skb's and this can be a problem when the memory becomes fragmented.
> >>
> >> This especially affects embedded systems that have constrained
> >> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> >> NTB's.
> >>
> >> The issue is after running for a while the kernel memory can become
> >> fragmented and it needs compacting.
> >> If the NTB allocation is needed before the memory has been compacted
> >> the atomic allocation can fail which can cause increased latency,
> >> large re-transmissions or disconnections depending upon the data
> >> being transmitted at the time.
> >> This situation occurs for less than a second until the kernel has
> >> compacted the memory but the failed devices can take a lot longer to
> >> recover from the failed TX packets.
> >>
> >> To ease this temporary situation I modified the CDC-NCM TX path to
> >> temporarily switch into a reduced memory mode which allocates an NTB
> >> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
> >> sized memory block and only transmit NTB's with a single network frame
> >> until the memory situation is resolved.
> >> Once the memory is compacted the CDC-NCM data can resume transmitting
> >> at the normal tx_max rate once again.
> >
> > I must say that I don't like the additional complexity added here. If
> > there are memory issues and you can reduce the buffer size to
> > USB_CDC_NCM_NTB_MIN_OUT_SIZE, then why don't you just set a lower tx_max
> > buffer size in the first place?
> >
> > echo 2048 > /sys/class/net/wwan0/cdc_ncm/tx_max
>
> When there isn't memory pressure this will hurt performance of
> course.
>
> It is a quite common paradigm to back down to 0 order memory requests
> when higher order ones fail, so this isn't such a bad change from the
> perspective.
>
> However, one negative about it is that when the system is under memory
> stress it doesn't help at all to keep attemping high order allocations
> when the system hasn't recovered yet. In fact, this can make it
> worse.
This makes me wonder why there is no notifier chain for this.
Or am I just too stupid to find it?
Regards
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox