On Wed, 9 Jul 2014, Rafael J. Wysocki wrote: > On Tuesday, July 08, 2014 02:47:03 PM Bjorn Helgaas wrote: > > [+cc linux-pm] > > > > On Tue, Jul 8, 2014 at 9:39 AM, Igor Bezukh <Igor@xxxxxxxxxxxxx> wrote: > > > Hi, > > > > > > > > > We are testing Intel Gigabit adapter driver (igb) under Fedora 20, kernel 3.14.4 for the following use-case: > > > > > > (*) Adapter is connected to the PCIE slot > > > (*) We put the system under suspend by running pm-suspend from user-space > > > (*) Remove the adapter from the PCIE slot > > > (*) Wake up the system > > > > > > Currenlty, we got kernel panics and the system got stuck. > > > > > > My question is - does the PCI subsystem logic calls the driver remove function when driver resume function returns with error code? > > > > > > Or should I implement the call to igb_remove from igb_resume in the Intel driver? > > > > I don't know what the best design is here. I suspect that when we > > resume, we should re-enumerate the PCI topology to see if anything > > changed, but I don't think we do that. I think there *is* something > > like that for ACPI -- the BIOS can send a Bus Check notification on > > resume if it knows something has changed. > > In ACPI we wait for system resume to complete and handle the notifications > then. Calling .remove() callbacks from drivers during system resume doesn't > really work, especially if they happen too early (e.g. during the "noirq resume" > stage). USB uses a similar approach. Hot-unplugs are handled by the khubd thread, which is freezable and therefore doesn't run until after the system is resumed. > > But my guess is that if you > > remove an adapter below a switch that is powered down because the > > system is suspended, the interrupt we would normally get is lost > > forever. > > > > It doesn't seem like something that should be solved in the driver, > > because you could just as easily have *added* a device while > > suspended, and the core has to re-enumerate to find that. > > The driver's system resume callbacks need to be able to cope with > missing devices. In the USB stack, the subsystem core resume code checks to see if a device has been unplugged before the driver's ->resume callback is invoked. If a device is gone, the driver callback is skipped. Thus drivers don't have to worry about trying to resume a device that has been unplugged. Alan Stern -- 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
