[PATCH net] tg3: Add PHY reset for 5717/5719/5720 in change ring and flow control paths

2018-11-19 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam 

This patch has the fix to avoid PHY lockup with 5717/5719/5720 in change
ring and flow control paths. This patch solves the RX hang while doing
continuous ring or flow control parameters with heavy traffic from peer.

Signed-off-by: Siva Reddy Kallam 
Acked-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/tg3.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 8929530..432c3b8 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12422,6 +12422,7 @@ static int tg3_set_ringparam(struct net_device *dev, 
struct ethtool_ringparam *e
 {
struct tg3 *tp = netdev_priv(dev);
int i, irq_sync = 0, err = 0;
+   bool reset_phy = false;
 
if ((ering->rx_pending > tp->rx_std_ring_mask) ||
(ering->rx_jumbo_pending > tp->rx_jmb_ring_mask) ||
@@ -12453,7 +12454,13 @@ static int tg3_set_ringparam(struct net_device *dev, 
struct ethtool_ringparam *e
 
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
-   err = tg3_restart_hw(tp, false);
+   /* Reset PHY to avoid PHY lock up */
+   if (tg3_asic_rev(tp) == ASIC_REV_5717 ||
+   tg3_asic_rev(tp) == ASIC_REV_5719 ||
+   tg3_asic_rev(tp) == ASIC_REV_5720)
+   reset_phy = true;
+
+   err = tg3_restart_hw(tp, reset_phy);
if (!err)
tg3_netif_start(tp);
}
@@ -12487,6 +12494,7 @@ static int tg3_set_pauseparam(struct net_device *dev, 
struct ethtool_pauseparam
 {
struct tg3 *tp = netdev_priv(dev);
int err = 0;
+   bool reset_phy = false;
 
if (tp->link_config.autoneg == AUTONEG_ENABLE)
tg3_warn_mgmt_link_flap(tp);
@@ -12556,7 +12564,13 @@ static int tg3_set_pauseparam(struct net_device *dev, 
struct ethtool_pauseparam
 
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
-   err = tg3_restart_hw(tp, false);
+   /* Reset PHY to avoid PHY lock up */
+   if (tg3_asic_rev(tp) == ASIC_REV_5717 ||
+   tg3_asic_rev(tp) == ASIC_REV_5719 ||
+   tg3_asic_rev(tp) == ASIC_REV_5720)
+   reset_phy = true;
+
+   err = tg3_restart_hw(tp, reset_phy);
if (!err)
tg3_netif_start(tp);
}
-- 
1.8.3.1

[PATCH net 2/2] tg3: Add higher cpu clock for 5762.

2018-07-15 Thread Siva Reddy Kallam 
From: Sanjeev Bansal 

This patch has fix for TX timeout while running bi-directional
traffic with 100 Mbps using 5762.

Signed-off-by: Sanjeev Bansal 
Signed-off-by: Siva Reddy Kallam 
Reviewed-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/tg3.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 2ee1527..aa1374d 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9294,6 +9294,15 @@ static int tg3_chip_reset(struct tg3 *tp)
 
tg3_restore_clk(tp);
 
+   /* Increase the core clock speed to fix tx timeout issue for 5762
+* with 100Mbps link speed.
+*/
+   if (tg3_asic_rev(tp) == ASIC_REV_5762) {
+   val = tr32(TG3_CPMU_CLCK_ORIDE_ENABLE);
+   tw32(TG3_CPMU_CLCK_ORIDE_ENABLE, val |
+TG3_CPMU_MAC_ORIDE_ENABLE);
+   }
+
/* Reprobe ASF enable state.  */
tg3_flag_clear(tp, ENABLE_ASF);
tp->phy_flags &= ~(TG3_PHYFLG_1G_ON_VAUX_OK |
-- 
1.8.3.1

[PATCH net 0/2] tg3: Update copyright and fix for tx timeout with 5762

2018-07-15 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam 

First patch:
Update copyright

Second patch:
Add higher cpu clock for 5762

Sanjeev Bansal (1):
  tg3: Add higher cpu clock for 5762.

Siva Reddy Kallam (1):
  tg3: Update copyright

 drivers/net/ethernet/broadcom/tg3.c | 17 +
 drivers/net/ethernet/broadcom/tg3.h |  4 ++--
 2 files changed, 15 insertions(+), 6 deletions(-)

-- 
1.8.3.1

[PATCH net 1/2] tg3: Update copyright

2018-07-15 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam 

Signed-off-by: Siva Reddy Kallam 
Reviewed-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/tg3.c | 4 
 drivers/net/ethernet/broadcom/tg3.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 3be87ef..2ee1527 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -6,11 +6,15 @@
  * Copyright (C) 2004 Sun Microsystems Inc.
  * Copyright (C) 2005-2016 Broadcom Corporation.
  * Copyright (C) 2016-2017 Broadcom Limited.
+ * Copyright (C) 2018 Broadcom. All Rights Reserved. The term "Broadcom"
+ * refers to Broadcom Inc. and/or its subsidiaries.
  *
  * Firmware is:
  * Derived from proprietary unpublished source code,
  * Copyright (C) 2000-2016 Broadcom Corporation.
  * Copyright (C) 2016-2017 Broadcom Ltd.
+ * Copyright (C) 2018 Broadcom. All Rights Reserved. The term "Broadcom"
+ * refers to Broadcom Inc. and/or its subsidiaries.
  *
  * Permission is hereby granted for the distribution of this firmware
  * data in hexadecimal or equivalent format, provided this copyright
diff --git a/drivers/net/ethernet/broadcom/tg3.h 
b/drivers/net/ethernet/broadcom/tg3.h
index 1d61aa3..a772a33 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -7,6 +7,8 @@
  * Copyright (C) 2004 Sun Microsystems Inc.
  * Copyright (C) 2007-2016 Broadcom Corporation.
  * Copyright (C) 2016-2017 Broadcom Limited.
+ * Copyright (C) 2018 Broadcom. All Rights Reserved. The term "Broadcom"
+ * refers to Broadcom Inc. and/or its subsidiaries.
  */
 
 #ifndef _T3_H
-- 
1.8.3.1

Re: tg3 crashes under high load, when using 100Mbits

2018-04-18 Thread Siva Reddy Kallam 
On Sat, Apr 14, 2018 at 9:17 PM, Kai-Heng Feng
<kai.heng.f...@canonical.com> wrote:
> Hi Satish,
>
>> On 2018Mar21, at 00:57, Kai-Heng Feng <kai.heng.f...@canonical.com> wrote:
>>
>> Satish Baddipadige <satish.baddipad...@broadcom.com> wrote:
>>
>>> On Thu, Feb 15, 2018 at 7:37 PM, Siva Reddy Kallam
>>> <siva.kal...@broadcom.com> wrote:
>>>> On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
>>>> <siva.kal...@broadcom.com> wrote:
>>>>> On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
>>>>> <kai.heng.f...@canonical.com> wrote:
>>>>>> Hi Broadcom folks,
>>>>>>
>>>>>> We are now enabling a new platform with tg3 nic, unfortunately we 
>>>>>> observed
>>>>>> the bug [1] that dated back to 2015.
>>>>>> I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762 MRRS 
>>>>>> to
>>>>>> 2048”) but it does’t work.
>>>>>>
>>>>>> Do you have any idea how to solve the issue?
>>>>>>
>>>>>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447664
>>>>>>
>>>>>> Kai-Heng
>>>>> Thank you for reporting. We will check and update you.
>>>> With link aware mode, the clock speed could be slow and boot code does not
>>>> complete within the expected time with lower link speeds. Need to override
>>>> and the clock in driver. We are checking the feasibility of adding
>>>> this in driver or firmware.
>>>
>>> Hi Kai-Heng,
>>>
>>> Can you please test the attached patch?
>>
>> I built a kernel and asked affected users to try.
>
> Users reported that the crash still happens with the patch.
>
> Kai-Heng
>
Thanks for the feedback. We will re-work on the patch and soon provide
you the update.
>>
>> Thanks for your work.
>>
>> Kai-Heng
>>
>>>
>>> Thanks,
>>> Satish
>>> 
>

Re: NETDEV WATCHDOG: eth0 (tg3): transmit queue 0 timed out

2018-02-28 Thread Siva Reddy Kallam 
On Sat, Feb 24, 2018 at 3:48 PM, Borislav Petkov  wrote:
> Hi,
>
> this didn't happen before but after 4.16-rc1 my tg3 nic stops for
> whatever reason and the connection to the machine is dead. It didn't show
> anything in dmesg until today.
>
> The IO pagefaults look like it is trying to access something it
> shouldn't and maybe that's why it times out.
>
> It triggers pretty quickly so I'd call it a reliable reproducer and thus
> I can test patches... :-)
>
> Thx.
Thanks for reporting this. Somehow, this mail moved to my spam folder.
Hence, delay in response.
Looks like this is similar to below issue and it was reported some time back.
https://www.spinics.net/lists/netdev/msg482757.html
We are actively working on this. We will soon provide you an update on this.

Re: tg3 crashes under high load, when using 100Mbits

2018-02-15 Thread Siva Reddy Kallam 
On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
<siva.kal...@broadcom.com> wrote:
> On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
> <kai.heng.f...@canonical.com> wrote:
>> Hi Broadcom folks,
>>
>> We are now enabling a new platform with tg3 nic, unfortunately we observed
>> the bug [1] that dated back to 2015.
>> I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762 MRRS to
>> 2048”) but it does’t work.
>>
>> Do you have any idea how to solve the issue?
>>
>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447664
>>
>> Kai-Heng
>>
> Thank you for reporting. We will check and update you.
With link aware mode, the clock speed could be slow and boot code does not
complete within the expected time with lower link speeds. Need to override
and the clock in driver. We are checking the feasibility of adding
this in driver or firmware.

Re: tg3 crashes under high load, when using 100Mbits

2018-02-11 Thread Siva Reddy Kallam 
On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
 wrote:
> Hi Broadcom folks,
>
> We are now enabling a new platform with tg3 nic, unfortunately we observed
> the bug [1] that dated back to 2015.
> I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762 MRRS to
> 2048”) but it does’t work.
>
> Do you have any idea how to solve the issue?
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447664
>
> Kai-Heng
>
Thank you for reporting. We will check and update you.

[PATCH 3/3] tg3: Enable PHY reset in MTU change path for 5720

2017-12-22 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam <siva.kal...@broadcom.com>

A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.

Signed-off-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
Signed-off-by: Michael Chan <michael.c...@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index a0caa71..8995cfe 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14239,7 +14239,8 @@ static int tg3_change_mtu(struct net_device *dev, int 
new_mtu)
 */
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
-   tg3_asic_rev(tp) == ASIC_REV_5719)
+   tg3_asic_rev(tp) == ASIC_REV_5719 ||
+   tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
 
err = tg3_restart_hw(tp, reset_phy);
-- 
2.1.0

[PATCH net 0/3] update on copyright and couple of fixes

2017-12-22 Thread Siva Reddy Kallam 
First patch:
Update copyright

Second patch:
Add workaround to restrict 5762 MRRS

Third patch:
Add PHY reset in change MTU path for 5720

Siva Reddy Kallam (3):
  tg3: Update copyright
  tg3: Add workaround to restrict 5762 MRRS to 2048
  tg3: Enable PHY reset in MTU change path for 5720

 drivers/net/ethernet/broadcom/tg3.c | 18 +++---
 drivers/net/ethernet/broadcom/tg3.h |  7 ++-
 2 files changed, 21 insertions(+), 4 deletions(-)

-- 
2.1.0

[PATCH 1/3] tg3: Update copyright

2017-12-22 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam <siva.kal...@broadcom.com>

Signed-off-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
Signed-off-by: Michael Chan <michael.c...@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c | 6 --
 drivers/net/ethernet/broadcom/tg3.h | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index d09c5a9..5fe8d9b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -4,11 +4,13 @@
  * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (da...@redhat.com)
  * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgar...@pobox.com)
  * Copyright (C) 2004 Sun Microsystems Inc.
