From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 28 18:26:54 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE8B31E1 for ; Sun, 28 Sep 2014 18:26:53 +0000 (UTC) Received: from nm27-vm5.access.bullet.mail.bf1.yahoo.com (nm27-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.228]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B72A63D for ; Sun, 28 Sep 2014 18:26:53 +0000 (UTC) Received: from [66.196.81.163] by nm27.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2014 18:24:23 -0000 Received: from [66.196.81.140] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2014 18:24:23 -0000 Received: from [127.0.0.1] by omp1016.access.mail.bf1.yahoo.com with NNFMP; 28 Sep 2014 18:24:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 641230.67594.bm@omp1016.access.mail.bf1.yahoo.com Received: (qmail 94540 invoked by uid 60001); 28 Sep 2014 18:24:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1411928663; bh=q6rdIwwkZdgvEJSJFvrJ6+c2BjabNPeC37i2lrmLDaE=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MiDOH3Ky2lbiqCctYGARtf2oNdGuAkttDkRp3JTa7tWCexjHig3R0gE+BLH4UsGQ3Mdqs9LH6+tyLIgJVOGwZgwwsBgvuOGy26pdy8amPyamayPVPtTL3O5Vxf1f5VQPvpTLET1znSoXSuXyqjY40U4Ql1Io/DejIPigYVaUGvM= X-YMail-OSG: QkPYOewVM1nKrIQ4eIb3hMiSYzqrf9k0ROXFlkCvsTZT9lP lKYhko2TuTDIhGwoq3FOnsOdHV8ZVg7boX2nRi7eEerUMjM9bIkOiSZYff6O lVNQAu2MALUTzoN8gbMR529KK9oyfU9lWnFLkxkxrIzuusEIv7X5N8Xc5Vmk iSs1ku9MJORECCE2tC1yDOLLYA9sVlU1CvrvOKUtp.3uzpTmBccug6I8g17j Isc.metmw9yPhHcA5Ks8jXIO1rB3903UmRMl.pQz0h_XwBwvtxYsJHDuxJ5G awznfZEexQfx3Bmoa3CxM_eTmnNq6fAotqJYLimoI75490ZDomS6v_cM5cyn 5E3FZ_qZZmedJdIdAl67ZA26t3VQkZbU1CZWDseJdXmE3RI8CJBgUTdz821B 58PcO5GJa0sUqRGl8njR2IvK5ZkaJuf_jnoHpXS3cOGIWygtO_J32woRDXdN ogrfD_5RS5Ibz.sxupQDcT1uN1HnQq0blGk2nlEelUXUOeZjaftviMhy28zw Tqa3MPPxe1XQV5TzlhTmYX3n.GU.OghzchOFEZuCHLJEn8YWKthOxmOR1N7L 8kJvxhQbb9A-- Received: from [162.239.0.170] by web180901.mail.ne1.yahoo.com via HTTP; Sun, 28 Sep 2014 11:24:22 PDT X-Rocket-MIMEInfo: 002.001, Tm8sIEJJT1MgYm9vdCBpcyBjb21wbGV0ZWx5IGlycmVsZXZhbnQgdG8gdGhpcyBwcm9ibGVtLiAKCkl0IGxvb2tzIGxpa2UgSSBoYXZlIHRvIHJlLWFkZHJlc3MgdGhpcyBpc3N1ZSBkZWJhdGVkIDE1LTIwIHllYXJzIGFnby4KCkZpcnN0IG9mIGFsbCwgbGV0J3MgY2xlYXIgQklPUyBxdWVzdGlvbiBzbyB5b3Ugd2lsbCBub3QgYXJndWUgaXQgYWdhaW4uCkJJT1MgYm9vdCBzZXF1ZW5jZSBjYW4gYmUgc3BlY2lmaWVkIGluIGFueSBvcmRlciwgYW5kIGl0IGJvb3RzIGRlc2lyZWQgIGRyaXZlIGNvcnJlY3RseS4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <1411851225.9364.YahooMailNeo@web180902.mail.ne1.yahoo.com> Message-ID: <1411928662.22540.YahooMailNeo@web180901.mail.ne1.yahoo.com> Date: Sun, 28 Sep 2014 11:24:22 -0700 From: Jin Guojun Reply-To: Jin Guojun Subject: Re: Inproper ada# assignment in 10-BETA2 To: Mehmet Erol Sanliturk In-Reply-To: MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 28 Sep 2014 18:53:10 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "hackers@freebsd.org" , questions freebsd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 18:26:54 -0000 No, BIOS boot is completely irrelevant to this problem. It looks like I have to re-address this issue debated 15-20 years ago. First of all, let's clear BIOS question so you will not argue it again. BIOS boot sequence can be specified in any order, and it boots desired drive correctly. If not, 10.1-BETA2 will not be loaded, and we will not see this problem, period. After 10.1-BETA2 is loaded and booted, it enumerates drive(s) dynamically to assign ID to ada or da node. Kernel clearly knows which drive is ad1, 2, 3, ..., but it does not assigned proper ID to existing drive(s) for ada and da nodes. That is, ad note IDs are still correct, but ada and da node IDs are wrong. The dynamic enumeration is likely used for moving a boot drive from on system to another or from one bus to another without manually modifying fstab entries. That is, this mechanism wants to ensure no matter where this drive is plugged in, Boot drive should be always enumerated as ID 0 or the ID installation assigned to. How to ensure this? For boot drive, this is relatively easy -- the boot drive is always this first one in general, so this drive should always enumerated as ada0 or da0. If installation has assigned drive ID to not 0 somehow, then generic enumeration apply. Generic enumeration is drive serial number (S#) based enumeration mechanism, which has been used for at least two decades. For example, if two drives installed and their S# are AAAA and XXXXX (boot drive), regardless what SATA port they resides at -- AAAA at ad9 and XXXXX at ad5, We knew installation will likely name drive XXXXX as ada0 and AAAA as ada1. In fixed fashion, drive XXXXX is ad5 and AAAA is ad9, when a new drive is inserted as ad0, we knew drive XXXXX will be still ad5 and boot should not fail. But in current 10.1-BETA2, the new drive is likely will be ada0, drive XXXXX will be ada1, and AAAA will be ada2, then boot will fail. In case if new drive is inserted as ad8, drive XXXXX will remain as ada0 but AAAA will be ada21. Even though boot will succeed in this case, but mounting drive AAAA will fail. The S#-based enumeration will record the S# for corresponding device ID in a dynamic boot configuration file, which is used in boot time to determine what device ID should be assigned to each drive. After existing drive ID has been enumerated, any new drive(s) will be given a unused ID sequentially. This ensures that existing drive(s) will always get device ID originally assigned to, so the disk mounting operation will never fail no matter where a disk drive (has FreeBSD already installed) is plugged in. Hopefully, this explains what is correct the dynamic enumeration operation. In old time, we have a mechanisms to alter the dynamic enumeration to fixed one, but I do not know if this mechanism is still in 10.x-R. Because it looks like that current developers have no knowledge about this concept, I am going to open a bug to track this problem again soon, unless I will hear if we have a work around for this problem. On Saturday, September 27, 2014 3:15 PM, Mehmet Erol Sanliturk wrote: On Sat, Sep 27, 2014 at 1:53 PM, Jin Guojun wrote: Installed 10-BETA2 on SATA port 4 (ad8) and then added another SATA port 3 (ad6), the system has not correctly enumerate the ada # for the boot device. >As original boot (without the second SATA drive), the ad8 is enumerated as ada0 -- the boot drive: > >Sep 24 22:51:30 R10-B2 kernel: ada0 at ahcich2 bus 0 scbus2 target 0 lun 0 >Sep 24 22:51:30 R10-B2 kernel: ada0: ATA-8 SATA 2.x device >... >Sep 24 22:51:30 R10-B2 kernel: ada0: Previously was known as ad8 > > >However, after added another SATA drive (ad6), this new drive is assigned to ada0, but ad8 has changed to ada1. This is incorrect dynamic device assignment. FreeBSD has kept using fixed disk ID assignment due to the same problem introduced in around 4-R (or may be slightly later), and after a simple debate, a decision was made to use fixed drive ID to avoid such hassle. > >If now we want to use dynamic enumeration for drive ID# assignment, this has to be done correctly -- boot drive MUST assigned to 0 or whatever the # as installation assigned to; otherwise, adding a new drive will cause system not bootable, or make other existing drive not mountable due to enumeration # changes. > >Has this been reported as a known problem for 10-R, or shall I open a bug to track? > >-Jin > One point should be checked : On mainboards SATA ports are numbered from 0 or 1 to upward . BIOS always uses first SATA drive for boot . This is NOT related to the operating system . Therefore , it is necessary to check port numbers of existing drives and the bootable SATA drive should be connected to the smallest numbered SATA port among existent drives . For example , assume bootable drive is connected to SATA port 2 . New drive should be connected to a higher numbered SATA port . If there are only two SATA ports , then bootable drive should be connected to the first SATA port . If mainboard BIOS allows definition of any SATA port for boot , and bootable SATA port and drive is specified in there , again it may boot from that drive . Up to now , I did not see any BIOS which supplies such an ordering among SATA ports . Please check your BIOS for such a feature . If it is present you may use it , otherwise it is necessary to reconnect SATA cables . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 28 21:05:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49B97A0B for ; Sun, 28 Sep 2014 21:05:35 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 244A780F for ; Sun, 28 Sep 2014 21:05:34 +0000 (UTC) Received: from [172.16.0.55] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1DBB3545ED for ; Sun, 28 Sep 2014 21:05:26 +0000 (UTC) Message-ID: <54287814.9000207@freebsd.org> Date: Sun, 28 Sep 2014 17:05:24 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Inproper ada# assignment in 10-BETA2 References: <1411851225.9364.YahooMailNeo@web180902.mail.ne1.yahoo.com> <1411928662.22540.YahooMailNeo@web180901.mail.ne1.yahoo.com> In-Reply-To: <1411928662.22540.YahooMailNeo@web180901.mail.ne1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 21:05:35 -0000 On 09/28/2014 14:24, Jin Guojun wrote: > No, BIOS boot is completely irrelevant to this problem. > > It looks like I have to re-address this issue debated 15-20 years ago. > > First of all, let's clear BIOS question so you will not argue it again. > BIOS boot sequence can be specified in any order, and it boots desired drive correctly. > > If not, 10.1-BETA2 will not be loaded, and we will not see this problem, period. > > After 10.1-BETA2 is loaded and booted, it enumerates drive(s) dynamically to assign ID to ada or da node. > > Kernel clearly knows which drive is ad1, 2, 3, ..., but it does not assigned proper ID to existing drive(s) for ada and da nodes. > > That is, ad note IDs are still correct, but ada and da node IDs are wrong. > > The dynamic enumeration is likely used for moving a boot drive from on system to another > or from one bus to another without manually modifying fstab entries. > That is, this mechanism wants to ensure no matter where this drive is plugged in, > > Boot drive should be always enumerated as ID 0 or the ID installation assigned to. > > How to ensure this? For boot drive, this is relatively easy -- the boot drive is always this first one in general, > > so this drive should always enumerated as ada0 or da0. > If installation has assigned drive ID to not 0 somehow, then generic enumeration apply. > Generic enumeration is drive serial number (S#) based enumeration mechanism, which has been used for at least two decades. > For example, if two drives installed and their S# are AAAA and XXXXX (boot drive), > regardless what SATA port they resides at -- AAAA at ad9 and XXXXX at ad5, > We knew installation will likely name drive XXXXX as ada0 and AAAA as ada1. > In fixed fashion, drive XXXXX is ad5 and AAAA is ad9, when a new drive is inserted as ad0, > > we knew drive XXXXX will be still ad5 and boot should not fail. > But in current 10.1-BETA2, the new drive is likely will be ada0, drive XXXXX will be ada1, and AAAA will be ada2, then boot will fail. > In case if new drive is inserted as ad8, drive XXXXX will remain as ada0 but AAAA will be ada21. > Even though boot will succeed in this case, but mounting drive AAAA will fail. > > > The S#-based enumeration will record the S# for corresponding device ID in a dynamic boot configuration file, which is used in boot time to determine what device ID should be assigned to each drive. > After existing drive ID has been enumerated, any new drive(s) will be given a unused ID sequentially. > This ensures that existing drive(s) will always get device ID originally assigned to, so the disk mounting operation will never fail no matter where a disk drive (has FreeBSD already installed) is plugged in. > > > Hopefully, this explains what is correct the dynamic enumeration operation. > In old time, we have a mechanisms to alter the dynamic enumeration to fixed one, but I do not know if this mechanism is still in 10.x-R. > > Because it looks like that current developers have no knowledge about this concept, > I am going to open a bug to track this problem again soon, unless I will hear if we have a work around for this problem. > > > > On Saturday, September 27, 2014 3:15 PM, Mehmet Erol Sanliturk wrote: > > > > > > > > On Sat, Sep 27, 2014 at 1:53 PM, Jin Guojun wrote: > > Installed 10-BETA2 on SATA port 4 (ad8) and then added another SATA port 3 (ad6), the system has not correctly enumerate the ada # for the boot device. >> As original boot (without the second SATA drive), the ad8 is enumerated as ada0 -- the boot drive: >> >> Sep 24 22:51:30 R10-B2 kernel: ada0 at ahcich2 bus 0 scbus2 target 0 lun 0 >> Sep 24 22:51:30 R10-B2 kernel: ada0: ATA-8 SATA 2.x device >> ... >> Sep 24 22:51:30 R10-B2 kernel: ada0: Previously was known as ad8 >> >> >> However, after added another SATA drive (ad6), this new drive is assigned to ada0, but ad8 has changed to ada1. This is incorrect dynamic device assignment. FreeBSD has kept using fixed disk ID assignment due to the same problem introduced in around 4-R (or may be slightly later), and after a simple debate, a decision was made to use fixed drive ID to avoid such hassle. >> >> If now we want to use dynamic enumeration for drive ID# assignment, this has to be done correctly -- boot drive MUST assigned to 0 or whatever the # as installation assigned to; otherwise, adding a new drive will cause system not bootable, or make other existing drive not mountable due to enumeration # changes. >> >> Has this been reported as a known problem for 10-R, or shall I open a bug to track? >> >> -Jin >> > > > > > One point should be checked : > > > On mainboards SATA ports are numbered from 0 or 1 to upward . > > BIOS always uses first SATA drive for boot . This is NOT related to the operating system . > > Therefore , it is necessary to check port numbers of existing drives and the bootable SATA drive should be connected > > to the smallest numbered SATA port among existent drives . > > > > For example , assume bootable drive is connected to SATA port 2 . > > New drive should be connected to a higher numbered SATA port . > > If there are only two SATA ports , then bootable drive should be connected to the first SATA port . > > > If mainboard BIOS allows definition of any SATA port for boot , and bootable SATA port and drive is specified in there , again it may boot from that drive . Up to now , I did not see any BIOS which supplies such an ordering among SATA ports . Please check your BIOS for such a feature . If it is present you may use it , otherwise it is necessary to reconnect SATA cables . > > > > Thank you very much . > > > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > The Correct solution is probably to use the diskid (/dev/diskid/) or a label (gpt label, ufs label, glabel) so the device name doesn't matter so much. My understanding is that the new 'ada' device names, the devices are named linearly. -- Allan Jude