ubject: Re: [PATCH] Hard disk S3 resume time optimization
On Fri, 2013-08-02 at 16:41 +, Brandt, Todd E wrote:
> Do you mean in terms of debug after a failure? I can resubmit the patch with
> the scsi_sense_hdr buffer still in place. I just wanted to keep the first
> draft simple to get
On Fri, 2013-08-02 at 16:41 +, Brandt, Todd E wrote:
> Do you mean in terms of debug after a failure? I can resubmit the patch with
> the scsi_sense_hdr buffer still in place. I just wanted to keep the first
> draft simple to get the concept across.
How are errors reported?
Regards
] Hard disk S3 resume time optimization
On Thu, 2013-08-01 at 23:40 +, Brandt, Todd E wrote:
> This patch is a potential way to reduce the S3 resume time for SATA drives.
> Essentially this patch removes the hard disk resume time from the total
> system resume time, with the disks sti
On Thu, 2013-08-01 at 23:40 +, Brandt, Todd E wrote:
> This patch is a potential way to reduce the S3 resume time for SATA drives.
> Essentially this patch removes the hard disk resume time from the total
> system resume time, with the disks still taking as long to come back online
> but in
On Thu, May 16, 2013 at 03:44:41PM -0700, Tejun Heo wrote:
> So, while I agree about the problem and the solution seems to be
> headed the right way of making SCSI suspend/resume asynchronous,
> what's going on with patch splitting, submission format and comments?
> Please read up on patch submissi
Hello,
First of all, if at all possible, please try to fill the message to 80
columns, preferably a bit narrower than that. Most email clients can
do it without you knowing.
> [The Problem]
> The vast majority of time spent in S3 resume is consumed by the ATA
> subsystem as it resumes the comput
6 matches
Mail list logo
