[Macchiato] success (first boot)

Marc Zyngier marc.zyngier at arm.com
Tue Jan 30 11:26:17 GMT 2018


On 30/01/18 00:17, Marcin Wojtas wrote:
> Hi guys,
> 
> I just recalled, that for the SLES12 SP3 requirements, I agreed to
> 'downgrade' armada-8040-mcbin.dtb, so that it could use older DT
> bindings. 

Really? Do we now have per-distribution firmware?

> Maybe this is the reason of the observed inconsistencies? It's
> enough to take v4.15 dtb, put it in
> Platforms/Marvell/Armada/armada-8040-mcbin.dtb, rebuild and reflash the
> image. I'm curious if it can help anything. When I boot the mainline
> kernel with mainline dtb (or ACPI) everything seems fine to me, although
> I admit, that apart from iperf3, I didn't stress the network much
> (however all apt install succeeded).

Current mainline sort of works, but see the plat you quoted below, which
has nothing to do with DT (and may have to do with the skb being freed
too early).

Thanks,

	M.

> 
> Best regards,
> Marcin
> 
> 2018-01-25 13:44 GMT+01:00 Marc Zyngier <marc.zyngier at arm.com
> <mailto:marc.zyngier at arm.com>>:
> 
>     On 24/01/18 09:43, Marcin Wojtas wrote:
>     > +Antoine
>     >
>     > Hi Marc,
>     >
>     > 2018-01-24 10:25 GMT+01:00 Marc Zyngier <marc.zyngier at arm.com
>     <mailto:marc.zyngier at arm.com>>:
>     >> On 23/01/18 23:15, Ard Biesheuvel wrote:
>     >>> On 23 January 2018 at 23:12, Steve McIntyre <steve at einval.com
>     <mailto:steve at einval.com>> wrote:
>     >>>> On Tue, Jan 23, 2018 at 11:07:53PM +0000, Matthew Bentham wrote:
>     >>>>> Hi,
>     >>>>> Thanks. I've got it showing a Linux terminal using an old
>     Radeon 5570 now :-)
>     >>>>>
>     >>>>> My problem now is that the network device driver is causing a
>     kernel panic when
>     >>>>> doing "apt install task-gnome-desktop". I get a lot of warning
>     messages first
>     >>>>> along the lines of "detected wrong cpu at end of Tx processing".
>     >>>>
>     >>>> Aha! Not just me then! I've been seeing the same 2 things for a
>     while,
>     >>>> but Leif and Stuart have not.
>     >>>>
>     >>>> I was wondering if it's memory corruption in the driver, but
>     I've not
>     >>>> had much chance to dig into it yet.
>     >>>>
>     >>>
>     >>> I think this may be a known issue. Marc?
>     >>
>     >> I fixed something along those lines[1]. But this driver is being
>     >> randomly changed and almost never tested in a production
>     environment, so
>     >> it it breaks on almost every single effin' change.
>     >>
>     >> 4.14 should have the fix though... If it still breaks, I'll dust
>     off the
>     >> board and give it a spin.
>     >>
>     >>         M.
>     >>
>     >> [1]
>     >>
>     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/marvell/mvpp2.c?id=13c249a94f525fe4c757d28854049780b25605c4
>     <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/marvell/mvpp2.c?id=13c249a94f525fe4c757d28854049780b25605c4>
>     >> --
>     >
>     > I saw your patch is already a part of v4.14... Two days ago similar
>     > bug report was sent to the lists and I Antoine said it will be
>     > investigated.
> 
>     I've just booted with 4.15-rc9, and I don't see the TX issue any more,
>     which is what I expected with the above fix.
> 
>     What I am seeing is this:
> 
>     [   11.849032] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
>     [   12.720977] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>     [   12.809757] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
>     [   13.762656] mvpp2 f2000000.ethernet eth0: Link is Up - 1Gbps/Full
>     - flow control rx/tx
>     [   13.770787] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>     [   14.639318] BUG: Bad page state in process swapper/0  pfn:e6804
>     [   14.645296] page:ffff7fd8249a0100 count:0 mapcount:0 mapping:   
>           (null) index:0xfffff609268049c0
>     [   14.654659] flags: 0xfffe00000000100(slab)
>     [   14.658781] raw: 0fffe00000000100 0000000000000000
>     fffff609268049c0 0000000000400000
>     [   14.666563] raw: ffff7fd8232e5420 fffff60927bf0610
>     fffff6092b546000 0000000000000000
>     [   14.674348] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>     [   14.680818] bad because of flags: 0x100(slab)
>     [   14.685191] Modules linked in:
>     [   14.688271] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>     4.15.0-rc9-00124-g9f55a2093a18 #8070
>     [   14.696568] Hardware name: Marvell 8040 MACHIATOBin (DT)
>     [   14.701900] Call trace:
>     [   14.704362]  dump_backtrace+0x0/0x1c0
>     [   14.708039]  show_stack+0x24/0x30
>     [   14.711367]  dump_stack+0x8c/0xb0
>     [   14.714695]  bad_page+0xf0/0x158
>     [   14.717935]  free_pages_check_bad+0x80/0xa0
>     [   14.722134]  __free_pages_ok+0x24c/0x340
>     [   14.726071]  page_frag_free+0x78/0x88
>     [   14.729749]  skb_free_head+0x38/0x48
>     [   14.733337]  skb_release_data+0x140/0x158
>     [   14.737362]  skb_release_all+0x30/0x40
>     [   14.741126]  consume_skb+0x38/0x110
>     [   14.744630]  arp_process.constprop.4+0x158/0x778
>     [   14.749264]  arp_rcv+0xf0/0x118
>     [   14.752418]  __netif_receive_skb_core+0x5ac/0x8a8
>     [   14.757140]  __netif_receive_skb+0x28/0x78
>     [   14.761252]  netif_receive_skb_internal+0x30/0x120
>     [   14.766060]  napi_gro_receive+0x15c/0x188
>     [   14.770085]  mvpp2_poll+0x37c/0x678
>     [   14.773586]  net_rx_action+0x108/0x390
>     [   14.777349]  __do_softirq+0x120/0x370
>     [   14.781025]  irq_exit+0x90/0xb0
>     [   14.784179]  __handle_domain_irq+0x90/0xf8
>     [   14.788291]  gic_handle_irq+0x60/0xb0
>     [   14.791966]  el1_irq+0xb0/0x128
>     [   14.795119]  arch_cpu_idle+0x28/0x1c8
>     [   14.798796]  do_idle+0x138/0x1f0
>     [   14.802036]  cpu_startup_entry+0x28/0x30
>     [   14.805973]  rest_init+0xd4/0xe0
>     [   14.809216]  start_kernel+0x3a4/0x3b8
>     [   14.812911] Disabling lock debugging due to kernel taint
>     [   15.957032] mvpp2 f4000000.ethernet eth2: Link is Up - 1Gbps/Full
>     - flow control rx/tx
>     [   15.965006] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
>     [   46.036434] device eth0 entered promiscuous mode
> 
>     which happens if you attach a macvtap to the network interface
>     (in this case eth0). As this is the only system where this happens,
>     I assume the Ethernet driver is doing something pretty bad when
>     it comes to managing the skb life cycle. None of the non-Marvell
>     systems I have access to explode this way...
> 
>     Thanks,
> 
>             M.
>     --
>     Jazz is not dead. It just smells funny...
> 
> 


-- 
Jazz is not dead. It just smells funny...



More information about the Macchiato mailing list