Mark Lord wrote:
Jeff Garzik wrote:
...
If you pop the BIOS chip or plug the card into a non-x86 box (or any
of several other alternatives), the problem is likely to go away.
..
Yeah, I was hoping for a removable BIOS chip, but it's soldered in place.
And that's not a solution for most users anyway.
That was an example, silly :) I'm not asking users to pop out chips.
I'm illustrating that they are separate and distinct pieces, and you
cannot assume.
Boot into a non-x86 platform, or use your x86 BIOS to disable all
optional ROMs, and the BIOS-stomps-data issue goes away.
I'm not saying the _problem_ goes away; instead I am illustrating why it
is incorrect to update sata_mv for this problem. The solution belongs
elsewhere, because the problem is not with the chip, but the BIOS.
Continuing with the other emails...
What other cards do we support that automatically overwrite user data
without confirmation or notice of any kind?
If you use any vendor RAID (BIOS RAID / "fake RAID"), and fail to use
DM+dmraid, then data corruption occurs due to lack of knowledge about
the presence of underlying BIOS-created RAID metadata.
Your case is just another case of problems caused by lack of knowledge
of the underlying vendor RAID that the BIOS insists upon using.
I'm pretty sure the most recently Fedora release has full dmraid support
for known formats, so AFAICS the task at hand should be simply to figure
out how to identify the underlying vendor RAID (on-disk signatures are
greatly preferred over PCI ID matching), and update dmraid accordingly.
Welcome to the suck that is BIOS RAID :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
