<br><br><div class="gmail_quote">On Sat, Oct 25, 2008 at 9:25 AM, Tom Sylla <span dir="ltr"><<a href="mailto:tsylla@gmail.com">tsylla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>Hopefully it is clear now how things can move like that. The Opterons<br>
won't move. It is possible with HT that other devices may exist on<br>
higher bus numbers without a bridge (real or fake) from bus 0. It is<br>
weird, and non-legacy compatible, so it should not happen with NB and<br>
SB devices. There are exceptions, though, when we connect our nc<br>
FPGAs, and put them at bus 20, we have no bridge in config space<br>
connecting them to bus 0. By default, the linux kernel will not find<br>
them (it does a normal PCI scan, looking for bridges, subordinates,<br>
etc). We must advertise the non-contiguous PCI busses in an ACPI table<br>
for Linux and Windows to "see" the higher busses that are not bridged<br>
to bus 0. (there are some other ways to force the linux kernel to find<br>
the devices, but the ACPI method works for all the current OSes we've<br>
tried). The point is that making the PCI busses discontiguous is<br>
"weird", and makes you jump through other hoops to play well with<br>
OSes.</blockquote><div> </div></div>linux kernel will do some legacy check from irq_routes_tables..... when acpi is disabled...<br><br>YH<br>