linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Hein-Pieter van Braam <hp@syntomax.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Morrison, Tom" <tmorrison@empirix.com>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	Tejun Heo <htejun@gmail.com>, Alan Cox <alan@redhat.com>
Subject: Re: [PATCH] sata_mv:  Fix broken Marvell 7042 support.
Date: Wed, 05 Dec 2007 18:55:00 -0500	[thread overview]
Message-ID: <47573A54.5000004@rtr.ca> (raw)
In-Reply-To: <475735B4.7020401@rtr.ca>

Mark Lord wrote:
>...
>>> Yeah, that's my suspicion too.. they must have just simply moved
>>> the metadata to near the end instead of sector-8.
...
>> They write their RAID metadata near-ish to the end of the drive.
>> On my 320GB drives, it ended up at about -199853 sectors from
>> the end of the drive.  I have no idea what logic leads to them
>> choosing such a peculiar location for it.
> ..
> 
> Correction:  Metadata begins at sector -191192 on my drive.
...

Okay, I figured it out.

The final sector on the drive is at 625142448,
which in hex is sector 0x2542eab0.

The metadata on this drive is at sector 624951296,
which in hex is sector 0x25400000.

Note that this corresponds to a nice round giga-byte value.

So their RAID BIOS is just truncating the drive capacity down
to an even gigabyte, and then putting the metadata right after that.

I don't know what they might do with a drive whose capacity
is exactly some gigabyte value, though --> probably they just
subtract a gigabyte from that, to make room for the metadata.

So..  I do want to make this board usable under Linux.

To do so, requires that we perhaps do a similar capacity truncation
in sata_mv, but only if we see a metadata block at the expected location
(because a "Legacy" mode drive will use the *real* capacity,
placing the metadata in the 9th sector instead.

Jeff / Tejun / Alan:

What do you think we (I) should do here?

0. Initially, we need to further beef-up the recently added boot-time warning
about data-loss.   Again, the BIOS will have *already* written metadata to
the drive before we ever get to warn about it.  We cannot prevent it,
but we should at least warn the user about this absurdity.
It would also be useful to print the max "usable" capacity as part
of this warning (based on the calculation below).

Now we have a choice as to what else to do:

1.  Just clip the drive capacity similar to how the BIOS does it.

   clipped_sectors = ((physical_sectors - 1) & ~0x0000000fffff);

OR:

2. Check for the Highpoint BIOS signature at the metadata sector first,
and only clip capacity if we see their signature there.

OR:

3. Don't clip, but printk() WARNINGs whenever a write is performed
to data beyond the theoretical clipped capacity.

OR:

4. Something better (?).

?????????????????????

  reply	other threads:[~2007-12-05 23:55 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-01 18:07 [PATCH] sata_mv: Fix broken Marvell 7042 support Mark Lord
2007-12-01 18:16 ` Alan Cox
2007-12-01 22:45 ` Jeff Garzik
2007-12-03 12:27 ` Morrison, Tom
2007-12-03 14:47   ` hp
2007-12-03 14:56     ` Morrison, Tom
2007-12-03 17:26     ` Mark Lord
2007-12-03 18:14       ` Mark Lord
2007-12-03 18:30         ` Jeff Garzik
2007-12-03 18:32           ` Mark Lord
2007-12-03 18:37             ` Morrison, Tom
2007-12-03 18:40               ` Mark Lord
2007-12-03 18:44                 ` Mark Lord
2007-12-03 18:42                   ` Alan Cox
2007-12-03 19:12                     ` Mark Lord
2007-12-03 20:40                       ` Mark Lord
2007-12-03 23:59                         ` Mark Lord
2007-12-04  0:20                           ` [PATCH] sata_mv: Warn about Highpoint RocketRAID BIOS treatment of "Legacy" drives Mark Lord
2007-12-04 19:09                             ` Jeff Garzik
2007-12-03 18:30         ` [PATCH] sata_mv: Fix broken Marvell 7042 support Mark Lord
2007-12-03 20:11           ` Hein-Pieter van Braam
2007-12-03 20:24             ` Mark Lord
2007-12-03 20:37               ` Hein-Pieter van Braam
2007-12-03 20:54                 ` Mark Lord
2007-12-03 22:28                   ` Hein-Pieter van Braam
2007-12-03 23:37                     ` Mark Lord
2007-12-03 22:48                   ` Hein-Pieter van Braam
2007-12-03 23:10                     ` Alan Cox
2007-12-03 23:33                       ` Mark Lord
2007-12-03 23:34                         ` Alan Cox
2007-12-03 23:47                       ` Mark Lord
2007-12-03 23:47                         ` Alan Cox
2007-12-04  0:01                       ` Hein-Pieter van Braam
2007-12-04  0:07                         ` Mark Lord
2007-12-04  0:17                           ` Hein-Pieter van Braam
2007-12-04  0:23                             ` Mark Lord
2007-12-04  0:35                               ` Hein-Pieter van Braam
2007-12-04  0:36                               ` Mark Lord
2007-12-04 23:56                               ` Hein-Pieter van Braam
2007-12-05 22:45                                 ` Mark Lord
2007-12-05 23:22                                   ` Mark Lord
2007-12-05 23:35                                     ` Mark Lord
2007-12-05 23:55                                       ` Mark Lord [this message]
2007-12-06  0:02                                         ` Jeff Garzik
2007-12-06  3:57                                           ` Mark Lord
2007-12-06  4:45                                             ` Jeff Garzik
2007-12-06 22:24                                               ` Mark Lord
2007-12-06  4:03                                           ` Mark Lord
2007-12-06  4:43                                             ` Jeff Garzik
2007-12-06 22:23                                               ` Mark Lord
2007-12-07  2:22                                                 ` Jeff Garzik
2007-12-06 22:32                                           ` Mark Lord
2007-12-04 19:21                             ` Hein-Pieter van Braam
2007-12-04  1:17           ` Mark Lord

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=47573A54.5000004@rtr.ca \
    --to=liml@rtr.ca \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alan@redhat.com \
    --cc=hp@syntomax.com \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=tmorrison@empirix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).