Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752817AbcD0C4F (ORCPT ); Tue, 26 Apr 2016 22:56:05 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:36811 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbcD0C4D (ORCPT ); Tue, 26 Apr 2016 22:56:03 -0400 MIME-Version: 1.0 In-Reply-To: References: <1454107764-19876-1-git-send-email-stefan@agner.ch> <20160421034520.GA19965@shlinux2.ap.freescale.net> <20160426012341.GB8870@tiger> <1461663072.7839.17.camel@pengutronix.de> <20160427015835.GE30692@tiger> Date: Tue, 26 Apr 2016 23:56:01 -0300 Message-ID: Subject: Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled From: Fabio Estevam To: Dong Aisheng Cc: Shawn Guo , Lucas Stach , Michael Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , Stefan Agner , mingo@redhat.com, "kernel@pengutronix.de" , Thomas Gleixner , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1760 Lines: 52 On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> We need to firstly understand why this is happening. The .prepare hook >> is defined to be non-atomic context, and so that we call sleep function >> in there. We did everything right. Why are we getting the warning? If >> I'm correct, this warning only happens on i.MX7D. Why is that? >> > > This is mainly caused by during kernel early booting, there's only one init idle > task running. > See: > void __init sched_init(void) > { > ..... > /* > * Make us the idle thread. Technically, schedule() should not be > * called from this thread, however somewhere below it might be, > * but because we are the idle thread, we just pick up running again > * when this runqueue becomes "idle". > */ > init_idle(current, smp_processor_id()); > ... > } > > And the idle sched class indicates it's not valid to schedule for idle task. > const struct sched_class idle_sched_class = { > /* .next is NULL */ > /* no enqueue/yield_task for idle tasks */ > > /* dequeue is not valid, we print a debug message there: */ > .dequeue_task = dequeue_task_idle, > ........... > > } > > /* > * It is not legal to sleep in the idle task - print a warning > * message if some code attempts to do it: > */ > static void > dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags) > { > raw_spin_unlock_irq(&rq->lock); > printk(KERN_ERR "bad: scheduling from the idle thread!\n"); > dump_stack(); > raw_spin_lock_irq(&rq->lock); > } > > > Below is the full log of imx7d booting FYI. This does not answer Shawn's question: why do we see this only on mx7d?