From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 263A2C433EF for ; Tue, 24 May 2022 14:19:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238127AbiEXOT3 (ORCPT ); Tue, 24 May 2022 10:19:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234426AbiEXOT2 (ORCPT ); Tue, 24 May 2022 10:19:28 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 456AB606C3; Tue, 24 May 2022 07:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 07E2A80B5; Tue, 24 May 2022 14:15:24 +0000 (UTC) Date: Tue, 24 May 2022 17:19:23 +0300 From: Tony Lindgren To: Yegor Yefremov Cc: Arnd Bergmann , Ard Biesheuvel , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM Subject: Re: am335x: 5.18.x: system stalling Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org * Yegor Yefremov [220524 13:34]: > Hi Arnd, > > On Sat, May 21, 2022 at 9:41 PM Arnd Bergmann wrote: > > > > On Thu, May 19, 2022 at 5:52 PM Yegor Yefremov > > wrote: > > > On Thu, May 12, 2022 at 12:20 PM Yegor Yefremov > > > wrote: > > > > On Thu, May 12, 2022 at 10:43 AM Arnd Bergmann wrote: > > > > > > > > > > On Thu, May 12, 2022 at 7:41 AM Tony Lindgren wrote: > > > > > > * Yegor Yefremov [220511 14:16]: > > > > > > > On Thu, May 5, 2022 at 7:08 AM Tony Lindgren wrote: > > > > > > > > * Yegor Yefremov [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 :) > > > > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0521C433EF for ; Tue, 24 May 2022 14:20:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vcii3mxXvmVHGAbrXincxGanGtLFyzQk9gUDiYZxwVk=; b=I3sENKn0aJ0oCc 1cTiU5EKo/Gu8hlMT26ypJL/dU42zc4Ab5yzSsXDjpOkczbpgGBIhqL8ypXUcOkaUE0/2OyV3b6AK kxM7waw68nA6ZuwWa48rWBw007Kz+Nm+2p4SmwnLC9W6uMNsCm5yHVSg7LlXoBO+PWT2ARMQ8NxoR 560AhIE2oe1jhH/pvrFWgzkgylWMdp77dzU6BizVRfM1zGuHrbXFqmvT3Yw/StlITMU2S2qg5Xso7 IXipNhfr7I7ERjQrysvHeBcda4aKd1e/Neue/3Fp8cpYYGiWtik/7HWsyHaUxvNBDm+HLHC0dZStV cIwvChUg6NsF5EOA8RMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntVNl-008ERM-6R; Tue, 24 May 2022 14:19:33 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntVNg-008EQd-BD for linux-arm-kernel@lists.infradead.org; Tue, 24 May 2022 14:19:32 +0000 Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 07E2A80B5; Tue, 24 May 2022 14:15:24 +0000 (UTC) Date: Tue, 24 May 2022 17:19:23 +0300 From: Tony Lindgren To: Yegor Yefremov Cc: Arnd Bergmann , Ard Biesheuvel , Linux-OMAP , linux-clk , Stephen Boyd , Linux ARM Subject: Re: am335x: 5.18.x: system stalling Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220524_071928_463923_58CDB4E4 X-CRM114-Status: GOOD ( 32.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Yegor Yefremov [220524 13:34]: > Hi Arnd, > > On Sat, May 21, 2022 at 9:41 PM Arnd Bergmann wrote: > > > > On Thu, May 19, 2022 at 5:52 PM Yegor Yefremov > > wrote: > > > On Thu, May 12, 2022 at 12:20 PM Yegor Yefremov > > > wrote: > > > > On Thu, May 12, 2022 at 10:43 AM Arnd Bergmann wrote: > > > > > > > > > > On Thu, May 12, 2022 at 7:41 AM Tony Lindgren wrote: > > > > > > * Yegor Yefremov [220511 14:16]: > > > > > > > On Thu, May 5, 2022 at 7:08 AM Tony Lindgren wrote: > > > > > > > > * Yegor Yefremov [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 :) > > > > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel