Hello,
On Tue, Apr 30, 2019 at 10:12:27AM +0200, Uwe Kleine-König wrote:
> 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].Thanks to Steve McIntyre I got access to a DB-MV784MP-GP and did the second test. I used mvebu_v7_defconfig and enabled CGROUPS and AUTOFS4 (to please systemd) and MVNETA_BM_ENABLE=y on 4.6. The latter breaks networking similar to newer kernel versions. So I guess the buffer management never worked on that board. I don't have the time to debug this issue further, but will disable buffer management for the Debian kernel again. Best regards Uwe
signature.asc
Description: PGP signature
