All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: weissg@vienna.at, kernel list <linux-kernel@vger.kernel.org>,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] OHCI problems with suspend/resume
Date: Tue, 29 Jul 2003 06:16:52 -0700	[thread overview]
Message-ID: <3F2673C4.9010302@pacbell.net> (raw)
In-Reply-To: <20030723220805.GA278@elf.ucw.cz>

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

Pavel Machek wrote:
> Hi!
> 
> In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> kills machine during secon suspend/resume cycle.

OK, I can see that in 2.6.0-test2 iff there's a device connected;
that's on OHCI hardware that doesn't retain power during suspend,
which means it uses the restart() path.  Hardware that retains
power depends on slightly different logic.


> What happens is that ohci_irq gets ohci->hcca == NULL, and kills
> machine. Why is ohci->hcca == NULL? ohci_stop was called from
> hcd_panic() and freed ohci->hcca.

Of course, the HC shouldn't have died and gone down those paths;
but the "HC died" paths need to work right too.


> I believe that we should
> 
> 1) not free ohci->hcca so that system has better chance surviving
> hcd_panic()

More like not calling stop() from hcd_panic.  Instead, all the
devices should be disconnected, and their urbs cleaned up.  That
way the controller will sit in a known and "safe" state (reset)
until the driver is shut down and gets stop()ped.  I think that
logic just "seemed to work" before, with subtle misbehaviors.

We're still working to make sure that we do all the right stuff
to shut down devices, no longer relying on USB device drivers to
shut themselves down properly in their disconnect() methods.
Many haven't, which can easily lead to oopsing on the shutdown
paths that don't get used very regularly.

Eventually I suspect that the HCD glue should grow logic to
try restarting drivers after the hardware dies/resets, but first
it's important to be sure they shut down properly.



> 2) inform user when hcd panics.

With a better diagnostic though.


Here's a patch that makes things slightly better.  It's still
not fully functional yet -- I forgot how many FIXMEs are in
those PM code paths! -- and shouldn't be merged as-is, but it
works slightly better:

  - Has a more informative diagnostic message (which HC died);

  - When HC dies, mark the whole tree as unavailable so that
    new URB submissions using that HC will just fail;

  - Then hcd_panic() just disconnects all the devices, still
    keeping the root hub around.

  - OHCI-specific (should be generic, hcd-pci.c):  don't
    try resuming a halted controller.

Where "better" means that it seems functional after the
first suspend/resume cycle, and re-enumerates the device
that's connected ... but there's still strangeness.  And
I can see how some of it would be generic.

- Dave



