Other Parts Discussed in Thread: AM3359, DP83630,
We are facing non-systematic ti_prueth errors on AM3359 working as a DAN in PRP network.
This is a custom device made by analogy with TMDSICE3359. The only one diffence is the PHY IC - we use DP83630.
The device is driven RT-Linux (SDK 06.03.00.106), moreover it's a standard image am335x-evm-linux-rt-06.03.00.106.img.zip.
Since it's a PRP network we use PRU with a PRP mode enabled.
The device boots and works the first time correctly, but than (the error occurs at different intervals after startup - several hours or more) occures some PRU driver errors (see attached dmesg logs). Finally network stack starts to work incorrectly - it does not respond to ping and device transmits only HSR-PRP supervision frames.
We see two oops, and both of them are caused by the ti_prueth driver. Critical is the second one, because it's closing a task, that handles eth irqs.
The two dmesg logs, that are attached to this post, are made on devices connected to the same PRP LAN. Both devices were enabled almost simultaneously, so from dmesg you can see, that errors appeared NOT simultaneously.
At the same time another DANs, that use another PRP hardware solution are working well in this network for several weeks now.
We can't localize the problem yet.
Can you help us with this issue?
Maybe there're some linux kernel configurations, that can solve this problem?
Or maybe there's some bug in ti_prueth driver, that should be fixed?
/cfs-file/__key/communityserver-discussions-components-files/791/dmesg_5F00_dev2.log
/cfs-file/__key/communityserver-discussions-components-files/791/dmesg_5F00_dev1.log
If you need some addition information - we are ready to provide everything we can.
