Mailing List Archive: Linux: Kernel

One problem in reassign pci bus number?

1 2

View All

Index | Next | Previous | View Threaded

yinghai at kernel

May 7, 2012, 8:42 PM

Post #26 of 41 (60 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, May 7, 2012 at 7:46 PM, Richard Yang <weiyang [at] linux> wrote:
> On Sun, May 06, 2012 at 07:04:09PM -0700, Yinghai Lu wrote:
>>On Sun, May 6, 2012 at 6:17 PM, Richard Yang <weiyang [at] linux> wrote:
>>> so this free space will be combined with the free space got from
>>> parent, form a big space to meet the requirement.
>>>
>>> This is the general idea about probe_resource()?
>>>
>>> And this is the design decision to find the free space at the end
>>> of top, even at the start we have more free space?
>>
>>no, probe_resource will get from start if space is big enough.
>>
>>if not, it will try to extend top.
>
> Hmm... for example we still have this
> parent[70-160]
> brother1[70-80] res[90-150] brother2[151-160]
> ->child[105-140]
>
> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
> IORESOURCE_PCI_FIXED);
>
> I think this call is used to allocate a res of size 16 under res.
> When there is no enough free space, it will expend res, and res->parent.
>
> While in this situation, res doesn't have enough free space. so it need
> to expend itself.
>
> In the probe_resource() it tries to extend res on the right side.
> So even there is enough space between brother1 and res, I think the
> probe_resource() will not return 0.
>
> Do you think my analysis is correct?

it will reduce needed size one by one. so at last it will return
[91, 104]

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 9, 2012, 8:35 PM

Post #27 of 41 (64 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, May 07, 2012 at 08:42:59PM -0700, Yinghai Lu wrote:
>>>no, probe_resource will get from start if space is big enough.
>>>
>>>if not, it will try to extend top.
>>
>> Hmm... for example we still have this
>> parent[70-160]
>> brother1[70-80] res[90-150] brother2[151-160]
>> ->child[105-140]
>>
>> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
>> IORESOURCE_PCI_FIXED);
>>
>> I think this call is used to allocate a res of size 16 under res.
>> When there is no enough free space, it will expend res, and res->parent.
>>
>> While in this situation, res doesn't have enough free space. so it need
>> to expend itself.
>>
>> In the probe_resource() it tries to extend res on the right side.
>> So even there is enough space between brother1 and res, I think the
>> probe_resource() will not return 0.
>>
>> Do you think my analysis is correct?
>
>it will reduce needed size one by one. so at last it will return
>[91, 104]
Yes, agree. This is the current behavior.

While in this case.
70-160]
brother1[70-80] res[90-150] brother151-160]
->child

There is free space between 81-89, and 90-104. These two free range add
up to 25, which is more than the required space, 16.

If we have this resource tree.
parent[70-180]
brother1[70-80] re[90-150] brothr2[170-180]
d[105-140]

There are enough free space between res and brother2.
Then probe_resource will return [141-156] with size 16.
And also expend res.

So I mean this is the design decision to not count in the free space on
the left? Even there is enough free space?

>
>Yinghai

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

May 9, 2012, 10:42 PM

Post #28 of 41 (60 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Wed, May 9, 2012 at 8:35 PM, Richard Yang <weiyang [at] linux> wrote:
> On Mon, May 07, 2012 at 08:42:59PM -0700, Yinghai Lu wrote:
>>>>no, probe_resource will get from start if space is big enough.
>>>>
>>>>if not, it will try to extend top.
>>>
>>> Hmm... for example we still have this
>>> parent[70-160]
>>> brother1[70-80] res[90-150] brother2[151-160]
>>> ->child[105-140]
>>>
>>> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
>>> IORESOURCE_PCI_FIXED);
>>>
>>> I think this call is used to allocate a res of size 16 under res.
>>> When there is no enough free space, it will expend res, and res->parent.
>>>
>>> While in this situation, res doesn't have enough free space. so it need
>>> to expend itself.
>>>
>>> In the probe_resource() it tries to extend res on the right side.
>>> So even there is enough space between brother1 and res, I think the
>>> probe_resource() will not return 0.
>>>
>>> Do you think my analysis is correct?
>>
>>it will reduce needed size one by one. so at last it will return
>>[91, 104]
> Yes, agree. This is the current behavior.
>
> While in this case.
>    70-160]
> brother1[70-80] res[90-150] brother151-160]
>    ->child
>
> There is free space between 81-89, and 90-104. These two free range add
> up to 25, which is more than the required space, 16.
>
> If we have this resource tree.
>    parent[70-180]
> brother1[70-80] re[90-150] brothr2[170-180]
>    d[105-140]
>
> There are enough free space between res and brother2.
> Then probe_resource will return [141-156] with size 16.
> And also expend res.
>
> So I mean this is the design decision to not count in the free space on
> the left? Even there is enough free space?

