Hi Rajat, >> >> This issue was observed on a system, where I was experimenting with >> pcie hot-plug and the device being hot plugged is not the most well >> behaved. It exhibits the following behavior: >> >> - Initialization of the device can take “relatively” long (order 100s ms) >> - On hot add the link presence can toggle before stabilizing > > Yup, this would be a problem if the work queue was reordered in this case. > >> >> The toggle of device presence can generate multiple events on a single >> hot plug, where one hot add event can lead to following events >> ADD->REMOVE->ADD. And given the device can take some time to initialize, >> we can have three HP events being processed concurrently. > > The HP events are actually serialized, but only from the perspective > if PCI subsystem (i.e. once they have been dispatched from the > workqueue): > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=50b52fdee050745935d92e7026373edea2647e60 > With an ordered workqueue I am wondering if the locking is needed. My kernel tree seems to be a bit behind and does not contain this change. I suppose there could still be a race between pciehp_probe and the processing of the HP event. >> >> Also note this seen with surprise ADD and REMOVE. >> > > Can you please send lspci -vvvv for the slot? I suspect that your > device has a power controller. In absense of it, the link state > changes would generate HP events regardless of "surprise" bit. Yes we are behind a slot with power management. Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Thanks, Sandeep -- 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
