On Thu, Jan 26, 2012 at 10:49:47AM +0100, Arend van Spriel wrote:

quoted

quoted

quoted

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.

Just a wild guess: it seems that we're affected using different HW
configs with different USB devices, so it would indicate that usb
autopm is the culprit.

Except Arend, all other users reporting that have ums_realtek, so they
hit that driver issue. I just posted ums_realtek fix.

Arend issue is different, it happens on different kernel version 3.3-rc1 vs 3.2.

Stanislaw