> Date: Tue, 6 Apr 2010 21:39:48 -0500
> From: Marco Peereboom <sl...@peereboom.us>
>
> Why?
>
> RAID mode is NOT a valid ID for ahci.
Actually, it is. The hardware works exactly the same way if the
controller is in RAID mode or in AHCI. The different PCI ID acts
simply as a flag to indicate that the disks behind the controller
might contain metadata for one of the propriatery Intel software RAID
solutions. I guess it makes sure that Windows loads a different
driver that understands that metadata format instead of loading the
generic AHCI driver that would overwrite the metadata and destroy any
RAID volumes behind it. Oh, and the BIOS probably knows how to boot
from these RAID volumes as well. Note that I say *might* contain
metadata here; only when you actually create a RAID volume (through
the BIOS or other tools) the metadata will be actually there. I don't
know how Windows treats blank disks behind such a controller in RAID
mode.
Now to the question how OpenBSD should treat these controllers in RAID
mode. Ideally softraid would understand the Intel metadata format and
do the right thing. For that to work, these RAID ID's will have to be
added to the ahci(4) driver, otherwise softraid will not have access
to the disks that form the RAID volume and can't do its thing.
Perhaps some infrastructure is needed to communicate the fact that
disks are in RAID mode with softraid, such that softraid doesn't have
to check for a zillion of metadata formats. I can imagine though that
adding support for the Intel metdata format to softraid is not a
terribly high priority. Doing so really only makes sense if you want
to share the volume with Windows, otherwise you're probably much
better off using plain softraid on these disks (assuming booting from
plain softraid works).
Meanwhile, we probably should not add these RAID IDs to the ahci(4)
driver (and remove the ones that are already there). That makes sure
that there is no risk we accidentally overwrite the Intel-specific
metadata on these disks. People simply have to flip the controller
back in AHCI mode to access their disks (taking the hopefully
conscious decision to destroy any existing RAID volumes).
> On Tue, Apr 06, 2010 at 09:09:47PM -0400, Brad wrote:
> > On Mon, Mar 15, 2010 at 10:19:18PM -0400, Brad wrote:
> > > The following diff adds the remaining PCI ids for the Intel AHCI
> > > controllers with a RAID mode to the existing ICH8 / ICH10 PCI ids.
> > >
> > >
> > > Add the Intel ICH7 (82801GHM / GR), ICH9 (82801I) and ICH10 (82801JD),
> > > 6321ESB and PCH (3400) RAID mode PCI ids.
> >
> > Updated for the latest rev of ahci.c.
> >
> >
> > Index: ahci.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> > retrieving revision 1.161
> > diff -u -p -r1.161 ahci.c
> > --- ahci.c 6 Apr 2010 13:59:37 -0000 1.161
> > +++ ahci.c 7 Apr 2010 00:40:18 -0000
> > @@ -440,11 +440,25 @@ static const struct ahci_device ahci_dev
> > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
> > NULL, ahci_ati_sb600_attach },
> >
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_1,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_2,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_1,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_2,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GHM_RAID,
> > + NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GR_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801H_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_RAID,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JD_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JI_RAID,
> > NULL, NULL },
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
