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]

Date:	Tue, 07 Jul 2009 19:42:02 +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 03:13 AM, Christof Warlich wrote:
>> Christof Warlich schrieb:
>>> Do you think I can fix the issue and circumvent the BIOS by passing
>>> the real geomerty of the drive as kernel boot parameters? This may
>>> also have the nice side effect that I could utilize the full capacity
>>> of the drive. I'll definitly do some experiments in this direction and
>>> let you know immediately if I succeed. Please let me know if this may
>>> be a waste of time or if you know an appropriate fix.
>> I retried with the boot parameter hda=16383,16,63 according to the
>> values that I got from fdisk, but without success. Anyway, I would have
>> expected that the kernel may have had a way to set the LBA48 geometry
>> instead of CHS, but it looks like I'm on the wrong track here...
>
> That's an old IDE parameter, not a libata one, and 160GB is way too 
> large to be settable using CHS. What you likely want to do is pass the 
> ignore_hpa=1 option to libata when it's loaded - either 
> libata.ignore_hpa=1 on kernel command line, or in /etc/modprobe.conf 
> if it's a module (how exactly to do this depends on your 
> distribution). That way the protected area on the disk will get 
> disabled and you can use the full capacity.
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?

View attachment "christof.vcf" of type "text/x-vcard" (279 bytes)