- * Copyright (C) 2005-2014 Broadcom Corporation.
+ * Copyright (C) 2005-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Limited.
  *
  * Firmware is:
  * Derived from proprietary unpublished source code,
- * Copyright (C) 2000-2003 Broadcom Corporation.
+ * Copyright (C) 2000-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Ltd.
  *
  * Permission is hereby granted for the distribution of this firmware
  * data in hexadecimal or equivalent format, provided this copyright
diff --git a/drivers/net/ethernet/broadcom/tg3.h 
b/drivers/net/ethernet/broadcom/tg3.h
index c2d02d0..3d60fc7 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -5,7 +5,8 @@
  * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (da...@redhat.com)
  * Copyright (C) 2001 Jeff Garzik (jgar...@pobox.com)
  * Copyright (C) 2004 Sun Microsystems Inc.
- * Copyright (C) 2007-2014 Broadcom Corporation.
+ * Copyright (C) 2007-2016 Broadcom Corporation.
+ * Copyright (C) 2016-2017 Broadcom Limited.
  */
 
 #ifndef _T3_H
-- 
2.1.0

[PATCH 2/3] tg3: Add workaround to restrict 5762 MRRS to 2048

2017-12-22 Thread Siva Reddy Kallam 
From: Siva Reddy Kallam <siva.kal...@broadcom.com>

One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.

Signed-off-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
Signed-off-by: Michael Chan <michael.c...@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c | 10 ++
 drivers/net/ethernet/broadcom/tg3.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 5fe8d9b..a0caa71 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10054,6 +10054,16 @@ static int tg3_reset_hw(struct tg3 *tp, bool reset_phy)
 
tw32(GRC_MODE, tp->grc_mode | val);
 
+   /* On one of the AMD platform, MRRS is restricted to 4000 because of
+* south bridge limitation. As a workaround, Driver is setting MRRS
+* to 2048 instead of default 4096.
+*/
+   if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+   tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+   val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+   tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+   }
+
/* Setup the timer prescalar register.  Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
diff --git a/drivers/net/ethernet/broadcom/tg3.h 
b/drivers/net/ethernet/broadcom/tg3.h
index 3d60fc7..1f0271f 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -97,6 +97,7 @@
 #define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR0x0106
 #define TG3PCI_SUBDEVICE_ID_DELL_MERLOT0x0109
 #define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT   0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762  0x07f0
 #define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
 #define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
 #define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2   0x009a
@@ -282,6 +283,9 @@
 #define TG3PCI_STD_RING_PROD_IDX   0x0098 /* 64-bit */
 #define TG3PCI_RCV_RET_RING_CON_IDX0x00a0 /* 64-bit */
 /* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x00b4
+#define  MAX_READ_REQ_SIZE_2048 0x4000
+#define  MAX_READ_REQ_MASK  0x7000
 #define TG3PCI_DUAL_MAC_CTRL   0x00b8
 #define  DUAL_MAC_CTRL_CH_MASK  0x0003
 #define  DUAL_MAC_CTRL_ID   0x0004
-- 
2.1.0

Re: [PATCH] tg3: Fix rx hang on MTU change with 5717/5719

2017-12-16 Thread Siva Reddy Kallam 
On Sat, Dec 16, 2017 at 2:51 AM, Brian King  wrote:
> This fixes a hang issue seen when changing the MTU size from 1500 MTU
> to 9000 MTU on both 5717 and 5719 chips. In discussion with Broadcom,
> they've indicated that these chipsets have the same phy as the 57766
> chipset, so the same workarounds apply. This has been tested by IBM
> on both Power 8 and Power 9 systems as well as by Broadcom on x86
> hardware and has been confirmed to resolve the hang issue.
Thanks for the patch. We need more time to review.
>
> Cc: stable 
> Signed-off-by: Brian King 
> ---
>  drivers/net/ethernet/broadcom/tg3.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index de51c21..d09c5a9 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -14225,7 +14225,9 @@ static int tg3_change_mtu(struct net_device *dev, int 
> new_mtu)
> /* Reset PHY, otherwise the read DMA engine will be in a mode that
>  * breaks all requests to 256 bytes.
>  */
> -   if (tg3_asic_rev(tp) == ASIC_REV_57766)
> +   if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
> +   tg3_asic_rev(tp) == ASIC_REV_5717 ||
> +   tg3_asic_rev(tp) == ASIC_REV_5719)
> reset_phy = true;
>
> err = tg3_restart_hw(tp, reset_phy);
> --
> 1.8.3.1
>

Re: tg3 pxe weirdness

2017-09-27 Thread Siva Reddy Kallam 
On Wed, Sep 27, 2017 at 3:35 PM, Berend De Schouwer
<berend.de.schou...@gmail.com> wrote:
> On Mon, 2017-09-25 at 15:11 +0530, Siva Reddy Kallam wrote:
>> On Fri, Sep 22, 2017 at 9:04 PM, Berend De Schouwer
>> <berend.de.schou...@gmail.com> wrote:
>> > On Fri, 2017-09-22 at 11:51 +0530, Siva Reddy Kallam wrote:
>> > >
>> > >
>> > > Can you please share below details?
>> > > 1) Model and Manufacturer of the system
>> > > 2) Linux distro/kernel used?
>> >
>> > 4.13.3 gets a little further, but after some more data is
>> > transferred
>> > the tg3 driver still crashes.  This is unfortunately before I've
>> > got a
>> > writeable filesystem.
>> >
>> > The last line is:
>> > tg3 :01:00.0: tg3_stop_block timed out, ofs=4c00 enable_bit=2
>> >
>> > I've got some ideas to get the full dmesg.
>> >
>> > As with the other kernels it works OK on 1Gbps, but not slower
>> > switches.
>>
>> I am suspecting with link aware mode, the clock speed could be slow
>> and boot code does not
>> complete within the expected time with lower link speeds. So,
>> Providing a patch to override clock.
>> Can you please try with attached debug patch and provide us the
>> feedback with 100M link?
>> If it solves this issue, we will work on proper changes.
>
> This does work on 4.13.3 and PXE for me.
>
> I've tested on 1 Gbps, 100 Mbps and 10 Mbps.  I've done some
> preliminary testing (eg. large file copies.)

Good. We will work on required changes and upstream proper patch after
sanity test with multiple speeds.

Re: tg3 pxe weirdness

2017-09-25 Thread Siva Reddy Kallam 
On Fri, Sep 22, 2017 at 9:04 PM, Berend De Schouwer
<berend.de.schou...@gmail.com> wrote:
> On Fri, 2017-09-22 at 11:51 +0530, Siva Reddy Kallam wrote:
>>
>>
>> Can you please share below details?
>> 1) Model and Manufacturer of the system
>> 2) Linux distro/kernel used?
>
> 4.13.3 gets a little further, but after some more data is transferred
> the tg3 driver still crashes.  This is unfortunately before I've got a
> writeable filesystem.
>
> The last line is:
> tg3 :01:00.0: tg3_stop_block timed out, ofs=4c00 enable_bit=2
>
> I've got some ideas to get the full dmesg.
>
> As with the other kernels it works OK on 1Gbps, but not slower
> switches.
I am suspecting with link aware mode, the clock speed could be slow
and boot code does not
complete within the expected time with lower link speeds. So,
Providing a patch to override clock.
Can you please try with attached debug patch and provide us the
feedback with 100M link?
If it solves this issue, we will work on proper changes.


0001-tg3-Add-clock-override-support-for-5762.patch
Description: Binary data

Re: tg3 pxe weirdness

2017-09-22 Thread Siva Reddy Kallam 
On Thu, Sep 21, 2017 at 7:53 PM, Berend De Schouwer
 wrote:
> Hi,
>
> I've got a machine with a Broadcom bcm5762c, using the tg3 driver, that
> fails to receive network packets under some very specific conditions.
>
> It works perfectly using a 1Gbps switch.  If, however, it first uses
> PXE and then loads the Linux tg3 driver, and the switch is 100Mbps, it
> no longer receives packets larger than ICMP.
>
> It does do ARP and ping.
>
> If it boots using PXE on a 1Gbps switch, boots into Linux, and then
> it's plugged into 100 Mbps it also stops receiving packets.
>
> mii-diag and dmesg confirm auto-negotiated speed and flow control, and
> confirm temporary disconnect as the cables are moved.
>
> PXE boots using UNDI, which then transfers a kernel using TFTP, which
> transfers correctly.  The kernel boots, loads the tg3 driver, connects
> the network.  Up to this point everything works.  Ping will work too.
> Any other network traffic fails.
>
> Booting from a harddrive works fine.  I assume the UNDI driver
> somewhere breaks auto-negotiation.  I've tried using mii-tool and
> ethtool, but I haven't managed to make it work yet.
>
> Is it possible to get negotiation working after PXE boot?  Are there
> any tg3 driver flags that might make a difference?
>
>
> Berend

