> > What's the purpose of the card-counting loop in
> > host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
> >
>
> I'm not too familiar with that driver, but they've been playing around
> with multiplexing several cards into one controller. Might be bits and
> pieces of that.
>
AFAI
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> > What do you think of the patch attached to comment #40 in the Bugzilla
> > entry?
> >
>
> Looks ok. As long as those two synchronization points are guaranteed,
> then I'm happy.
Maybe a better approach would be to leave the workqueue unfreezable,
a
On Mon, 25 Feb 2008 12:58:30 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> Thanks for the explanations.
>
> On Mon, 25 Feb 2008, Pierre Ossman wrote:
>
> > Trying to keep up with the PM changes is a full time job. For now I've
> > mostly ignored it as I don't even have time for the other s
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> Trying to keep up with the PM changes is a full time job. For now I've
> mostly ignored it as I don't even have time for the other stuff.
> Patches welcome.
What do you think of the patch attached to comment #40 in the Bugz
On Sun, 24 Feb 2008 10:33:34 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Well, the patch itself isn't really adequate; it was just a first pass
> intended to illustrate the nature of the problem.
>
> The problems in the MMC subsystem go deeper.
>
> The first is the way it uses flush_
On Mon, 25 Feb 2008, Pavel Machek wrote:
> Hi!
>
> Alan thinks that `subj` is correct...
More precisely, reads and writes of pointers are always atomic. That
is, if a write and a read occur concurrently, it is guaranteed that the
read will obtain either the old or the new value of the pointer
On Monday, 25 of February 2008, Zdenek Kabelac wrote:
> Hi
Hi,
[CCs restored, added CC to Dave]
> I'm finally going to test some kernel - because I'd been trying it
> against the HEAD - but unfortunately it looks like there is something
> seriously broken with -rc3 and sata merge - anyway - I'm
On Monday, 25 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > > Very subtly wrong ;-).
> > >
> > > imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> > > 0xabcd reads suspending_task while the other cpu is writing to it,
> > > and s
On Monday, 25 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Pavel Machek wrote:
>
> > > > At the very least, you'd need rmb() before reading it and wmb() after
> > > > writing to it, but I'm not sure if that's enough on every obscure
> > > > architecture out there.
> > >
> > > No, ne
Hi!
Alan thinks that `subj` is correct...
> > > > At the very least, you'd need rmb() before reading it and wmb() after
> > > > writing to it, but I'm not sure if that's enough on every obscure
> > > > architecture out there.
> > >
> > > No, neither one is needed because of the way suspending_ta
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > Very subtly wrong ;-).
> >
> > imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> > 0xabcd reads suspending_task while the other cpu is writing to it,
> > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly
>
On Sun, 24 Feb 2008, Pavel Machek wrote:
> > > At the very least, you'd need rmb() before reading it and wmb() after
> > > writing to it, but I'm not sure if that's enough on every obscure
> > > architecture out there.
> >
> > No, neither one is needed because of the way suspending_task is used.
On Sunday, 24 of February 2008, Pavel Machek wrote:
> On Sun 2008-02-24 15:33:01, Alan Stern wrote:
> > On Sun, 24 Feb 2008, Pavel Machek wrote:
> >
> > > > > What locking protects this variable? What happens when suspending_task
> > > > > exits? (Hmm, that would probably be bug, anyway?)
> > > >
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Remove the code that acquires all device semaphores from the suspend
> > code path as it causes multiple problems to appear (most notably,
>
On Sun 2008-02-24 15:33:01, Alan Stern wrote:
> On Sun, 24 Feb 2008, Pavel Machek wrote:
>
> > > > What locking protects this variable? What happens when suspending_task
> > > > exits? (Hmm, that would probably be bug, anyway?)
> > >
> > > It's protected by whatever existing locking scheme allows
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove the code that acquires all device semaphores from the suspend
> code path as it causes multiple problems to appear (most notably,
> http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert t
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Remove the code that acquires all device semaphores from the suspend
> > code path as it causes multiple problems to appear (most notably,
>
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove the code that acquires all device semaphores from the suspend
> code path as it causes multiple problems to appear (most notably,
> http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert t
On Sun, 24 Feb 2008, Pavel Machek wrote:
> > > What locking protects this variable? What happens when suspending_task
> > > exits? (Hmm, that would probably be bug, anyway?)
> >
> > It's protected by whatever existing locking scheme allows only one
> > task to start a system sleep at a time. For
On Sunday, 24 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Alan Stern wrote:
> > On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > > >
> > > > > Ultima
On Sunday, 24 of February 2008, Zdenek Kabelac wrote:
> 2008/2/24, Alan Stern <[EMAIL PROTECTED]>:
> > On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> >
> >
> > > > You know, with this new patch we probably don't need
> > > > device_pm_schedule_removal() any more.
> > >
> > > No, we don't. Howe
Hi!
> > > @@ -25,6 +25,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "../base.h"
> > > #include "power.h"
> > > @@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem);
> > >
> > > int (*platform_enable_wakeup)(struct device *dev, int is_on);
2008/2/24, Alan Stern <[EMAIL PROTECTED]>:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
>
> > > You know, with this new patch we probably don't need
> > > device_pm_schedule_removal() any more.
> >
> > No, we don't. However, because of that dpm_suspend() and
> device_power_down()
> > nee
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > You know, with this new patch we probably don't need
> > device_pm_schedule_removal() any more.
>
> No, we don't. However, because of that dpm_suspend() and device_power_down()
> need to be changed not to assume that the removed devices will end
On Sun, 24 Feb 2008, Pavel Machek wrote:
> Hi!
>
> > Index: usb-2.6/drivers/base/power/main.c
> > ===
> > --- usb-2.6.orig/drivers/base/power/main.c
> > +++ usb-2.6/drivers/base/power/main.c
> > @@ -25,6 +25,7 @@
> > #include
> >
Hi!
> Index: usb-2.6/drivers/base/power/main.c
> ===
> --- usb-2.6.orig/drivers/base/power/main.c
> +++ usb-2.6/drivers/base/power/main.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../base
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > In fact this turns out to be exactly the problem with the MMC
> > subsystem. It uses a dedicated workqueue (kmmcd) to handle state
> > changes, and mmc_suspend_host() does a flush_workqueue(). If the
> > workqueue contains an entry to register or
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Alan Stern wrote:
>
> > It happened in a workqueue. There could be lots of similar cases: Some
> > interrupt-driven event causes a hotplug action. Since the action can't
> > be carried out in interrupt context, the driver
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > > I still have no clear idea about what's going on with the ACPI bug in
> > > #9874.
>
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > >
> > > > Ultimately no, it's not. However, we are now late in the -rc2 time
> > > >
On Sat, 23 Feb 2008, Alan Stern wrote:
> It happened in a workqueue. There could be lots of similar cases: Some
> interrupt-driven event causes a hotplug action. Since the action can't
> be carried out in interrupt context, the driver has no choice but to
> defer it to a workqueue or kernel t
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Alan Stern wrote:
> > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > > and
> > > the release of -rc3 seems to be imminent. At th
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > and
> > the release of -rc3 seems to be imminent. At this point, IMO, that's the
> > safest thing to do. BTW, app
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Ultimately no, it's not. However, we are now late in the -rc2 time frame and
> the release of -rc3 seems to be imminent. At this point, IMO, that's the
> safest thing to do. BTW, appended is the patch I'd like to get applied.
In the interest of h
On Saturday, 23 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > Unfortunately, I missed your Bugzilla comment at
> > http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
>
> Strange... But obviously you did see it eventually.
>
> > Well, in the face of
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Unfortunately, I missed your Bugzilla comment at
> http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
Strange... But obviously you did see it eventually.
> Well, in the face of it, I'm considering to remove the code that
> acquires device semaph
On Friday, 22 of February 2008, Alan Stern wrote:
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > BTW, below is a simplified version of the patch, without the mutex
> > protecting
> > suspending_task. I'd like to push it upstream if it looks good.
>
> It does look good. Go ahead and push
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > > --- linux-2.6.orig/drivers/base/core.c
> > > +++ linux-2.6/drivers/base/core.c
> > > @@ -929,6 +929,11 @@ void device_del(struct device *dev)
> > > struct device *parent = dev->parent;
> > > struct class_interface *class_intf;
> > >
> > > +
On Thursday, 21 of February 2008, Alan Stern wrote:
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > > > +bool in_suspend_context(void)
> > > > +{
> > > > + bool result;
> > > > +
> > > > + mutex_lock(&suspending_task_mtx);
> > > > + result = (suspending_task == current);
>
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > > +bool in_suspend_context(void)
> > > +{
> > > + bool result;
> > > +
> > > + mutex_lock(&suspending_task_mtx);
> > > + result = (suspending_task == current);
> > > + mutex_unlock(&suspending_task_mtx);
> > > + return result;
> > > +}
> >
> > If
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>
> > Well, below is an uncompiled and untested but illustrating the idea that
> > might allow people not to bother with device_pm_schedule_removal()
> > explicitly and can fix the issue at hand.
>
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>
> > Well, below is an uncompiled and untested but illustrating the idea that
> > might allow people not to bother with device_pm_schedule_removal()
> > explicitly and can fix the issue at hand.
>
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> Well, below is an uncompiled and untested but illustrating the idea that
> might allow people not to bother with device_pm_schedule_removal()
> explicitly and can fix the issue at hand.
>
> [There are some cases that need handling and are not covere
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Pierre Ossman wrote:
>
> > > And why not simply fail the suspend if the resume routine doesn't exist
> > > and the suspend routine does? Maybe with an error message in the
> > > system log.
> >
> > For the asymmetric cas
On Wed, 20 Feb 2008, Pierre Ossman wrote:
> > And why not simply fail the suspend if the resume routine doesn't exist
> > and the suspend routine does? Maybe with an error message in the
> > system log.
>
> For the asymmetric case, I guess that would do. But I still want to remove
> devices whe
On Wednesday, 20 of February 2008, Pierre Ossman wrote:
> On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> >
> > Do I understand this correctly? You've got special handling for the
> > case where a bus handler doesn't have a resume routine, but no special
>
On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Do I understand this correctly? You've got special handling for the
> case where a bus handler doesn't have a resume routine, but no special
> handling for the case where it doesn't have a suspend routine?
Hmm.
On Wed, 20 Feb 2008, Pierre Ossman wrote:
> Not really. But you have some things confused. What it checks is if
> the mmc bus handler (not a proper driver model, just a way of
> separating the MMC, SD and SDIO stuff) has a resume function. And if
> it doesn't, it removes the card (since it cannot
On Wed, 20 Feb 2008 11:42:56 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
> > Thanks a lot for the debugging work!
> >
> > First, the patch triggers, which means that the problem discovered by Alan
> > is
> > trou
On Tue, 19 Feb 2008 [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10030
>
>
>
>
>
> --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
> Thanks a lot for the debugging work!
>
> First, the patch triggers, which means that the problem discovered by Al
50 matches
Mail list logo
