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 17:30:16 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Christof Warlich <christof@...lich.name>
CC:	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: "EXT3-fs error" after resume from s2ram

On 07/07/2009 11:42 AM, Christof Warlich wrote:
> 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?

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