On Wed, 08 Aug 2007 11:21:08 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Alan Cox wrote:
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
Ok the report in that thread
Em Wed, 08 Aug 2007 11:21:08 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| Alan Cox wrote:
| I'd rather know what is going on here. A drive can legitimately
| support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
| READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
|
| Ok the report in that
Luiz Fernando N. Capitulino wrote:
Em Wed, 08 Aug 2007 11:21:08 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| Alan Cox wrote:
| I'd rather know what is going on here. A drive can legitimately
| support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
| READ_NATIVE_MAX_EXT is mandatory if
-- Original message --
From: Tejun Heo [EMAIL PROTECTED]
Luiz Fernando N. Capitulino wrote:
Em Wed, 08 Aug 2007 11:21:08 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| Alan Cox wrote:
| I'd rather know what is going on here. A drive can legitimately
|
Em Wed, 08 Aug 2007 16:50:39 +
[EMAIL PROTECTED] (Quel Qun) escreveu:
| -- Original message --
| From: Tejun Heo [EMAIL PROTECTED]
| Luiz Fernando N. Capitulino wrote:
| Em Wed, 08 Aug 2007 11:21:08 +0900
| Tejun Heo [EMAIL PROTECTED] escreveu:
|
| |
Em Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
| the drive. If the horkage is set, all HPA operations are skipped.
|
| While at
Luiz Fernando N. Capitulino wrote:
Em Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
| the drive. If the horkage is set, all
Em Wed, 08 Aug 2007 00:00:28 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| Luiz Fernando N. Capitulino wrote:
| Em Tue, 7 Aug 2007 14:42:50 +0900
| Tejun Heo [EMAIL PROTECTED] escreveu:
|
| | HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| | on READ_NATIVE_MAX_EXT.
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage is set, all HPA operations are skipped.
I'd rather know
Alan Cox wrote:
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage is set, all HPA operations are skipped.
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Jeff
From: Ben Collins [EMAIL PROTECTED]
The original HPA patch that Kyle worked
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no?
No - and we hit this specific case in old IDE with some Maxtor drives.
Haven't tried that but the problem is that the
On Tue, 07 Aug 2007 11:47:38 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Looks basically
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
Ok the report in that thread is different. The offending Maxtor simply
aborts the read_native_max_ext
-
To unsubscribe
Alan Cox wrote:
On Tue, 07 Aug 2007 11:47:38 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Alan Cox wrote:
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no?
No - and we hit this specific case in old IDE with some Maxtor drives.
Hmmm... Looking up the spec...
On 08/07/2007 11:36 AM, Tejun Heo wrote:
Alan Cox wrote:
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage
There's also this Fedora bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251047#c2
...where after an error on the slave device the master starts throwing
HPA errors after the port is reset. Don't know if it's related or
not...
Looks unrelated. You get a timeout
ata2.01:
Well, it's what the ide driver does. BTW, according to the spec, we
need to test bit 14 and 15 of word 87 before trusting any value the
device reports in words 85-87 and 120, which libata currently doesn't
do. Are we leaving this out intentionally (for broken devices) or just
did we just
Alan Cox wrote:
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
Ok the report in that thread is different. The offending Maxtor simply
aborts the read_native_max_ext
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage is set, all HPA operations are skipped.
While at it, make HPA test a bit more reliable by also checking
ata_id_has_hpa().
21 matches
Mail list logo