Can you please share below details?
1) Model and Manufacturer of the system
2) Linux distro/kernel used?

Re: netdev watchdog enp1s0 (tg3): transmit queue 0 timed out

2017-09-04 Thread Siva Reddy Kallam 
On Fri, Sep 1, 2017 at 12:13 PM, Frans van Berckel  wrote:
> Dear Michael and Siva,
>
> On Thu, 2017-08-31 at 23:36 -0700, Michael Chan wrote:
>> On Thu, Aug 31, 2017 at 11:10 PM, Frans van Berckel
>>  wrote:
>> >
>> >  a long list of likely the same type of error codes.
>> >
>>
>> Please post the entire register dump.
>
> [  237.169194] tg3 :01:00.0 enp1s0: Link is up at 1000 Mbps, full
> duplex
> [  237.169335] tg3 :01:00.0 enp1s0: Flow control is on for TX and
> on for RX
> [  237.169375] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes
> ready
> [  243.683910] tg3 :01:00.0 enp1s0: DMA Status error.  Resetting
> chip.
> [  243.759610] hrtimer: interrupt took 9464192 ns
> [  245.317566] tg3 :01:00.0 enp1s0: 0x: 0x165914e4,
> 0x00100406, 0x0221, 0x0010
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0010: 0xefcf0004,
> 0x, 0x, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0020: 0x,
> 0x, 0x, 0x01eb1028
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0030: 0x,
> 0x0048, 0x, 0x0105
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0040: 0x,
> 0x, 0xc0025001, 0x64002000
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0050: 0x00fc5803,
> 0x80818283, 0x0087d005, 0xfee0300c
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0060: 0x,
> 0x4122, 0x42010298, 0x7618
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0070: 0x10f2,
> 0x00a0, 0x, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0080: 0x165914e4,
> 0x3c1d0002, 0x04130034, 0x3c085082
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0090: 0x01009509,
> 0x, 0x, 0x00ce
> [  245.476295] tg3 :01:00.0 enp1s0: 0x00a0: 0x,
> 0x0006, 0x, 0x000c
> [  245.476295] tg3 :01:00.0 enp1s0: 0x00b0: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x00c0: 0x,
> 0x, 0x000e, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x00d0: 0x00010010,
> 0x0fa0, 0x00122104, 0x00036c11
> [  245.476295] tg3 :01:00.0 enp1s0: 0x00e0: 0x1011,
> 0x, 0x, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0100: 0x13c10001,
> 0x00014000, 0x0011c000, 0x000e3010
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0110: 0x,
> 0x11c1, 0x00a0, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0130: 0x,
> 0x, 0x, 0x16010002
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0150: 0x80ff,
> 0x, 0x, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0160: 0x16c10003,
> 0xfe3b2547, 0x001ec9ff, 0x00010004
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0170: 0x,
> 0x0007810e, 0x0001, 0x2c0c3c0e
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0180: 0x3f062304,
> 0x, 0x, 0x
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0200: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0210: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0220: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0230: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0240: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0250: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0260: 0x,
> 0x0001, 0x, 0x00ce
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0270: 0x,
> 0x0001, 0x, 0x0001
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0280: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0290: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02a0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02b0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02c0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02d0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02e0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x02f0: 0x,
> 0x0006, 0x, 0x0006
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0300: 0x,
> 0x000f, 0x, 0x000f
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0310: 0x,
> 0x000f, 0x, 0x000f
> [  245.476295] tg3 :01:00.0 enp1s0: 0x0320: 0x,
> 0x000f, 0x, 0x000f
> [  245.476295] tg3 :01:00.0

Re: [Problem] Broadcom BCM5762 Ethernet tg3 times out with stack trace

2017-06-06 Thread Siva Reddy Kallam 
On Fri, Jun 2, 2017 at 3:31 AM, Daniel Kim  wrote:
> On Fri, May 12, 2017 at 6:12 PM, Daniel Kim  wrote:
>> I believe I do have IOMMU enabled. At least the dmesg output seems to
>> imply that I do:
>> [1.141948] iommu: Adding device :00:02.0 to group 0
>> [1.142033] iommu: Adding device :00:10.0 to group 1
>> [1.142074] iommu: Adding device :00:10.1 to group 1
>> [1.142119] iommu: Adding device :00:11.0 to group 2
>> [1.142172] iommu: Adding device :00:12.0 to group 3
>> [1.142184] iommu: Adding device :00:12.2 to group 3
>> [1.142234] iommu: Adding device :00:13.0 to group 4
>> [1.142247] iommu: Adding device :00:13.2 to group 4
>> [1.142303] iommu: Adding device :00:14.0 to group 5
>> [1.142315] iommu: Adding device :00:14.2 to group 5
>> [1.142328] iommu: Adding device :00:14.3 to group 5
>> [1.142373] iommu: Adding device :00:14.4 to group 6
>> [1.142417] iommu: Adding device :00:14.5 to group 7
>> [1.142529] iommu: Adding device :00:15.0 to group 8
>> [1.142570] iommu: Adding device :00:15.2 to group 8
>> [1.142639] iommu: Adding device :00:18.0 to group 9
>> [1.142653] iommu: Adding device :00:18.1 to group 9
>> [1.142668] iommu: Adding device :00:18.2 to group 9
>> [1.142682] iommu: Adding device :00:18.3 to group 9
>> [1.142695] iommu: Adding device :00:18.4 to group 9
>> [1.142712] iommu: Adding device :00:18.5 to group 9
>> [1.142725] iommu: Adding device :01:00.0 to group 0
>> [1.142733] iommu: Adding device :01:00.1 to group 0
>> [1.142840] iommu: Adding device :04:00.0 to group 8
>> [1.143305] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40
>>
>> The last kernel I used where the NIC mostly worked was 4.4.0 (x86-64).
>> Even when it worked, it had this issue we've experienced since v3.13
>> where the NIC would suddenly become unresponsive. It won't be
>> considered disconnected from the network, but RX/TX packets, errors,
>> dropped, etc. values displayed with ifconfig would show a number that
>> looked suspiciously close to 32-bit INT_MAX.
>>
>> Since v4.8, I can trigger it much faster and it now prints out a call
>> stack and other messages into dmesg.
>
> I'd like to follow up on this since I haven't heard of any updates for
> awhile. Is there anything I can do on my end to help?
We are analyzing the Logs. Please wait for some more time.
If needed, we will send a debug patch to collect more information.

Re: [Problem] Broadcom BCM5762 Ethernet tg3 times out with stack trace

2017-05-12 Thread Siva Reddy Kallam 
On Fri, May 12, 2017 at 9:39 AM, Siva Reddy Kallam
<siva.kal...@broadcom.com> wrote:
> On Thu, May 11, 2017 at 8:55 PM, Daniel Kim <d...@playmechanix.com> wrote:
>> Summary:
>> Broadcom BCM5762 Ethernet tg3 times out with stack trace
>>
>> Description:
>> The ethernet device will disconnect with dmesg reporting a stack trace
>> and a time out (visible in DMesg Output below). The ethernet device
>> will periodically reconnect and disconnect and the driver will output
>> a lot of hex values into logs.
>>
>> The computer doesn't have to have network activity in order to trigger
>> this to happen, but I believe it can trigger faster if there was. It
>> usually occurs as soon as a few minutes after bootup to upwards of a
>> few hours in my test cases.
>>
>> Kernel version:
>> Linux version 4.11.0-041100-generic (kernel@tangerine) (gcc version
>> 6.3.0 20170415 (Ubuntu 6.3.0-14ubuntu3) ) #201705041534 SMP Thu May 4
>> 19:36:05 UTC 2017
>>
>> Full DMesg Output:
>> https://launchpadlibrarian.net/319135862/error_dmesg.txt
>> Bug has been reported with additional information at:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1689383
>>
>> Please let me know if there is other data or logs that you may need.
>>
> Thank you for reporting this. We will look into the logs and contact
> you directly if we need any other data.
As a first impression, we are suspecting TSO packet is causing TX timeout.
Can you please disable TSO and check if TX timeout still happens or not?
Please let us know your findings.
We are trying to reproduce locally. If we couldn't, we will send a
debug patch to collect more data.
>>
>> Cut DMesg Output:
>> [ 6244.283996] [ cut here ]
>> [ 6244.284051] WARNING: CPU: 0 PID: 0 at
>> /home/kernel/COD/linux/net/sched/sch_generic.c:316
>> dev_watchdog+0x22c/0x230
>> [ 6244.284058] NETDEV WATCHDOG: enp4s0 (tg3): transmit queue 0 timed out
>> [ 6244.284064] Modules linked in: snd_hda_codec_hdmi hp_wmi
>> snd_hda_codec_realtek snd_hda_codec_generic sparse_keymap
>> snd_hda_intel snd_hda_codec edac_mce_amd edac_core crct10dif_pclmul
>> crc32_pclmul snd_hda_core snd_hwdep ghash_clmulni_intel pcbc joydev
>> input_leds snd_pcm aesni_intel aes_x86_64 snd_seq_midi
>> snd_seq_midi_event snd_rawmidi crypto_simd snd_seq snd_seq_device
>> snd_timer glue_helper snd cryptd soundcore serio_raw k10temp shpchp
>> i2c_piix4 mac_hid tpm_infineon wmi parport_pc ppdev lp parport autofs4
>> hid_generic usbhid hid psmouse tg3 ptp pps_core ahci libahci video
>> [ 6244.284129] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 4.11.0-041100-generic #201705041534
>> [ 6244.284131] Hardware name: Hewlett-Packard HP EliteDesk 705 G1
>> MT/2215, BIOS L06 v02.17 12/11/2014
>> [ 6244.284132] Call Trace:
>> [ 6244.284135]  
>> [ 6244.284141]  dump_stack+0x63/0x81
>> [ 6244.284143]  __warn+0xcb/0xf0
>> [ 6244.284146]  warn_slowpath_fmt+0x5a/0x80
>> [ 6244.284149]  ? cpu_load_update+0xdd/0x150
>> [ 6244.284155]  dev_watchdog+0x22c/0x230
>> [ 6244.284159]  ? qdisc_rcu_free+0x50/0x50
>> [ 6244.284162]  call_timer_fn+0x35/0x140
>> [ 6244.284165]  run_timer_softirq+0x1db/0x440
>> [ 6244.284168]  ? ktime_get+0x41/0xb0
>> [ 6244.284172]  ? lapic_next_event+0x1d/0x30
>> [ 6244.284175]  ? clockevents_program_event+0x7f/0x120
>> [ 6244.284179]  __do_softirq+0x104/0x2af
>> [ 6244.284183]  irq_exit+0xb6/0xc0
>> [ 6244.284187]  smp_apic_timer_interrupt+0x3d/0x50
>> [ 6244.284190]  apic_timer_interrupt+0x89/0x90
>> [ 6244.284193] RIP: 0010:cpuidle_enter_state+0x122/0x2c0
>> [ 6244.284195] RSP: 0018:86203dc8 EFLAGS: 0246 ORIG_RAX:
>> ff10
>> [ 6244.284198] RAX:  RBX: 0002 RCX: 
>> 001f
>> [ 6244.284200] RDX: 05addc53de33 RSI: a01a2ec189d8 RDI: 
>> 
>> [ 6244.284202] RBP: 86203e08 R08: cd01 R09: 
>> 0018
>> [ 6244.284203] R10: 86203d98 R11: 0ef9 R12: 
>> a01a1d6ab200
>> [ 6244.284205] R13: 862f92d8 R14: 0002 R15: 
>> 862f92c0
>> [ 6244.284207]  
>> [ 6244.284211]  ? cpuidle_enter_state+0x110/0x2c0
>> [ 6244.284213]  cpuidle_enter+0x17/0x20
>> [ 6244.284218]  call_cpuidle+0x23/0x40
>> [ 6244.284221]  do_idle+0x189/0x200
>> [ 6244.284224]  cpu_startup_entry+0x71/0x80
>> [ 6244.284227]  rest_init+0x77/0x80
>> [ 6244.284230]  start_kernel+0x455/0x476
>> [ 6244.284235]  ? early_idt_handler_array+0x120/0x120
>> [ 6244.284239]  x86_64_

