On Tue, May 29, 2012 at 10:14:51AM -0700, Yinghai Lu wrote:
>On Tue, May 29, 2012 at 4:59 AM, Richard Yang
><weiyang@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> I think about this issue again, this behavior of kernel will bring some
>> unconvenience to the user.
>>
>> Do you think the kernel could handle this situation?
>
>in this extreme case, you may need user to do some comprise.
>
>We should always try to use setting from BIOS if it is sane.
>
>Yinghai
Yinghai
+-------+
| | root bridge(0,255)
+---+---+
| Bus 0
-----+-----------+------------------------------+--
| |
| |
| |
+----+----+ +-----+-----+
| | B1(1,15) | |B2(32,35)
+----+----+ +-----+-----+
| Bus 1 | Bus 32
-----+----------------------- -----------
|
+----+----+
| | B3
+---------+
I reread the current code, v3.4, in linus tree,
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
And I come up with another condition which will have a problem when
kernel is not given the parameter, pci=assign-busses.
Same condition as previous:
-------------------------------------------------------------------------------
B1 and B2 works fine with the BIOS and get the bus number assigned.
B3 is not probed by BIOS.
Difference between the previous example:
-------------------------------------------------------------------------------
In this case, B2 is assigned bus range (32, 35), which has a gap between
B1 number range (1, 15).
When kernel meets B3 in second pass, B3 will be assigned with bus number
16. Well, this time the bus number 16 doesn't overlap with bus number of
B2.
But, the pci_fixup_parent_subordinate_busnr() will not work since the
pci=assign-buses is not passed to kernel.
So B1's bus window is still (1,15) not (1,16).
BTW, is this also a extrem case?
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
