[lkml]   [2003]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] pdcraid and weird IDE geometry
    Andries Brouwer wrote:
    > On Thu, Jul 17, 2003 at 03:58:38PM +0100, Alan Cox wrote:
    >>On Iau, 2003-07-17 at 15:37, Walt H wrote:
    >>>On the second drive, it's like this:
    >>>capacity = 80418240, head=255, sect = 63
    >>>lba = capacity / (head * sect) = 5005 int or 5005.80 float
    >>>lba = lba * (head * sect) = 80405325 int or 80418240.01 float
    >>>lba = lba - sect = 80405262 int or 80418177 float
    >>Would fixed point solve this. Start from capacity <<= 16 and then
    >>do the maths. That would put lba in 65536ths of a sector which
    >>should have the same result as your float maths
    > Ach Alan - I have not seen these earlier posts, but float or
    > fixed point here is just nonsense.
    > The purpose of
    > A = B/C;
    > A *= C;
    > can only be to round B down to the largest multiple of C below it.
    > Using infinite precision just turns this into
    > A = B;
    > He needs the first sector of the last cylinder, in a setup where
    > cylinders have size 16*63 or so, but the surrounding software
    > thinks that it is 255*63, a mistake.
    > I don't know anything about these RAIDs, but possibly it would
    > help to give boot parameters for this disk.
    > Maybe he is victim of the completely ridiculous
    > drive->head = 255;
    > in ide-disk.c.
    > (We have drive->head, the number of physical heads, and
    > drive->bios_head, the translation presently used by the BIOS -
    > or at least that is the intention. It is a bug if the former
    > is larger than 16. The latter may well be 255.)
    > Andries
    OK. Just got home from work. I've tried booting and specifying geometry
    via hdg=79780,16,63 hdg=noprobe etc... The geometry is accepted,
    however, drive access fails when trying to read the disk. This geometry
    is the geometry reported by hde (my old drive without screwy geometry).
    The code in calc_pdcblock_offset to calculate the offset is unchanged
    in my patch (except the date type conversion to float) and calls
    get_info_ptr for geometry. From what I can tell, this call returns the
    physical geometry of the disk so using fdisk to fool it doesn't work.
    I've also tried using unsigned long to store the calcs, multiplying the
    capacity by 100 to start, doing the maths and dividing the final lba by
    100. This doesn't work cause it overflows the data type. Won't I have
    similar problems using fixed point? At this point, my very limited
    knowledge of C keeps me from getting much further.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.040 / U:24.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site