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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
