On Thu, 22 Jun 2006, David Brownell wrote:
> On Thursday 22 June 2006 1:31 pm, Alan Stern wrote:
> > On Thu, 22 Jun 2006, David Brownell wrote:
> >
> > > > The PM core _should_ be
> > > > able to handle a device being added or removed while some parts of
> > > > the system are suspended or frozen, just so long as the actual parent is
> > > > still awake. Uevents can safely be queued until userspace is unfrozen or
> > > > otherwise able to process them.
> > >
> > > Fixing that involves updating pm core locking, ISTR. I've thought that
> > > the root cause of the issue is that the list of devices to be suspended
> > > is created at the wrong time ... very early and globally scoped, not
> > > on-demand and privately scoped.
> >
> > I believe this has been fixed for quite a while.
>
> That's been said, but nonetheless the last few times I've tried to do
> things like handling disconnect processing anything other than very
> late (after khubd got woken up again), it was still deadlocksville.
> Yes, this is _after_ folk have said "this has been fixed...".
Okay, I have tried it. This patch
Index: usb-2.6/drivers/usb/core/hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1779,7 +1779,14 @@ int usb_port_resume(struct usb_device *u
#endif
status = 0;
} else
+{int i;
+for (i = 0; i < udev->maxchild; ++i) {
+ if (udev->children[i]) {
+ printk(KERN_INFO "Disconnecting child %d\n", i);
+ usb_disconnect(&udev->children[i]);
+}}
status = finish_port_resume(udev);
+}
if (status < 0)
dev_dbg(&udev->dev, "can't resume, status %d\n",
status);
causes all USB devices to be removed during an early stage of resume
processing. I tried it with STD (since STR isn't usable on this machine).
The devices actually get removed twice: once during the "resume so we can
write out the memory image" phase and then once again during the actual
final resume.
With a hub plugged in, it worked just fine. With a USB flash disk plugged
in the machine hung, but not because of anything wrong with the driver
model or PM cores. It was a bug in the SCSI core, requiring a 1-line fix.
With that fix in place, the test also worked with the mass-storage device.
Thus removing a device during suspend or resume processing should not be
any sort of problem. Adding a device need not be a problem either,
provided we add the requirement that the parent not be suspended when the
child is added.
Alan Stern