We can not extend start.

when we have bridge using [90, 150] all children devices will be on bus 90.
if change the bridge to use low like 81, then all device need to
remove and rescan them.

also keep the old bus number is safer.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 10, 2012, 6:23 PM

Post #29 of 41 (62 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Wed, May 09, 2012 at 10:42:06PM -0700, Yinghai Lu wrote:
>
>We can not extend start.
>
>when we have bridge using [90, 150] all children devices will be on bus 90.
>if change the bridge to use low like 81, then all device need to
>remove and rescan them.
>
>also keep the old bus number is safer.
Oh, got it.
>
>Yinghai

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 13, 2012, 6:55 PM

Post #30 of 41 (61 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, Apr 23, 2012 at 03:46:03PM -0400, Don Dutile wrote:
>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>All,
>>
>>I am reading the pci_scan_bridge() and not sure what will happen in
>>following situation.
>>
>>Suppose the kernel is not passed the pci=assign-busses.
>>
>>Below is a picture about the pci system.
>>
>> +-------+
>> | | root bridge(0,255)
>> +---+---+
>> | Bus 0
>> -----+-----------+------------------------------+--
>> | |
>> | |
>> | |
>> +----+----+ +-----+-----+
>> | | B1(1,15) | |B2(16,28)
>> +----+----+ +-----+-----+
>> | Bus 1 | Bus 16
>> -----+----------------------- ----------+----------------
>> |
>> +----+----+
>> | | B3
>> +---------+
>>
>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>number and range.
>>
>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>
>>So in pci_scan_bridge(), B3 will be met in the second pass and get bus
>>number 16?
>
Yinghai,

Take my original question.

B3 doesn't get the bus number, which its parent doesn't have free bus
number and there is no gap between B1 and B2.

So in this case, the probe_resource() can't find bus number for B3.
Then cause pci_bridge_probe_busn_res() return non-zero.

Then B3 couldn't work fine?

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

May 13, 2012, 10:40 PM

Post #31 of 41 (64 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Sun, May 13, 2012 at 6:55 PM, Richard Yang
<weiyang [at] linux> wrote:
> On Mon, Apr 23, 2012 at 03:46:03PM -0400, Don Dutile wrote:
>>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>>All,
>>>
>>>I am reading the pci_scan_bridge() and not sure what will happen in
>>>following situation.
>>>
>>>Suppose the kernel is not passed the pci=assign-busses.
>>>
>>>Below is a picture about the pci system.
>>>
>>> +-------+
>>> | | root bridge(0,255)
>>> +---+---+
>>> | Bus 0
>>> -----+-----------+------------------------------+--
>>> | |
>>> | |
>>> | |
>>> +----+----+ +-----+-----+
>>> | | B1(1,15) | |B2(16,28)
>>> +----+----+ +-----+-----+
>>> | Bus 1 | Bus 16
>>> -----+----------------------- ----------+----------------
>>> |
>>> +----+----+
>>> | | B3
>>> +---------+
>>>
>>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>>number and range.
>>>
>>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>>
>>>So in pci_scan_bridge(), B3 will be met in the second pass and get bus
>>>number 16?
>>
> Yinghai,
>
> Take my original question.
>
> B3 doesn't get the bus number, which its parent doesn't have free bus
> number and there is no gap between B1 and B2.
>
> So in this case, the probe_resource() can't find bus number for B3.
> Then cause pci_bridge_probe_busn_res() return non-zero.
>
> Then B3 couldn't work fine?

