RFC: PNP: do not stop/start devices in suspend/resume path

RFC: PNP: do not stop/start devices in suspend/resume path

[Bjorn Helgaas]

Re: warning on suspend-to-RAM caused by
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
thread here: http://lkml.org/lkml/2007/11/22/110

On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
> I didn't get it. Maybe some trolls poking around or something (maybe the
> ext3 breakage which fsck fixed). It works after recompilation of the
> whole tree. And the important part -- the warning has gone.

Good.  It's not clear to me whether it is safe to leave devices
enabled while we sleep.  I don't see an actual problem, but there
might be something related to hotplug while we're asleep or something.
So I'll cc: some additional people who might have some insight.



RFC: PNP: do not stop/start devices in suspend/resume path

Do not disable PNP devices in the suspend path.  We still call
the driver's suspend method, which should prevent further use of
the device, and the protocol suspend method, which may put the
device in a low-power state.

This means we will not disable the device and release its
resources.  The driver suspend method typically does not release
its resources in the suspend path.  For example, if we have:

  03f8-03ff : 00:06
    03f8-03ff : serial

pnp_stop_dev() would release the 00:06 region, which still
has a child.  This causes a warning from __release_resource
and corrupts /proc/ioports.

However, we should do this the same way Windows does, so if
Windows disables devices before going to sleep, we should, too.
It doesn't *look* necessary to me because

  - In the ACPI 3.0b spec, I can't find any mention of _DIS in
    connection with sleep.  And Device Object Notifications,
    Section 5.6.3, Table 5-43, says we should get a bus check
    after awakening if hardware was removed while we slept.

    This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
    makes a similar point about how the OS re-enumerates devices
    as a result of a power state change (3rd last paragraph of
    text).

  - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
    suggests that Windows only stops a device to rebalance hardware
    resources.

[This should go before
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch
for best bisect-ability.]

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: linux-mm/drivers/pnp/driver.c
===================================================================
--- linux-mm.orig/drivers/pnp/driver.c	2007-11-30 13:58:25.000000000 -0700
+++ linux-mm/drivers/pnp/driver.c	2007-12-03 09:58:35.000000000 -0700
@@ -161,13 +161,6 @@
 			return error;
 	}
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
-	    pnp_can_disable(pnp_dev)) {
-		error = pnp_stop_dev(pnp_dev);
-		if (error)
-			return error;
-	}
-
 	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
 		pnp_dev->protocol->suspend(pnp_dev, state);
 	return 0;
@@ -177,7 +170,6 @@
 {
 	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
 	struct pnp_driver *pnp_drv = pnp_dev->driver;
-	int error;
 
 	if (!pnp_drv)
 		return 0;
@@ -185,12 +177,6 @@
 	if (pnp_dev->protocol && pnp_dev->protocol->resume)
 		pnp_dev->protocol->resume(pnp_dev);
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
-		error = pnp_start_dev(pnp_dev);
-		if (error)
-			return error;
-	}

Re: RFC: PNP: do not stop/start devices in suspend/resume path

[Matthew Wilcox]

On Wed, Dec 05, 2007 at 11:24:18AM -0700, Bjorn Helgaas wrote:
> This means we will not disable the device and release its
> resources.  The driver suspend method typically does not release
> its resources in the suspend path.  For example, if we have:
> 
>   03f8-03ff : 00:06
>     03f8-03ff : serial
> 
> pnp_stop_dev() would release the 00:06 region, which still
> has a child.  This causes a warning from __release_resource
> and corrupts /proc/ioports.

So, I put the warning in there because I genuinely didn't know if we
were doing this, and if so what the semantics should be.

I'm quite happy to see resources with children being released -- I just
want to know what we should do with those children.  As the first person
to come across this problem, I think you get to decide the semantics.

It seems to me from this description that all we want to do is reparent
the children -- which is easy enough to do; just a matter of twizzling
all the ->parent pointers of the children; the ->sibling of the resource
before the one being released and the ->sibling of the last child of the
one being released.

If you think it's a genuine bug that happens to have been caught by this
check, I'm happy to see the check being useful, and we don't need to
allow the removal of resources.

