> My current understanding:
>
> (i) The drive reports geometry 16383/16/63 and 80041248 sectors
> (ii) With J46 jumper it reports 4092/16/63 and 80041248 sectors
> (iii) After running JUMPON.EXE the report still is 16383/16/63 and 80041248.
> (iv) After running JUMPON.EXE and with jumper it is 16383/16/63 and 66055248.
Well actually, the drive reports 65531/16/63
No, it doesn't.
Do not confuse the Linux kernel CHS with the disk identify data CHS.
> Now there is an unfortunate side effect of JUMPON.EXE + jumper on large
> Maxtor disks, which is also a side effect of the jumper on large IBM disks,
> namely that access of sector 66055248 and past fails with I/O errors.
> However, MaxBlast succeeds in accessing all of the disk, so this is
> still possible.
>
> A guess:
> Maybe what is done is effectively a SET MAX ADDRESS.
> If that is true, a READ NATIVE MAX ADDRESS (F8)
> followed by a SET MAX ADDRESS (F9) should make the disk
> accessible again.
>
> In all cases, a READ NATIVE MAX ADDRESS should give us
> the actual size.
>
> Do you think you can test this hypothesis?
Yeah, that sounds like what I was looking for. I will try inserting
some code which does that just before it goes to check the LBA capacity,
and see if it picks up on everything.
Excellent.
(A copy of the ATA-5 spec can be found at http://www.t13.org/.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:16 EST