Re: [Problem] Broadcom BCM5762 Ethernet tg3 times out with stack trace

2017-05-11 Thread Siva Reddy Kallam 
On Thu, May 11, 2017 at 8:55 PM, Daniel Kim  wrote:
> Summary:
> Broadcom BCM5762 Ethernet tg3 times out with stack trace
>
> Description:
> The ethernet device will disconnect with dmesg reporting a stack trace
> and a time out (visible in DMesg Output below). The ethernet device
> will periodically reconnect and disconnect and the driver will output
> a lot of hex values into logs.
>
> The computer doesn't have to have network activity in order to trigger
> this to happen, but I believe it can trigger faster if there was. It
> usually occurs as soon as a few minutes after bootup to upwards of a
> few hours in my test cases.
>
> Kernel version:
> Linux version 4.11.0-041100-generic (kernel@tangerine) (gcc version
> 6.3.0 20170415 (Ubuntu 6.3.0-14ubuntu3) ) #201705041534 SMP Thu May 4
> 19:36:05 UTC 2017
>
> Full DMesg Output:
> https://launchpadlibrarian.net/319135862/error_dmesg.txt
> Bug has been reported with additional information at:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1689383
>
> Please let me know if there is other data or logs that you may need.
>
Thank you for reporting this. We will look into the logs and contact
you directly if we need any other data.
>
> Cut DMesg Output:
> [ 6244.283996] [ cut here ]
> [ 6244.284051] WARNING: CPU: 0 PID: 0 at
> /home/kernel/COD/linux/net/sched/sch_generic.c:316
> dev_watchdog+0x22c/0x230
> [ 6244.284058] NETDEV WATCHDOG: enp4s0 (tg3): transmit queue 0 timed out
> [ 6244.284064] Modules linked in: snd_hda_codec_hdmi hp_wmi
> snd_hda_codec_realtek snd_hda_codec_generic sparse_keymap
> snd_hda_intel snd_hda_codec edac_mce_amd edac_core crct10dif_pclmul
> crc32_pclmul snd_hda_core snd_hwdep ghash_clmulni_intel pcbc joydev
> input_leds snd_pcm aesni_intel aes_x86_64 snd_seq_midi
> snd_seq_midi_event snd_rawmidi crypto_simd snd_seq snd_seq_device
> snd_timer glue_helper snd cryptd soundcore serio_raw k10temp shpchp
> i2c_piix4 mac_hid tpm_infineon wmi parport_pc ppdev lp parport autofs4
> hid_generic usbhid hid psmouse tg3 ptp pps_core ahci libahci video
> [ 6244.284129] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.11.0-041100-generic #201705041534
> [ 6244.284131] Hardware name: Hewlett-Packard HP EliteDesk 705 G1
> MT/2215, BIOS L06 v02.17 12/11/2014
> [ 6244.284132] Call Trace:
> [ 6244.284135]  
> [ 6244.284141]  dump_stack+0x63/0x81
> [ 6244.284143]  __warn+0xcb/0xf0
> [ 6244.284146]  warn_slowpath_fmt+0x5a/0x80
> [ 6244.284149]  ? cpu_load_update+0xdd/0x150
> [ 6244.284155]  dev_watchdog+0x22c/0x230
> [ 6244.284159]  ? qdisc_rcu_free+0x50/0x50
> [ 6244.284162]  call_timer_fn+0x35/0x140
> [ 6244.284165]  run_timer_softirq+0x1db/0x440
> [ 6244.284168]  ? ktime_get+0x41/0xb0
> [ 6244.284172]  ? lapic_next_event+0x1d/0x30
> [ 6244.284175]  ? clockevents_program_event+0x7f/0x120
> [ 6244.284179]  __do_softirq+0x104/0x2af
> [ 6244.284183]  irq_exit+0xb6/0xc0
> [ 6244.284187]  smp_apic_timer_interrupt+0x3d/0x50
> [ 6244.284190]  apic_timer_interrupt+0x89/0x90
> [ 6244.284193] RIP: 0010:cpuidle_enter_state+0x122/0x2c0
> [ 6244.284195] RSP: 0018:86203dc8 EFLAGS: 0246 ORIG_RAX:
> ff10
> [ 6244.284198] RAX:  RBX: 0002 RCX: 
> 001f
> [ 6244.284200] RDX: 05addc53de33 RSI: a01a2ec189d8 RDI: 
> 
> [ 6244.284202] RBP: 86203e08 R08: cd01 R09: 
> 0018
> [ 6244.284203] R10: 86203d98 R11: 0ef9 R12: 
> a01a1d6ab200
> [ 6244.284205] R13: 862f92d8 R14: 0002 R15: 
> 862f92c0
> [ 6244.284207]  
> [ 6244.284211]  ? cpuidle_enter_state+0x110/0x2c0
> [ 6244.284213]  cpuidle_enter+0x17/0x20
> [ 6244.284218]  call_cpuidle+0x23/0x40
> [ 6244.284221]  do_idle+0x189/0x200
> [ 6244.284224]  cpu_startup_entry+0x71/0x80
> [ 6244.284227]  rest_init+0x77/0x80
> [ 6244.284230]  start_kernel+0x455/0x476
> [ 6244.284235]  ? early_idt_handler_array+0x120/0x120
> [ 6244.284239]  x86_64_start_reservations+0x24/0x26
> [ 6244.284243]  x86_64_start_kernel+0x14d/0x170
> [ 6244.284246]  start_cpu+0x14/0x14
> [ 6244.284251] ---[ end trace b14ec0a8b1e2a4e8 ]---
> [ 6244.284259] tg3 :04:00.0 enp4s0: transmit timed out, resetting
> [ 6244.398892] hrtimer: interrupt took 65509334 ns
> [ 6247.090588] tg3 :04:00.0 enp4s0: 0x: 0x168714e4,
> 0x00100506, 0x0210, 0x0010
> [ 6247.090601] tg3 :04:00.0 enp4s0: 0x0010: 0xe212000c,
> 0x, 0xe211000c, 0x
> [ 6247.090607] tg3 :04:00.0 enp4s0: 0x0020: 0xe21c,
> 0x, 0x, 0x2215103c
> [ 6247.090610] tg3 :04:00.0 enp4s0: 0x0030: 0x,
> 0x0048, 0x, 0x010a
> [ 6247.090613] tg3 :04:00.0 enp4s0: 0x0040: 0x,
> 0x3900, 0xc8035001, 0x16002008
> [ 6247.090617] tg3 :04:00.0 enp4s0: 0x0050: 0x5803,
> 0x, 0x0086a005, 0x
> [ 6247.090622] tg3 :04:00.0 enp4s0: 0x0060: 0x,
> 0x,

Re: [PATCH net-next] tg3: Add the ability to conditionally build w/ HWMON

