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: <4A54C049.9080100@warlich.name>
Date:	Wed, 08 Jul 2009 17:50:33 +0200
From:	Christof Warlich <christof@...lich.name>
To:	Tejun Heo <tj@...nel.org>
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

Tejun Heo schrieb:
> 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"?
>   
I've addached both the output of dmesg (I hope this is what you want 
when asking for the full boot log) and the output of "lspci -nn" while 
the kernel boot parameter libata.ignore_hpa=1 was set.
>   
>>> 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.
>   
Thanks for the (updated) patch, I'll go and test it asap; I hope I get 
it done today, otherwise it may take until Friday as I'm busy tomorrow.

View attachment "lspci.log" of type "text/x-log" (2010 bytes)

View attachment "dmesg.log" of type "text/x-log" (38073 bytes)