The only thing is, if you're going to be re-acquiring these resources
upon resume, you'll need to use insert_resource() instead of
request_region() because the child will now be in that spot.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: RFC: PNP: do not stop/start devices in suspend/resume path

[Rafael J. Wysocki]

On Wednesday, 5 of December 2007, Bjorn Helgaas wrote:
> Re: warning on suspend-to-RAM caused by
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
> thread here: http://lkml.org/lkml/2007/11/22/110
> 
> On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
> > I didn't get it. Maybe some trolls poking around or something (maybe the
> > ext3 breakage which fsck fixed). It works after recompilation of the
> > whole tree. And the important part -- the warning has gone.
> 
> Good.  It's not clear to me whether it is safe to leave devices
> enabled while we sleep.  I don't see an actual problem, but there
> might be something related to hotplug while we're asleep or something.
> So I'll cc: some additional people who might have some insight.
> 
> 
> 
> RFC: PNP: do not stop/start devices in suspend/resume path
> 
> Do not disable PNP devices in the suspend path.  We still call
> the driver's suspend method, which should prevent further use of
> the device, and the protocol suspend method, which may put the
> device in a low-power state.
> 
> This means we will not disable the device and release its
> resources.  The driver suspend method typically does not release
> its resources in the suspend path.  For example, if we have:
> 
>   03f8-03ff : 00:06
>     03f8-03ff : serial
> 
> pnp_stop_dev() would release the 00:06 region, which still
> has a child.  This causes a warning from __release_resource
> and corrupts /proc/ioports.
> 
> However, we should do this the same way Windows does, so if
> Windows disables devices before going to sleep, we should, too.
> It doesn't *look* necessary to me because
> 
>   - In the ACPI 3.0b spec, I can't find any mention of _DIS in
>     connection with sleep.  And Device Object Notifications,
>     Section 5.6.3, Table 5-43, says we should get a bus check
>     after awakening if hardware was removed while we slept.
> 
>     This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
>     makes a similar point about how the OS re-enumerates devices
>     as a result of a power state change (3rd last paragraph of
>     text).
> 
>   - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
>     suggests that Windows only stops a device to rebalance hardware
>     resources.
> 
> [This should go before
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch
> for best bisect-ability.]

The only comment I can make is that this change is along with the lines of
what PCI drivers do, so it looks reasonable.

In any case it's worthy of checking if removing the pnp_stop(start)_dev()
invocations from the suspend/resume code paths will cause any problems to
appear, IMO.

> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: linux-mm/drivers/pnp/driver.c
> ===================================================================
> --- linux-mm.orig/drivers/pnp/driver.c	2007-11-30 13:58:25.000000000 -0700
> +++ linux-mm/drivers/pnp/driver.c	2007-12-03 09:58:35.000000000 -0700
> @@ -161,13 +161,6 @@
>  			return error;
>  	}
>  
> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
> -	    pnp_can_disable(pnp_dev)) {
> -		error = pnp_stop_dev(pnp_dev);
> -		if (error)
> -			return error;
> -	}
> -
>  	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
>  		pnp_dev->protocol->suspend(pnp_dev, state);
>  	return 0;
> @@ -177,7 +170,6 @@
>  {
>  	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
>  	struct pnp_driver *pnp_drv = pnp_dev->driver;
> -	int error;
>  
>  	if (!pnp_drv)
>  		return 0;
> @@ -185,12 +177,6 @@
>  	if (pnp_dev->protocol && pnp_dev->protocol->resume)
>  		pnp_dev->protocol->resume(pnp_dev);
>  
> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
> -		error = pnp_start_dev(pnp_dev);
> -		if (error)
> -			return error;
> -	}
> -
>  	if (pnp_drv->resume)
>  		return pnp_drv->resume(pnp_dev);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 



-- 
"Premature optimization is the root of all evil." - Donald Knuth

PNP: do not stop/start devices in suspend/resume path

[Bjorn Helgaas]

