RE: [PATCH 1/3] mpt2sas: Wait for port enable to get complete before reporting devices to OS.

From: "Moore, Eric" <Eric.Moore@lsi.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Desai, Kashyap" <Kashyap.Desai@lsi.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Prakash, Sathya" <Sathya.Prakash@lsi.com>
Subject: RE: [PATCH 1/3] mpt2sas: Wait for port enable to get complete before reporting devices to OS.
Date: Mon, 13 Sep 2010 18:45:06 -0600	[thread overview]
Message-ID: <4565AEA676113A449269C2F3A549520F4918AF07@cosmail03.lsi.com> (raw)
In-Reply-To: <1284213782.2986.15.camel@mulgrave.site>

On Saturday, September 11, 2010 8:03 AM, James Bottomley wrote:
> >
> > IMO, this patch is really needed. Without it you probably will not be
> > able to boot after a fresh installation of OS when there are multiple
> > drives.
> 
> But that's an installer problem, not a kernel one.

Probably I'm not explaining it clearly.  I pretty sure this is a device driver issue.

The installation needs to occur on the same drive which BIOS is planning to booting to.    

Installer typically use the first reported drive to put the OS on.  Since LSI controller firmware does discovery, there is no guarantee which hard drive is going to be reported first. What I'm trying to say is discovery is random, and drives can be reported in any order.   If you have 100 hard drives in an enclosure, then the first reported drive can be any one of the 100 drives.  If you made a mistake an didn't get put OS onto the same drive BIOS is booting to, then your screwed the next time you boot up.

The boot drive info is passed from BIOS to driver via the bios configuration page I mentioned in the previous email.  The device driver makes sure the first hard drive reported is going to the drive your booting to.  Thus you need to wait for discovery to complete in order to find the correct drive, which is what this patch is all about.

> 
> >   The issue is Red Hat or SuSE is going to place the new OS on the
> > first reported drive, e.g. /dev/sda.  This boot drive information is
> > passed from the BIOS to the driver via a configuration page called
> > bios page 2.
> 
> I think both installers already take this into account: grub finds it
> when it builds the mapping table for the first time.

Yes if BIOS boots to the correct drive containing the OS and grub, then I agree with everything your saying.

> 
> >   The driver needs to wait for all firmware to complete discovery,
> > then search for boot device as indicated in the config page, then
> > report it first.  Without the patch, there is no guarantee which
> drive
> > or raid volume is getting reported first.  In other words the device
> > driver could of reported bios drive located at 0x83 as /dev/sda,
> > instead of 0x80, then when you reboot, the BIOS is not finding boot
> > partition. The end user can select the boot device by going into the
> > BIOS configuration utility; e.g. control C.
> 
> But you don't need it to be reported first.  The default install on
> both
> SLES and RHEL (and Fedora and openSUSE) is by label.  So once we get
> the
> boot drive from the mapping, we build its label into the grub config
> and
> fstab files and we always run from it, regardless of the order it
> appears in the bootup.
> 

Yes if BIOS boots to the correct drive containing the OS, then I agree that device labels, ids, path, and uuid  all work.