2017-03-07 Thread Siva Reddy Kallam 
On Tue, Mar 7, 2017 at 2:26 AM, Florian Fainelli <f.faine...@gmail.com> wrote:
> Introduce a Kconfig option: CONFIG_TIGON3_HWMON which allows to build
> in/out support for thermal sensors reported by Tigon3 NICs.
>
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
Acked-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
> ---
>  drivers/net/ethernet/broadcom/Kconfig | 8 +++-
>  drivers/net/ethernet/broadcom/tg3.c   | 7 +++
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/Kconfig 
> b/drivers/net/ethernet/broadcom/Kconfig
> index 940fb24bba21..96413808c726 100644
> --- a/drivers/net/ethernet/broadcom/Kconfig
> +++ b/drivers/net/ethernet/broadcom/Kconfig
> @@ -109,7 +109,6 @@ config TIGON3
> tristate "Broadcom Tigon3 support"
> depends on PCI
> select PHYLIB
> -   select HWMON
> imply PTP_1588_CLOCK
> ---help---
>   This driver supports Broadcom Tigon3 based gigabit Ethernet cards.
> @@ -117,6 +116,13 @@ config TIGON3
>   To compile this driver as a module, choose M here: the module
>   will be called tg3.  This is recommended.
>
> +config TIGON3_HWMON
> +   bool "Broadcom Tigon3 HWMON support"
> +   default y
> +   depends on TIGON3 && HWMON && !(TIGON3=y && HWMON=m)
> +   ---help---
> + Say Y if you want to expose the thermal sensor on Tigon3 devices.
> +
>  config BNX2X
> tristate "Broadcom NetXtremeII 10Gb support"
> depends on PCI
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 30d1eb9ebec9..f395b951f5e7 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -825,6 +825,7 @@ static int tg3_ape_event_lock(struct tg3 *tp, u32 
> timeout_us)
> return timeout_us ? 0 : -EBUSY;
>  }
>
> +#ifdef CONFIG_TIGON3_HWMON
>  static int tg3_ape_wait_for_event(struct tg3 *tp, u32 timeout_us)
>  {
> u32 i, apedata;
> @@ -904,6 +905,7 @@ static int tg3_ape_scratchpad_read(struct tg3 *tp, u32 
> *data, u32 base_off,
>
> return 0;
>  }
> +#endif
>
>  static int tg3_ape_send_event(struct tg3 *tp, u32 event)
>  {
> @@ -10744,6 +10746,7 @@ static int tg3_init_hw(struct tg3 *tp, bool reset_phy)
> return tg3_reset_hw(tp, reset_phy);
>  }
>
> +#ifdef CONFIG_TIGON3_HWMON
>  static void tg3_sd_scan_scratchpad(struct tg3 *tp, struct tg3_ocir *ocir)
>  {
> int i;
> @@ -10826,6 +10829,10 @@ static void tg3_hwmon_open(struct tg3 *tp)
> dev_err(>dev, "Cannot register hwmon device, 
> aborting\n");
> }
>  }
> +#else
> +static inline void tg3_hwmon_close(struct tg3 *tp) { }
> +static inline void tg3_hwmon_open(struct tg3 *tp) { }
> +#endif /* CONFIG_TIGON3_HWMON */
>
>
>  #define TG3_STAT_ADD32(PSTAT, REG) \
> --
> 2.9.3
>

Re: 4.9.0-rc8: tg3 dead after resume

2017-01-24 Thread Siva Reddy Kallam 
On Mon, Jan 16, 2017 at 8:29 PM, Billy Shuman <wshum...@gmail.com> wrote:
> On Mon, Jan 16, 2017 at 2:15 AM, Siva Reddy Kallam
> <siva.kal...@broadcom.com> wrote:
>> Hi,
>>
>> Sorry for the late reply.
>> We don't have exact model.
>> We tried to reproduce with HP elitebook folio laptop & HP elite thunderbolt
>> 3 dock.
>> We observed issue with Thunder bolt bridge. All the connected devices on the
>> TH3 dock don't function at all.
>> Are you observing same issue? Did you get a chance to check with HP on this?
>
> No the only device that does not function is the nic and only after resume, it
> functions prior to that.  I have a usb keyboard and three monitors
> attached to the
> dock that function properly before and after resume.  Did you turn off
> authentication for thunderbolt in bios?
Do you mean Thunderbolt Security Level to “PCIe and DisplayPort - No Security”?
If Yes, We already set the same and using it.
As we are unable to reproduce, Can you please check with HP once on this?
>
>> As per our discussion with HP, Thunder bolt bridge driver is provided for
>> windows OS only.
>>
>> Regards,
>> Siva
>> ----Original Message-
>> From: Billy Shuman [mailto:wshum...@gmail.com]
>> Sent: Wednesday, December 28, 2016 7:33 PM
>> To: Siva Reddy Kallam <siva.kal...@broadcom.com>
>> Subject: Re: 4.9.0-rc8: tg3 dead after resume
>>
>> On Mon, Dec 26, 2016 at 1:27 AM, Siva Reddy Kallam
>> <siva.kal...@broadcom.com> wrote:
>>> On Mon, Dec 12, 2016 at 3:53 PM, Siva Reddy Kallam
>>> <siva.kal...@broadcom.com> wrote:
>>>> On Fri, Dec 9, 2016 at 7:59 PM, Billy Shuman <wshum...@gmail.com> wrote:
>>>>> On Thu, Dec 8, 2016 at 4:03 AM, Siva Reddy Kallam
>>>>> <siva.kal...@broadcom.com> wrote:
>>>>>> On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman <wshum...@gmail.com>
>>>>>> wrote:
>>>>>>> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan
>>>>>>> <michael.c...@broadcom.com> wrote:
>>>>>>>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman <wshum...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>>>>>>>
>>>>>>>>> In logs I see:
>>>>>>>>> kernel: tg3 :44:00.0: phy probe failed, err -19
>>>>>>>>> kernel: tg3 :44:00.0: Problem fetching invariants of chip,
>>>>>>>>> aborting
>>>>>>>>
>>>>>>>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>>>>>>>
>>>>>>>> If it's a true suspend/resume operation, the driver does not have
>>>>>>>> to go through probe during resume.  Please explain how you do
>>>>>>>> suspend/resume.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry my previous message was accidentally sent to early.
>>>>>>>
>>>>>>> I used systemd (systemctl suspend) to suspend.
>>>>>>>
>>>>>> We need more information to proceed further.
>>>>>> Without suspend, Are you able to use the tg3 port?
>>>>>
>>>>> Yes the port works fine without suspend.
>>>> OK
>>>>>
>>>>>> Which Broadcom card are you having in laptop?
>>>>>
>>>>> The nic is a NetXtreme BCM57762 Gigabit Ethernet PCIe in a thunderbolt3
>>>>> dock.
>>>>>
>>>> OK
>>>>>> Please provide complete tg3 specific logs in dmesg.
>>>>>>
>>>>>
>>>>> [   32.084010] tg3.c:v3.137 (May 11, 2014)
>>>>> [   32.124695] tg3 :44:00.0 eth0: Tigon3 [partno(BCM957762) rev
>>>>> 57766001] (PCI Express) MAC address 98:e7:f4:8b:13:19
>>>>> [   32.124698] tg3 :44:00.0 eth0: attached PHY is 57765
>>>>> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
>>>>> [   32.124699] tg3 :44:00.0 eth0: RXcsums[1] LinkChgREG[0]
>>>>> MIirq[0] ASF[0] TSOcap[1]
>>>>> [   32.124700] tg3 :44:00.0 eth0: dma_rwctrl[0001]
>>>>> dma_mask[64-bit]
>>>>> [   32.219764] tg3 :44:00.0 enp68s0: renamed from eth0
>>>>> [   36.219245] tg3 :44:00.0 enp68s0: Link is up at 1000 Mbps, full
>>>>> duplex
>>>>> [   36.219250] tg3 00

Re: 4.9.0-rc8: tg3 dead after resume

2016-12-25 Thread Siva Reddy Kallam 
On Mon, Dec 12, 2016 at 3:53 PM, Siva Reddy Kallam
<siva.kal...@broadcom.com> wrote:
> On Fri, Dec 9, 2016 at 7:59 PM, Billy Shuman <wshum...@gmail.com> wrote:
>> On Thu, Dec 8, 2016 at 4:03 AM, Siva Reddy Kallam
>> <siva.kal...@broadcom.com> wrote:
>>> On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman <wshum...@gmail.com> wrote:
>>>> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan <michael.c...@broadcom.com> 
>>>> wrote:
>>>>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman <wshum...@gmail.com> wrote:
>>>>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>>>>
>>>>>> In logs I see:
>>>>>> kernel: tg3 :44:00.0: phy probe failed, err -19
>>>>>> kernel: tg3 :44:00.0: Problem fetching invariants of chip, aborting
>>>>>
>>>>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>>>>
>>>>> If it's a true suspend/resume operation, the driver does not have to
>>>>> go through probe during resume.  Please explain how you do
>>>>> suspend/resume.
>>>>>
>>>>
>>>> Sorry my previous message was accidentally sent to early.
>>>>
>>>> I used systemd (systemctl suspend) to suspend.
>>>>
>>> We need more information to proceed further.
>>> Without suspend, Are you able to use the tg3 port?
>>
>> Yes the port works fine without suspend.
> OK
>>
>>> Which Broadcom card are you having in laptop?
>>
>> The nic is a NetXtreme BCM57762 Gigabit Ethernet PCIe in a thunderbolt3 dock.
>>
> OK
>>> Please provide complete tg3 specific logs in dmesg.
>>>
>>
>> [   32.084010] tg3.c:v3.137 (May 11, 2014)
>> [   32.124695] tg3 :44:00.0 eth0: Tigon3 [partno(BCM957762) rev
>> 57766001] (PCI Express) MAC address 98:e7:f4:8b:13:19
>> [   32.124698] tg3 :44:00.0 eth0: attached PHY is 57765
>> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
>> [   32.124699] tg3 :44:00.0 eth0: RXcsums[1] LinkChgREG[0]
>> MIirq[0] ASF[0] TSOcap[1]
>> [   32.124700] tg3 :44:00.0 eth0: dma_rwctrl[0001] dma_mask[64-bit]
>> [   32.219764] tg3 :44:00.0 enp68s0: renamed from eth0
>> [   36.219245] tg3 :44:00.0 enp68s0: Link is up at 1000 Mbps, full duplex
>> [   36.219250] tg3 :44:00.0 enp68s0: Flow control is on for TX and on 
>> for RX
>> [   36.219251] tg3 :44:00.0 enp68s0: EEE is disabled
>>
>> after resume
>> [   92.292838] tg3 :44:00.0 enp68s0: No firmware running
>> [   93.521744] tg3 :44:00.0: tg3_abort_hw timed out,
>> TX_MODE_ENABLE will not clear MAC_TX_MODE=
>> [  106.704655] tg3 :44:00.0 enp68s0: Link is down
>> [  108.370356] tg3 :44:00.0: tg3_abort_hw timed out,
>> TX_MODE_ENABLE will not clear MAC_TX_MODE=
>>
>> after rmmod, modprobe
>> [  570.933636] tg3 :44:00.0: tg3_abort_hw timed out,
>> TX_MODE_ENABLE will not clear MAC_TX_MODE=
>> [  604.847215] tg3.c:v3.137 (May 11, 2014)
>> [  605.010075] tg3 :44:00.0: phy probe failed, err -19
>> [  605.010077] tg3 :44:00.0: Problem fetching invariants of chip, 
>> aborting
>>
>>
>>
>>
> We will try to reproduce and update you on this.
We are unable to reproduce this issue with Ubuntu 16.10 (K4.8.0-22) kernel.
We are in the process of verifying with 4.9.0-rc8  kernel and let you
know the feedback.
Can you please let us know the make/model of your laptop and procedure
followed to enable tg3 driver?
>>>>> Did this work before?  There has been very few changes to tg3 recently.
>>>>>
>>>>
>>>> This is a new laptop for me, but the same behavior is seen on 4.4.36 and 
>>>> 4.8.12.
>>>>
>>>>>>
>>>>>> rmmod and modprobe does not fix the problem only a reboot resolves the 
>>>>>> issue.
>>>>>>
>>>>>> Billy

Re: 4.9.0-rc8: tg3 dead after resume

2016-12-12 Thread Siva Reddy Kallam 
On Fri, Dec 9, 2016 at 7:59 PM, Billy Shuman <wshum...@gmail.com> wrote:
> On Thu, Dec 8, 2016 at 4:03 AM, Siva Reddy Kallam
> <siva.kal...@broadcom.com> wrote:
>> On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman <wshum...@gmail.com> wrote:
>>> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan <michael.c...@broadcom.com> 
>>> wrote:
>>>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman <wshum...@gmail.com> wrote:
>>>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>>>
>>>>> In logs I see:
>>>>> kernel: tg3 :44:00.0: phy probe failed, err -19
>>>>> kernel: tg3 :44:00.0: Problem fetching invariants of chip, aborting
>>>>
>>>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>>>
>>>> If it's a true suspend/resume operation, the driver does not have to
>>>> go through probe during resume.  Please explain how you do
>>>> suspend/resume.
>>>>
>>>
>>> Sorry my previous message was accidentally sent to early.
>>>
>>> I used systemd (systemctl suspend) to suspend.
>>>
>> We need more information to proceed further.
>> Without suspend, Are you able to use the tg3 port?
>
> Yes the port works fine without suspend.
OK
>
>> Which Broadcom card are you having in laptop?
>
> The nic is a NetXtreme BCM57762 Gigabit Ethernet PCIe in a thunderbolt3 dock.
>
OK
>> Please provide complete tg3 specific logs in dmesg.
>>
>
> [   32.084010] tg3.c:v3.137 (May 11, 2014)
> [   32.124695] tg3 :44:00.0 eth0: Tigon3 [partno(BCM957762) rev
> 57766001] (PCI Express) MAC address 98:e7:f4:8b:13:19
> [   32.124698] tg3 :44:00.0 eth0: attached PHY is 57765
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [   32.124699] tg3 :44:00.0 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[0] TSOcap[1]
> [   32.124700] tg3 :44:00.0 eth0: dma_rwctrl[0001] dma_mask[64-bit]
> [   32.219764] tg3 :44:00.0 enp68s0: renamed from eth0
> [   36.219245] tg3 :44:00.0 enp68s0: Link is up at 1000 Mbps, full duplex
> [   36.219250] tg3 :44:00.0 enp68s0: Flow control is on for TX and on for 
> RX
> [   36.219251] tg3 :44:00.0 enp68s0: EEE is disabled
>
> after resume
> [   92.292838] tg3 :44:00.0 enp68s0: No firmware running
> [   93.521744] tg3 :44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=
> [  106.704655] tg3 :44:00.0 enp68s0: Link is down
> [  108.370356] tg3 :44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=
>
> after rmmod, modprobe
> [  570.933636] tg3 :44:00.0: tg3_abort_hw timed out,
> TX_MODE_ENABLE will not clear MAC_TX_MODE=
> [  604.847215] tg3.c:v3.137 (May 11, 2014)
> [  605.010075] tg3 :44:00.0: phy probe failed, err -19
> [  605.010077] tg3 :44:00.0: Problem fetching invariants of chip, aborting
>
>
>
>
We will try to reproduce and update you on this.
>>>> Did this work before?  There has been very few changes to tg3 recently.
>>>>
>>>
>>> This is a new laptop for me, but the same behavior is seen on 4.4.36 and 
>>> 4.8.12.
>>>
>>>>>
>>>>> rmmod and modprobe does not fix the problem only a reboot resolves the 
>>>>> issue.
>>>>>
>>>>> Billy

Re: 4.9.0-rc8: tg3 dead after resume

2016-12-08 Thread Siva Reddy Kallam 
On Thu, Dec 8, 2016 at 12:14 AM, Billy Shuman  wrote:
> On Wed, Dec 7, 2016 at 12:37 PM, Michael Chan  
> wrote:
>> On Wed, Dec 7, 2016 at 7:20 AM, Billy Shuman  wrote:
>>> After resume on 4.9.0-rc8 tg3 is dead.
>>>
>>> In logs I see:
>>> kernel: tg3 :44:00.0: phy probe failed, err -19
>>> kernel: tg3 :44:00.0: Problem fetching invariants of chip, aborting
>>
>> -19 is -ENODEV which means tg3 cannot read the PHY ID.
>>
>> If it's a true suspend/resume operation, the driver does not have to
>> go through probe during resume.  Please explain how you do
>> suspend/resume.
>>
>
> Sorry my previous message was accidentally sent to early.
>
> I used systemd (systemctl suspend) to suspend.
>
We need more information to proceed further.
Without suspend, Are you able to use the tg3 port?
Which Broadcom card are you having in laptop?
Please provide complete tg3 specific logs in dmesg.

>> Did this work before?  There has been very few changes to tg3 recently.
>>
>
> This is a new laptop for me, but the same behavior is seen on 4.4.36 and 
> 4.8.12.
>
>>>
>>> rmmod and modprobe does not fix the problem only a reboot resolves the 
>>> issue.
>>>
>>> Billy

Re: tg3 BUG: spinlock lockup suspected

2016-10-18 Thread Siva Reddy Kallam 
On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos  wrote:
>> > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>> > test further.
>>
>> It gets stranger and stranger - my old 4.7 image worked fine, freshly
>> compiled 4.7 exhibits the same problem.
>>
>> Toolchain has not changed, that I know for sure.
>>
>> What may have changed is kernel .config. My old conf was with whatever I
>> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
>> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
>> then to 4.7 with this config, answering quiestion about new options when
>> any appeared. Diff is not available since I do not have the old configs
>> archived.
>
> I did some more digging. Found an older configuration that is working
> and recreated a newer one that is bad, for the same 4.7 kernel. This is
> reproducible now, from "make clean" state.
>
> Working config from 4.7-rc4 attached as config-4.7, broken config from
> 4.7 attached as config-4.7-bad.
>
> Will try to bisect the configs as time permits. But looking at the
> stack traces, the issue is probably timing related, when ip and dhclient
> do something with the same lock. seq_read that outputs stats could be
> reading /proc/net/dev that reads counters from each interface.
>
> ifupdown seems to use the following for dhcp interfaces:
>   up
> [[/bin/ip link set dev %iface% address %hwaddress%]]
> /sbin/dhclient -v -pf /run/dhclient.%iface%.pid -lf 
> /var/lib/dhcp/dhclient.%iface%.leases -I -df 
> /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
> ...
>
> so ip link is setting link up, this creates some work for the
> background, and the dhclient goes adn reads /proc/net/dev, and lockup is
> suspected but not proven?
>
> I started a loop for test, doing cat /proc/net/dev in a loop and at the
> same link link up and down from console, but up and down is slow process
> and the loop did not seem to trigger the warning over night, so it was
> not so simple.
>
I am busy with other priority tasks. One of my colleague Deepak will
work this with you.
I added him to CC list.
Thanks.
>
>> > > [   83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014
>> > > [   83.797819]  lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: 
>> > > ip/1001, .owner_cpu: 1
>> > > [   83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4
>> > > [   83.982129] Call Trace:
>> > > [   84.014160]  [004b7220] spin_dump+0x60/0xa0
>> > > [   84.078203]  [004b73a0] do_raw_spin_lock+0xa0/0x120
>> > > [   84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> > > [   84.107193] ip (1001) used greatest stack depth: 2168 bytes left
>> > > [   84.306955]  [0092c0d0] _raw_spin_lock_bh+0x30/0x40
>> > > [   84.380188]  [100822cc] tg3_get_stats64+0xc/0x80 [tg3]
>> > > [   84.456885]  [007fac8c] dev_get_stats+0x2c/0xc0
>> > > [   84.525506]  [0081a4e8] dev_seq_printf_stats+0x8/0xe0
>> > > [   84.600986]  [0081a5e4] dev_seq_show+0x24/0x40
>> > > [   84.668467]  [005cb6c4] seq_read+0x2c4/0x440
>> > > [   84.733656]  [0060b97c] proc_reg_read+0x3c/0x80
>> > > [   84.802282]  [005a219c] __vfs_read+0x1c/0x140
>> > > [   84.868613]  [005a2310] vfs_read+0x50/0x100
>> > > [   84.932662]  [005a265c] SyS_read+0x3c/0xa0
>> > > [   84.995573]  [004061d4] linux_sparc_syscall32+0x34/0x60
>> > > [   85.073748] * CPU[  0]: TSTATE[0044f0001a22] 
>> > > TPC[f79a16b0] TNPC[f79a16b4] TASK[dhclient:1014]
>> > > [   85.208732]  TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0]
>> > > [   85.287633]   CPU[  1]: TSTATE[004480001605] 
>> > > TPC[004b26f0] TNPC[004d0b0c] TASK[swapper/1:0]
>> > > [   85.420338]  TPC[trace_hardirqs_off+0x10/0x20] 
>> > > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] 
>> > > RPC[rest_init+0x178/0x1a0]
>> > > [   85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex
>> > > [   85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off 
>> > > for RX
>> > > [   85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> --
> Meelis Roos (mr...@linux.ee)

Re: tg3 BUG: spinlock lockup suspected

2016-10-13 Thread Siva Reddy Kallam 
On Mon, Oct 10, 2016 at 5:21 PM, Siva Reddy Kallam
<siva.kal...@broadcom.com> wrote:
> On Sun, Oct 9, 2016 at 12:35 AM, Meelis Roos <mr...@linux.ee> wrote:
>>> > That did not go well - bisect found the following commit but that does
>>> > not seem to be related at all. So probably the reproducibility is not
>>> > 100% but more random.
>>>
>>> Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>>> test further.
>>
>> It gets stranger and stranger - my old 4.7 image worked fine, freshly
>> compiled 4.7 exhibits the same problem.
>>
>> Toolchain has not changed, that I know for sure.
>>
>> What may have changed is kernel .config. My old conf was with whatever I
>> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
>> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
>> then to 4.7 with this config, answering quiestion about new options when
>> any appeared. Diff is not available since I do not have the old configs
>> archived.
>>
>> Any ideas where to continue from here?
> Probably, You can do fresh system installation if possible.
> Any way, I will try to reproduce with 4.7 and 4.8 kernel versions.
> Will let you know my response in 1-2 days.
We are unable to reproduce with Intel system. we tried with both 4.7
and 4.8 kernel versions.
We are trying to get one SPARC system. We will let you know once we
are done with reproducing with SPARC system.
>>
>>>
>>> >
>>> >
>>> > 4c5773f9f5462dcb372857813918bbfe8c0cdcdd is the first bad commit
>>> > commit 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>>> > Author: Krzysztof Kozlowski <k...@kernel.org>
>>> > Date:   Sat May 28 11:54:12 2016 +0200
>>> >
>>> > dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>>> >
>>> > Add license and copyrights (file introduced in 2014) to header with
>>> > Exynos5410 clock IDs. Additionally reformat it to improve readability.
>>> >
>>> > Signed-off-by: Krzysztof Kozlowski <k...@kernel.org>
>>> > Acked-by: Stephen Boyd <sb...@codeaurora.org>
>>> > Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>> > Signed-off-by: Sylwester Nawrocki <s.nawro...@samsung.com>
>>> >
>>> > :04 04 acbd432e11366a8eb8775942bc7b8caa476226e2 
>>> > 08e3a3f98c3d4fa2a93123c3f21b2847c06b4665 M  include
>>> >
>>> >
>>> > The whiole bisect log seems to dig around in unrelated places so at best
>>> > it just narrows the window by adding some known-bad data points.
>>> >
>>> > git bisect start
>>> > # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
>>> > git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
>>> > # bad: [ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea] Merge tag 
>>> > 'arc-4.8-rc4-fixes' of 
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
>>> > git bisect bad ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea
>>> > # good: [e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b] affs ->d_compare(): 
>>> > don't bother with ->d_inode
>>> > git bisect good e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b
>>> > # bad: [77a87824ed676ca8ff8482e4157d3adb284fd381] 
>>> > clocksource/drivers/clps_711x: fixup for "ARM: clps711x:
>>> > git bisect bad 77a87824ed676ca8ff8482e4157d3adb284fd381
>>> > # bad: [27acbec338113a75b9d72aeb53149a3538031dda] Merge 
>>> > git://www.linux-watchdog.org/linux-watchdog
>>> > git bisect bad 27acbec338113a75b9d72aeb53149a3538031dda
>>> > # bad: [7f155c702677d057d03b192ce652311de5434697] Merge tag 
>>> > 'nfs-for-4.8-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
>>> > git bisect bad 7f155c702677d057d03b192ce652311de5434697
>>> > # good: [797cee982eef9195736afc5e7f3b8f613c41d19a] Merge branch 
>>> > 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit
>>> > git bisect good 797cee982eef9195736afc5e7f3b8f613c41d19a
>>> > # bad: [1056c9bd2702ea1bb79abf9bd1e78c578589d247] Merge tag 
>>> > 'clk-for-linus-4.8' of 
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>>> > git bisect bad 1056c9bd2702ea1bb79abf9bd1e78c578589d247
>>> > # bad: [1ff435d3571199a799ba6ccfe05544dcd21b9fb3] Merge branch 
>>> > 'clk-st-critica

Re: tg3 BUG: spinlock lockup suspected

2016-10-10 Thread Siva Reddy Kallam 
On Sun, Oct 9, 2016 at 12:35 AM, Meelis Roos  wrote:
>> > That did not go well - bisect found the following commit but that does
>> > not seem to be related at all. So probably the reproducibility is not
>> > 100% but more random.
>>
>> Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>> test further.
>
> It gets stranger and stranger - my old 4.7 image worked fine, freshly
> compiled 4.7 exhibits the same problem.
>
> Toolchain has not changed, that I know for sure.
>
> What may have changed is kernel .config. My old conf was with whatever I
> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
> then to 4.7 with this config, answering quiestion about new options when
> any appeared. Diff is not available since I do not have the old configs
> archived.
>
> Any ideas where to continue from here?
Probably, You can do fresh system installation if possible.
Any way, I will try to reproduce with 4.7 and 4.8 kernel versions.
Will let you know my response in 1-2 days.
>
>>
>> >
>> >
>> > 4c5773f9f5462dcb372857813918bbfe8c0cdcdd is the first bad commit
>> > commit 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> > Author: Krzysztof Kozlowski 
>> > Date:   Sat May 28 11:54:12 2016 +0200
>> >
>> > dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>> >
>> > Add license and copyrights (file introduced in 2014) to header with
>> > Exynos5410 clock IDs. Additionally reformat it to improve readability.
>> >
>> > Signed-off-by: Krzysztof Kozlowski 
>> > Acked-by: Stephen Boyd 
>> > Reviewed-by: Javier Martinez Canillas 
>> > Signed-off-by: Sylwester Nawrocki 
>> >
>> > :04 04 acbd432e11366a8eb8775942bc7b8caa476226e2 
>> > 08e3a3f98c3d4fa2a93123c3f21b2847c06b4665 M  include
>> >
>> >
>> > The whiole bisect log seems to dig around in unrelated places so at best
>> > it just narrows the window by adding some known-bad data points.
>> >
>> > git bisect start
>> > # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
>> > git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
>> > # bad: [ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea] Merge tag 
>> > 'arc-4.8-rc4-fixes' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
>> > git bisect bad ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea
>> > # good: [e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b] affs ->d_compare(): 
>> > don't bother with ->d_inode
>> > git bisect good e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b
>> > # bad: [77a87824ed676ca8ff8482e4157d3adb284fd381] 
>> > clocksource/drivers/clps_711x: fixup for "ARM: clps711x:
>> > git bisect bad 77a87824ed676ca8ff8482e4157d3adb284fd381
>> > # bad: [27acbec338113a75b9d72aeb53149a3538031dda] Merge 
>> > git://www.linux-watchdog.org/linux-watchdog
>> > git bisect bad 27acbec338113a75b9d72aeb53149a3538031dda
>> > # bad: [7f155c702677d057d03b192ce652311de5434697] Merge tag 
>> > 'nfs-for-4.8-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
>> > git bisect bad 7f155c702677d057d03b192ce652311de5434697
>> > # good: [797cee982eef9195736afc5e7f3b8f613c41d19a] Merge branch 
>> > 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit
>> > git bisect good 797cee982eef9195736afc5e7f3b8f613c41d19a
>> > # bad: [1056c9bd2702ea1bb79abf9bd1e78c578589d247] Merge tag 
>> > 'clk-for-linus-4.8' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> > git bisect bad 1056c9bd2702ea1bb79abf9bd1e78c578589d247
>> > # bad: [1ff435d3571199a799ba6ccfe05544dcd21b9fb3] Merge branch 
>> > 'clk-st-critical' into clk-next
>> > git bisect bad 1ff435d3571199a799ba6ccfe05544dcd21b9fb3
>> > # bad: [0e4504470667d355b53ca3c9802fdd2120c9f946] clk: samsung: 
>> > exynos5433: Add CLK_IGNORE_UNUSED flag to PCIE device
>> > git bisect bad 0e4504470667d355b53ca3c9802fdd2120c9f946
>> > # bad: [880c81b3b6604a004d56b5975c8bed47276e8bf6] clk: samsung: 
>> > exynos5440: Constify all clock initializers
>> > git bisect bad 880c81b3b6604a004d56b5975c8bed47276e8bf6
>> > # bad: [b3a96eed8e84780d300b79b58047ea277ba358b7] clk: samsung: 
>> > exynos3250: Move platform driver and of_device_id to init section
>> > git bisect bad b3a96eed8e84780d300b79b58047ea277ba358b7
>> > # bad: [4528dd8ed477bf202bd33ee48d38d656672d37f8] dt-bindings: clock: Add 
>> > watchdog and SSS clock IDs to Exynos5410
>> > git bisect bad 4528dd8ed477bf202bd33ee48d38d656672d37f8
>> > # bad: [5cd3535a27a7cf8fc4070b499d66e419e7e72b61] dt-bindings: clock: Add 
>> > PWM and USB clock IDs to Exynos5410
>> > git bisect bad 5cd3535a27a7cf8fc4070b499d66e419e7e72b61
>> > # bad: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: clock: Add 
>> > license and reformat Exynos5410 clock IDs
>> > git bisect bad 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> > # first bad commit:

Re: tg3 BUG: spinlock lockup suspected

2016-10-08 Thread Siva Reddy Kallam 
On Sat, Oct 8, 2016 at 10:15 PM, Meelis Roos  wrote:
>> That did not go well - bisect found the following commit but that does
>> not seem to be related at all. So probably the reproducibility is not
>> 100% but more random.
>
> Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
> test further.
>
Thanks for reporting this. We will look into this.
Any specific steps to reproduce this?
>>
>>
>> 4c5773f9f5462dcb372857813918bbfe8c0cdcdd is the first bad commit
>> commit 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> Author: Krzysztof Kozlowski 
>> Date:   Sat May 28 11:54:12 2016 +0200
>>
>> dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>>
>> Add license and copyrights (file introduced in 2014) to header with
>> Exynos5410 clock IDs. Additionally reformat it to improve readability.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Acked-by: Stephen Boyd 
>> Reviewed-by: Javier Martinez Canillas 
>> Signed-off-by: Sylwester Nawrocki 
>>
>> :04 04 acbd432e11366a8eb8775942bc7b8caa476226e2 
>> 08e3a3f98c3d4fa2a93123c3f21b2847c06b4665 M  include
>>
>>
>> The whiole bisect log seems to dig around in unrelated places so at best
>> it just narrows the window by adding some known-bad data points.
>>
>> git bisect start
>> # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
>> git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
>> # bad: [ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea] Merge tag 
>> 'arc-4.8-rc4-fixes' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
>> git bisect bad ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea
>> # good: [e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b] affs ->d_compare(): don't 
>> bother with ->d_inode
>> git bisect good e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b
>> # bad: [77a87824ed676ca8ff8482e4157d3adb284fd381] 
>> clocksource/drivers/clps_711x: fixup for "ARM: clps711x:
>> git bisect bad 77a87824ed676ca8ff8482e4157d3adb284fd381
>> # bad: [27acbec338113a75b9d72aeb53149a3538031dda] Merge 
>> git://www.linux-watchdog.org/linux-watchdog
>> git bisect bad 27acbec338113a75b9d72aeb53149a3538031dda
>> # bad: [7f155c702677d057d03b192ce652311de5434697] Merge tag 'nfs-for-4.8-1' 
>> of git://git.linux-nfs.org/projects/trondmy/linux-nfs
>> git bisect bad 7f155c702677d057d03b192ce652311de5434697
>> # good: [797cee982eef9195736afc5e7f3b8f613c41d19a] Merge branch 'stable-4.8' 
>> of git://git.infradead.org/users/pcmoore/audit
>> git bisect good 797cee982eef9195736afc5e7f3b8f613c41d19a
>> # bad: [1056c9bd2702ea1bb79abf9bd1e78c578589d247] Merge tag 
>> 'clk-for-linus-4.8' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> git bisect bad 1056c9bd2702ea1bb79abf9bd1e78c578589d247
>> # bad: [1ff435d3571199a799ba6ccfe05544dcd21b9fb3] Merge branch 
>> 'clk-st-critical' into clk-next
>> git bisect bad 1ff435d3571199a799ba6ccfe05544dcd21b9fb3
>> # bad: [0e4504470667d355b53ca3c9802fdd2120c9f946] clk: samsung: exynos5433: 
>> Add CLK_IGNORE_UNUSED flag to PCIE device
>> git bisect bad 0e4504470667d355b53ca3c9802fdd2120c9f946
>> # bad: [880c81b3b6604a004d56b5975c8bed47276e8bf6] clk: samsung: exynos5440: 
>> Constify all clock initializers
>> git bisect bad 880c81b3b6604a004d56b5975c8bed47276e8bf6
>> # bad: [b3a96eed8e84780d300b79b58047ea277ba358b7] clk: samsung: exynos3250: 
>> Move platform driver and of_device_id to init section
>> git bisect bad b3a96eed8e84780d300b79b58047ea277ba358b7
>> # bad: [4528dd8ed477bf202bd33ee48d38d656672d37f8] dt-bindings: clock: Add 
>> watchdog and SSS clock IDs to Exynos5410
>> git bisect bad 4528dd8ed477bf202bd33ee48d38d656672d37f8
>> # bad: [5cd3535a27a7cf8fc4070b499d66e419e7e72b61] dt-bindings: clock: Add 
>> PWM and USB clock IDs to Exynos5410
>> git bisect bad 5cd3535a27a7cf8fc4070b499d66e419e7e72b61
>> # bad: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: clock: Add 
>> license and reformat Exynos5410 clock IDs
>> git bisect bad 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> # first bad commit: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: 
>> clock: Add license and reformat Exynos5410 clock IDs
>>
>>
>> >
>> > [   74.123859] tg3.c:v3.137 (May 11, 2014)
>> > [   74.123880] PCI: Enabling device: (:00:02.0), cmd 2
>> > [   74.315794] tg3 :00:02.0 (unnamed net_device) (uninitialized): 
>> > Cannot get nvram lock, tg3_nvram_init failed
>> > [   74.656152] tg3 :00:02.0 eth0: Tigon3 [partno(none) rev 2003] 
>> > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:85
>> > [   74.656160] tg3 :00:02.0 eth0: attached PHY is 5704 
>> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > [   74.656167] tg3 :00:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
>> > ASF[0] TSOcap[1]
>> > [   74.656172] tg3 :00:02.0 eth0: dma_rwctrl[763f] dma_mask[32-bit]
>> > [   74.656322] PCI: Enabling device: (:00:02.1), cmd 2
>> > [

Re: [PATCH net v2] tg3: Fix for disallow tx coalescing time to be 0

2016-09-01 Thread Siva Reddy Kallam 
On Thu, Sep 1, 2016 at 2:58 PM, Ivan Vecera <ivec...@redhat.com> wrote:
> The recent commit 087d7a8c9174 "tg3: Fix for diasllow rx coalescing
> time to be 0" disallow to set Rx coalescing time to be 0 as this stops
> generating interrupts for the incoming packets. I found the zero
> Tx coalescing time stops generating interrupts for outgoing packets
> as well and fires Tx watchdog later. To avoid this, don't allow to set
> Tx coalescing time to 0 and also remove subsequent checks that become
> senseless.
>
> Cc: satish.baddipad...@broadcom.com
> Cc: siva.kal...@broadcom.com
> Cc: michael.c...@broadcom.com
> Signed-off-by: Ivan Vecera <ivec...@redhat.com>
Acked-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
> ---
>  drivers/net/ethernet/broadcom/tg3.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 6592612..a2551bc 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -14012,6 +14012,7 @@ static int tg3_set_coalesce(struct net_device *dev, 
> struct ethtool_coalesce *ec)
> if ((ec->rx_coalesce_usecs > MAX_RXCOL_TICKS) ||
> (!ec->rx_coalesce_usecs) ||
> (ec->tx_coalesce_usecs > MAX_TXCOL_TICKS) ||
> +   (!ec->tx_coalesce_usecs) ||
> (ec->rx_max_coalesced_frames > MAX_RXMAX_FRAMES) ||
> (ec->tx_max_coalesced_frames > MAX_TXMAX_FRAMES) ||
> (ec->rx_coalesce_usecs_irq > max_rxcoal_tick_int) ||
> @@ -14022,16 +14023,6 @@ static int tg3_set_coalesce(struct net_device *dev, 
> struct ethtool_coalesce *ec)
> (ec->stats_block_coalesce_usecs < min_stat_coal_ticks))
> return -EINVAL;
>
> -   /* No rx interrupts will be generated if both are zero */
> -   if ((ec->rx_coalesce_usecs == 0) &&
> -   (ec->rx_max_coalesced_frames == 0))
> -   return -EINVAL;
> -
> -   /* No tx interrupts will be generated if both are zero */
> -   if ((ec->tx_coalesce_usecs == 0) &&
> -   (ec->tx_max_coalesced_frames == 0))
> -   return -EINVAL;
> -
> /* Only copy relevant parameters, ignore all others. */
> tp->coal.rx_coalesce_usecs = ec->rx_coalesce_usecs;
> tp->coal.tx_coalesce_usecs = ec->tx_coalesce_usecs;
> --
> 2.7.3
>

Re: [PATCH net 1/2] tg3: Fix for diasllow rx coalescing time to be 0

2016-08-04 Thread Siva Reddy Kallam 
On Thu, Aug 4, 2016 at 3:45 AM, Michael Chan  wrote:
> On Wed, Aug 3, 2016 at 9:04 AM, Rick Jones  wrote:
>>
>> Should anything then happen with:
>>
>> /* No rx interrupts will be generated if both are zero */
>> if ((ec->rx_coalesce_usecs == 0) &&
>> (ec->rx_max_coalesced_frames == 0))
>> return -EINVAL;
>>
>>
>> which is the next block of code?  The logic there seems to suggest that it
>> was intended to be able to have an rx_coalesce_usecs of 0 and rely on packet
>> arrival to trigger an interrupt.  Presumably setting rx_max_coalesced_frames
>> to 1 to disable interrupt coalescing.
>>
>
> I remember writing this block of code over 10 years ago for early
> generations of the chip.  Newer chips seem to behave differently and
> rx_coalesce_usecs can never be zero.  So this block can be removed now
> that the condition can never be true.  We should probably leave a
> comment there for future reference.
Thanks Rick for identifying this.
Thanks Michael for your inputs. I will submit a patch with removal of
this block of code and add a comment for future reference.

Re: question: tg3 driver/nics and inconsistent RX ring count

2016-07-29 Thread Siva Reddy Kallam 
On Wed, Jul 27, 2016 at 4:25 AM, Michael Chan  wrote:
> On Tue, Jul 26, 2016 at 1:32 PM, Michal Soltys  wrote:
>> On 2016-07-26 22:06, Alexander Duyck wrote:
>>> On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys  wrote:
 Hi,

 I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
 servers - and all of them have certain peculiarity: they claim to have
 up to 4 TX and RX rings (and this can be set/verified just fine through
 ethtool -l/-L, with driver defaulting to 4 rings), indirection table
 (ethtool -x) looks fine as well:

 RX flow hash indirection table for eth1b with 3 RX ring(s):
 0:  0 1 2 3 0 1 2 3
 8:  0 1 2 3 0 1 2 3
 ..

 But this "3 RX ring(s)" is actually a real limit if I try to adjust
 anything, for example all those commands would fail:

 ethtool -X eth1b equal 4
 ethtool -X eth1b weight 1 1 1 1

 But would work fine for 3 and less rings. This was quickly tested with
 different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
 exact results. Nothing fancier (-N/-U) is supported either.

 Any hints/comments about the cause of this and/or possible workarounds ?
>>>
>>> Well a quick look at the driver code makes it seem the problem lies in
>>> tg3_get_rxnfc.  I suspect the bug is related to the following lines:
>>>
>>> /* The first interrupt vector only
>>>  * handles link interrupts.
>>>  */
>>> info->data -= 1;
>>>
>>> I'm not sure what the number of interrupt vectors has to do with the
>>> number of rings.  Perhaps someone more familiar with the driver can
>>> point out why you would subtract 1 from tp->rxq_cnt to get the number
>>> of queues when it seems like it should be tp->rxq_cnt.
>>>
>>> Hope that helps.
>>>
>>> - Alex
>>>
>>
>> Ah thanks, seems to be the case then. Quick git blame shows it's been
>> since the very introduction of RSS indirection configurability (ca.
>> 2011) in this driver, 90415477bf1356f72acc34063ff52441fc10a754.
>>
>> I've CCed the author, maybe he will be able to shed some light.
>
> Matt is no longer working here.  The driver should support up to 5
> MSIX vectors and 4 RSS rings.  It looks like the code to subtract 1 in
> tg3_get_rxnfc() is not correct.  Siva will look further into this.
> Thanks for reporting the issue.
Yes, the code to subtract 1 in tg3_get_rxnfc looks incorrect. we will
upstream the patch for removing this code.

Re: [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c

2016-04-21 Thread Siva Reddy Kallam 
On Thu, Apr 14, 2016 at 8:42 AM, <zengzhao...@163.com> wrote:
>
> From: Zhaoxiu Zeng <zhaoxiu.z...@gmail.com>
>
> Signed-off-by: Zhaoxiu Zeng <zhaoxiu.z...@gmail.com>
Looks good to me.
Acked-by: Siva Reddy Kallam <siva.kal...@broadcom.com>
> ---
>  drivers/net/ethernet/broadcom/tg3.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 3010080..802a429 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
>
> err = -EIO;
> for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
> -   u8 hw8 = hweight8(data[i]);
> -
> -   if ((hw8 & 0x1) && parity[i])
> -   goto out;
> -   else if (!(hw8 & 0x1) && !parity[i])
> +   if (parity8(data[i]) == !!parity[i])
> goto out;
> }
> err = 0;
> --
> 2.5.0
>
>