Re: One problem in reassign pci bus number?

[Yinghai Lu]

On Mon, Apr 23, 2012 at 2:09 PM, Don Dutile <ddutile@xxxxxxxxxx> wrote:
> On 04/23/2012 04:19 PM, Yinghai Lu wrote:
>>
>> On Mon, Apr 23, 2012 at 12:46 PM, Don Dutile<ddutile@xxxxxxxxxx>  wrote:
>>>
>>> I have run into a similar problem recently when trying to use
>>> pci=assign-busses
>>> with an SRIOV device behind a non-ARI-capable PCIe switch.
>>> In this scenario, the assign-busses code assigned the next bus number,
>>> which conflicted with an existing one on the system, and hangs the
>>> system -- two bridges responding to the same PCI bus num evidently
>>> confuses the hw! ;-)
>>
>>
>> can you post boot log and lspci -vvxxx?
>>
>> Yinghai
>
>
> Attached requested logs of linux-3.4-rc2 booted on RHEL6.2 installation.
>
> I don't have a boot log of failing condition (pci=assign-devices)

what is pci=assign-devices ? you have own local patches to handle that?

or you mean pci=assign-busses?

> b/c it wedges at boot, and the serial line doesn't output anything
> even though I've tried every magic trick known with grub & kernel boot
> params.
> ... the PCI log btwn early boot and until the console is reconfigured is
> 'lost'
> on the serial line, and that's when the hang occurs.
> It's been 'fun' to debug w/o that serial output...
>
> Let me know if you need something else. (lspci -t ?)

can you check busn_alloc patchset fix the overlapping problem for you?
It already split scan bus to two pass, also it  will double check not
scanned peer bridges.

git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-busn-alloc

you can merge them to your 3.4-rc2...

Thanks

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