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]
Message-ID: <f47b0230-1513-4a81-9d78-3f092b979c48@electromag.com.au>
Date: Mon, 11 Dec 2023 17:23:47 +0800
From: Richard Tresidder <rtresidd@...ctromag.com.au>
To: Jakub Kicinski <kuba@...nel.org>, vinschen@...hat.com
Cc: netdev@...r.kernel.org
Subject: Re: STMMAC Ethernet Driver support


> Richard Tresidder
>
>
> On 9/12/2023 3:06 pm, Richard Tresidder wrote:
>> On 9/12/2023 2:12 am, Jakub Kicinski wrote:
>>> On Fri, 8 Dec 2023 14:03:25 +0800 Richard Tresidder wrote:
>>>> I've looked through the diffset 6.3.3 >>> 6.6.3 on the driver
>>>> drivers\net\ethernet\stmicro\stmmac
>>>> But nothing is jumping out at me.
>>>>
>>>> I could use a pointer as to where to look to start tracing this.
>>> Bisection is good way to zero in on the bad change if you don't
>>> have much hard to rebase code in your tree.
>>>
>>> Otherwise you can dump the relevant registers and the descriptors
>>> (descriptors_status file in debugfs) and see if driver is doing
>>> anything differently on the newer kernel?
>>>
>> Thanks Jakub
>>   Yep I think I'll have to start bisecting things on Monday.
>> Luckily to work through this I shouldn't have to merge very much.
>> Have a great weekend
>>
>> Cheers
>>   Richard Tresidder
>>
> Hi Jakub
>    Ok the bad commit is the following:
> ************************************
> 6b2c6e4a938fece9b539c8085f21d17c5e6eb9de is the first bad commit
> commit 6b2c6e4a938fece9b539c8085f21d17c5e6eb9de
> Author: Corinna Vinschen <vinschen@...hat.com>
> Date:   Mon Apr 17 21:28:45 2023 +0200
>
>     net: stmmac: propagate feature flags to vlan
>
>     stmmac_dev_probe doesn't propagate feature flags to VLANs.  So 
> features
>     like offloading don't correspond with the general features and 
> it's not
>     possible to manipulate features via ethtool -K to affect VLANs.
>
>     Propagate feature flags to vlan features.  Drop TSO feature because
>     it does not work on VLANs yet.
>
>     Signed-off-by: Corinna Vinschen <vinschen@...hat.com>
>     Link: 
> https://lore.kernel.org/r/20230417192845.590034-1-vinschen@redhat.com
>     Signed-off-by: Jakub Kicinski <kuba@...nel.org>
>
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
>  1 file changed, 4 insertions(+)
> ****************************************
> From back in the work for 6.4-rc1
>
> Theres a single line addition  approx line 7506 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
> ndev->vlan_features |= ndev->features;
>
> Commenting this out and things work again.
> ***   BAD COMMENT!  We're not using VLANs on this interface, or in 
> this system at all. ***   BAD COMMENT!
> Also verified I had reenabled tx crc offload during this test.
>
> Cheers
>   Richard Tresidder
>
Actually my apologies we are using VLAN. I'd forgot how a switch was 
linked in..
We use the SOC's internal  STMMAC interface to connect to a Marvel 
switch IC and expose each port individually using vlan, I'd forgot that 
part.
It's an  88E6352-xx-TFJ2I000  device utilising the 'marvell,mv88e6085' 
compatible driver  in drivers\net\dsa\mv88e6xxx

Cheers
    Richard Tresidder


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