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=-1.8 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 EB77EC432C0 for ; Fri, 29 Nov 2019 20:53:54 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7DC3921736 for ; Fri, 29 Nov 2019 20:53:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gevrMVLy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DC3921736 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1ianGb-00056Z-R5; Fri, 29 Nov 2019 15:53:29 -0500 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1iXpoF-0006OD-Vc for kernelnewbies@kernelnewbies.org; Thu, 21 Nov 2019 12:00:00 -0500 Received: by mail-wr1-x435.google.com with SMTP id s5so5350307wrw.2 for ; Thu, 21 Nov 2019 08:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:reply-to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=jLq5sxyeMH3WAhDyLYU4tMeXiWPGYD1GxpwgdHrNWxw=; b=gevrMVLyTH/5XjGdrnNex4QzMmJNm1dsNRGqDFroor+/wy1vQW/aUvsTZsrBvNFYWB CztlpctR8F1FRBj5jKR7XW9KQKgn+2Rxo1KJcGFxja1JmuW/10eU2ha6ZtsGNnnzE41/ qUhtg++Wp+bgF4N91z3jhJ9RuIIOFejd6q7SCD3PG2srmnaFBjRH4Xa8pc99AD2vYgiJ UldUdqacRMUGNhoaQH/hAdfIUE7czd6PzMTMX2PvFSGgeXT+Y+Kr/7LDD3EWwxn7omjJ mvh94FbGR/I7RtQ2iH2K9NIL3IL8l3ipTmr7696/9ioCj2E/ihLey7HOQ42AB877X8sv boKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:reply-to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=jLq5sxyeMH3WAhDyLYU4tMeXiWPGYD1GxpwgdHrNWxw=; b=CFOnda9Z1Fy4b75nJlEnhSdO8N+JBpcFOyxg224oby25gqmog1pkfJ776z+Yc2PDuI 3mOcsTRxiovpVaVPAE9rR1yyicK66KrX1GfSenwUyKFlLCi63ujkSA+mv9AF9X+B5HZw zkIHaKnqkwzogrq2haK9D/LIMpAgFSH6kPShT3Irf/psXHyf784bnzWBCLJY1M7/t7tY FZBryfHIhCX0evqfX/88HOcbaD+ykl6+MMOHgGF18e7QDf5C1xcD1J5Ft1L32xMZfWR4 oiWLtW1xngyiCUtkNiucu9v2vWs4BS9JD8ZqF+3o7uCOiflkNE9KoEdWTLz3CfMGKq5A ekGQ== X-Gm-Message-State: APjAAAXUQ6YAHViKaagHDwxlrUNCArDaUO7nfttwbR96hdSuPHPlXPJY HqicsrO29+Lh3QeAhWeofanSn9EL X-Google-Smtp-Source: APXvYqy7Nyytzos1XMcno9jVNDNUUqy6G3mRKRJaDhHaDPbKPqb3+2ITCWMCc7kbztmH+mIxpDk3mA== X-Received: by 2002:a5d:6104:: with SMTP id v4mr11640868wrt.36.1574355596948; Thu, 21 Nov 2019 08:59:56 -0800 (PST) Received: from [192.168.1.20] (46-54-243-84.static.kate-wing.si. [46.54.243.84]) by smtp.googlemail.com with ESMTPSA id b3sm206610wmj.44.2019.11.21.08.59.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 08:59:55 -0800 (PST) To: kernelnewbies@kernelnewbies.org From: Primoz Beltram Subject: I2C bus driver TIMEDOUT because of PM autosuspend Message-ID: <83466c12-9329-dbee-1751-6f7717210f4f@gmail.com> Date: Thu, 21 Nov 2019 17:59:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Language: en-GB X-Mailman-Approved-At: Fri, 29 Nov 2019 15:53:27 -0500 X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: primoz.beltram@gmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kernelnewbies-bounces@kernelnewbies.org I am analysing a problem with I2C bus driver where the problem shows up as I2C bus completely blocked. The LX driver in question is /drivers/i2c/busses/i2c-xiic.c. Problem is difficult to reproduce, it happens very rarely. So far I saw that the main precondition is to have very heavy I2C traffic on bus. In my case this is achieved/reproduced via netdev driving SFP LEDs via /sys/class/leds/ (via gpio-pca953x). I generate traffic with iperf3. Network traffic is on 10Gbps EMAC. LX kernel is 4.14.0. What I saw from debugging this problem is that I2C bus get blocked when wait_event_timeout() completes because of timeout. The timeout handling in this driver is probably not robust enough (bus should not remain blocked), but at this moment this are just my speculations (don't know enough details). Looking the driver code and data on oscilloscope, I saw that SCL in single I2C data transfer sequence can be interrupted for very long delays, e.g up to hundredths of usec (SCL is 100kHz). I started to suspect that PM autosuspend delay could play some role here. There are only two delays in driver code, first in wait_event_timeout and second in set autosuspend delay. Case is a bit strange because in very busy I2C traffic, PM autosuspend should not be triggered at all. Additionally, if I lower PM timeout, e.g. from 1000 (default) to 100, I hit the problem sooner (waits for problem hit are in order of n*10minutes). It looks to me that PM autosupend is playing some role here. Power management options in my .config: # CONFIG_SUSPEND is not set # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y I intentionally did not put all detail descriptions of embedded system and test setup here (long list), because the main reason of this post is: The workaround that works for me/customer (at the moment) is to disable PM autosuspend in the driver code, either by incerementing PM delay from 1000 to 10000 or by disabling autosuspend (comment out call to pm_runtime_put_autosuspend() in xiic_xfer()). But, I would like to expose/discuss this issue (maintainer of the code, or others). The reason/source of the problem can be much more complex and in some other place. So my question is who should I contact, is this the M: in the MAINTAINERS list, the MODULE_AUTHOR, ...? How to proceed. WBR Primoz _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies