[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191025073304.zqw2yxaulkyopk5y@beryllium.lan>
Date: Fri, 25 Oct 2019 09:33:04 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Stefan Wahren <wahrenst@....net>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
UNGLinuxDriver@...rochip.com, netdev@...r.kernel.org,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rt-users@...r.kernel.org,
Woojung Huh <woojung.huh@...rochip.com>,
Marc Zyngier <maz@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] net: usb: lan78xx: Use phy_mac_interrupt() for interrupt
handling
Hi Stefan,
On Thu, Oct 24, 2019 at 07:25:37PM +0200, Stefan Wahren wrote:
> Am 24.10.19 um 16:12 schrieb Daniel Wagner:
> > On Thu, Oct 24, 2019 at 01:06:10PM +0200, Daniel Wagner wrote:
> >
> > Sebastians suggested to try the RPi kernel. The rpi-5.2.y kernel
> > behaves exactly the same. That is one PHY interrupt and later on NFS
> > timeouts.
> >
> > According their website the current shipped RPi kernel is in version
> > 4.18. Here is what happends with rpi-4.18.y:
>
> No, it's 4.19. It's always a LTS kernel.
Ah okay and obviously, 4.19 works also nicely. No surprise here.
> I'm curious, what's the motivation behind this? The rpi tree contains
> additional hacks, so i'm not sure the results are comparable. Also the
> USB host driver is a different one.
The idea was to see what the PHY interrupt is doing. As it turns out
the RPi tree and mainline have almost the same infrastructure code
here (irqdomain). There are some additional tweaks in the RPi
kernel. My initial revert patch removed all this infrastructure code,
which is probably not a good idea. If the way forward is to steal the
bits and pieces from the RPi tree which should keep this code in
place.
With the local_irq_disable() patch, which I am going to send asap, the
warning which everyone is seeing should be gone. So one bug down.
> > There are no NFS timeouts and commands like 'apt update' work reasoble
> > fast. So no long delays or hangs. Time to burn this hardware.
>
> Since enabling lan78xx for Raspberry Pi 3B+, we found a lot of driver
> issues. So i'm not really surprised, that there are still more of them.
If the vendor would work on fixing the bugs it would not be real
problem.
Thanks,
Daniel
Powered by blists - more mailing lists