Randy Dunlap wrote:
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default
On Sun, May 20, 2007 19:17, Tejun Heo wrote:
> Indan Zupancic wrote:
>> So over all it takes half a second longer to detect the disk, but
>> because everything waits on it, it takes more than three seconds
>> longer to resume.
>
> Eeeek. Extra three secs doesn't sound too hot. :-(
Hey, without
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
> Indan Zupancic wrote:
> >>> Everything seems to work fine without sd_resume(), so why is it needed?
> >> Because not all disks spin up without being told to do so and like it or
> >> not spinning disks up on resume is the default
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default behavior. As I wrote in
the other reply, it would be worthwhile to make it
Indan Zupancic wrote:
>> Can you try to measure with sd_resume in place?
>
> [2.173366] sd 0:0:0:0: [sda] Starting disk
> [2.475422] ata2: SATA link down (SStatus 0 SControl 310)
> [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [5.481928] ata1.00:
On Sun, May 20, 2007 11:54, Tejun Heo wrote:
> Indan Zupancic wrote:
>> On Sat, May 19, 2007 21:04, Tejun Heo wrote:
>>> Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
Indan Zupancic wrote:
> On Sat, May 19, 2007 21:04, Tejun Heo wrote:
>> Tejun Heo wrote:
>>> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
>>> isn't there, so the whole skip-0xff logic probably shouldn't apply in
>>> such cases, but we can also achieve pretty good result
Indan Zupancic wrote:
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we can also achieve pretty good result by just
On Sun, May 20, 2007 11:54, Tejun Heo wrote:
Indan Zupancic wrote:
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we
Indan Zupancic wrote:
Can you try to measure with sd_resume in place?
[2.173366] sd 0:0:0:0: [sda] Starting disk
[2.475422] ata2: SATA link down (SStatus 0 SControl 310)
[5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[5.481928] ata1.00: ata_hpa_resize 1:
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default behavior. As I wrote in
the other reply, it would be worthwhile to make it
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default behavior. As I
On Sun, May 20, 2007 19:17, Tejun Heo wrote:
Indan Zupancic wrote:
So over all it takes half a second longer to detect the disk, but
because everything waits on it, it takes more than three seconds
longer to resume.
Eeeek. Extra three secs doesn't sound too hot. :-(
Hey, without your
Randy Dunlap wrote:
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote:
Indan Zupancic wrote:
Everything seems to work fine without sd_resume(), so why is it needed?
Because not all disks spin up without being told to do so and like it or
not spinning disks up on resume is the default
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
> Tejun Heo wrote:
>> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
>> isn't there, so the whole skip-0xff logic probably shouldn't apply in
>> such cases, but we can also achieve pretty good result by just making
>> the first
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we can also achieve pretty good result by just making
the first reset
16 matches
Mail list logo
