[Macchiato] [EXT] Network driver crash

[Marcin Wojtas]

HI Jeremy,

2018-03-06 22:08 GMT+01:00 Jeremy Linton <Jeremy.Linton at arm.com>:
> Hi,
>
>
>
> So I was running Leif’s firmware (as well as an build of my own from early
> January) and they were having the problems with the 1G port as well.
>
>
>
> I tossed the latest 4.16 DTB in the firmware build and that fixed the
> network problem, except I also made the mistake of pulling forward the
> edk2/openplatform/atf/marvell-binary tree’s too, and ended up disabling the
> flash based UEFI variable store because It seems the mem mapping to the SPI
> flash is somehow broken. Basically it spews “Firmware Volume for Variable
> Store is corrupted”.
>

Thanks for confirming the DTBs.

I updated marvell-armada-wip branch with 3 new commits:
150e1b4 - Marvell/Armada: Ensure proper access to memory mapped SPI
e3c5b71 - Revert "Platforms/Armada80x0McBin: Use GIC interrupts directly"
61bf1b6 - Revert "Platforms/Armada80x0McBin: Restore old
system-controller binding"

I'd appreciate giving a try to boot from SD and checking the network
in your setup.

>
>
> PCIe remains broken, as do the 10G ports, but I don’t need the USB->Ethernet
> adapter anymore.
>
>

What do you mean by:
1. "PCIe remains broken" - kernel or firmware? What are the symptoms?

2. "as do the 10G ports" - ditto?

Thanks,
Marcin

>
>
>
>
>
>
>
> From: Macchiato [mailto:macchiato-bounces at lists.einval.com] On Behalf Of
> Marcin Wojtas
> Sent: Sunday, March 04, 2018 7:39 AM
> To: Stefan Chulski
> Cc: macchiato at lists.einval.com
>
>
> Subject: Re: [Macchiato] [EXT] Network driver crash
>
>
>
> Stefan,
>
>
>
> 2018-03-04 14:30 GMT+01:00 Stefan Chulski <stefanc at marvell.com>:
>
>
>
>
>
> From: Marcin Wojtas [mailto:mw at semihalf.com]
> Sent: Sunday, March 04, 2018 3:18 PM
> To: Stefan Chulski <stefanc at marvell.com>
> Cc: Steve McIntyre <steve at einval.com>; macchiato at lists.einval.com
> Subject: Re: [Macchiato] [EXT] Network driver crash
>
>
>
> Hi Stefan,
>
>
>
> 2018-03-04 13:35 GMT+01:00 Stefan Chulski <stefanc at marvell.com>:
>
>> >IRQ requested during interface open procedure.
>> >So you should do "ifconfig eth2 up".
>> >I don't have mainline code right now, but should be something like this:
>> ># ifconfig eth2 up
>> ># cat /proc/interrupts | grep eth2
>> >134:          1          0          0          0       ICU 129 Level
>> > f4000000.ppv22.eth2.link
>> >135:          0          0          0          0       ICU  39 Level
>> > f4000000.ppv22.eth2.cpu0
>> >136:          0          0          0          0       ICU  43 Level
>> > f4000000.ppv22.eth2.cpu1
>> >137:          0          0          0          0       ICU  47 Level
>> > f4000000.ppv22.eth2.cpu2
>> >138:          0          0          0          0       ICU  51 Level
>> > f4000000.ppv22.eth2.cpu3
>>
>> Nope, not seeing that here:
>>
>> steve at mjolnir:~$ sudo ifconfig eth2 up
>> steve at mjolnir:~$ cat /proc/interrupts | grep eth2
>>  70:          0          0          0          0     GICv2 294 Level
>> eth2
>
> Packet processor use ICU interrupts...
>
> Could you please share your dtb file, boot log and ifconfig -a output.
>
>
>
> The DTB that Stuart was running, use older binding (ICU -> GIC mapping
> basing on the ATF configuration). Do you think it can matter?
>
>
>
> Yes. Look like it cause issue.
>
> Each TX done interrupt mapped to specific CPU by smp_affinity and without
> IRQ balancing. Look like with old dtb interrupt raised on wrong CPU’s.
>
> You can work around this issue by disabling TX Done interrupts in
> mvpp2_port_has_tx_irqs
>
>
>
>          for (i = 0; i < 5; i++) {
>
>                      ret = of_property_match_string(port_node,
> "interrupt-names",
>
>                                                                 irqs[i]);
>
>                      if (ret < 0)
>
>                                  return false;
>
>           }
>
> -       return true;
>
> +      return false;
>
>
>
>
>
>
>
> With distros we can only manipulate DTB / ACPI contents, so let's confirm
> that.
>
>
>
> Thanks,
>
> Marcin
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.