archive mirror
 help / color / mirror / Atom feed
From: Walt H <>
Cc: linux-kernel <>,
Subject: Re: [PATCH] pdcraid and weird IDE geometry
Date: Thu, 17 Jul 2003 07:37:18 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Arjan van de Ven wrote:
> On Thu, 2003-07-17 at 04:26, Walt H wrote:
>>compatible with the binary FastTrak.o module. I'm not much of a coder,
>>so if this could be done more efficiently than my attached patch, please
>>let me know. Please CC any replies. Thanks,
> (un)fortionatly it's not valid to use floating point in the kernel.
> Could you try the same thing by using u64 as type instead please ?

I've tried it using unsigned long, and it will fail to find the second
drive. The problem is that the FastTrak bios writes the superblock to
the second drive in the same place as if it had the geometry of the
first drive. How it does it, I do not know. What I know is that the
offset for the superblock on both drives lies at:  80418177

On the first drive, you get there like this:

capacity = 80418240, head = 16, sect = 63
lba = capacity / (head * sect) = 79780
lba = lba * (head * sect) = 80418240
lba = lba - sect = 80418177
This one's correct.

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

If integer results are used, the second drive's offset is returned as
80405262, which is not the offset for the superblock. It lies at the
same location as the first drive.

Insmodding the module compiled with ints as calculations results in this:
Jul 17 07:15:16 waltsathlon kernel:  ataraid/disc0/disc: p1 p2 < >
Jul 17 07:15:16 waltsathlon kernel: Drive 0 is 39266 Mb (33 / 0)
Jul 17 07:15:16 waltsathlon kernel: Raid0 array consists of 1 drives.
Jul 17 07:15:16 waltsathlon kernel: Promise Fasttrak(tm) Softwareraid
driver for linux version 0.03beta

While the one with floating calcs finds both drives.
My only guess at this point, is that the FastTrak bios is using
different geometry than what's reported to us. I'm not sure how this
would work, but I've thought about storing the offset of the working
drive to use in the event that the offset calculation fails and the
capacity is identical on additional drives. Seems kinda hacky to me, but
then what do I know :) I'm up for trying things, any other ideas?

-Walt Holman

  reply	other threads:[~2003-07-17 14:22 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 [this message]
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
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).