netdev - Re: Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

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-next>] [day] [month] [year] [list]

Message-ID: <20190430081223.GA7409@taurus.defre.kleine-koenig.org>
Date:   Tue, 30 Apr 2019 10:12:27 +0200
From:   Uwe Kleine-König <uwe@...ine-koenig.org>
To:     Aurelien Jarno <aurel32@...ian.org>, 927825@...s.debian.org
Cc:     Jason Cooper <jason@...edaemon.net>, Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        netdev@...r.kernel.org, Marcin Wojtas <mw@...ihalf.com>
Subject: Re: Bug#927825: arm: mvneta driver used on Armada XP GP boards does
 not receive packets (regression from 4.9)

[Adding the mvebu guys and netdev to Cc]

Hello,

On Thu, Apr 25, 2019 at 09:17:32PM +0200, Aurelien Jarno wrote:
> On 2019-04-25 14:50, Aurelien Jarno wrote:
> > On 2019-04-23 22:16, Aurelien Jarno wrote:
> > > Source: linux
> > > Version: 4.19.28-2
> > > Severity: important
> > > 
> > > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > > GP board) from buster to stretch, the ethernet device is not working

"upgrading from buster to stretch" doesn't make sense. I think you meant
from stretch to buster.

> > 
> > More precisely the board is a "Marvell Armada XP Development Board
> > DB-MV784MP-GP"
> > 
> > > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > > that the packets correctly leave the board and that the reception side
> > > fails.

If you can send to a remote host at least ARP (or ND) must be working,
so some reception still works, right?

> > > The module used for the ethernet device is mvneta. The corresponding DT
> > > compatible entry is "marvell,armada-xp-neta".
> > >
> > 
> > I have started a "bisection" with the kernels from snapshot. This is
> > what I have found so far:
> > 
> > This one works:
> > - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 
> > 
> > The following ones don't:
> > - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> > - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> > 
> > My guess (I don't have time to try more now) is that the issue is caused
> > by the following change:
> > 
> > |  [ Uwe Kleine-König ]
> > |  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> > 
> 
> I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel 
> 4.19.28-2 fixes the issue. Note that it breaks the ABI.

A colleague happens to work with an XP based machine with a (nearly)
vanilla kernel based on 5.1.0-rc6 and there enabling MVNETA_BM_ENABLE
doesn't render networking nonfunctional.

Looking through the changes to drivers/net/ethernet/marvell/mvneta*
between 5.0 and 5.1-rc6 there isn't something that would explain a fix
though. There doesn't seem to be a good explanation in the debian
specific patches either.

So this problem is either machine specific or it works with the mvneta
driver builtin. (I didn't double check, but guess that my colleague uses
=y and the Debian kernel =m). Well, or I missed something.

Is it possible to test a few things on hartmann? I'd suggest:

 - try (vanilla) 5.1-rc6 with MVNETA=y
 - try an older kernel (maybe 4.6 as the buffer manager stuff was
   introduced in dc35a10f68d3 ("net: mvneta: bm: add support for
   hardware buffer management") which made it into 4.6-rc1) with
   MVNETA_BM_ENABLE=[ym].

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)