linux-kernel - Re: SATA powersave patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <450E771E.1070207@gmail.com>
Date:	Mon, 18 Sep 2006 19:38:22 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	kernel list <linux-kernel@...r.kernel.org>, axboe@...e.de
Subject: Re: SATA powersave patches

Hello,

Pavel Machek wrote:
>> Can you check if there is any difference between [D/H]IPS and static? 
>> ICH6M on my notebook can't do DIPS/HIPS, so I couldn't compare them 
>> against static.
> 
> What is D/HIPS? I could not find anything relevant..

D/HIPS stand for device/host initiated power saving.  These modes use 
two SATA link powersaving state (partial and slumber).  Static mode 
simply turns off PHY on unoccupied port using SControl register.  So, if 
you have an access to a notebook which has a SATA dock which support 
link powersaving, you can test it by...

* set link powersaving mode to HIPS/static. (mode 4)

* w/ device inserted, leave it idle for 15 seconds and record power 
consumption level (link should be in slumber state).

* pull out the device, wait for libata to detach the device and record 
power consumption level (libata should have turned off PHY after 
detaching the device).

I wanna know whether there is any difference in the amount of power 
saved between slumber and off states.

>>> It would be great to be able to power SATA
>>> controller down, then power it back up when it is needed... I tried
>>> following hack, but could not get it to work. Any ideas?
>> 1. One way to do it would be by dynamic power management.  It would be 
>> nice to have wake-up mechanism at the block layer.  Idle timer can run 
>> in the block layer or it can be implemented in the userland.
>>
>> ATM, this implies that the attached devices are powered down too 
>> (spindown).  As spinning up takes quite some time, we can implement 
> 
> For now, powering down controller when disks are spinned down would be
> very nice first step.

Yeap.

> When I forced disk to be spinned down (with power/state file)
> controller actually survived power down/power up... unfortunately with
> so long delay (~30 sec) that it is not usable in practice.

Can you describe what you've done in more detail?  Do you have dmesg of 
the 30sec wait?

>> So, I think option #1 is the way to go - implementing leveled dynamic 
>> power management infrastructure and adding support in the block layer. 
>> What do you think?
> 
> Would be nice :-).

So, do you think we're ready for another PM infrastructure update?  :-P

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/