On Wednesday 05 December 2007 11:24:18 am Bjorn Helgaas wrote:
> Re: warning on suspend-to-RAM caused by
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
> thread here: http://lkml.org/lkml/2007/11/22/110
> 
> On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
> > I didn't get it. Maybe some trolls poking around or something (maybe the
> > ext3 breakage which fsck fixed). It works after recompilation of the
> > whole tree. And the important part -- the warning has gone.
> 
> Good.  It's not clear to me whether it is safe to leave devices
> enabled while we sleep.  I don't see an actual problem, but there
> might be something related to hotplug while we're asleep or something.
> So I'll cc: some additional people who might have some insight.

I checked with a Windows kernel person, who said that when preparing
to sleep, Windows puts devices in S3 state (I think he meant D3)
and does not use _DIS.

I think this patch is the right thing to do.  It's possible we'll
trip over some BIOS issue, but in the long term, we should try to
do it the same way Windows does.  Andrew, can you add this before
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch?

Thanks,
  Bjorn


PNP: do not stop/start devices in suspend/resume path

Do not disable PNP devices in the suspend path.  We still call
the driver's suspend method, which should prevent further use of
the device, and the protocol suspend method, which may put the
device in a low-power state.

I'm told that Windows puts devices in a low-power state (Linux
does this in the protocol suspend method), but does not use _DIS
in the suspend path.  Other relevant references:

  - In the ACPI 3.0b spec, I can't find any mention of _DIS in
    connection with sleep.  And Device Object Notifications,
    Section 5.6.3, Table 5-43, says we should get a bus check
    after awakening if hardware was removed while we slept.

  - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
    makes a similar point about how the OS re-enumerates devices
    as a result of a power state change (3rd last paragraph of
    text).

  - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
    suggests that Windows only stops a device to rebalance hardware
    resources.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: linux-mm/drivers/pnp/driver.c
===================================================================
--- linux-mm.orig/drivers/pnp/driver.c	2007-11-30 13:58:25.000000000 -0700
+++ linux-mm/drivers/pnp/driver.c	2007-12-03 09:58:35.000000000 -0700
@@ -161,13 +161,6 @@
 			return error;
 	}
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
-	    pnp_can_disable(pnp_dev)) {
-		error = pnp_stop_dev(pnp_dev);
-		if (error)
-			return error;
-	}
-
 	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
 		pnp_dev->protocol->suspend(pnp_dev, state);
 	return 0;
@@ -177,7 +170,6 @@
 {
 	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
 	struct pnp_driver *pnp_drv = pnp_dev->driver;
-	int error;
 
 	if (!pnp_drv)
 		return 0;
@@ -185,12 +177,6 @@
 	if (pnp_dev->protocol && pnp_dev->protocol->resume)
 		pnp_dev->protocol->resume(pnp_dev);
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
-		error = pnp_start_dev(pnp_dev);
-		if (error)
-			return error;
-	}
-
 	if (pnp_drv->resume)
 		return pnp_drv->resume(pnp_dev);
 

Re: PNP: do not stop/start devices in suspend/resume path

[Andrew Morton]

On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> Andrew, can you add this before
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch?
> 
> ...
>
> PNP: do not stop/start devices in suspend/resume path

I did, but I also temporarily dropped
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch.

Is it expected that this patch will fix
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch? 
Should I bring it back?

Re: PNP: do not stop/start devices in suspend/resume path

[Bjorn Helgaas]

On Wednesday 12 December 2007 01:16:10 am Andrew Morton wrote:
> On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> 
> > Andrew, can you add this before
> > pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch?
> > 
> > ...
> >
> > PNP: do not stop/start devices in suspend/resume path
> 
> I did, but I also temporarily dropped
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch.

Thanks.

> Is it expected that this patch will fix
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch? 
> Should I bring it back?

No, not yet.  The "do not stop/start" patch should fix the kernel/resource.c
warning, but I don't understand the "acpi reboots machine" (critical temp
reached) problem yet.

Bjorn

Re: PNP: do not stop/start devices in suspend/resume path

[Pierre Ossman]

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

