netdev - Re: No traffic with Marvell switch and latest linux-next

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

Date:   Sun, 17 Feb 2019 17:40:53 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next

On 17.02.2019 16:50, Heiner Kallweit wrote:
> On 17.02.2019 16:40, Russell King - ARM Linux admin wrote:
>> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>>> When testing latest linux-next on the ZII DTU I face the issue that no
>>> traffic is flowing over the switch ports, even though in dmesg
>>> everything looks good. Also PHY properly establishes the link.
>>>
>>> With 4.20.10 I don't have the issue and with 5.0-rc6 also not.
>>> However on 5.0-rc6 I got the following, also number of network
>>> interrupts seems to be very high (few minutes after boot).
>>> Any idea what's going on?
>>>
>>> Andrew, IIRC you recently fixed some interrupt-related issue:
>>> 7ae710f9f8b2 ("gpio: vf610: Mask all GPIO interrupts")
>>> But the description doesn't seem to match this trace.
>>
>> I have a fix for the trace you have below, but it has nothing to do
>> with no traffic.  I'll send it out shortly.
>>
>> Which protocol are you using (ipv4 or ipv6)?  Have you setup a
>> bridge device containing the ports you wish to switch network
>> traffic.  Without a bridge device, DSA will by default treat each
>> port as a separate port.  The other thing that gets people is the
>> ethernet interface connected to the DSA switch must be up _before_
>> bringing up any of the switch ports.
>>
> ipv4, a simple ping. No bridge. Device is connected to a switch
> that is always on.
> 
> Technical environment and userspace is always the same, so it seems
> to be the kernel version.
> 
There haven't been that many changes to mv88e8xxx since 5.0-rc6.
I reverted 7c0db24cc431 ("dsa: mv88e6xxx: Ensure all pending interrupts
are handled prior to exit") who looked like a candidate and bingo:
network is working again. Obviously something is wrong with this patch.

>>>
>>> irq 56: nobody cared (try booting with the "irqpoll" option)
>>> CPU: 0 PID: 577 Comm: irq/38-400d1000 Not tainted 5.0.0-rc6 #1
>>> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
>>> [<8010c898>] (unwind_backtrace) from [<8010ad98>] (show_stack+0x10/0x14)
>>> [<8010ad98>] (show_stack) from [<80149660>] (__report_bad_irq+0x38/0xb0)
>>> [<80149660>] (__report_bad_irq) from [<80149478>] (note_interrupt+0x10c/0x294)
>>> [<80149478>] (note_interrupt) from [<80149cac>] (handle_nested_irq+0xd8/0xf4)
>>> [<80149cac>] (handle_nested_irq) from [<80384a64>] (mv88e6xxx_g2_irq_thread_fn+0x90/0xc0)
>>> [<80384a64>] (mv88e6xxx_g2_irq_thread_fn) from [<80149c60>] (handle_nested_irq+0x8c/0xf4)
>>> [<80149c60>] (handle_nested_irq) from [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work+0x98/0xcc)
>>> [<8037ccd0>] (mv88e6xxx_g1_irq_thread_work) from [<80147ff4>] (irq_thread_fn+0x1c/0x78)
>>> [<80147ff4>] (irq_thread_fn) from [<80148280>] (irq_thread+0x124/0x1cc)
>>> [<80148280>] (irq_thread) from [<8012f8e8>] (kthread+0x140/0x148)
>>> [<8012f8e8>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
>>> Exception stack(0x9f6c7fb0 to 0x9f6c7ff8)
>>> 7fa0:                                     00000000 00000000 00000000 00000000
>>> 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> handlers:
>>> [<b09c70df>] irq_default_primary_handler threaded [<44d6803f>] phy_interrupt
>>> Disabling IRQ #56
>>>
>>>
>>> 36:    2030566   mscm-ir  79 Edge      400d1000.ethernet
>>>  38:    1010437  gpio-vf610   2 Level     400d1000.ethernet-1:00
>>>  42:          0  mv88e6xxx-g1   3 Edge      mv88e6xxx-g1-atu-prob
>>>  44:          0  mv88e6xxx-g1   5 Edge      mv88e6xxx-g1-vtu-prob
>>>  46:    1010435  mv88e6xxx-g1   7 Edge      mv88e6xxx-g2
>>>  49:          0  mv88e6xxx-g2   1 Edge      mv88e6xxx-1:01
>>>  53:          0  mv88e6xxx-g2   5 Edge      mv88e6xxx-1:05
>>>  54:          0  mv88e6xxx-g2   6 Edge      mv88e6xxx-1:06
>>>  56:     100000  mv88e6xxx-g2   8 Edge      mv88e6xxx-1:08
>>>  63:          0  mv88e6xxx-g2  15 Edge      mv88e6xxx-watchdog
>>>
>>> Heiner
>>>
>>
>