Date:   Tue, 14 May 2019 16:25:36 +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

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.

Uboot in fedora is currently at 2019-04, with a number of uefi patches
you can see here:
https://src.fedoraproject.org/rpms/uboot-tools/tree/master
I belive all of the patches are about teaching uboot about the generic
distro agnostic UEFI setup and not something to do with memory or board
config.

I've also tried uboot master + distro agnostic patches with the same
result.

My PAGE_SIZE is the Fedora default 4096. Fedora 30 aarch kernels and
userspace unmodified.

My general interest is about running unmodified Fedora on this board.
I am not sure if uboot or EDK2 with the marvell build instructions is
the best way to go about it.

Thanks 
Yanko
> 
> Maybe Marcin could confirm this is the same issue as what happened in
> this thread.
> 
> Thanks,
> 
> Maxime
> 
> > > ------------[ cut here ]------------
> > > kernel BUG at include/linux/mm.h:547!
> > > Internal error: Oops - BUG: 0 [#1] SMP
> > > Modules linked in: crct10dif_ce ghash_ce spi_orion i2c_mux_pca954x i2c_mux sfp mdio_i2c omap_rng mvpp2 armada_thermal phylink marvell sbsa_gwdt mvmdio vfat fat mmc_block rtc_armada38x sdhci_xenon_driver phy_generic sdhci_pltfm xhci_plat_hcd ahci_platform phy_mvebu_cp110_comphy i2c_mv64xxx sdhci fuse
> > > Process swapper/0 (pid: 0, stack limit = 0x0000000058631e79)
> > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.1-300.fc30.aarch64 #1
> > > Hardware name: Marvell mvebu_armada-8k/mvebu_armada-8k, BIOS 2019.04 04/18/2019
> > > pstate: 40400005 (nZcv daif +PAN -UAO)
> > > pc : page_frag_free+0x74/0xa0
> > > lr : page_frag_free+0x74/0xa0
> > > sp : ffff000010003a60
> > > x29: ffff000010003a60 x28: ffff0000117e5480 
> > > x27: 0000000000000000 x26: 0000000000000000 
> > > x25: ffff80007fc40462 x24: ffff80007fc40458 
> > > x23: ffff80007fc40450 x22: ffff0000117dbc00 
> > > x21: ffff8001356c2a00 x20: ffff80007fc404c0 
> > > x19: ffff80007fc40400 x18: 0000000000000000 
> > > x17: 0000000000000000 x16: 0000000000000000 
> > > x15: 0000000000000010 x14: ffffffffffffffff 
> > > x13: ffff00009000375f x12: ffff000010003767 
> > > x11: ffff000011679000 x10: ffff000010eb6428 
> > > x9 : ffff00001185a000 x8 : 00000000000001c7 
> > > x7 : 0000000000000015 x6 : 0000000000000001 
> > > x5 : 0000000000000000 x4 : ffff80013f72a190 
> > > x3 : ffff80013f730488 x2 : ffff80013f72a190 
> > > x1 : 0000000000000000 x0 : 000000000000003e 
> > > Call trace:
> > >  page_frag_free+0x74/0xa0
> > >  skb_free_head+0x28/0x48
> > >  skb_release_data+0x13c/0x178
> > >  skb_release_all+0x30/0x40
> > >  consume_skb+0x38/0xc8
> > >  arp_process+0x2d0/0x6e0
> > >  arp_rcv+0x100/0x178
> > >  __netif_receive_skb_one_core+0x50/0x60
> > >  __netif_receive_skb+0x28/0x70
> > >  netif_receive_skb_internal+0x44/0xd0
> > >  napi_gro_receive+0x198/0x1c8
> > >  mvpp2_rx+0x1f8/0x500 [mvpp2]
> > >  mvpp2_poll+0x150/0x1e8 [mvpp2]
> > >  napi_poll+0xb4/0x250
> > >  net_rx_action+0xbc/0x1b0
> > >  __do_softirq+0x138/0x334
> > >  irq_exit+0xc0/0xe0
> > >  __handle_domain_irq+0x70/0xc0
> > >  gic_handle_irq+0x58/0xa8
> > >  el1_irq+0xf0/0x1c0
> > >  arch_cpu_idle+0x3c/0x1c8
> > >  default_idle_call+0x20/0x3c
> > >  cpuidle_idle_call+0x140/0x190
> > >  do_idle+0xb0/0x108
> > >  cpu_startup_entry+0x2c/0x30
> > >  rest_init+0xc0/0xcc
> > >  arch_call_rest_init+0x14/0x1c
> > >  start_kernel+0x4ac/0x4c0
> > > Code: aa0203e0 d0006101 91226021 9400cf32 (d4210000) 
> > > ---[ end trace 267606a8b5fb06cb ]---
> > > Kernel panic - not syncing: Fatal exception in interrupt
> > > SMP: stopping secondary CPUs
> > > Kernel Offset: disabled
> > > CPU features: 0x002,21006000
> > > Memory Limit: none
> > > ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---  

Powered by blists - more mailing lists