On Mon, Apr 23, 2012 at 2:09 PM, Don Dutile<ddutile@xxxxxxxxxx> wrote:yes, that's what I meant. sorry, my bad... :(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?
I'll try as soon as I get back to the office;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