B3 is on Bus 1? B3 is the one of bridges on Bus1?

if B3 is only bridge on Bus1, it probe_resource should return [2,15]
at first, and then scan B3.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 13, 2012, 11:46 PM

Post #32 of 41 (62 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Sun, May 13, 2012 at 10:40:41PM -0700, Yinghai Lu wrote:
>On Sun, May 13, 2012 at 6:55 PM, Richard Yang
><weiyang [at] linux> wrote:
>> On Mon, Apr 23, 2012 at 03:46:03PM -0400, Don Dutile wrote:
>>>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>>>All,
>>>>
>>>>I am reading the pci_scan_bridge() and not sure what will happen in
>>>>following situation.
>>>>
>>>>Suppose the kernel is not passed the pci=assign-busses.
>>>>
>>>>Below is a picture about the pci system.
>>>>
>>>> +-------+
>>>> | | root bridge(0,255)
>>>> +---+---+
>>>> | Bus 0
>>>> -----+-----------+------------------------------+--
>>>> | |
>>>> | |
>>>> | |
>>>> +----+----+ +-----+-----+
>>>> | | B1(1,15) | |B2(16,28)
>>>> +----+----+ +-----+-----+
>>>> | Bus 1 | Bus 16
>>>> -----+----------------------- ----------+----------------
>>>> |
>>>> +----+----+
>>>> | | B3
>>>> +---------+
>>>>
>>>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>>>number and range.
>>>>
>>>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>>>
>>>>So in pci_scan_bridge(), B3 will be met in the second pass and get bus
>>>>number 16?
>>>
>> Yinghai,
>>
>> Take my original question.
>>
>> B3 doesn't get the bus number, which its parent doesn't have free bus
>> number and there is no gap between B1 and B2.
>>
>> So in this case, the probe_resource() can't find bus number for B3.
>> Then cause pci_bridge_probe_busn_res() return non-zero.
>>
>> Then B3 couldn't work fine?
>
>B3 is on Bus 1? B3 is the one of bridges on Bus1?
No, I omit other bridges on Bus#1.
They will occupy bus number 2-15, which is calculated by BIOS and set to
bridge's configuration space.
>
>if B3 is only bridge on Bus1, it probe_resource should return [2,15]
>at first, and then scan B3.
>
>Yinghai

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

May 15, 2012, 10:32 AM

Post #33 of 41 (57 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Sun, May 13, 2012 at 11:46 PM, Richard Yang
<weiyang [at] linux> wrote:
> On Sun, May 13, 2012 at 10:40:41PM -0700, Yinghai Lu wrote:
>>On Sun, May 13, 2012 at 6:55 PM, Richard Yang
>><weiyang [at] linux> wrote:
>>> On Mon, Apr 23, 2012 at 03:46:03PM -0400, Don Dutile wrote:
>>>>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>>>>All,
>>>>>
>>>>>I am reading the pci_scan_bridge() and not sure what will happen in
>>>>>following situation.
>>>>>
>>>>>Suppose the kernel is not passed the pci=assign-busses.
>>>>>
>>>>>Below is a picture about the pci system.
>>>>>
>>>>> +-------+
>>>>> | | root bridge(0,255)
>>>>> +---+---+
>>>>> | Bus 0
>>>>> -----+-----------+------------------------------+--
>>>>> | |
>>>>> | |
>>>>> | |
>>>>> +----+----+ +-----+-----+
>>>>> | | B1(1,15) | |B2(16,28)
>>>>> +----+----+ +-----+-----+
>>>>> | Bus 1 | Bus 16
>>>>> -----+----------------------- ----------+----------------
>>>>> |
>>>>> +----+----+
>>>>> | | B3
>>>>> +---------+
>>>>>
>>>>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>>>>number and range.
>>>>>
>>>>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>>>>
>>> Take my original question.
>>>
>>> B3 doesn't get the bus number, which its parent doesn't have free bus
>>> number and there is no gap between B1 and B2.
>>>
>>> So in this case, the probe_resource() can't find bus number for B3.
>>> Then cause pci_bridge_probe_busn_res() return non-zero.
>>>
>>> Then B3 couldn't work fine?
>>
>>B3 is on Bus 1? B3 is the one of bridges on Bus1?
> No, I omit other bridges on Bus#1.
> They will occupy bus number 2-15, which is calculated by BIOS and set to
> bridge's configuration space.

