All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@cyclades.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Brownell <david-b@pacbell.net>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] Fix USB suspend/resume crasher
Date: Wed, 23 Nov 2005 14:14:07 +1100	[thread overview]
Message-ID: <1132715647.4707.8.camel@localhost> (raw)
In-Reply-To: <1132715288.26560.262.camel@gaston>

Hi.

On Wed, 2005-11-23 at 14:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
> 
> I haven't fixed UHCI as I don't have any HW to test, though I hope I
> haven't broken it neither. Alan, I would appreciate if you could have a
> look.
> 
> This patch applies on top of the patch that moves the PowerMac specific
> code out of ohci-pci.c to hcd-pci.c where it belongs. This patch isn't
> upstream yet for reasons I don't fully understand (why does USB stuffs
> has such a high latency for going upstream ?), I'm sending it as a reply
> to this email for completeness.
> 
> Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
> I suspect PCs have some more sneaky issues too (they don't frankly crash
> with machine checks because x86 tend to silently swallow PCI errors but
> that won't last afaik, at least PCI Express will blow up in those
> situations, but the USB code may still misbehave).

Sounds great. Maybe I'll finally be able to change my first question to
people with suspend problems from: "Do you have USB built as modules and
unloaded while suspending."

Regards,

Nigel

WARNING: multiple messages have this Message-ID (diff)
From: Nigel Cunningham <ncunningham@cyclades.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Brownell <david-b@pacbell.net>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] Fix USB suspend/resume crasher
Date: Wed, 23 Nov 2005 14:14:07 +1100	[thread overview]
Message-ID: <1132715647.4707.8.camel@localhost> (raw)
In-Reply-To: <1132715288.26560.262.camel@gaston>

Hi.

On Wed, 2005-11-23 at 14:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
> 
> I haven't fixed UHCI as I don't have any HW to test, though I hope I
> haven't broken it neither. Alan, I would appreciate if you could have a
> look.
> 
> This patch applies on top of the patch that moves the PowerMac specific
> code out of ohci-pci.c to hcd-pci.c where it belongs. This patch isn't
> upstream yet for reasons I don't fully understand (why does USB stuffs
> has such a high latency for going upstream ?), I'm sending it as a reply
> to this email for completeness.
> 
> Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
> I suspect PCs have some more sneaky issues too (they don't frankly crash
> with machine checks because x86 tend to silently swallow PCI errors but
> that won't last afaik, at least PCI Express will blow up in those
> situations, but the USB code may still misbehave).

Sounds great. Maybe I'll finally be able to change my first question to
people with suspend problems from: "Do you have USB built as modules and
unloaded while suspending."

Regards,

Nigel


  parent reply	other threads:[~2005-11-23  4:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-23  3:08 [PATCH] Fix USB suspend/resume crasher Benjamin Herrenschmidt
2005-11-23  3:08 ` Benjamin Herrenschmidt
2005-11-23  3:09 ` Benjamin Herrenschmidt
2005-11-23  3:09   ` Benjamin Herrenschmidt
2005-11-23  3:14 ` Nigel Cunningham [this message]
2005-11-23  3:14   ` Nigel Cunningham
2005-11-23  5:13   ` Benjamin Herrenschmidt
2005-11-23  5:13     ` Benjamin Herrenschmidt
2005-11-23 17:10 ` Greg KH
2005-11-23 17:10   ` Greg KH
2005-11-23 18:58   ` David Brownell
2005-11-23 18:58     ` David Brownell
2005-11-24  0:22 ` Rafael J. Wysocki
2005-11-24  0:22   ` Rafael J. Wysocki
2005-11-24  0:29   ` sysfs question JaniD++
2005-11-24  1:23   ` [PATCH] Fix USB suspend/resume crasher Benjamin Herrenschmidt
2005-11-24  1:23     ` Benjamin Herrenschmidt
2005-11-24 20:50     ` Rafael J. Wysocki
2005-11-24 20:50       ` Rafael J. Wysocki
2005-11-24 21:01       ` Benjamin Herrenschmidt
2005-11-24 21:01         ` Benjamin Herrenschmidt
2005-11-24 21:14         ` Rafael J. Wysocki
2005-11-24 21:14           ` Rafael J. Wysocki
2005-11-24 21:22           ` Benjamin Herrenschmidt
2005-11-24 21:22             ` Benjamin Herrenschmidt
2005-11-24 16:52 ` Arkadiusz Miskiewicz

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=1132715647.4707.8.camel@localhost \
    --to=ncunningham@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=stern@rowland.harvard.edu \
    /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.