From patchwork Wed Nov 18 13:23:41 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Norbert van Bolhuis X-Patchwork-Id: 38744 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 4DB2DB6EF1 for ; Thu, 19 Nov 2009 00:25:54 +1100 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1NAkVj-0002mJ-4h; Wed, 18 Nov 2009 13:23:51 +0000 Received: from smtp-vbr9.xs4all.nl ([194.109.24.29]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1NAkVb-0002kC-OO for linux-mtd@lists.infradead.org; Wed, 18 Nov 2009 13:23:48 +0000 Received: from mail3.aimsys.nl (a80-127-156-242.adsl.xs4all.nl [80.127.156.242]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id nAIDNfNq001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Nov 2009 14:23:42 +0100 (CET) (envelope-from nvbolhuis@aimvalley.nl) Received: from linpc062.aimsys.nl (linpc062.aimsys.nl [10.10.4.142]) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id nAIDNfMi017207; Wed, 18 Nov 2009 14:23:41 +0100 Received: from linpc062.aimsys.nl (localhost.localdomain [127.0.0.1]) by linpc062.aimsys.nl (8.14.1/8.13.1) with ESMTP id nAIDNfKr012116; Wed, 18 Nov 2009 14:23:41 +0100 Received: (from nvbolhuis@localhost) by linpc062.aimsys.nl (8.14.1/8.14.1/Submit) id nAIDNf94012115; Wed, 18 Nov 2009 14:23:41 +0100 Date: Wed, 18 Nov 2009 14:23:41 +0100 From: Norbert van Bolhuis Message-Id: <200911181323.nAIDNf94012115@linpc062.aimsys.nl> To: linux-mtd@lists.infradead.org Subject: [PATCH] add FAQ entry for "task pdflush:110 blocked for more than 120 seconds" X-Virus-Scanned: by XS4ALL Virus Scanner X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20091118_082344_441843_619D000B X-CRM114-Status: GOOD ( 11.95 ) X-Spam-Score: 0.0 (/) X-Spam-Report: SpamAssassin version 3.2.5 on bombadil.infradead.org summary: Content analysis details: (0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- _SUMMARY_ Cc: nvbolhuis@aimvalley.nl X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org This FAQ entry explains the possible relationship with the warning "INFO: task pdflush:110 blocked for more than 120 seconds" and the UBI background thread. Signed-off-by: Norbert van Bolhuis --- faq/ubifs.xml | 28 ++++++++++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/faq/ubifs.xml b/faq/ubifs.xml index 9a731c1..84a79d7 100644 --- a/faq/ubifs.xml +++ b/faq/ubifs.xml @@ -39,6 +39,7 @@
  • UBIFS suddenly became read-only - what is this?
  • I see this UBIFS error: "validate_sb: LEB size mismatch: 129024 in superblock, 126976 real"
  • I see this UBI error: "ubi_io_read: error -74 while reading 126976 bytes from PEB 47:4096, read 126976 bytes"
    • +
  • Is UBI/UBIFS related to this error: "INFO: task pdflush:110 blocked for more than 120 seconds"?
  • I want to study UBIFS - any recommendations?
    • @@ -1146,6 +1147,33 @@ them properly. In that case the -74 error happens when reading the first NAND page.

    +

    +Is UBI/UBIFS related to this error: "INFO: task pdflush:110 blocked for more than 120 seconds"? +

    + +

    There is a known case for which the UBI background thread is related. If you are using +NOR flash and UBI attaches to empty flash the UBI background thread will format it (only +this way it can allow using the entire UBI volume). Formatting means that for +each eraseblock it +

      +
    • erases (very slow on NOR!)
      • +
    • writes the UBI headers
      • +
    +Depending on your CFI/MTD chip driver the "MTD/CFI chip lock" may be held for the time +it needs to erase a block. +User-space applications which manipulate files may be blocked by the UBI background thread because +of the "MTD/CFI chip lock". This causes pdflush to block as well since it acquires the +UBIFS journal io_mutex that the application holds. See +this +mail thread for details. +There are two ways to solve this: +
      +
    1. ubiformat the entire NOR partition before UBI attaches
      2. +
    2. use erase-suspend for writing (if your chip supports this)
      3. +
    +

    + +

    I want to study UBIFS - any recommendations?