-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/10/2014 12:23 AM, Douglas Gilbert wrote:
> It is a command in the "Sense Data Reporting feature set" which is
> optional for ATA devices and "P" as in "Prohibited" for ATAPI
> devices. See the Feature set summary table.
Oops, you're right.
> You
On 14-01-09 02:20 PM, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 1:29 PM, Douglas Gilbert wrote:
When REQUEST SENSE had its original semantics, TEST UNIT READY was
the only game in town for monitoring power management. From my
reading of spc4r36n.pdf section
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 1:29 PM, Douglas Gilbert wrote:
> When REQUEST SENSE had its original semantics, TEST UNIT READY was
> the only game in town for monitoring power management. From my
> reading of spc4r36n.pdf section 5.1.2 "Important commands for all
> SCS
On 14-01-07 10:40 AM, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:20 AM, Alan Stern wrote:
This raises two questions:
Should the host's resume be allowed to complete while the host is
still in error recovery? Wouldn't it be better to wait until the
recover
On Thu, 9 Jan 2014, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/9/2014 11:14 AM, Alan Stern wrote:
> > That's true, but it isn't a problem. We know that requests with
> > REQ_PM are sent only at certain, controlled times. In particular,
> > the only time such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 11:14 AM, Alan Stern wrote:
> That's true, but it isn't a problem. We know that requests with
> REQ_PM are sent only at certain, controlled times. In particular,
> the only time such a request would be sent while the disk is
> RPM_SUSPEND
On Thu, 9 Jan 2014, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/9/2014 10:40 AM, Alan Stern wrote:
> > We should change the code in the block layer. blk_pm_peek_request
> > should allow requests with REQ_PM set to go through, no matter
> > what the rpm_status
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 10:40 AM, Alan Stern wrote:
> We should change the code in the block layer. blk_pm_peek_request
> should allow requests with REQ_PM set to go through, no matter
> what the rpm_status is. Then the disk driver could query the disk
> (to se
On Thu, 9 Jan 2014, Aaron Lu wrote:
> > It's a knotty situation. The only way to find out whether the disk is
> > spinning is to ask it, which requires doing I/O, which requires
> > spinning up the disk. Maybe we need to add a mechanism to the block
> > layer's runtime PM implementation for addr
On Thursday, January 09, 2014 01:17:12 PM Rafael J. Wysocki wrote:
> On Thursday, January 09, 2014 09:29:59 AM Aaron Lu wrote:
> > On 01/09/2014 05:21 AM, Alan Stern wrote:
> > > On Wed, 8 Jan 2014, Phillip Susi wrote:
> > >> You issue a REQUEST SENSE command and that returns status indicating
> >
On Thursday, January 09, 2014 09:29:59 AM Aaron Lu wrote:
> On 01/09/2014 05:21 AM, Alan Stern wrote:
> > On Wed, 8 Jan 2014, Phillip Susi wrote:
> >> You issue a REQUEST SENSE command and that returns status indicating
> >> whether the drive is stopped, or in standby. See my patches. One of
> >
On 01/09/2014 05:21 AM, Alan Stern wrote:
> On Wed, 8 Jan 2014, Phillip Susi wrote:
>> You issue a REQUEST SENSE command and that returns status indicating
>> whether the drive is stopped, or in standby. See my patches. One of
>
> I never saw your patches. Where were they posted?
>
> If you is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 4:21 PM, Alan Stern wrote:
> I never saw your patches. Where were they posted?
Higher up in this thread on linux-ide and linux-scsi. Subject was Let
sleeping disks lie.
> If you issue the REQUEST SENSE command in the usual way (going
>
On Wed, 8 Jan 2014, Phillip Susi wrote:
> > In essence, you want your disk's state to move directly from
> > unpowered (system asleep) to runtime-suspended with no intermediate
> > active -- but only if the disk doesn't spin up all by itself.
> >
> > One problem: How can the kernel tell whether t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 12:46 PM, Alan Stern wrote:
> I/O _was_ done. To spin up the disk requires sending it a START
> command. That's I/O.
Yes, currently, but that's exactly what I'm trying to get rid of.
> In essence, you want your disk's state to move dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 2:00 AM, Aaron Lu wrote:
> Then I would say we just keep the pm_request_resume call in their
> system resume callback. For drives that have that cool feature
> turned on, it will be in runtime active state while it's actually
> in standby m
On Wed, 8 Jan 2014, Alan Stern wrote:
> In essence, you want your disk's state to move directly from unpowered
> (system asleep) to runtime-suspended with no intermediate active -- but
> only if the disk doesn't spin up all by itself.
> In the end, it sounds like what you want can be done fairly
On Tue, 7 Jan 2014, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/07/2014 02:18 PM, Alan Stern wrote:
> > I don't know how you manually spin down your disk, but one
> > reasonable way to do it is to set the autosuspend timeout to 0. If
> > you use this approac
On 01/08/2014 01:24 PM, Phillip Susi wrote:
> On 01/07/2014 09:36 PM, Aaron Lu wrote:
>> Oh, of course, my stupid :-) Then I suddenly think my patches can
>> kind of work - let's say we have done the hdparm setting thing
>> before suspend and the disk will be spun up in standby mode next
>> time it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:36 PM, Aaron Lu wrote:
> I think the host controller can decide not to power all its ports,
> only when a specific reg in the port's memory range is set, it will
> give power to that port and thus spin up the drive. Makes sense?
The
On 01/08/2014 10:19 AM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/07/2014 09:11 PM, Aaron Lu wrote:
>> I thought that feature is used to control if a disk should be spun
>> up once powered from the host side.
>
> That *is* what it sounds like, only ATA disk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:11 PM, Aaron Lu wrote:
> I thought that feature is used to control if a disk should be spun
> up once powered from the host side.
That *is* what it sounds like, only ATA disks either spin up as soon
as power is applied, or wait for
On 01/08/2014 09:53 AM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/07/2014 08:32 PM, Aaron Lu wrote:
>> The ATA and SCSI devices are all resumed in my patches, notice
>> there is a single pm_request_resume call in both ATA and SCSI's
>> system resume callback
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:32 PM, Aaron Lu wrote:
> The ATA and SCSI devices are all resumed in my patches, notice
> there is a single pm_request_resume call in both ATA and SCSI's
> system resume callback, so the runtime status and the disk's state
> is synce
On 01/08/2014 09:16 AM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/07/2014 08:03 PM, Aaron Lu wrote:
>> You mean you want to leave the disk runtime suspended after a
>> system resume and in the meantime make sure the disk is indeed not
>> spun up?
>
> Yep.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:03 PM, Aaron Lu wrote:
> You mean you want to leave the disk runtime suspended after a
> system resume and in the meantime make sure the disk is indeed not
> spun up?
Yep. If it is spun up, then the runtime status should be updated
On 01/07/2014 10:50 PM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/7/2014 2:49 AM, Aaron Lu wrote:
>> We can modify the device's system resume callback. To better
>> illustrate the idea, I just made two patches to do this and I did
>> some quick tests and didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 02:18 PM, Alan Stern wrote:
> I don't know how you manually spin down your disk, but one
> reasonable way to do it is to set the autosuspend timeout to 0. If
> you use this approach and apply my patch, the disk should remain
> spun dow
On Tue, 7 Jan 2014, Phillip Susi wrote:
> On 1/7/2014 1:05 PM, Alan Stern wrote:
> > I disagree with your argument. If you aren't using autosuspend at
> > all then you don't mind having your disks spin all the time.
> > Therefore you don't mind if the disks spin up during system
> > resume.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 1:05 PM, Alan Stern wrote:
> I disagree with your argument. If you aren't using autosuspend at
> all then you don't mind having your disks spin all the time.
> Therefore you don't mind if the disks spin up during system
> resume.
I prefer
On Tue, 7 Jan 2014, Phillip Susi wrote:
> On 1/7/2014 11:08 AM, Alan Stern wrote:
> > Okay, that's a different matter. There's a much simpler way to
> > accomplish this. The patch below will avoid spinning up drives
> > that were already in runtime suspend when the system sleep started.
> > (I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 11:08 AM, Alan Stern wrote:
> Okay, that's a different matter. There's a much simpler way to
> accomplish this. The patch below will avoid spinning up drives
> that were already in runtime suspend when the system sleep started.
> (If a
On Tue, 7 Jan 2014, Phillip Susi wrote:
> On 1/7/2014 10:25 AM, Alan Stern wrote:
> > This doesn't seem like a good idea. The way to speed up resumes is
> > to allow sd's resume routine to return while the disk is still
> > spinning up (i.e., make the spin-up asynchronous). There already
> > hav
On Tue, 7 Jan 2014, Phillip Susi wrote:
> On 1/7/2014 10:20 AM, Alan Stern wrote:
> > This raises two questions:
> >
> > Should the host's resume be allowed to complete while the host is
> > still in error recovery? Wouldn't it be better to wait until the
> > recovery is finished?
>
> Ahh, righ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:25 AM, Alan Stern wrote:
> This doesn't seem like a good idea. The way to speed up resumes is
> to allow sd's resume routine to return while the disk is still
> spinning up (i.e., make the spin-up asynchronous). There already
> have be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:20 AM, Alan Stern wrote:
> This raises two questions:
>
> Should the host's resume be allowed to complete while the host is
> still in error recovery? Wouldn't it be better to wait until the
> recovery is finished?
Ahh, right, my othe
On Tue, 7 Jan 2014, Aaron Lu wrote:
> From: Aaron Lu
> Date: Tue, 7 Jan 2014 15:02:13 +0800
> Subject: [PATCH 1/2] SCSI: pm: make use of runtime PM for SCSI device
>
> To make system resume fast, modify SCSI PM callbacks so that if
> CONFIG_PM_RUNTIME is set, during a system suspend transition,
On Mon, 6 Jan 2014, Phillip Susi wrote:
> On 01/06/2014 10:38 AM, Alan Stern wrote:
> > Indeed. I can't see any place where the SCSI or block layers
> > would stop the queue of a device when it gets runtime suspended.
> > Maybe some other layer is doing this.
>
> So I've stepped through it in qe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 2:49 AM, Aaron Lu wrote:
> We can modify the device's system resume callback. To better
> illustrate the idea, I just made two patches to do this and I did
> some quick tests and didn't find anything wrong.
That misses one key aspect I was
On 01/06/2014 10:40 PM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/6/2014 4:15 AM, Aaron Lu wrote:
>> My guess why it doesn't work for you is that, when you call
>> blk_pre_runtime_suspend in sd_resume_work, there are requests left
>> in the queue so that call
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/06/2014 10:38 AM, Alan Stern wrote:
> Indeed. I can't see any place where the SCSI or block layers
> would stop the queue of a device when it gets runtime suspended.
> Maybe some other layer is doing this.
So I've stepped through it in qemu a
On Mon, 6 Jan 2014, Phillip Susi wrote:
> The issue is that the REQ_PM flagged REQUEST SENSE command issued
> during the system_resume is never dispatched. I patched scsi_execute
> to make the request type REQ_TYPE_PM_RESUME and that got the request
> dispatched.
Note that REQ_TYPE_PM_RESUME is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/6/2014 4:15 AM, Aaron Lu wrote:
> My guess why it doesn't work for you is that, when you call
> blk_pre_runtime_suspend in sd_resume_work, there are requests left
> in the queue so that call will simply fail, it's not meant to be
> used that way.
On 01/06/2014 03:36 PM, Sujit Reddy Thumma wrote:
> On 1/6/2014 7:44 AM, Phillip Susi wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 12/16/2013 06:30 PM, Phillip Susi wrote:
>>> For some reason, the system hangs on resume if I issue the REQUEST
>>> SENSE command after blk_pre
On 1/6/2014 7:44 AM, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/16/2013 06:30 PM, Phillip Susi wrote:
For some reason, the system hangs on resume if I issue the REQUEST
SENSE command after blk_pre_runtime_suspend. My understanding is
that the REQ_PM flag should m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/16/2013 06:30 PM, Phillip Susi wrote:
> For some reason, the system hangs on resume if I issue the REQUEST
> SENSE command after blk_pre_runtime_suspend. My understanding is
> that the REQ_PM flag should make the command process even though
>
46 matches
Mail list logo
