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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
