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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux