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: <4A543FA5.1090608@warlich.name>
Date:	Wed, 08 Jul 2009 08:41:41 +0200
From:	Christof Warlich <christof@...lich.name>
To:	Robert Hancock <hancockrwd@...il.com>
CC:	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: "EXT3-fs error" after resume from s2ram

Robert Hancock schrieb:
> On 07/07/2009 11:42 AM, Christof Warlich wrote:
>> Hmm - that doen't seem to fix it :-(:
>>
>> After the reboot, fdisk still reports 137.4GB, and dmesg now contains
>> the line:
>>
>> ata1.00: device aborted resize (268435456 -> 312581808), skipping HPA
>> handling
>>
>> instead of
>>
>> ata1.00: HPA detected: current 268435456, native 312581808
>>
>> that we have seen without the libata.ignore_hpa=1 kernel command line
>> option.
>>
>> After s2ram -f -p, I still see the EXT3-fs error on resume. Is it worth
>> to take another log from this suspend /resume cycle?
>
> 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.
>
> 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.
--
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/