Messages in this thread | | | Date | Tue, 24 Apr 2012 22:56:46 -0400 | From | Don Dutile <> | Subject | Re: One problem in reassign pci bus number? |
| |
On 04/23/2012 06:07 PM, Yinghai Lu wrote: > On Mon, Apr 23, 2012 at 2:09 PM, Don Dutile<ddutile@redhat.com> wrote: >> On 04/23/2012 04:19 PM, Yinghai Lu wrote: >>> >>> On Mon, Apr 23, 2012 at 12:46 PM, Don Dutile<ddutile@redhat.com> 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.
| |