Re: am335x: 5.18.x: system stalling

* Yegor Yefremov [off-list ref] [220524 13:34]:

Hi Arnd,

On Sat, May 21, 2022 at 9:41 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Thu, May 19, 2022 at 5:52 PM Yegor Yefremov
[off-list ref] wrote:

quoted

On Thu, May 12, 2022 at 12:20 PM Yegor Yefremov
[off-list ref] wrote:

quoted

On Thu, May 12, 2022 at 10:43 AM Arnd Bergmann [off-list ref] wrote:

quoted

On Thu, May 12, 2022 at 7:41 AM Tony Lindgren [off-list ref] wrote:

quoted

* Yegor Yefremov [off-list ref] [220511 14:16]:

quoted

On Thu, May 5, 2022 at 7:08 AM Tony Lindgren [off-list ref] wrote:

quoted

* Yegor Yefremov [off-list ref] [220504 10:35]:

quoted

Hi Tony, all,

since kernel 5.18.x (5.17.x doesn't show this behavior), the system
stalls as soon as I invoke the following commands (initializing
USB-to-CAN converter):

slcand -o -s8 -t hw -S 3000000 /dev/ttyUSB0
ip link set slcan0 up

Oh, I missed this part at first and only looked at the backtrace.
Which CAN driver
are you using? It's likely a problem in the kernel driver.

I am using the slcan driver [1].

Ok, so this is just a serial port based driver, which means the
follow-up question
is what you use for your uart. Is this one of the USB-serial ones or an on-chip
uart? Which driver?

This is the following chain: am335x -> musb-> ftdi_sio (FT-X flavor).

I have also tried another system with two FT4232 chips (RS232 devices)
and performed transmission tests. This had no effect, the system
didn't stall.

Maybe also try with CONFIG_MUSB_PIO_ONLY=y to see if it makes things
better or worse :)

quoted

quoted

quoted

quoted

CONFIG_DMA_API_DEBUG is still likely to pinpoint the bug, but I might also
just see it by looking at the right source file.

I'll try to get more debug info with CONFIG_DMA_API_DEBUG.

DMA_API_DEBUG showed nothing new. But disabling the CPUfreq driver
"solved" the problem. I have tried different governors and got these
two groups:

ondemand, schedutil - cause the problem
conservative, powersave, performance and userspace - don't cause the problem

So far, I have only seen the same debug output that I've initially
sent and in most cases, the system stalls without the output.

Ok, so that sounds like it happens when you change the frequency.
I assume this means you are using drivers/cpufreq/omap-cpufreq.c?

Yes.

quoted

When using the usersapce governor, do you see problems when you
manually change the frequency from sysfs?

No, I can switch between 300MHz and 600MHz and perform CAN tests.
Everything goes well.

OK so not cpufreq related.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel