James, We had internal discussion again after your input. Here is summary of discussion and we are agreed not to push this patchset for upstream. Please reject this submission. I have provided summary just for information point of view. Patch1: Wait for discovery to complete. "This patch is only required when fresh installation is happening. Next reboot onwards that part of code does not play any role" That is what a concern of James. James suggested do not wait for whole topology to discover. Let's start boot ASAP possible once grub is detected by BIOS. Issue solve by this patch: While installation user cannot identify end-device on which they want to install OS. Pros of this patch : It solves installation problem where we have huge topology attached to the system. It will report /dev/sda which is marked as "preferred boot device in BIOS page8". This way user can always make sure /dev/sda is a device where they want to install OS. Cons of this patch : After Installation, code provided in this patch is not required. There is a no need to always provide /dev/sda scsi device name to preferred boot device. Default RHEL and SLES installation is based on LABEL. (This is part of udev). Using this patch driver will wait for discovery to be completed by firmware later it will report prefer boot device first to the SML. Workaround: Without this patch customer can still solve real-time installation issue. They can opt for reduced topology when going for OS installation. e.a if they are 100 drivers in topology, they can disconnect 99 drivers for time being and only connect 1 driver on which they want to install OS. Once OS installation is done, connect those 99 devices back to topology. Patch 2: Actual enumeration logic. This patch is again an agreement of same /dev/sdX for preferred boot device, which is already known to upstream and only solution, is udev. LSI agreed with James comment. Attached is james last comment for reference. Thanks, Kashyap > -----Original Message----- > From: Moore, Eric > Sent: Tuesday, September 14, 2010 6:15 AM > To: James Bottomley > Cc: Desai, Kashyap; linux-scsi@vger.kernel.org; Prakash, Sathya > Subject: RE: [PATCH 1/3] mpt2sas: Wait for port enable to get complete > before reporting devices to OS. > > 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.