On 04/23/2012 06:07 PM, Yinghai Lu wrote:
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?
yes, that's what I meant. sorry, my bad... :(
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
I'll try as soon as I get back to the office;
I'm out the next few days, and don't have external access to my test system.
--
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