[-- Attachment #2: die.patch --]
[-- Type: text/plain, Size: 2244 bytes --]

--- 1.68/drivers/usb/core/hcd.c	Tue Jul 15 09:47:16 2003
+++ edited/drivers/usb/core/hcd.c	Sun Jul 27 19:42:46 2003
@@ -1487,8 +1488,26 @@
 
 static void hcd_panic (void *_hcd)
 {
-	struct usb_hcd *hcd = _hcd;
-	hcd->driver->stop (hcd);
+	struct usb_hcd		*hcd = _hcd;
+	struct usb_device	*hub = hcd->self.root_hub;
+
+	hub = usb_get_dev (hub);
+	usb_disconnect (&hub);
+
+	/* FIXME either try to restart, or arrange to clean up the 
+	 * hc-internal state, like usb_hcd_pci_remove() does
+	 */
+}
+
+void mark_gone (struct usb_device *dev)
+{
+	unsigned	i;
+
+	dev->state = USB_STATE_NOTATTACHED;
+	for (i = 0; i < dev->maxchild; i++) {
+		if (dev->children [i])
+			mark_gone (dev->children [i]);
+	}
 }
 
 /**
@@ -1501,29 +1520,12 @@
  */
 void usb_hc_died (struct usb_hcd *hcd)
 {
-	struct list_head	*devlist, *urblist;
-	struct hcd_dev		*dev;
-	struct urb		*urb;
-	unsigned long		flags;
-	
-	/* flag every pending urb as done */
-	spin_lock_irqsave (&hcd_data_lock, flags);
-	list_for_each (devlist, &hcd->dev_list) {
-		dev = list_entry (devlist, struct hcd_dev, dev_list);
-		list_for_each (urblist, &dev->urb_list) {
-			urb = list_entry (urblist, struct urb, urb_list);
-			dev_dbg (hcd->controller, "shutdown %s urb %p pipe %x, current status %d\n",
-				hcd->self.bus_name, urb, urb->pipe, urb->status);
-			if (urb->status == -EINPROGRESS)
-				urb->status = -ESHUTDOWN;
-		}
-	}
-	urb = (struct urb *) hcd->rh_timer.data;
-	if (urb)
-		urb->status = -ESHUTDOWN;
-	spin_unlock_irqrestore (&hcd_data_lock, flags);
+	dev_err (hcd->controller, "HC died; pending I/O will be aborted.\n");
 
-	/* hcd->stop() needs a task context */
+	/* prevent new submissions to devices in this tree */
+	mark_gone (hcd->self.root_hub);
+	
+	/* then usb_disconnect() them all, in a task context */
 	INIT_WORK (&hcd->work, hcd_panic, hcd);
 	(void) schedule_work (&hcd->work);
 }
--- 1.12/drivers/usb/host/ohci-pci.c	Mon Apr 14 02:51:40 2003
+++ edited/drivers/usb/host/ohci-pci.c	Sun Jul 27 18:51:21 2003
@@ -199,6 +199,11 @@
 	int			retval = 0;
 	unsigned long		flags;
 
+	if (hcd->state == USB_STATE_HALT) {
+		ohci_dbg (ohci, "USB restart of halted device\n");
+		return -EL3HLT;
+	}
+
 #ifdef CONFIG_PMAC_PBOOK
 	{
 		struct device_node *of_node;

  parent reply	other threads:[~2003-07-29 13:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-23 22:08 OHCI problems with suspend/resume Pavel Machek
2003-07-24  1:19 ` [linux-usb-devel] " David Brownell
2003-07-24 10:24   ` Pavel Machek
2003-07-24 17:10     ` David Brownell
2003-07-24 22:10       ` Pavel Machek
2003-07-24 12:37 ` Dominik Brugger
2003-07-24 12:56   ` Dominik Brugger
2003-07-24 22:04   ` Pavel Machek
2003-07-24 22:46   ` Pavel Machek
2003-07-25  7:52     ` Dominik Brugger
2003-07-25 15:06       ` [linux-usb-devel] " Alan Stern
2003-07-25 17:20         ` Benjamin Herrenschmidt
2003-07-25 22:48           ` David Brownell
2003-07-26 16:02             ` Alan Stern
2003-07-26 21:01             ` Pavel Machek
2003-07-26 21:16               ` David Brownell
2003-07-27 14:57               ` Alan Stern
2003-07-31  3:27               ` David Brownell
2003-07-31  3:51                 ` David Brownell
2003-07-31  9:42                 ` Pavel Machek
2003-07-31 13:37                   ` David Brownell
2003-07-31 14:09                     ` Pavel Machek
2003-07-31 17:32                       ` David Brownell
2003-07-31 17:31                         ` Pavel Machek
2003-07-31 21:32                         ` Benjamin Herrenschmidt
2003-07-31 21:30                       ` Benjamin Herrenschmidt
2003-07-31 21:29                     ` Benjamin Herrenschmidt
2003-07-31  9:47                 ` Pavel Machek
2003-07-31 13:30                   ` David Brownell
2003-07-31 16:06                     ` Pavel Machek
2003-07-31  9:49                 ` Pavel Machek
2003-07-31 13:23                   ` David Brownell
2003-07-31 16:07                     ` Pavel Machek
2003-07-31 21:25                     ` Benjamin Herrenschmidt
2003-07-31 21:25                   ` Benjamin Herrenschmidt
2003-07-31 22:08                     ` Pavel Machek
2003-07-31 21:23                 ` Benjamin Herrenschmidt
2003-07-31 21:55                   ` David Brownell
2003-07-31 22:05                     ` Benjamin Herrenschmidt
2003-07-31 22:09                       ` Pavel Machek
2003-07-31 23:12                         ` Oliver Neukum
2003-08-01  9:33                           ` Pavel Machek
2003-07-31 22:03                   ` Pavel Machek
2003-08-01  0:27                     ` Benjamin Herrenschmidt
2003-08-04 19:25                       ` Pavel Machek
2003-08-01 18:20       ` Dominik Brugger
2003-07-29 13:16 ` David Brownell [this message]
2003-07-31 14:18   ` [linux-usb-devel] " Pavel Machek
2003-08-01 17:41     ` David Brownell
2003-08-07 22:35       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F2673C4.9010302@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=pavel@ucw.cz \
    --cc=weissg@vienna.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.