linux-kernel - Re: [git patches] libata hibernation fixes

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: <4911053E.9070103@kernel.org>
Date:	Wed, 05 Nov 2008 11:30:22 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Elias Oltmanns <eo@...ensachen.de>
CC:	Robert Hancock <hancockr@...w.ca>, Mark Lord <liml@....ca>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] libata hibernation fixes

Elias Oltmanns wrote:
>> On these systems, not spinning the disk down is fine because the BIOS
>> does it. However this would cause problems on systems where the BIOS
>> doesn't do so as it will cause an emergency unload on power-down.
> 
> Ah, but do BIOSes just cut power without spinning disks down first?
> Pressing the power button on my laptop either at the prompt for the HD
> password or in GRUB's menu spins the disk down properly. Isn't that the
> BIOS doing its job?

Drives don't like emergency unloads but they are designed to take
some.  BIOS diddling with the storage controller behind OS's back
causes a lot of trouble.  On certain machines, the BIOS expects the
storage controller to be in certain state on suspend and tries to
issue commands assuming that particular state triggering a minute long
CPU burn before finally entering suspend.  It just isn't worth it and
if BIOS wants to do it, it should be smart and don't do it if the
system is powering off in orderly manner (that is, driven by OS).

The double spindown happens due to combination of weirdities in the
BIOS and drive firmware.  Some drives like to spin up on FLUSH while
spun down even when the buffer is empty.  Others like to spin up on
STANDBY_IMMEDIATE recevied while spun down and then spin back down.

My guess is HP added BIOS spin down feature to BIOS and tested with
certain flavors of drives and then later found out that other drives
suffer from the new BIOS behavior and patched up their preloaded
windows driver.  It's a messy case requiring a messy workaround.

Thanks.

-- 
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/