Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 15 Nov 2022 13:10:34 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     netdev@kapio-technology.com
Cc:     Ido Schimmel <idosch@idosch.org>, davem@davemloft.net,
        kuba@kernel.org, netdev@vger.kernel.org,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 net-next 0/2] mv88e6xxx: Add MAB offload support
Message-ID: <20221115111034.z5bggxqhdf7kbw64@skbuf>
References: <20221112203748.68995-1-netdev@kapio-technology.com>
 <Y3NcOYvCkmcRufIn@shredder>
 <5559fa646aaad7551af9243831b48408@kapio-technology.com>
 <20221115102833.ahwnahrqstcs2eug@skbuf>
 <7c02d4f14e59a6e26431c086a9bb9643@kapio-technology.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7c02d4f14e59a6e26431c086a9bb9643@kapio-technology.com>
Precedence: bulk

On Tue, Nov 15, 2022 at 11:52:40AM +0100, netdev@kapio-technology.com wrote:
> I had a discussion with Jacub, which resulted in me sending a mail to
> maintainers on this. The problem is shown below...
> 
> the phy is marvell/6097/88e3082
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 332 at drivers/net/phy/phy.c:975
> phy_error+0x28/0x54
> Modules linked in:
> CPU: 0 PID: 332 Comm: kworker/0:0 Tainted: G        W          6.0.0 #17
> Hardware name: Freescale i.MX27 (Device Tree Support)
> Workqueue: events_power_efficient phy_state_machine
>   unwind_backtrace from show_stack+0x18/0x1c
>   show_stack from dump_stack_lvl+0x28/0x30
>   dump_stack_lvl from __warn+0xb8/0x114
>   __warn from warn_slowpath_fmt+0x80/0xbc
>   warn_slowpath_fmt from phy_error+0x28/0x54
>   phy_error from phy_state_machine+0xbc/0x218
>   phy_state_machine from process_one_work+0x17c/0x244
>   process_one_work from worker_thread+0x248/0x2cc
>   worker_thread from kthread+0xb0/0xbc
>   kthread from ret_from_fork+0x14/0x2c
> Exception stack(0xc4a71fb0 to 0xc4a71ff8)
> 1fa0:                                     00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> ---[ end trace 0000000000000000 ]---

Was that email public on the lists? I don't see it...

The phy_error() is called from phy_state_machine() if one of
phy_check_link_status() or phy_start_aneg() fails.

Could you please print exactly the value of "err", as well as dig deeper
to see which call is failing, all the way into the PHY driver?

Easiest way to do that would probably be something like:

$ trace-cmd record -e mdio sleep 10 &
... do your stuff ...
$ trace-cmd report
    kworker/u4:3-337   [001]    59.054741: mdio_access:          0000:00:00.3 read  phy:0x13 reg:0x01 val:0x7949
    kworker/u4:3-337   [001]    59.054941: mdio_access:          0000:00:00.3 read  phy:0x13 reg:0x09 val:0x0700
    kworker/u4:3-337   [001]    59.055262: mdio_access:          0000:00:00.3 read  phy:0x13 reg:0x0a val:0x4000
    kworker/u4:3-337   [001]    60.075808: mdio_access:          0000:00:00.3 read  phy:0x13 reg:0x1c val:0x3005

"val" will be negative when there is an error. This is to see quicker what fails,
and if some MDIO access ever works.

If you don't want to enable CONFIG_FTRACE or install trace-cmd, you
could also probably do the debugging manually.