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 X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0BEFC433DB for ; Wed, 24 Feb 2021 16:21:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9754964EDD for ; Wed, 24 Feb 2021 16:21:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232578AbhBXQVQ (ORCPT ); Wed, 24 Feb 2021 11:21:16 -0500 Received: from mxcwn13.webd.pl ([194.181.228.69]:37062 "EHLO mxcwn13.webd.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232949AbhBXQU2 (ORCPT ); Wed, 24 Feb 2021 11:20:28 -0500 X-Greylist: delayed 17685 seconds by postgrey-1.27 at vger.kernel.org; Wed, 24 Feb 2021 11:20:26 EST Received: from wn13.int.webd ([192.168.101.113] helo=wn13.webd.pl) by mta01.webd.pl with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lEsHr-0005vz-9l for linux-can@vger.kernel.org; Wed, 24 Feb 2021 12:24:59 +0100 Received: from [192.168.101.231] (port=45408 helo=mta01.int.webd) by wn13.webd.pl with esmtp (Exim 4.93) (envelope-from ) id 1lEsHr-0005DL-76 for linux-can@vger.kernel.org; Wed, 24 Feb 2021 12:24:59 +0100 X-Quarantine-ID: <7yOqngGKG_Gm> X-Virus-Scanned: amavisd-new at mxwn13.webd.pl Received: from wn13.webd.pl ([192.168.101.113]) by mta01.int.webd (mxwn13.webd.pl [192.168.101.200]) (amavisd-new, port 10134) with ESMTP id 7yOqngGKG_Gm for ; Wed, 24 Feb 2021 12:24:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xtrack.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UvujGglEUtXAHcPQWfT7nTB6HDaNso/Ri9rzb4oMUvE=; b=nGHo4sKex60knr2hiPRAgqlNf+ j9oioqLl1zbk7Z+hqt5SieIEAKwUasGcTLUT/2fxeONQzlLCoRuKGtuztwExA5UlIbW3YWd2bDj08 YBbZ4QOBMfJiO05L1tWCwoNojZNIbSuS4lkb2/FH5NSk28s4TOVORPW9Zj9efXh7W+GM4tCBxM2YE G+fPSGCTpLqHGccpSUMgHgnmZaz8RPzLEfjDfpAuWsPnvhSGGI4X44c9J/XQCDtgiXvESAJdHPxac iKsAnljz2Kpq3HjvkzW3ras5uo2p4SEHQ3yrUcy269gtSs8dII12No9XytaJRWz5YmQiHQ+kWxq+4 epu3QBAw==; Received: from [185.241.198.130] (port=56500 helo=[192.168.32.4]) by wn13.webd.pl with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lEsHq-0005D2-Ui for linux-can@vger.kernel.org; Wed, 24 Feb 2021 12:24:58 +0100 To: linux-can@vger.kernel.org From: Mariusz Madej Subject: m_can: a lot of 'Rx FIFO 0 Message Lost' in dmesg Message-ID: Date: Wed, 24 Feb 2021 12:24:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org Hi, I have a problem with m_can controller in my sama5d2 processor. Under heavy can traffic it happens that my device starts to report (dmesg): [   77.610000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.620000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.630000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.630000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.640000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.640000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.650000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.660000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost [   77.660000] m_can_platform f8054000.can can0: Rx FIFO 0 Message Lost what causes large load problem in my system. I think I have a clue what is going on but my kernel knowledge is low so i want You to tell me if I am right or not. So: The only place in m_can.c file, where interrupt register is cleared is function called when interrupt arrives static irqreturn_t m_can_isr(int irq, void *dev_id) { . .         /* ACK all irqs */         if (ir & IR_ALL_INT)                 m_can_write(cdev, M_CAN_IR, ir); . . } But when we enter 'NAPI mode' in heavy load we are never get to this function until load gets lower and interrupts are enabled again. In this situation, this code: static int m_can_do_rx_poll(struct net_device *dev, int quota) {         struct m_can_classdev *cdev = netdev_priv(dev);         u32 pkts = 0;         u32 rxfs;         rxfs = m_can_read(cdev, M_CAN_RXF0S);         if (!(rxfs & RXFS_FFL_MASK)) {                 netdev_dbg(dev, "no messages in fifo0\n");                 return 0;         }         while ((rxfs & RXFS_FFL_MASK) && (quota > 0)) {                 if (rxfs & RXFS_RFL)                         netdev_warn(dev, "Rx FIFO 0 Message Lost\n");                 m_can_read_fifo(dev, rxfs);                 quota--;                 pkts++;                 rxfs = m_can_read(cdev, M_CAN_RXF0S);         }         if (pkts)                 can_led_event(dev, CAN_LED_EVENT_RX);         return pkts; } will always have (rxfs & RXFS_RFL) == true until interrupt are enabled again. That is why we got so many messages in a row for so long time. So clearing RXFS_RFL bit after warning is issued could be a solution. Can You tell me if I am right?