with that new condition, probe_resource will return zero.

for those kind of case:
1. use echo 1 > /sys .../remove to remove devices under Bridge2.
2. use setpci to change bus register of bridge2 to move high to make
more space for bridge 1.
3. rescan bridge 1 and bridge 2.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 15, 2012, 6:18 PM

Post #34 of 41 (59 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Tue, May 15, 2012 at 10:32:46AM -0700, Yinghai Lu wrote:
>On Sun, May 13, 2012 at 11:46 PM, Richard Yang
><weiyang [at] linux> wrote:
>> On Sun, May 13, 2012 at 10:40:41PM -0700, Yinghai Lu wrote:
>>>On Sun, May 13, 2012 at 6:55 PM, Richard Yang
>>><weiyang [at] linux> wrote:
>>>> On Mon, Apr 23, 2012 at 03:46:03PM -0400, Don Dutile wrote:
>>>>>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>>>>>All,
>>>>>>
>>>>>>I am reading the pci_scan_bridge() and not sure what will happen in
>>>>>>following situation.
>>>>>>
>>>>>>Suppose the kernel is not passed the pci=assign-busses.
>>>>>>
>>>>>>Below is a picture about the pci system.
>>>>>>
>>>>>> +-------+
>>>>>> | | root bridge(0,255)
>>>>>> +---+---+
>>>>>> | Bus 0
>>>>>> -----+-----------+------------------------------+--
>>>>>> | |
>>>>>> | |
>>>>>> | |
>>>>>> +----+----+ +-----+-----+
>>>>>> | | B1(1,15) | |B2(16,28)
>>>>>> +----+----+ +-----+-----+
>>>>>> | Bus 1 | Bus 16
>>>>>> -----+----------------------- ----------+----------------
>>>>>> |
>>>>>> +----+----+
>>>>>> | | B3
>>>>>> +---------+
>>>>>>
>>>>>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>>>>>number and range.
>>>>>>
>>>>>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>>>>>
>>>> Take my original question.
>>>>
>>>> B3 doesn't get the bus number, which its parent doesn't have free bus
>>>> number and there is no gap between B1 and B2.
>>>>
>>>> So in this case, the probe_resource() can't find bus number for B3.
>>>> Then cause pci_bridge_probe_busn_res() return non-zero.
>>>>
>>>> Then B3 couldn't work fine?
>>>
>>>B3 is on Bus 1? B3 is the one of bridges on Bus1?
>> No, I omit other bridges on Bus#1.
>> They will occupy bus number 2-15, which is calculated by BIOS and set to
>> bridge's configuration space.
>
>with that new condition, probe_resource will return zero.
>
>for those kind of case:
>1. use echo 1 > /sys .../remove to remove devices under Bridge2.
>2. use setpci to change bus register of bridge2 to move high to make
>more space for bridge 1.
>3. rescan bridge 1 and bridge 2.
So these steps is done after boot up and user find B3 doesn't work?
>
>Yinghai

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

May 15, 2012, 7:11 PM

