archive mirror
 help / color / mirror / Atom feed
From: Walt H <>
To: Andries Brouwer <>
Cc: Alan Cox <>,,
	Linux Kernel Mailing List <>,
Subject: Re: [PATCH] pdcraid and weird IDE geometry
Date: Thu, 17 Jul 2003 19:33:00 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.


  reply	other threads:[~2003-07-18  2:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-17  2:26 Walt H
2003-07-17  8:49 ` Arjan van de Ven
2003-07-17 14:37   ` Walt H
2003-07-17 14:58     ` Alan Cox
2003-07-17 15:34       ` Jeff Garzik
2003-07-17 16:03         ` Andries Brouwer
2003-07-17 15:34       ` Andries Brouwer
2003-07-18  2:33         ` Walt H [this message]
2003-07-18  8:58           ` Andries Brouwer
2003-07-18 13:56             ` Walt H
2003-07-17 12:19 ` David Zaffiro
2003-07-18 14:51 Walt H

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] pdcraid and weird IDE geometry' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).