On Thu, 6 Dec 2007 16:25:57 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> PNP: do not stop/start devices in suspend/resume path
> 
> Do not disable PNP devices in the suspend path.  We still call
> the driver's suspend method, which should prevent further use of
> the device, and the protocol suspend method, which may put the
> device in a low-power state.
> 
> I'm told that Windows puts devices in a low-power state (Linux
> does this in the protocol suspend method), but does not use _DIS
> in the suspend path.  Other relevant references:
> 
>   - In the ACPI 3.0b spec, I can't find any mention of _DIS in
>     connection with sleep.  And Device Object Notifications,
>     Section 5.6.3, Table 5-43, says we should get a bus check
>     after awakening if hardware was removed while we slept.
> 
>   - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
>     makes a similar point about how the OS re-enumerates devices
>     as a result of a power state change (3rd last paragraph of
>     text).
> 
>   - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
>     suggests that Windows only stops a device to rebalance hardware
>     resources.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 

Tested-by: Pierre Ossman <drzeus@drzeus.cx>

No noticeable issues with suspend or hibernate using this patch.

Rgds
Pierre

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: PNP: do not stop/start devices in suspend/resume path

[Shaohua Li]

On Thu, 2007-12-06 at 02:24 +0800, Bjorn Helgaas wrote:
> Re: warning on suspend-to-RAM caused by
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
> thread here: http://lkml.org/lkml/2007/11/22/110
> 
> On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
> > I didn't get it. Maybe some trolls poking around or something (maybe
> the
> > ext3 breakage which fsck fixed). It works after recompilation of the
> > whole tree. And the important part -- the warning has gone.
> 
> Good.  It's not clear to me whether it is safe to leave devices
> enabled while we sleep.  I don't see an actual problem, but there
> might be something related to hotplug while we're asleep or something.
> So I'll cc: some additional people who might have some insight.
> 
> 
> 
> RFC: PNP: do not stop/start devices in suspend/resume path
> 
> Do not disable PNP devices in the suspend path.  We still call
> the driver's suspend method, which should prevent further use of
> the device, and the protocol suspend method, which may put the
> device in a low-power state.
> 
> This means we will not disable the device and release its
> resources.  The driver suspend method typically does not release
> its resources in the suspend path.  For example, if we have:
> 
>   03f8-03ff : 00:06
>     03f8-03ff : serial
> 
> pnp_stop_dev() would release the 00:06 region, which still
> has a child.  This causes a warning from __release_resource
> and corrupts /proc/ioports.
> 
> However, we should do this the same way Windows does, so if
> Windows disables devices before going to sleep, we should, too.
> It doesn't *look* necessary to me because
> 
>   - In the ACPI 3.0b spec, I can't find any mention of _DIS in
>     connection with sleep.  And Device Object Notifications,
>     Section 5.6.3, Table 5-43, says we should get a bus check
>     after awakening if hardware was removed while we slept.
> 
>     This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
>     makes a similar point about how the OS re-enumerates devices
>     as a result of a power state change (3rd last paragraph of
>     text).
> 
>   - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
>     suggests that Windows only stops a device to rebalance hardware
>     resources.
> 
> [This should go before
> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch
> for best bisect-ability.]
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: linux-mm/drivers/pnp/driver.c
> ===================================================================
> --- linux-mm.orig/drivers/pnp/driver.c  2007-11-30 13:58:25.000000000
> -0700
> +++ linux-mm/drivers/pnp/driver.c       2007-12-03 09:58:35.000000000
> -0700
> @@ -161,13 +161,6 @@
>                         return error;
>         }
> 
> -       if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
> -           pnp_can_disable(pnp_dev)) {
> -               error = pnp_stop_dev(pnp_dev);
> -               if (error)
> -                       return error;
> -       }
> -
>         if (pnp_dev->protocol && pnp_dev->protocol->suspend)
>                 pnp_dev->protocol->suspend(pnp_dev, state);
>         return 0;
> @@ -177,7 +170,6 @@
>  {
>         struct pnp_dev *pnp_dev = to_pnp_dev(dev);
>         struct pnp_driver *pnp_drv = pnp_dev->driver;
> -       int error;
> 
>         if (!pnp_drv)
>                 return 0;
> @@ -185,12 +177,6 @@
>         if (pnp_dev->protocol && pnp_dev->protocol->resume)
>                 pnp_dev->protocol->resume(pnp_dev);
> 
> -       if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
> -               error = pnp_start_dev(pnp_dev);
> -               if (error)
> -                       return error;
> -       }
> -
I'd suggest keep pnp_start_dev here to prevent BIOS not or assign
different resources after a resume.