Post #35 of 41 (57 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Tue, May 15, 2012 at 6:18 PM, Richard Yang
<weiyang [at] linux> wrote:
> On Tue, May 15, 2012 at 10:32:46AM -0700, Yinghai Lu wrote:
>>>>>>On 04/22/2012 11:52 AM, Richard Yang wrote:
>>>>>>>All,
>>>>>>>
>>>>>>>I am reading the pci_scan_bridge() and not sure what will happen in
>>>>>>>following situation.
>>>>>>>
>>>>>>>Suppose the kernel is not passed the pci=assign-busses.
>>>>>>>
>>>>>>>Below is a picture about the pci system.
>>>>>>>
>>>>>>> +-------+
>>>>>>> | | root bridge(0,255)
>>>>>>> +---+---+
>>>>>>> | Bus 0
>>>>>>> -----+-----------+------------------------------+--
>>>>>>> | |
>>>>>>> | |
>>>>>>> | |
>>>>>>> +----+----+ +-----+-----+
>>>>>>> | | B1(1,15) | |B2(16,28)
>>>>>>> +----+----+ +-----+-----+
>>>>>>> | Bus 1 | Bus 16
>>>>>>> -----+----------------------- ----------+----------------
>>>>>>> |
>>>>>>> +----+----+
>>>>>>> | | B3
>>>>>>> +---------+
>>>>>>>
>>>>>>>Suppose B1 and B2 works fine with the BIOS, which get the right bus
>>>>>>>number and range.
>>>>>>>
>>>>>>>B3 does not works fine with the BIOS, which doesn't get the bus number.
>>>>>>>
>>>>> Take my original question.
>>>>>
>>>>> B3 doesn't get the bus number, which its parent doesn't have free bus
>>>>> number and there is no gap between B1 and B2.
>>>>>
>>>>> So in this case, the probe_resource() can't find bus number for B3.
>>>>> Then cause pci_bridge_probe_busn_res() return non-zero.
>>>>>
>>>>> Then B3 couldn't work fine?
>>>>
>>>>B3 is on Bus 1? B3 is the one of bridges on Bus1?
>>> No, I omit other bridges on Bus#1.
>>> They will occupy bus number 2-15, which is calculated by BIOS and set to
>>> bridge's configuration space.
>>
>>with that new condition, probe_resource will return zero.
>>
>>for those kind of case:
>>1. use echo 1 > /sys .../remove to remove devices under Bridge2.
>>2. use setpci to change bus register of bridge2 to move high to make
>>more space for bridge 1.
>>3. rescan bridge 1 and bridge 2.
> So these steps is done after boot up and user find B3 doesn't work?

yes, after os is booted up.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

May 29, 2012, 4:59 AM

Post #36 of 41 (50 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Tue, May 15, 2012 at 07:11:34PM -0700, Yinghai Lu wrote:
>> So these steps is done after boot up and user find B3 doesn't work?
>
>yes, after os is booted up.
>
>Yinghai

Yinghai

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?
--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

May 29, 2012, 10:14 AM

Post #37 of 41 (47 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Tue, May 29, 2012 at 4:59 AM, Richard Yang
<weiyang [at] linux> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

Jun 4, 2012, 6:34 AM

Post #38 of 41 (47 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

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 [at] linux> 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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

Jun 4, 2012, 4:36 PM

Post #39 of 41 (45 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, Jun 4, 2012 at 6:34 AM, Richard Yang <weiyang [at] linux> wrote:
> 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 [at] linux> 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?

that should be handled by busn_alloc branch.

kernel will try to probe in [1,15] at first, and could extend B1 range
to [1, 31] if needed.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weiyang at linux

Jun 4, 2012, 11:26 PM

Post #40 of 41 (49 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, Jun 04, 2012 at 04:36:33PM -0700, Yinghai Lu wrote:
>On Mon, Jun 4, 2012 at 6:34 AM, Richard Yang <weiyang [at] linux> wrote:
>> 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 [at] linux> 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?
>
>that should be handled by busn_alloc branch.
>
>kernel will try to probe in [1,15] at first, and could extend B1 range
>to [1, 31] if needed.
Hmm... when do you think this branch will be merged to the mainstream?
>
>Thanks
>
>Yinghai

--
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

Jun 5, 2012, 11:01 AM

Post #41 of 41 (45 views)
Permalink

Re: One problem in reassign pci bus number? [In reply to]

On Mon, Jun 4, 2012 at 11:26 PM, Richard Yang
<weiyang [at] linux> wrote:
> On Mon, Jun 04, 2012 at 04:36:33PM -0700, Yinghai Lu wrote:
>>
>>kernel will try to probe in [1,15] at first, and could extend B1 range
>>to [1, 31] if needed.
> Hmm... when do you think this branch will be merged to the mainstream?
>>

not sure. could be 3.7

Bjorn still think that probe_resource is too complicated.

So i still need to find some time to simplify it.
or need to route that attached patch through Andrew or get Ack from
Andrew or Linus.

Thanks

Yinghai

Attachments:

probe_resource_2.patch (5.91 KB)

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads