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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Feb 2019 15:08:31 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Nadav Haklai <nadavh@...vell.com>
Subject: Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules

On Fri, Feb 01, 2019 at 12:01:19PM +0100, Miquel Raynal wrote:
> Hi Vivien,
> 
> Vivien Didelot <vivien.didelot@...il.com> wrote on Wed, 30 Jan 2019
> 19:46:08 -0500:
> 
> > Hi Miquèl,
> > 
> > On Wed, 30 Jan 2019 10:46:06 +0100, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > 
> > > > > > Today, there is no S2RAM support for switches. First, I proposed to add
> > > > > > suspend/resume callbacks to the mv88e6xxx driver - just enough to avoid
> > > > > > crashing the kernel.    
> > > > > 
> > > > > Then i would suggest the mv88e6xxx refuses the suspend. Actually that
> > > > > probably is the first correct step. We don't have suspend support, so
> > > > > stop the suspend happening, so preventing the kernel crash.    
> > 
> > Actually can you show me the crash that is happening?
> 
> Sure, here it is: http://code.bulix.org/swwb11-569137
> 
> Actually it is a silent crash but the platform never resumes. I am
> pretty sure this is due to the kthread_queue_delayed_work() loop which
> might access registers before it is allowed to do so.

Hi Miquel

That sounds like it is an MDIO driver problem, or at least, a resume
ordering problem. You need to ensure that the MDIO bus driver is
resumed before the switch driver. Also, that the switch is suspended
before the MDIO bus driver is suspended.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