netdev - Re: mvpp2: oops on first received packet

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

Date:   Thu, 16 May 2019 16:14:44 +0300
From:   Yanko Kaneti <yaneti@...lera.com>
To:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Marcin Wojtas <mw@...ihalf.com>
Cc:     netdev <netdev@...r.kernel.org>, Matteo Croce <mcroce@...hat.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Luka Perkov <luka.perkov@...tura.hr>
Subject: Re: mvpp2:  oops on first received packet

After some putzing around in kernel and edk2 sources, I stumbled on this
magic one-liner for kernel/mvpp2 that fixes the crashing with a
controller already initialized by uboot/mvpp2

--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -530,6 +530,8 @@ static int mvpp2_bm_init(struct platform_device *pdev, struct mvpp2 *priv)
                mvpp2_write(priv, MVPP2_BM_INTR_MASK_REG(i), 0);
                /* Clear BM cause register */
                mvpp2_write(priv, MVPP2_BM_INTR_CAUSE_REG(i), 0);
+               /* Magic for dealing with firmware leftovers */
+               mvpp2_read(priv, MVPP2_BM_PHY_ALLOC_REG(i));
        }
 
        /* Allocate and initialize BM pools */

Useful ?
-Yanko

On Wed, 2019-05-15 at 10:34 +0300, Yanko Kaneti wrote:
> On Tue, 2019-05-14 at 16:25 +0300, Yanko Kaneti wrote:
> > On Tue, 2019-05-14 at 14:32 +0200, Maxime Chevallier wrote:
> > > Hi Yanko,
> > > 
> > > > On Tue, 14 May 2019 10:29:31 +0300
> > > > Yanko Kaneti <yaneti@...lera.com> wrote:
> > > > 
> > > > > Hello,
> > > > > 
> > > > > I am trying to get some Fedora working on the MACCHIATObin SingleShot
> > > > > and I am getting an OOPS on what seems to be the first received packet
> > > > > on the gigabit port.
> > > > > 
> > > > > I've tried both 5.0.x stable and 5.1.1 with the same result.  
> > > > > mvpp2 f4000000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
> > > > > IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
> > > > > page:ffff7e0001ff1000 count:0 mapcount:0 mapping:0000000000000000 index:0x0
> > > > > flags: 0x1fffe000000000()
> > > > > raw: 001fffe000000000 ffff7e0001ff1008 ffff7e0001ff1008 0000000000000000
> > > > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> > > > > page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)  
> > > > 
> > > > Looks like a page refcnt bug (trying to free a page with already have
> > > > zero refcnt).
> > > 
> > > This looks like another issue that was reported here, where the cause
> > > was in the EFI firmware :
> > > 
> > > https://lore.kernel.org/netdev/6355174d-4ab6-595d-17db-311bce607aef@arm.com/
> > > 
> > > Can you give some details on the version of the firmware you have and
> > > if you are using EFI or uboot ?
> > 
> > I am booting a UEFI enabled uboot as built by Fedora , wrapped around by
> > the Marvell ATF, v18.12 , also tried with 17.10 without a difference.
> > From an SD card. 4G memory DIMM as supplied by SolidRun.
> ...
> > I am not sure if uboot or EDK2 with the marvell build instructions is
> > the best way to go about it.
> > 
> 
> FWIW, from this thread I learned about the Macchiato list @einval and
> tried the last test internal edk2 build that Marcin mentions there
> (flash-image-mcbin-mainline-r20190509.bin).
> 
> It finds and boots the same Fedora 30 setup that uboot works with. 
> 
> Gigabit ethernet seems to work without crashing. The 10Gs do not seem to
> work and show suspect PHY status with or without SFP+/DACs,  probably
> for some DoubleShot vs SingleShot reason..
> 
> PCIe (where I have an NVMe drive on an M.2 adapter) doesn't. Same drive,
> same kernel with the uboot firmware works fine.
> 
> On a balance of what works or doesn't with uboot vs edk2 and what it
> would take to build one of the two I'd prefer uboot (if mvpp2 somehow
> manages to work with whatever uboot+shim+grub leave behind).
> 
> -Yanko
> 
> 
> 
>