Robert Hancock schrieb:On 07/07/2009 03:13 AM, Christof Warlich wrote:Hmm - that doen't seem to fix it :-(:Christof Warlich schrieb:Do you think I can fix the issue and circumvent the BIOS by passingI retried with the boot parameter hda=16383,16,63 according to the
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.
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.
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?