Andries.Brouwer@cwi.nl wrote:
> From dfe@infinite-internet.net Sat Mar 25 02:31:05 2000
>
> > [So these error messages come precisely at the end of the
> > truncated disk. But it seems that you are using CHS,
> > not LBA addressing:
> >
> > hda: dma_intr: error=0x10 { SectorIdNotFound },
> > CHS=65530/15/61, sector=48737112
> >
> > and with CHS and 65531/16/63 it is clear that you cannot
> > get beyond 66055248 sectors. Why are you using CHS?]
> >
>
> Whoops! My fault. I incorrectly modified ide-disk.c to report the correct
> capacity by multiplying the logical geometry. I changed that now so it
> actually updates the lba_capacity field and still leaves LBA enabled. The
> drive still doesn't read past 66055248 sectors though.
>
> But the error messages will be different, I suppose.
>
> So I now removed my patch and am putting your patch onto the kernel.
>
> I have no idea which patch you might be referring to.
>
I cooked up a patch that calculated the BIOS C*H*S and set lba capacity to that..
It doesn't help though since you still can't do IO access to the disk past the
66055248 limit.
>
> 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 and 66055248 (which is exactly that
CHS multiplied out). The award bios then translates the LBA capacity to
4111/255/63, and EZ-Drive then reports 4982/255/63 which is much much closer to
the total capacity. What I really don't get though is if they are clipping the
drive at 66055248 sectors, how in the world do they expect to have it be readable
by DOS above 32GB unless EZ-Drive fixes this when it gets an extended BIOS call
for values over 66055248. Hmm.. I wonder if it would be possible to boot to DOS
with EZD loaded, check to see if the whole disk is accessible, and if so try
booting Linux from DOS and see if now Linux can see the full capacity.
>
> 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.
-Dave
-
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