linux-kernel - Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface

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, 24 Mar 2024 12:55:34 +0100
From: Benjamin Bigler <benjamin@...ler.one>
To: Parthiban Veerasooran <Parthiban.Veerasooran@...rochip.com>
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 horatiu.vultur@...rochip.com, Woojung.Huh@...rochip.com,
 Nicolas.Ferre@...rochip.com, UNGLinuxDriver@...rochip.com,
 Thorsten.Kummermehr@...rochip.com, davem@...emloft.net,
 edumazet@...gle.com,  kuba@...nel.org, pabeni@...hat.com,
 robh+dt@...nel.org,  krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, corbet@....net,  steen.hegelund@...rochip.com,
 rdunlap@...radead.org, horms@...nel.org,  casper.casan@...il.com,
 andrew@...n.ch
Subject: Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface

Hi Parthiban

I hope I send this in the right context as it is not related to just one patch or
some specific code.

I conducted UDP load testing using three i.MX8MM boards in conjunction with the
LAN8651. The setup involved one board functioning as a server, which is just
echoing back received data, while the remaining two boards acted as clients,
sending UDP packets of different sizes in various bursts to the server.
Due to hardware constraints, the SPI bus speed was limited to 15 MHz, which might
have influenced the results.

During the tests I experienced some issues:

- The boards just start receiving after first sending something (ping another board).
  Some measurements showed that the irq stays asserted after init. This makes sense
  as far as I understand the chapter 7.7 of the specification, the irq is deasserted
  on reception of the first data header following CSn being asserted. As a workaround
  I trigger the thread at the end of oa_tc6_init.

- If there is a lot of traffic, the receive buffer overflow error spams the log.

- If there is a lot of traffic, I got various kernel panics in oa_tc6_update_rx_skb.
  Mostly because more data to rx_skb is added than allocated and sometimes because
  rx_skb is null in oa_tc6_update_rx_skb or oa_tc6_prcs_rx_frame_end. Some debugging
  with a logic analyzer showed that the chip is not behave correctly. There is more
  bytes between start_valid and end_valid than there should be. Also there
  seems to be 2 end_valid without a start_valid between. What is common is that the incorrect
  frame starts in a chunk where end_valid and start_valid is set.
  In my opinion its a problem in the chip (maybe related to the errata in the next point)
  but the driver should be resilent and just drop the packet and not cause a kernel panic.

- Sometimes the chip stops working. It always asserts the irq but there is no data (rca=0)
  and also exst is not active. I found out that there is an errata (DS80001075) point s3
  that explains this. I set the ZARFE bit in CONFIG0. This also fixes the point above.
  The driver now works since about 2.5 weeks with various load with just one loss of frame
  error where I had to reboot the system after about 4 days.

Is there a reason why you removed the netdev watchdog which was active in v2?

Thanks,
Benjamin Bigler