Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Aug 2001 23:56:50 -0400
From:      JT <luser@ahab.com>
To:        Nick Sayer <nsayer@quack.kfu.com>, mobile@freebsd.org
Subject:   Re: ATA idle spindown patch.
Message-ID:  <20010822235650.C410@zed.unbeat.com>
In-Reply-To: <3B635732.6030409@quack.kfu.com>; from nsayer@quack.kfu.com on Sat, Jul 28, 2001 at 05:22:10PM -0700
References:  <200107280841.f6S8fvR80063@freebsd.dk> <3B6354F9.2070801@quack.kfu.com> <3B635732.6030409@quack.kfu.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I tried the patch with this modification, but I haven't noticed it spin down
at all, not that I'm very patient (though I *can* verify sysctl
hw.ata.suspend=300). I haven't the knowledge to really understand how this
patch works, but:

	a) What stuff could keep the drive from spinning down?  I can think of
		i) cron?
		ii) fetchmail?
		iii) ???
	b) What would it take to write a userland program that could request
	an immediate spindown (even if suid)?  

It seems like a userland util to attempt immediate spindown would be a nice
thing to have, since constant disk spinning seems to flout expectations of
laptop hard drive specs (I've burned out more than one, apparently after long
up-times) and since full suspend isn't always my intention... On the other
hand, I can easily imagine how calling such a utility might generate enough
disk activity to thwart itself.

It would seem (were it a simple program) to get this patch from 50% of the
usefulness of the Right Way (tm) (when Søren's priorities permit) to 65%...

On Sat, Jul 28, 2001 at 05:22:10PM -0700, Nick Sayer wrote:
> Nick Sayer wrote:
> 
> I spoke too soon. I just had to use ATA_WAIT_READY instead of ATA_WAIT_INTR.
> 
> So I have the same patch as the one that was posted, but I duplicated 
> the 'if ( ata_suspend > 0 )' block at the end if ad_reinit() with 
> ATA_WAIT_READY instead of ATA_WAIT_INTR. With that, spindown survives 
> suspend/resume (well, on resume the drive spins up, obviously, but then 
> after the wait time it spins back down).

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822235650.C410>