All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arend van Spriel" <arend@broadcom.com>
To: "Josh Boyer" <jwboyer@gmail.com>
Cc: "Francis Moreau" <francis.moro@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	"Greg KH" <greg@kroah.com>
Subject: Re: kernel 3.2.1: BUG: scheduling while atomic: swapper/0/0/0x10000100
Date: Thu, 26 Jan 2012 10:04:58 +0100	[thread overview]
Message-ID: <4F21173A.9060405@broadcom.com> (raw)
In-Reply-To: <CA+5PVA4Cq5BRfKEa1uckVbtCGKhKmuw1tujQ19T3wk3c5CcsAQ@mail.gmail.com>

On 01/25/2012 05:49 PM, Josh Boyer wrote:
> On Wed, Jan 25, 2012 at 11:37 AM, Francis Moreau <francis.moro@gmail.com> wrote:
>> Hello,
>>
>> On Wed, Jan 25, 2012 at 1:11 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>
>>> We've had a few similar issues reported in Fedora yesterday after we
>>> rebased to 3.2.1.
>>
>> From which kernel did you rebase to 3.2.1 ?
> 
> Fedora 16 went from 3.1.9 to 3.2.1 earlier this week.  We hadn't been getting
> reports like this until 3.2.1 showed up.  I asked one of the reporters to try
> 3.2.0 and they say it recreates there still, so it seems the issue showed up
> with the 3.2 release.  One user managed to capture the trace below using a
> kernel with a variety of debug options turned on.  It isn't the same backtrace
> but it might be related.
> 
> backtrace:
> :BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:785
> :in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
> :1 lock held by swapper/0/0:
> : #0:  (&chip->rts51x_suspend_timer){+.-...}, at: [<ffffffff8108d711>]
> run_timer_softirq+0x111/0x600
> :Pid: 0, comm: swapper/0 Tainted: G        W    3.2.0-2.fc17.x86_64.debug #1
> :Call Trace:
> : <IRQ>  [<ffffffff8105ee7a>] __might_sleep+0x13a/0x1f0
> : [<ffffffffa00180b0>] ? rts51x_modi_suspend_timer+0x50/0x50 [ums_realtek]
> : [<ffffffff813fdee3>] __pm_runtime_idle+0xa3/0xb0
> : [<ffffffffa00180b0>] ? rts51x_modi_suspend_timer+0x50/0x50 [ums_realtek]
> : [<ffffffff8146ed30>] usb_autopm_put_interface+0x30/0x40

This trace seems to indicate what is wrong. At least for this one user.
The usb_autopm_put_interface() call seems result in a sleep and the
rts51x_suspend_timer_fn is holding a lock. Below the code indicated in
the trace.

runtime.c:
768 /**
769  * __pm_runtime_idle - Entry point for runtime idle operations.
770  * @dev: Device to send idle notification for.
771  * @rpmflags: Flag bits.
772  *
773  * If the RPM_GET_PUT flag is set, decrement the device's usage
count and
774  * return immediately if it is larger than zero.  Then carry out an idle
775  * notification, either synchronous or asynchronous.
776  *
777  * This routine may be called in atomic context if the RPM_ASYNC
flag is set,
778  * or if pm_runtime_irq_safe() has been called.
779  */
780 int __pm_runtime_idle(struct device *dev, int rpmflags)
781 {
782         unsigned long flags;
783         int retval;
784
785         might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);

This issue can either be caused in ums_realtek module or the usb autopm
code. Have not looked into that.

Gr. AvS


  reply	other threads:[~2012-01-26  9:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24 15:59 kernel 3.2.1: BUG: scheduling while atomic: swapper/0/0/0x10000100 Francis Moreau
2012-01-25  8:17 ` Arend van Spriel
2012-01-25  8:35   ` Francis Moreau
2012-01-25 10:00     ` Arend van Spriel
2012-01-25 12:11       ` Josh Boyer
2012-01-25 16:37         ` Francis Moreau
2012-01-25 16:49           ` Josh Boyer
2012-01-26  9:04             ` Arend van Spriel [this message]
2012-01-26  9:16               ` Francis Moreau
2012-01-26  9:49                 ` Arend van Spriel
2012-01-26 11:29                   ` [PATCH] USB: Realtek cr: fix autopm scheduling while atomic Stanislaw Gruszka
2012-01-26 11:34                   ` kernel 3.2.1: BUG: scheduling while atomic: swapper/0/0/0x10000100 Stanislaw Gruszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F21173A.9060405@broadcom.com \
    --to=arend@broadcom.com \
    --cc=francis.moro@gmail.com \
    --cc=greg@kroah.com \
    --cc=jwboyer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.