Hi Greg,
Please drop
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
that deadlocks suspend and hibernation on some systems, and apply the appended
$subject patch (which provides the equivalent functionality and introduces
safeguards against deadlocking in the relevant cases) ins
On Fri, 11 Jan 2008, Rafael J. Wysocki wrote:
> Hi,
>
> The patch below is intended as a replacement for
> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that
> deadlocked
> suspend and hibernation on some systems. Â The present patch contains some
> safeguards against deadlocks
Hi,
The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems. The present patch contains some
safeguards against deadlocks in the relevant cases and a mechanism to print
warnings if a d
On Thu, 10 Jan 2008, Rafael J. Wysocki wrote:
> > > > > > Also, the kerneldoc for destroy_suspended_device() should contain
> > > > > > an
> > > > > > extra paragraph warning that the routine should never be called
> > > > > > except
> > > > > > within the scope of a system sleep transition.
On Thursday, 10 of January 2008, Alan Stern wrote:
> On Thu, 10 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Wednesday, 9 of January 2008, Alan Stern wrote:
> > > On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> >
On Thu, 10 Jan 2008, Rafael J. Wysocki wrote:
> On Wednesday, 9 of January 2008, Alan Stern wrote:
> > On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> > > > the list_move_tail() comes before the resume_device(). It
On Wednesday, 9 of January 2008, Alan Stern wrote:
> On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
>
> > > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> > > the list_move_tail() comes before the resume_device(). It's the same
> > > as in dpm_power_up().
> >
> > Still, d
On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
> > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> > the list_move_tail() comes before the resume_device(). It's the same
> > as in dpm_power_up().
>
> Still, device_pm_schedule_removal() can (in theory) be called concurrentl
On Wednesday, 9 of January 2008, Alan Stern wrote:
> On Tue, 8 Jan 2008, Rafael J. Wysocki wrote:
>
> > Appended is what I managed to put together today.
> >
> > It probably still has some problems, but I'm not seeing them right now (too
> > tired). At least, it doesn't break my system. ;-)
> >
On Tue, 8 Jan 2008, Rafael J. Wysocki wrote:
> Appended is what I managed to put together today.
>
> It probably still has some problems, but I'm not seeing them right now (too
> tired). At least, it doesn't break my system. ;-)
>
> Please review.
Okay, this seems to be better. I like the way
On Monday, 7 of January 2008, Alan Stern wrote:
> On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
[--snip--]
>
> > Okay, well, now I'm leaning towards the asynchronous approach.
> >
> > I'll prepare a new patch and send it later today.
>
> Okay.
Appended is what I managed to put together today.
I
On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
> > > Do you mean it might have been released already by another thread
> > > calling device_pm_destroy_suspended() on the same device?
> >
> > I was thinking that it might be called before lock_all_devices().
>
> I've added pm_sleep_start_end_mtx and
On Monday, 7 of January 2008, Alan Stern wrote:
> On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Monday, 7 of January 2008, Alan Stern wrote:
> > > On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > Please see the patch at: http://lkml.org/lkml/2008/1/6/298 . It
> > > > represent
On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Alan Stern wrote:
> > On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > Please see the patch at: http://lkml.org/lkml/2008/1/6/298 . It
> > > represents my
> > > current idea about how to do that.
> >
> > It has
On Monday, 7 of January 2008, Alan Stern wrote:
> On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
>
> > Please see the patch at: http://lkml.org/lkml/2008/1/6/298 . It represents
> > my
> > current idea about how to do that.
>
> It has some problems.
>
> First, note that the list manipulations in
On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
> Please see the patch at: http://lkml.org/lkml/2008/1/6/298 . It represents my
> current idea about how to do that.
It has some problems.
First, note that the list manipulations in dpm_suspend(),
device_power_down(), and so on aren't protected by d
On Monday, 7 of January 2008, Alan Stern wrote:
> Let's try to summarize the main issues here:
>
> 1. We want the PM core to lock all devices during suspend and
> hibernation. This implies that registration and unregistration
> at such times can't work, because they need to lock
Let's try to summarize the main issues here:
1. We want the PM core to lock all devices during suspend and
hibernation. This implies that registration and unregistration
at such times can't work, because they need to lock the
device sem in order to make probe and remo
Hi,
The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems. The present patch contains some
safeguards against deadlocks in that cases and a mechanism to print warnings
if a deadlock
On Monday, 7 of January 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Johannes Berg wrote:
> > Rafael J. Wysocki wrote:
> >
> > >> I don't see anything wrong with it. All that will happen is that the
> > >> removal will start before the suspend and finish after the resume.
> > >
On Monday, 7 of January 2008, Johannes Berg wrote:
> Rafael J. Wysocki wrote:
>
> >> I don't see anything wrong with it. All that will happen is that the
> >> removal will start before the suspend and finish after the resume.
> >
> > In that case, we'll attempt to call the device's .suspend() and
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > > No -- the whole idea here is to print an error message in the system
> > > log if a driver's resume method tries to call device_del(). Deadlock
> > > is unavoidable in this case, but at least w
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > No -- the whole idea here is to print an error message in the system
> > log if a driver's resume method tries to call device_del(). Deadlock
> > is unavoidable in this case, but at least we'll know which driver is
> > guilty.
>
> Still, if we d
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > > Still, shouldn't we fail the removal of the device apart from giving the
> > > warning?
> >
> > Actually, having thought about it a bit more, I don't see the point in
> > preventing the removal
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> Still, our present approach doesn't seem to be correct overall. For example,
> I think we should prevent a suspend from happening while a device is being
> removed.
We could, however I don't think it's dangerous to allow it. The two
problems to avo
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 6 of January 2008, Alan Stern wrote:
>
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
>
> We can't. device_del() can't fail -- it returns vo
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
>
> Actually, having thought about it a bit more, I don't see the point in
> preventing the removal of the device from the list in device_pm_remove() if
> we allo
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> > On Sunday, 6 of January 2008, Alan Stern wrote:
> > > On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > If you can figure out a way to disable the warning in device_del()
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Alan Stern wrote:
> Still, shouldn't we fail the removal of the device apart from giving the
> warning?
We can't. device_del() can't fail -- it returns void. Besides, how
can a driver hope to deal with an unregistrat
On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Alan Stern wrote:
> > On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > > If you can figure out a way to disable the warning in device_del() for
> > > > just the one device being unregistered by
> > > > d
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
>
> > > If you can figure out a way to disable the warning in device_del() for
> > > just the one device being unregistered by
> > > device_pm_destroy_suspended(),
> >
> > Something like this, perhaps
On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > If you can figure out a way to disable the warning in device_del() for
> > just the one device being unregistered by
> > device_pm_destroy_suspended(),
>
> Something like this, perhaps:
>
> @@ -905,6 +915,18 @@ void device_del(struct device * de
On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Saturday, 5 of January 2008, Alan Stern wrote:
> > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > > > Still, even doing that is not enough, since someone can call
> > > > destroy_suspende
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> On Saturday, 5 of January 2008, Alan Stern wrote:
> > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > > Still, even doing that is not enough, since someone can call
> > > destroy_suspended_device() from a .suspend() routine and then the device
> > >
On Saturday, 5 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > On Saturday, 5 of January 2008, Alan Stern wrote:
> > > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > > Another thing to watch out for: Just in case somebody ends up calling
> > > >
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> On Saturday, 5 of January 2008, Alan Stern wrote:
> > On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> >
> > > > Another thing to watch out for: Just in case somebody ends up calling
> > > > destroy_suspended_device(dev) from within dev's own resume me
On Saturday, 5 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > > Another thing to watch out for: Just in case somebody ends up calling
> > > destroy_suspended_device(dev) from within dev's own resume method, you
> > > should interchange the resume_device()
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> > Another thing to watch out for: Just in case somebody ends up calling
> > destroy_suspended_device(dev) from within dev's own resume method, you
> > should interchange the resume_device() and the list_move_tail()
> > calls in dpm_resume().
>
> Ho
On Saturday, 5 of January 2008, Alan Stern wrote:
> On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
>
> > Greg, Andrew,
> >
> > The appended patch is a replacement for
> > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that
> > deadlocked
> > suspend and hibernation on some systems
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
> Greg, Andrew,
>
> The appended patch is a replacement for
> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that
> deadlocked
> suspend and hibernation on some systems.
>
> Please consider for applying.
This warning message:
> @@
Greg, Andrew,
The appended patch is a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems.
Please consider for applying.
Thanks,
Rafael
---
From: Alan Stern <[EMAIL PROTECTED]>, Rafael J. Wysocki <[EMAIL PROTECT
On Friday, 4 of January 2008, Rafael J. Wysocki wrote:
> On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> > On Wednesday, 2 of January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Rafael J. Wysocki wrote:
> > >
> > > > On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
> > >
42 matches
Mail list logo
