From patchwork Tue Jun 14 20:32:41 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrei Warkentin X-Patchwork-Id: 880032 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p5EKWiQQ016920 for ; Tue, 14 Jun 2011 20:32:44 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753819Ab1FNUcn (ORCPT ); Tue, 14 Jun 2011 16:32:43 -0400 Received: from exprod5og104.obsmtp.com ([64.18.0.178]:56087 "EHLO exprod5og104.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753796Ab1FNUcn convert rfc822-to-8bit (ORCPT ); Tue, 14 Jun 2011 16:32:43 -0400 Received: from il93mgrg01.am.mot-mobility.com ([144.188.21.13]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKTffFaqpWaJ6jTxWuaN/X+BoO8x0CuUqg@postini.com; Tue, 14 Jun 2011 13:32:42 PDT Received: from il93mgrg01.am.mot-mobility.com ([10.22.94.168]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id p5EKTxWO019361 for ; Tue, 14 Jun 2011 16:29:59 -0400 (EDT) Received: from mail-px0-f169.google.com (mail-px0-f169.google.com [209.85.212.169]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id p5EKFXJb011204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 14 Jun 2011 16:29:58 -0400 (EDT) Received: by mail-px0-f169.google.com with SMTP id 9so4056057pxi.0 for ; Tue, 14 Jun 2011 13:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.222.18 with SMTP id u18mr1261404wfg.40.1308083561235; Tue, 14 Jun 2011 13:32:41 -0700 (PDT) Received: by 10.142.53.5 with HTTP; Tue, 14 Jun 2011 13:32:41 -0700 (PDT) In-Reply-To: <201106141610.42700.heiko@sntech.de> References: <201106022149.47936.heiko@sntech.de> <201106030956.43174.heiko@sntech.de> <201106141610.42700.heiko@sntech.de> Date: Tue, 14 Jun 2011 15:32:41 -0500 Message-ID: Subject: Re: irq flood with mmc boot partitions on s3c2416 with 3.0rc1 From: Andrei Warkentin To: =?ISO-8859-1?Q?Heiko_St=FCbner?= Cc: Kyungmin Park , linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-CFilter-Loop: Reflected Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Tue, 14 Jun 2011 20:32:44 +0000 (UTC) Hi Heiko, On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote: > Hi Andrei, > > Am Dienstag 14 Juni 2011 schrieb Andrei Warkentin: >> I recently came back from vacation (which is why I didn't pitch in >> before). Has there been any further update on this? I want to exclude >> my EMMC partitioning changes as the possible culprit here. > > nope, no updates yet. The flood also only starts when udev wants to > create its device nodes, meaning the initial detection seems not to > produce this problem > > But when I disable the whole boot partition stuff, it works as before > without irq storms. > > As there don't seem to exist reports from other emmc users about this > I guess the problem lays somewhere between the boot-partitions-patch > and the sdhci-s3c driver (for s3c2416 at least). > > As my knowledge about the whole mmc-subsystem is quite spare I also > don't really know where to start looking for the culprit yet. Alright. Curious. Can you let me know what eMMC device you are connecting to the controller? What is the eMMC revision? Can you also apply the following and let me know the results? This adds an error message if the partition switch fails, and forces the device to ALWAYS switch back to main user area after every completed RQ. >>>>>>>>>>>> start @@ -1325,10 +1326,13 @@ static int mmc_blk_resume(struct mmc_card *card) mmc_blk_set_blksize(md, card); /* - * Resume involves the card going into idle state, - * so current partition is always the main one. + * Force main user area on resume. Technically + * card should have switched itself during reset. */ - md->part_curr = md->part_type; + ret = mmc_blk_part_switch(card, md); + if (ret) + return ret; + mmc_queue_resume(&md->queue); list_for_each_entry(part_md, &md->part, part) { mmc_queue_resume(&part_md->queue); >>>>>>>>>>>>>>>>>>> end Thanks for helping tracking this down, A --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 71da564..74e1029 100755 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -450,9 +450,12 @@ static inline int mmc_blk_part_switch(struct mmc_card *card, ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONFIG, card->ext_csd.part_config, card->ext_csd.part_time); - if (ret) + if (ret) { + printk(KERN_ERR ">>> error switching to part_type %d\n", + md->part_type); return ret; -} + } + } main_md->part_curr = md->part_type; return 0; @@ -964,6 +967,13 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req) } out: + + /* Switch to main_md (type = 0) */ + ret = mmc_blk_part_switch(card, (struct mmc_blk_data *) mmc_get_drvdata(card)); + if (ret) { + ret = 0; + } + mmc_release_host(card->host); return ret; } >>>>>>>>>>>>>>>> end I am curious about the results. Here is another thing to try out. This forces a switch to user area (main partition) every time blk resume is invoked - >>>>>>>>>>>>>>>>>>> start diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 71da564..f7be8f7 100755 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -1318,6 +1318,7 @@ static int mmc_blk_suspend(struct mmc_card *card, pm_message_t state) static int mmc_blk_resume(struct mmc_card *card) { + int ret; struct mmc_blk_data *part_md; struct mmc_blk_data *md = mmc_get_drvdata(card);