Re: [PATCH] pdcraid and weird IDE geometry

From: Walt H (waltabbyh@comcast.net)
Date: Thu Jul 17 2003 - 21:33:00 EST


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.

-Walt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:32 EST