Messages in this thread | | | Date | Mon, 23 Apr 2012 15:07:23 -0700 | Subject | Re: One problem in reassign pci bus number? | From | Yinghai Lu <> |
| |
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?
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |