On Wed, Jul 9, 2014 at 10:35 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > On Wednesday, July 09, 2014 09:55:24 AM Bjorn Helgaas wrote: >> On Wed, Jul 9, 2014 at 8:18 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > 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? >> >> >> ... >> >> The driver's system resume callbacks need to be able to cope with >> >> missing devices. >> >> Based on this, it sounds like igb_resume() should call igb_remove() >> when it figures out the device is missing. > > I wouldn't say so. igb_resume() should not crash when the device is missing > and should just handle that situation cleanly. Obviously it is not its role > to remove the device from the hierarchy. OK, that makes sense. However, I don't know of anything in the PCI core that will notice that the device has disappeared, so I doubt it will be removed from the hierarchy. I think that means the slot will become unusable until a reboot, because the original device is gone and we can't add a new one because the original one is still in the hierarchy. That's not very good, but it is better than a panic. >> That might be the best we can do right now, but it doesn't sound like >> a general-purpose solution. Detecting device removal sounds like a >> core function, not a driver function. It doesn't seem like drivers >> should have to implement ->resume just to deal with this case. > > No, they shouldn't. They just need to be able to cope with missing devices > cleanly. > > Devices (and PCI devices in particular) can go away at any time, including > during system resume, without notice anyway and drivers need to be able to > cope with that regardless. > > The notification can actually come in *after* the device has gone in any > case and then whoever gets the notification should handle the device > removal. That is not the driver in particular, but in the meantime > the driver should still work without crashing. Yep. So the panic Igor is seeing is probably an igb_resume() problem, but after that's fixed, we'll probably trip over the PCI bug about not handling the remove. Bjorn -- 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
