New-bus unit wiring via hints..
韓家標 Bill Hacker
askbill at conducive.net
Sun Oct 28 01:16:14 PDT 2007
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
More information about the freebsd-current
mailing list