Re: One problem in reassign pci bus number?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 04/22/2012 11:52 AM, Richard Yang wrote:
All, I am reading the pci_scan_bridge() and not sure what will happen in following situation. Suppose the kernel is not passed the pci=assign-busses. Below is a picture about the pci system. +-------+ | | root bridge(0,255) +---+---+ | Bus 0 -----+-----------+------------------------------+-- | | | | | | +----+----+ +-----+-----+ | | B1(1,15) | |B2(16,28) +----+----+ +-----+-----+ | Bus 1 | Bus 16 -----+----------------------- ----------+---------------- | +----+----+ | | B3 +---------+ Suppose B1 and B2 works fine with the BIOS, which get the right bus number and range. B3 does not works fine with the BIOS, which doesn't get the bus number. So in pci_scan_bridge(), B3 will be met in the second pass and get bus number 16?
unfortunately, today, the answer is yes. 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! ;-) The PCI code is suppose to do two bus scans -- pass=0: to see what the BIOS has setup, and then pass=1 to assign non-BIOS setup devices. But, what I'm finding is that when pci=assign-busses is set, the pass=0 scan is not doing a full PCI tree scan and registering all the BIOS-setup busses first, and it tries to do extended bus assignment in pass=0, not pass=1; in the above configuration, it expands B1's bus num range from (1,15) to (1,16), then tries to scan behind it. that creates an overlap btwn B1 & B2's sec/sub bus-num ranges, and they both respond to a Type1 config cycle with a bus-number of 16 (typically when trying to read the VID register of 16:0.0 in this case).... boom! ... or more like silence due to system hang... *If* the system spaces bus ranges apart, e.g., in your config above, if the BIOS setup B1(1,15) and B2(24,32), then pci=assign-busses will work because bus num 16 is free, and two bridges won't think they both respond to type1 pci config cycle (with bus-number=16 lying in their sec/sub-bus num range), and all will (luckily) work. Unfortunately, I'm in & out of work due to at-home time requirements, so I haven't had a chance to work out a proper patch. What should happen in the above case, is the kernel prints a warning saying it couldn't do needed assign-busses operations due to configuration constraints... and continue to do pci (pass=1) bridge scanning.... and not wedge the system as it does now. The base problem is that (a)pass=0 is doing bus-assigning, and it shouldn't be done until pass=1, after all known BIOS-setup busses are known (b) the code doesn't have a nice warning and continuation when this conflict occurs.
Would this be a conflict?
summary: yes. -- 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