Hi Tony, On Tue, May 24, 2022 at 4:19 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220524 13:34]: > > Hi Arnd, > > > > On Sat, May 21, 2022 at 9:41 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > On Thu, May 19, 2022 at 5:52 PM Yegor Yefremov > > > <yegorslists@xxxxxxxxxxxxxx> wrote: > > > > On Thu, May 12, 2022 at 12:20 PM Yegor Yefremov > > > > <yegorslists@xxxxxxxxxxxxxx> wrote: > > > > > On Thu, May 12, 2022 at 10:43 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > > > > > > > On Thu, May 12, 2022 at 7:41 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220511 14:16]: > > > > > > > > On Thu, May 5, 2022 at 7:08 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > > > > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220504 10:35]: > > > > > > > > > > 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 :) PIO is always the last resort :-) And now it proves it again. With PIO_ONLY the system doesn't stall. Regards, Yegor > > > > > > 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. > > > > > 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
