From owner-freebsd-current@FreeBSD.ORG Sun Oct 28 08:16:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C93AE16A521 for ; Sun, 28 Oct 2007 08:16:14 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.net [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA9713C494 for ; Sun, 28 Oct 2007 08:16:14 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:63827 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Im3Jd-000Fg7-2L for freebsd-current@freebsd.org; Sun, 28 Oct 2007 08:16:13 +0000 Message-ID: <47244548.9060301@conducive.net> Date: Sun, 28 Oct 2007 04:16:08 -0400 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20071028070732.0271A4500E@ptavv.es.net> In-Reply-To: <20071028070732.0271A4500E@ptavv.es.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New-bus unit wiring via hints.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2007 08:16:14 -0000 Kevin Oberman wrote: *snip* >>> >> You are exhibiting are very 'selective' memory (the wetware one). > > My wetware is subject to too many errors, but I don't think this is one. > Sorry - that was meant in re Marcel's belief that the mapping of logical name to hex baseport addr of serial ports had [at some point in time | ever] been 'fixed'. They never were. Though from IBM ISA onward they were at least a smaller 'pool' of two, three, or four. >>> Back in the days of v3 and v4, adding an IDE disk to a system could >>> cause existing drives to change their device names. This meant that the >>> fstab was unexpectedly wrong and things sometimes got messy. The option >>> to fix this was added in V4 and moved to GENERIC after a while. Now the >>> order in which IDE ports is scanned does not break the device names. >> That would be nice - if only it were true. > > It is very true and I didn't find it nice. It was fixed in head on > Dec. 8, 1999 with the new ATA driver. That's only a partial 'fix'. > Prior to that, if you had two > drives, one on each IDE bus as master, they were numbered 0 and 1. If > you added a slave disk on the first bus, it became drive 1 and the > master on the second bus became drive 2. An improvement, certainly. > You still get the same > behavior today if you remove the ATA_STATIC_ID option from your kernel. > Sorry - it is more complex than that, and for (at least) two reasons: 1) Presence of at least two, often three or more *onboard* controllers, not to mention those commonly added to the bus. The entire controller 'block' may be inserted before as well as after the 'legacy' one(s). Likewise some environments place a bus-attached controller before, others after the onboard one(s) in the ordering. This also changes with BIOS rev & 'race', specifics of the add-on gear, and even PCI slot-order. Has done since pre-ISA days, (jumpers, DIP). Still does so in current MB, such as ASUS P5K and Gigagbyte GA G33-DS3R. 2) Then there are the BIOS options, including 'mode' as in 'IDE', 'Native', 'Compatible', 'RAID' and/or 'AHCI' enable/disable choices. Result: Citing just those two newest boards, is that the 'legacy' IDE block retains sequence-order, reserving 'seats' 0 thru 3 for devices - attached or absent - just as you noted. That IS 'nice'. But no longer 'enough', and absent PATA devices, perhaps not even relevant. - Supplementary SATA controllers may logically enumerate their 'seats' in EITHER forward OR reverse order vs the hardware / MB silkscreen labels, AND may insert the resulting block either after or BEFORE the legacy IDE block (0 thru 3) - renumber it in the process. /dev/ad0 becoming /dev/ad9, for example. A casual user is likely to have to deal with at least *part* of that menage, if only once... An R&D shop experimenting with the BIOS settings has to keep multiple /fstab and paper 'cheat sheets' just to go multi.. That is part of the same 'mapping' issue as serial ports, but is a growing problem, whereas serial ports have all but disappeared in any case. > While I found most of your arguments rather weak, Marcel has me pretty > much convinced that he is right, so I will not waste everyone's time > with countering them. Not interested in 'argument'. Just pointing out the assumptions about immutability of hex-addr to logical device ID are flawed. Historical OR recent. That is not going away. A better 'fix' needs steering options adopted by the BIOS-provider(s). Don't hold your breath while waiting on those to arrive OR be consistent. Beyond our control. Plan to adapt. Bill