> -----Original Message-----
> From: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx>
> Sent: 2019年11月11日 18:09
> To: Joakim Zhang <qiangqing.zhang@xxxxxxx>; sean@xxxxxxxxxx;
> linux-can@xxxxxxxxxxxxxxx
> Subject: Re: Wake up issue about Flexcan driver in v5.4 kernel
>
> On 11/11/19 10:48 AM, Joakim Zhang wrote:
> > I came across a strange phenomenon about wake up in Flexcan driver
> > with
> > v5.4 kernel, I connected two i.MX7D-SDB board.
> >
> > I found that CAN frame which try to wake up the system will not be
> > received at another side in order. Like below case:
> >
> > Sender: cangen can0 -vv
> > can0 4D9 [8] 89 72 0C 5F C8 15 2D 3A
> > can0 0AA [8] B7 DC 14 61 7F A0 8E 40
> > can0 304 [8] 42 5C D7 3B D6 1D 36 56
> > can0 0D9 [7] B0 C3 1B 7B 9B 3A 19
> > can0 66B [8] 8A B0 D9 56 00 46 76 48
> > can0 22D [8] 44 4B FD 53 B2 D3 A5 33
> > can0 47E [8] B9 6B 72 0B 4C 15 96 72
> > can0 54C [3] 3F BE 8F
> > can0 7C1 [8] EE A7 B4 11 6C 80 8F 7D
> > can0 5D6 [5] EB 20 1E 3E DB
> > can0 794 [8] B1 56 9E 13 6D 88 CE 52
> > can0 584 [1] 08
> >
> >
> >
> > Receiver: candump can0 &
> > can0 0AA [8] B7 DC 14 61 7F A0 8E 40
> > can0 304 [8] 42 5C D7 3B D6 1D 36 56
> > can0 0D9 [7] B0 C3 1B 7B 9B 3A 19
> > can0 66B [8] 8A B0 D9 56 00 46 76 48
> > can0 22D [8] 44 4B FD 53 B2 D3 A5 33
> > can0 4D9 [8] 89 72 0C 5F C8 15 2D 3A
> > can0 47E [8] B9 6B 72 0B 4C 15 96 72
> > can0 54C [3] 3F BE 8F
> > can0 7C1 [8] EE A7 B4 11 6C 80 8F 7D
> > can0 5D6 [5] EB 20 1E 3E DB
> > can0 794 [8] B1 56 9E 13 6D 88 CE 52
> > can0 584 [1] 08
> >
> > You can see that wake up frame(can0 4D9 [8] 89 72 0C 5F C8 15 2D
> > 3A) will be received at 6^th , it’s hard to understand.
>
> - What did you do before wakeup?
> - Clean reboot?
> - ifdown/ifup?
> - sending other packets?
> - Does this happen on every wakeup?
> - Is the wake up frame always "received" as 6th frame?
> - Is the situation the same, if you add some delay between the frames,
> using the "cangen -g option"?
> - How big can you make the -g until the frames are received in order
> again?
>
> The reception path works like this:
> In the interrupt handler the rx-offload reads all mailboxes based on the iflag
> register. It iterates over all set mailboxes, starting with the first. All mailboxes
> are read including the rx-timestamp, sorted and added into a queue. At the end
> of the IRQ handler the queue is added to the per device queue thats read in the
> NAPI and pushed into the networking stack.
>
> Maybe something with the timestamp of the first packet is wrong, as the
> counter is only 16 bits wide, it will overflow quite often.
>
> Maybe you can trace_printk the mailbox number, timestamp and can_id in
> mailbox_read() and analyse output after wakeup. Feel free to post the output
> of the tracer here.
Hi Marc,
echo 1 > /sys/kernel/debug/tracing/tracing_on
trace_printk("\nmailbox_num = %u, timestamp = %u, can_id = %x\n", n, timestamp, cfd->can_id); Add in mailbox_read(), but is print nothing, could you give me some guidance?
I always use printk() to debug, but I think it cannot print until suspend exit totally, so dump mailbox num, timestamp, and can id failed before.
Best Regards,
Joakim Zhang
> regards,
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Embedded Linux | https://www.pengutronix.de |
> Vertretung West/Dortmund | Phone: +49-231-2826-924 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
