Scheduling while atomic (2.6.10-rc3-bk13)

Scheduling while atomic (2.6.10-rc3-bk13)

[Lukas Hejtmanek]

Hello,

when suspending to disk I got:
scheduling while atomic: suspenddisk.sh/0x00000001/1452
[<c031dc81>] schedule+0x4b3/0x563
[<c031e170>] schedule_timeout+0x5d/0xab
[<c011e9e5>] process_timeout+0x0/0x9
[<c011edbd>] msleep+0x2c/0x34
[<df8303cb>] ehci_hub_resume+0xed/0x1de [ehci_hcd]
[<c025885f>] usb_resume_device+0x80/0xc7
[<c021dc2e>] dpm_resume+0xa2/0xa4
[<c021dc41>] device_resume+0x11/0x1e
[<c0130485>] finish+0x8/0x3a
[<c013058e>] pm_suspend_disk+0x3e/0x73
[<c012ecfa>] enter_state+0x6e/0x72
[<c012ee18>] state_store+0xa4/0xb7
[<c0184441>] subsys_attr_store+0x34/0x3d
[<c01846c0>] flush_write_buffer+0x3e/0x4a
[<c018473b>] sysfs_write_file+0x6f/0x7e
[<c01846cc>] sysfs_write_file+0x0/0x7e
[<c01504ec>] vfs_write+0xf4/0x12f
[<c014fa31>] filp_close+0x52/0x96
[<c01505f8>] sys_write+0x51/0x80
[<c010306f>] syscall_call+0x7/0xb

-- 
Lukáš Hejtmánek

Re: Scheduling while atomic (2.6.10-rc3-bk13)

[Greg KH]

On Mon, Dec 20, 2004 at 12:10:15AM +0100, Lukas Hejtmanek wrote:
> Hello,
> 
> when suspending to disk I got:
> scheduling while atomic: suspenddisk.sh/0x00000001/1452
> [<c031dc81>] schedule+0x4b3/0x563
> [<c031e170>] schedule_timeout+0x5d/0xab
> [<c011e9e5>] process_timeout+0x0/0x9
> [<c011edbd>] msleep+0x2c/0x34
> [<df8303cb>] ehci_hub_resume+0xed/0x1de [ehci_hcd]
> [<c025885f>] usb_resume_device+0x80/0xc7
> [<c021dc2e>] dpm_resume+0xa2/0xa4
> [<c021dc41>] device_resume+0x11/0x1e
> [<c0130485>] finish+0x8/0x3a
> [<c013058e>] pm_suspend_disk+0x3e/0x73
> [<c012ecfa>] enter_state+0x6e/0x72
> [<c012ee18>] state_store+0xa4/0xb7
> [<c0184441>] subsys_attr_store+0x34/0x3d
> [<c01846c0>] flush_write_buffer+0x3e/0x4a
> [<c018473b>] sysfs_write_file+0x6f/0x7e
> [<c01846cc>] sysfs_write_file+0x0/0x7e
> [<c01504ec>] vfs_write+0xf4/0x12f
> [<c014fa31>] filp_close+0x52/0x96
> [<c01505f8>] sys_write+0x51/0x80
> [<c010306f>] syscall_call+0x7/0xb

David, it looks like you grab a spinlock, and then call msleep(20);
which causes this warning.

Care to fix it?

thanks,

greg k-h

Re: Scheduling while atomic (2.6.10-rc3-bk13)

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Monday 20 December 2004 10:48 am, Greg KH wrote:

> 
> David, it looks like you grab a spinlock, and then call msleep(20);
> which causes this warning.
> 
> Care to fix it?

How bizarre ... I must have been tested that without spinlock
debugging, for some reason.  Grr.  I usually leave that on,
just to prevent stuff like this.

Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
not mdelay for that long, but this late in 2.6.10 it's safer.
(And this is also what OHCI does in that same code path.)

- Dave


[-- Attachment #2: Diff --]
[-- Type: text/x-diff, Size: 365 bytes --]

--- 1.43/drivers/usb/host/ehci-hub.c	Fri Dec 17 18:57:39 2004
+++ edited/drivers/usb/host/ehci-hub.c	Mon Dec 20 11:48:01 2004
@@ -122,7 +122,7 @@
 		writel (temp, &ehci->regs->port_status [i]);
 	}
 	i = HCS_N_PORTS (ehci->hcs_params);