Re: RFC: PNP: do not stop/start devices in suspend/resume path

[Bjorn Helgaas]

On Friday 07 December 2007 12:13:35 am Shaohua Li wrote:
> On Thu, 2007-12-06 at 02:24 +0800, Bjorn Helgaas wrote:
> > Index: linux-mm/drivers/pnp/driver.c
> > ===================================================================
> > --- linux-mm.orig/drivers/pnp/driver.c  2007-11-30 13:58:25.000000000
> > -0700
> > +++ linux-mm/drivers/pnp/driver.c       2007-12-03 09:58:35.000000000
> > -0700
> > @@ -161,13 +161,6 @@
> >                         return error;
> >         }
> > 
> > -       if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
> > -           pnp_can_disable(pnp_dev)) {
> > -               error = pnp_stop_dev(pnp_dev);
> > -               if (error)
> > -                       return error;
> > -       }
> > -
> >         if (pnp_dev->protocol && pnp_dev->protocol->suspend)
> >                 pnp_dev->protocol->suspend(pnp_dev, state);
> >         return 0;
> > @@ -177,7 +170,6 @@
> >  {
> >         struct pnp_dev *pnp_dev = to_pnp_dev(dev);
> >         struct pnp_driver *pnp_drv = pnp_dev->driver;
> > -       int error;
> > 
> >         if (!pnp_drv)
> >                 return 0;
> > @@ -185,12 +177,6 @@
> >         if (pnp_dev->protocol && pnp_dev->protocol->resume)
> >                 pnp_dev->protocol->resume(pnp_dev);
> > 
> > -       if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
> > -               error = pnp_start_dev(pnp_dev);
> > -               if (error)
> > -                       return error;
> > -       }
> > -
> I'd suggest keep pnp_start_dev here to prevent BIOS not or assign
> different resources after a resume.

The patch I currently have in -mm (http://lkml.org/lkml/2007/10/29/412)
merely requests resources in pnp_start_dev() and releases them in
pnp_stop_dev().  So if we remove pnp_stop_dev() but keep pnp_start_dev(),
I have to fix that patch to deal with things that may already be
reserved.

But I don't see any mention in the spec of running _SRS in the
sleep/wakup path, so I'm not convinced it's really necessary.
Section 7.4 mentions _TTS, _PTS, _GTS, etc., but not _SRS.

For devices, it looks like the intent is that BIOS should generate
notifications that cause OSPM to re-enumerate devices that might
have changed.  I'm pretty sure Linux is missing some of that code,
though, so I could believe that _SRS might help paper over that
deficiency.

What I'd really like to do is figure out how Windows uses _SRS and
do the same thing.

Bjorn

Re: do not stop/start devices in suspend/resume path: the SCSI case

[Stephane Ascoet]

Bjorn Helgaas a écrit :
> Good.  It's not clear to me whether it is safe to leave devices
> enabled while we sleep.  I don't see an actual problem, but there
> might be something related to hotplug while we're asleep or something.
> So I'll cc: some additional people who might have some insight.
Hi, is there a chance for SCSI sleeping being managed by ACPI(it seems 
to be the case for IDE)?

-- 
Bien cordialement, Stephane Ascoet, conseils pour que la technologie 
soit un progres respectueux de la vie.
Album photo:<http://www.flickr.com/photos/stephaneascoet/>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: do not stop/start devices in suspend/resume path: the SCSI case

[Bjorn Helgaas]

On Sunday 23 December 2007 6:43:49 pm Stephane Ascoet wrote:
> Bjorn Helgaas a écrit :
> > Good.  It's not clear to me whether it is safe to leave devices
> > enabled while we sleep.  I don't see an actual problem, but there
> > might be something related to hotplug while we're asleep or something.
> > So I'll cc: some additional people who might have some insight.
>
> Hi, is there a chance for SCSI sleeping being managed by ACPI(it seems
> to be the case for IDE)?

I'm sorry, I don't know the answer to this.

Bjorn

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html