lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 May 2017 14:45:28 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Daniel Kim <dkim@...ymechanix.com>
Cc:     Siva Reddy Kallam <siva.kallam@...adcom.com>,
        Prashant Sreedharan <prashant@...adcom.com>,
        Michael Chan <mchan@...adcom.com>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [Problem] Broadcom BCM5762 Ethernet tg3 times out with stack trace

On Fri, May 12, 2017 at 12:10 PM, Daniel Kim <dkim@...ymechanix.com> wrote:

> [ 4898.361530] tg3 0000:04:00.0 enp4s0: 0: Host status block
> [00000001:00000021:(0000:0486:0000):(0000:002c)]
> [ 4898.361535] tg3 0000:04:00.0 enp4s0: 0: NAPI info
> [00000021:00000021:(0135:002c:01ff):0000:(0568:0000:0000:0000)]

As you can see here, the driver has caught up with the hardware's
status tag of 0x21 and tx consumer of 0x2c.  However, the tx producer
is at 0x135, way ahead of the consumer.  The hardware is not
completing all these TX BDs from 0x2c to 0x135.

> [ 4898.360797] tg3 0000:04:00.0 enp4s0: 0x00000c00: 0x0000000a,
> 0x00000000, 0x00000003, 0x00000001
>
> [ 4898.360849] tg3 0000:04:00.0 enp4s0: 0x00001800: 0x00000016,
> 0x00000000, 0x00000135, 0x00000000
>
> [ 4898.361157] tg3 0000:04:00.0 enp4s0: 0x00004800: 0x380303fe,
> 0x00000000, 0x00000000, 0x00000100

I checked a few of the status registers related to the TX blocks and
the read DMA engine status and they are all ok.  The hardware sees the
tx producer of 0x135.

> [ 4898.361087] tg3 0000:04:00.0 enp4s0: 0x00003cc0: 0x00000135,
0x00000000, 0x00000000, 0x00000000

Even the internal host coalescing is seeing 0x135 as the tx index.
Somehow this is not DMA'ed to the host.

Do you have IOMMU enabled?  Does the same NIC used to work with a
different kernel?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