Hello linux-pci, I've been testing PCI hotplugging on two computers, a Trenton CPLE and a Force CPCI-735. They're both regular x86 PC's in a compact PCI formfactor. The hardware on both boards is nearly identical. The major difference is the PCI bridge used. The Trenton uses a Broadcom bridge, while the Force uses a Force Sentinel PCI-to-PCI bridge. I'd like to be able to tell Linux "I want to remove this PCI card", swap the card, then tell the system "rescan the bus" and have the new card be initialized. Running the hotplug manually is fine, I don't really care about using the front-panel switch to trigger hotplug. The card which I have plugged into the PCI backplane is cPCI hotplug capable. It also has a reset switch, which causes it to reset the onboard processor, clear the PCI interface, etc. The BAR addresses are all zeroed, as if the board just powered on, before the BIOS assigned addresses. I've tested six scenarios, all using a v2.6.31.2 kernel. 1) CONFIG_HOTPLUG_PCI=n, pci-core method, no reset 2) CONFIG_HOTPLUG_PCI=n, pci-core method, hard reset 3) CONFIG_HOTPLUG_PCI=y, pci-core method, no reset 4) CONFIG_HOTPLUG_PCI=y, pci-core method, hard reset 5) CONFIG_HOTPLUG_PCI=y, fakephp method, no reset 6) CONFIG_HOTPLUG_PCI=y, fakephp method, hard reset I used the following definitions in the table. 1) hard reset: After running the software hot-unplug, I pressed the reset switch on the card, zeroing the PCI BAR addresses. 2) no reset: The card was left in the slot, powered on. The PCI interface was not physically reset, so the PCI BAR addresses assigned by the BIOS (before the hot-unplug) are still in the PCI configuration space. I've tried doing a software hotplug via the following two methods. When possible, I tried both on the same kernel configuration. 1) the fakephp method: echo 0 > /sys/bus/pci/slots/.../power echo 1 > /sys/bus/pci/rescan 2) the pci-core method: echo 1 > /sys/bus/pci/devices/.../remove echo 1 > /sys/bus/pci/rescan All six scenarios work on the Force computer. It seems to re-assign the same PCI BAR addresses each time. All six scenarios fail on the Trenton computer. It always re-assigns the PCI BAR addresses starting at 0x40000000, which is just above the top of physical memory. There is 1GB of RAM in the system. On both the Trenton and Force computers, the BIOS assigns the PCI BAR addresses towards the top of memory. Both assign addresses above 0xF0000000. After running a hotplug on the Trenton computer, I have used a PCI logic analyzer to confirm that no transactions accessing the PCI BAR's of the hotplugged card make it onto the PCI bus. PCI configuration space still works. I have tried using the "memmap=" kernel parameter to force the Trenton computer to re-assign the PCI BAR addresses above 0xF0000000. This did not help. My question is: how can I debug this? Is it a Linux problem, or is it a BIOS problem? I'm happy to provide any more information, including logic analyzer traces if necessary. Thanks, Ira -- 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
