10 rpmsg channels with rpmsg_char write&read will make linux waring

[mingwei-learn]

Hi， Im trying to run 10 rpmsg channels between A53&R5 on my Xilinx borad,
I make 1 threads for each channel to send and recive message(R5 will send back the message)
Send action is write(dev_rpmsg_char_fd,&mesage,sizeof(message)
Recive action is read(dev_rpmsg_char_fd,&mesage,sizeof(message)

It`s ok when i send 10 times for each channel.But ,the linux will push "cut here waring" when i send 100 or more times.It will make my app waste time on waring print。

the waring message like this：

[mingwei-learn]

I guess the reason is linux kernel driver mailbox moudule. linux has up the code ,but my kernel version is old.

link 1:https://e2e.ti.com/support/processors-group/processors/f/processors-forum/538908/remoteproc2-mbox_send_message-failed--105
link2:https://lkml.org/lkml/diff/2020/10/16/837/1

link2 is not the best way.the last version of linux driver has changed it.

[arnopo]

@TanmayShah-xilinx : any advice?

[tnmysh]

@mingwei-learn what is the kernel version are you using?

[mingwei-learn]

5.4.0 build by petalinux2020.1
and i found the petalinux2022.2 based on "xlnx_rebase_v5.15_LTS_2022.2" ,maxilbox fo 5.15 is still old. but 5.20 has changed to new。
link：https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v5.15_LTS_2022.2/drivers/mailbox/mailbox.c

[mingwei-learn]

Now I make a mutex lock to lock my write and read function(used as a rpc), there is no warning, which means all 10 thread should send or read in a queue. but It seems not graceful。
As a user,I have 10 ept file，it should be I can write or read ept file anywhere and any time,I don`t need to take care about the rpmsg queue is full,or it is sending. All status should be returned by writer/read function .
thanks

[tnmysh]

Yes correct. I haven't tried this use case. Currently we have tested only with two end-points, with minimal data transfer. Based on above behavior somewhere race condition needs to be fixed. Either in general rpmsg/remoteproc/mailbox framework or in xilinx drivers (could be remoteproc, or mailbox) or RPU firmware side.