-	msleep (20);
+	mdelay (20);
 	while (i--) {
 		temp = readl (&ehci->regs->port_status [i]);
 		if ((temp & PORT_SUSPEND) == 0)

Re: Scheduling while atomic (2.6.10-rc3-bk13)

[Lee Revell]

On Mon, 2004-12-20 at 11:52 -0800, David Brownell wrote:
> On Monday 20 December 2004 10:48 am, Greg KH wrote:
> 
> > 
> > David, it looks like you grab a spinlock, and then call msleep(20);
> > which causes this warning.
> > 
> > Care to fix it?
> 
> How bizarre ... I must have been tested that without spinlock
> debugging, for some reason.  Grr.  I usually leave that on,
> just to prevent stuff like this.
> 
> Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
> not mdelay for that long, but this late in 2.6.10 it's safer.
> (And this is also what OHCI does in that same code path.)

Ugh.  20ms is WAY too long to hold a spinlock.  That's guaranteed to
cause audio skips.  Isn't there another way?

If OHCI calls mdelay(20) while holding a spinlock that needs to be
fixed.

Lee

Re: [linux-usb-devel] Re: Scheduling while atomic (2.6.10-rc3-bk13)

[David Brownell]

On Monday 20 December 2004 12:57 pm, Lee Revell wrote:
> On Mon, 2004-12-20 at 11:52 -0800, David Brownell wrote:
> > Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
> > not mdelay for that long, but this late in 2.6.10 it's safer.
> > (And this is also what OHCI does in that same code path.)
> 
> Ugh.  20ms is WAY too long to hold a spinlock.  That's guaranteed to
> cause audio skips.

During system resume?  :)

Anyone trying to use audio devices during system resume
probably deserves what they get, just now.  Best for them
to wait until after the system finishes resuming before
they start playing audio again.  (Over for example the
USB speaker hookup they were using... which has been
suspended for more than 20msec already!)


> Isn't there another way?
> 
> If OHCI calls mdelay(20) while holding a spinlock that needs to be
> fixed.

Eventually this is worth fixing ... after Linux behaves
sanely with selective device suspend/resume.

So for example, with PCI devices it sure _ought_ to be
reasonable to put devices into PCI_D3hot state, with
other active devices in PCI_D0 state and the CPU running
in C0 (or C1, C2, C3 as appropriate) ... and then rely
on ACPI to handle the device signaling PME# sanely,
by resuming the device issuing that signal.  (And to
do similar things for non-PCI/non-ACPI systems, too.)

Until then, there's no real point in trying to rework
those parts of usbcore to support selective resume
of HCDs.  Such code would never be used, and those
changes would conflict with more important work that's
going on.  (Both in terms of lines-of-code changing,
and in terms of opportunity costs.)

On the other hand, if you want to help fix all that,
we'd sure like to see your patches!

- Dave

Re: [linux-usb-devel] Re: Scheduling while atomic (2.6.10-rc3-bk13)

[Lee Revell]

On Mon, 2004-12-20 at 13:31 -0800, David Brownell wrote:
> On Monday 20 December 2004 12:57 pm, Lee Revell wrote:
> > On Mon, 2004-12-20 at 11:52 -0800, David Brownell wrote:
> > > Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
> > > not mdelay for that long, but this late in 2.6.10 it's safer.
> > > (And this is also what OHCI does in that same code path.)
> > 
> > Ugh.  20ms is WAY too long to hold a spinlock.  That's guaranteed to
> > cause audio skips.
> 
> During system resume?  :)
> 

Sorry, should have read the whole thread ;-)

Lee

Re: Scheduling while atomic (2.6.10-rc3-bk13)

[Greg KH]

On Mon, Dec 20, 2004 at 11:52:16AM -0800, David Brownell wrote:
> On Monday 20 December 2004 10:48 am, Greg KH wrote:
> 
> > 
> > David, it looks like you grab a spinlock, and then call msleep(20);
> > which causes this warning.
> > 
> > Care to fix it?
> 
> How bizarre ... I must have been tested that without spinlock
> debugging, for some reason.  Grr.  I usually leave that on,
> just to prevent stuff like this.
> 
> Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
> not mdelay for that long, but this late in 2.6.10 it's safer.
> (And this is also what OHCI does in that same code path.)

Applied, thanks.

greg k-h