linux-kernel - Re: "EXT3-fs error" after resume from s2ram

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: <4A54AD1A.1040009@kernel.org>
Date:	Wed, 08 Jul 2009 23:28:42 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Christof Warlich <christof@...lich.name>
CC:	Robert Hancock <hancockrwd@...il.com>,
	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: "EXT3-fs error" after resume from s2ram

Hello, Christof, Robert.

Christof Warlich wrote:
> Robert Hancock schrieb:
>> Hmm, so we tried to disable the HPA and enable the entire disk
>> capacity, but the drive refused. But it somehow ends up in the HPA
>> disabled state upon resume. According to the ATA spec, the drive will
>> refuse SET MAX ADDRESS EXT commands after one has already been
>> executed upon power-on or reset. That suggests that the BIOS is
>> applying the HPA on bootup, but not on resume.

Arghhh... this is nasty.  Nasty.

I can't find previous messages.  Can you please post full boot log and
the output of "lspci -nn"?

>> Is there a BIOS update available for this machine?
> Updating the BIOS was the first thing I did when I got the machine,
> maybe two month ago. And only after that update suspend to disk began to
> work at least.
> 
> What about doing it the other way round: Forcing the kernel to apply the
> HPA on resume? Whitout knowing if this is possible at all with
> reasonable effort, it would bring us in sync having the HPA enabled for
> both bootup and resume, right?
> The only drawback would be that we stay having only the 128GiB available.
> 
> I'd assume that Windows XP may do it this way, as suspend to ram does
> work there and it also only sees the 128GiB.

AFAIK, wxp doesn't revalidate or doesn't consider device size while
revalidating disk after resume.  The size check during revalidation is
safety net which is there because ATA devices sometimes don't have
meaning identifiers and there are vendor specific configuration
options which may offset sectors differently and writing to devices in
such cases can lead to data loss.

If the bios configured HPA during boot, it should be restoring it on
resume too.  Maybe those commands have been filtered out.  Eh... no,
all filtered out commands are transfer mode related.  Dang.

One thing we can do is to make libata remember the native size on
initial probing and let revalidation consider it.  Yeap, that would
work.  Can you please test the attached patch and post full log
including boot and suspend/resume?

Thanks.

-- 
tejun

View attachment "revalidate-consider-native.patch" of type "text/x-patch" (2242 bytes)